The Code Dump

A place a coder rants at…

The Code Dump header image 1

A Week in Nowhere for Better Code?

January 14th, 2010 · Uncategorized

I finished my army service (in the Israel Defence Force) 6 months ago. Before anyone gets carried away, let me assure you my service had no Rambo-like scenes involved, but simply required me to do what I always do – code.

But, it being an army and everything, everyone is required to do some “army” stuff every once in a while. One of those is at the heart of this post. About once a year, you’d get positioned in some far, remote and tiny base/settlement. During those weeks you are required to guard different posts, or patrol around the perimiter of the area.

Let me paint you the picture a little clearer. How would you like having to leave your life, in order to spend a week (or two) in a place that can be only regarded as ‘nowhere’, and spend 10 hours a day doing nothing but looking at some desert mountains? Now, imagine you know no one of the other few that are with you, the room is a dump, and you don’t even want to hear about the showers? Oh, it gets better. At night the temprature can drop so much, that checking your weapon before going to sleep is just painful, and requires you to jiggle your fingers for 5 minutes before you get enough dexterity to actually do it?

The view from nowhere

The view from nowhere

The real deal, though, is that I find myself missing those weeks, a bit at least. Why would a geek think about a week with no keyboard, and actually just about zero contact with the outside world given that cell reception is scarse, and miss it? Well, that’s just the point!

First of all, as any good geek, I stack a lot of books on my To Read List. Those weeks were where I did my most productive reading. I averaged a book a day, which required me to get an extra bag just for those. Can a week be really bad if you go to read all of The Hitchhiker’s Guide to the Galaxy series, The Return of the King and more?

But that’s just a bonus, I read a lot either way. The main thing is that you just get time off that you don’t consider to be your free time / vacation. I’ll explain. When you use your few vacation days, you use them wisely. You take your spouse abroad and enjoy the world’s wonders. Any part of a day off I just lay around feels like a waste to me, which doesn’t let me just use the days off to relax.

The problem is, that coders need time to zoom-out sometimes, in order to get new ideas. It was said before that if you’re stuck with a problem, you might get the insight by simply leaving your desk for a few minutes. But those insights are short-sighted. As you sling code, week after week, you get coder’s myopia. Every time I was sent away, I came back with a few ideas to make things better, or do things in a more productive way. It’s just amazing how simply stepping back for a week can help you realize problems you haven’t been able to grasp for months.

Now, unsurprisingly, the vacation days you use never seem to have the same effect. Don’t get me wrong, I’m not suggesting you find your solitude in some desert with no cell reception (unless that’s your cup of tea). I think employers will gain by making sure they’re employees have 4 weeks of vacation a year, so that spending 2 days playing video games won’t feel like a waste. I think sending teams together on a trip for a few days won’t be as good as sending them to a conference where they will see new people and new opinions and ideas. The key here is not just the change of scenery, but also simply experiencing something different.

Try to find a chance to zoom out and unwind, I bet it will do good to you and your team.

You should follow me on twitter.

→ 1 CommentTags:

Every Coder Should Read TDD By Example

January 12th, 2010 · Programming

I’ve just finished reading Kent Beck’s TDD by Example, and man, what a great reading that was. It was so good, I’m gonna put it in my top 10 books list (accompanied by other classics, like The Pragmatic Programmer and Beck’s probably most known book, Extreme Programming Explained).

I’ve been doing TDD (to an extent, say at least half of my production code) for the past 4 years or so. I was pretty sure I knew what the deal is, and there’s no doubt it’s paying off. I didn’t think there’s a lot more for me to learn. I thought to myself, “how much better can it get?”

Lately, a lot of anti-TDD posts have been popping up on the interweb, which made me ponder a bit more about it. Furthermore, I’ve been exposed to more casts and the likes regarding TDD that made me think I just might be able to squeeze some more fun from my TDD.

That’s when I realized my work place has a copy of the “TDD by Example” book. I’m a sucker for books, and having liked Kent’s writing so far, decided to add it to my book queue, and actually pushed it all the way to the top.

It’s a very light and fun reading. The style is a lot to my taste, and easy to follow (even for someone whose mother tongue isn’t English). But other than the pure writing style, there are just so many gold nuggets in that book. Just about every page has something golden.

Most coders will never have access to such a super-star-coder, that literally changed the way we work. This book is a great way to rub off some of that genius. The simplicity in which design decisions are explained is astonishing. I myself typed along all the code in the book as I read it. Sometimes I tried writing ahead, comparing my results to Kent’s, and every time I was surprised. The cleanliness he shows, the delicate thinking, truly amazing stuff.

Other than that, given all the critisicm that’s been direct at TDD lately, the book explains in great detail what are TDD’s objectives, how it can be used productively, and what should you expect of it.

And now, the really good stuff. The major pay-off I’m seeing currently, is that I found out a few ways to make TDD even better for me. Yes, the bug count is already low, but you can get it even lower. Not just that, picking up a few tips from Beck makes me think about the design of my code better, and simply make you a better coder.

Actually, most of my TDD ”education” is informal. Someone once explained the concept to me, and with time I refined my ways a bit using experience gained and knowledge found on the web. Reading the book on TDD, you find there are names for things you’ve already been doing, but never given much thought to. Moreover, there’s just that thing about naming things – sometimes it simply makes you understand them better.

I think I’ll stop writing any further, before this will make me look like I’m stalking Beck. But really, you should read this book. It’s so good, I’m going to order my own copy simply to have it around. Yes, that good.

You should follow me on twitter here.

→ No CommentsTags:

Trying to Find Coder’s Heaven

November 19th, 2009 · Programming

I read a post today by Kent Beck:

The prices for programming have fallen so far that just programming for someone isn’t going to meet my financial goals (4 kids to get through college). For my own satisfaction I need to program but to meet my goals I need to do something more than “just” programming.

This one really surprised me. Beck is a pioneer, someone that’s made a difference in the way software development is done today. I remember reading “Extreme Programming Explained” a few years ago and thinking to myself “This guy is a genius!” It’s not just XP itself, he wasn’t the only one to talk about agile. Someone capable of communicating in such a clear, concise way that knows how to code practically has to be a rock star hacker.

Maybe I was being naive, but I always liked thinking that if you’re just really good at programming, you’ll be able to land one of those dream jobs at a small software shop that pays good and spend the rest of your days happily hacking at your keyboard. And that’s if you’re a “regular” great coder. I thought people like Beck will likely get a good CTO/Guru job somewhere, make sure great code that customers love gets out and earn enough money to not have to worry too much about it. Or maybe be at a conference a week, giving inspiring talks and getting paid to do it great.

This relates to something I’ve been thinking a lot about lately. I’ve been thinking what is the best path to choose for my road ahead. At one point you notice that you keep telling to yourself that if you were running the business, X would have been done differently. You know, the usual ‘my company would give 2 monitors to each developer’, or ‘I’d never hire someone that only seems good enough‘, or ‘coders should be able to choose and get the best books around to read’. This, of course, doesn’t mean my current employer isn’t good, or that I don’t enjoy myself. I guess I’m one of those guys that notice things that bug them more than others.

Anyway, as these things stack up, a question is raised, “Why not start my own thing?” After all, my end goal isn’t that far-fetched. I’ve been reading “Founders at Work” lately. One of the best chapters there (though the whole book is awesome), is the one with Philip Greenspun, founder of ArsDigita. He describes his vision as simply getting brilliant people to write awesome software that customers love – the money should simply follow. This is an interesting business model, one that Joel Spolsky talks about in his chapter in the book too. He and his cofounder wanted to create a place great programmers will want to work at, assuming such a place will then be able to make money by creating great software.

On the one hand, we’ve got ArsDigita, that did really well before biting the dust (though I doubt Greenspun is sorry he did it). On the other hand, there’s Fog Creek that seems to be doing pretty well for about 10 years now. This means that creating such a place is possible, as Joel has done, but if ArsDigita is dead, and Kent Beck isn’t in such a company right now, one has to wonder if simply being really good is enough.

Joel said that he intended Fog Creek to start as a consulting company in order to get the capital for becoming an awesome software company, and that consulting companies are not likely to survive a lot of time, as consultants are usually first to go when a client isn’t making ends meet. I can’t help but agree with that.

What is a coder to do? Sounds like starting your own place, and aiming at being best at what you do is a good idea and vision. Creating a software company that will either get bought somewhere along the road, or simply be profitable enough for you and your team of awesome hackers to code away happily will be like a dream come true. But there seems to be something missing there. That special ingredient that Fog Creek had and others didn’t.

My quest for that missing part continues, until I’ll be able to start the best f***ing place for a hacker be at in Israel. And my best wishes to Kent Beck in finding the missing part to get to do what he loves doing, and does real good.

You should follow me on twitter here.

→ 4 CommentsTags:

Becoming a Happier Hacker: Actively Strive to Work with Other Hackers

October 17th, 2009 · Uncategorized

After a few years of working in the field, I’ve come to a conclusion: one of the best ways to evolve as a hacker is to work with other hackers. Not just that, I’d rather work alone than work with non-hackers. Wait, I can almost see you reaching to close this tab, mumbling to yourself this is nonsense. I’m not saying workplaces shouldn’t hire junior developers .I’m saying that working with people that don’t have Hacker Quality™ is frustrating.

In my previous work place, about 90% of developers were ‘home brewed’. That means 90% of developers are kids that performed well enough on analytical exams to be put to a 4-month course and study basic programming concepts, and just enough Java to become certified code monkeys. Some, those with hacker quality, keep learning and become real stars after a couple of years. The majority remain grunts that never grow to consider their work as a craft.

My experience with working with them is that the hackers make working so much more fun. You’ve got people to bounce ideas off, learn new things from, debate about tabs and spaces. The rest make work a nightmare, and made me want to get back to my high-school way of coding (all night long, alone in the dark, with some Iron Maiden).

Being fed up with this, when I started working in a new place recently, I made a decision to try and surround myself with fellow hackers. First of all, you should start with the actual selection of a work place. Given my case (which was that I wasn’t going to start anything up by myself), I interviewed in lots of places, and chose the place that seemed to have the best and most hackers in, judging from the people I’ve interacted with in the interview process, and knowing some people from the company.

Just getting to a good work place isn’t enough, because I’ve yet to hear about a place that is 100% hacker driven (other than start ups with 5 people). You should always try and work with the better guys around. Seems like interesting projects tend to gravitate towards hackers, wherever they are. Even if the better guys aren’t working with you on your current project, grab a coffee with them. Some chatting on whatever is going on with other hackers always makes you see things differently.

Given that you usually can’t get rid of the less-competent guys (legally), your only next chance in increasing Hacker-to-Coder ratio is bringing in more hackers. If you know of any good hackers that might be in search of a job, get them an interview. Usually, that’s all it will take to get them in. Also, try and take an active part in the interviewing process. That will allow you to influence the type of people that you’ll work with, and maybe raise the bar a little bit.

I really think that investing energy in the peopleware of the workplace accounts for 80% of the evolving of coders there. And, given that we coders rarely see daylight and spend most of the time at work, that’s the lion’s share of learning opportunities you’ll have. Maybe it sounds odd to put all this effort in a place that isn’t yours, but does it really matter who’s the founder? You’re there, and better make the best of the experience.

All that leaves in the workplace is making sure your team encourages learning, experimenting and sharing (maybe I’ll cover it in another post sometime).

You should follow me on twitter here.

→ 1 CommentTags:

Writing a BuildBot Latent Build Slave

October 4th, 2009 · Programming, Uncategorized

We’ve been working on creating a scalable and stable building and testing environment for our team.
After some checking, BuildBot was found to be the best (for our needs, at least).

Gathering the different abilities that are needed for testing our products, and the different limitations we’ve got in our testing lab, we came to the conclusion that using some sort of distribution framework is needed. Being the code monkeys that we are, we started designing a whole solution for integrating BuildBot with our distribution framework of choice, when looking at the BuildBot manual I saw it already has support for this concept, the Latent Buildslave !

One small thing is, that adding support for a new one isn’t so clear. The manual simply states that one needs just to implement start_instance and stop_instance methods and be done with it, but, in my opinion, lacks some details, so here is what we figured:

  1. The start_instance method should return a deferred that, when called, will return once a new build slave is ready to go.
  2. How do you return the new slave’s IP to BuildBot? No need! Once it will be connected, the master will figure it’s the one you just created (via AbstractLatentBuildSlave.attached).
  3. The actual value returned from start_instance is pretty insignificant (will be printed to the log, as the manual states).
  4. The stop_instance method is pretty much the same, and should take care of making the distribution framework aware that the allocated buildslave is free to be destroyed/reused.

Why don’t my latent slaves die?

As you may have noticed, once start_instance is called and a slave connects to the master, BuildBot is in no hurry to call your stop_instance once the build is completed. Actually, as far as BuildBot is concerned, that slave is there to stay (at least, as far as we figured). In case you’d rather to generate a new slave for each build, you will need to override the buildFinished method of the abstract slave, and in it call the unsubstantiate method. A bit of a headache, but that’s the way it is.

Happy testing!

P.S. If you’re using the latest BuildBot (from the git repository), try out the Console view, it’s really awesome!

You should follow me on twitter here.

→ No CommentsTags:

Bash Nitpicking on Redirections

August 12th, 2009 · Uncategorized

This little excerpt from the bash man page explains the reason I just wasted 2 hours:

Note that the order of redirections is significant.  For example, the command
ls > dirlist 2>&1
directs both standard output and standard error to the file dirlist, while the command
ls 2>&1 > dirlist
directs only the standard output to file dirlist, because the standard error was duplicated as standard output before the standard output was redirected to dirlist.

→ No CommentsTags:

Fixing Equations in Word Documents Converted from OpenOffice

June 28th, 2009 · Uncategorized

This is a short tip post. If you were ever frustrated with the fact that OpenOffice documents with equations don’t show up properly when converted to MS-Word documents you’re gonna love this!

It’s a known problem that converted equations need to be “double clicked” in Word for it to re-render them and show up properly. Turns out someone has posted a great macro here that simply does that automatically for you and saves the need to go through the whole document manually (if you don’t remember how to set up a macro, like me, there are nice instructions here).

→ No CommentsTags:

So You Got an Arduino

May 14th, 2009 · Uncategorized

After playing around a bit with my new Arduino, I’ve gathered a list of a few things that I wish I knew when I started, as it would have saved some of my time. Hope it helps someone. Happy hacking!

There’s a builtin LED
This one I didn’t get right away. There’s a reason most of the examples in the tutorial sections refer to LEDs on pin 13 – there’s a small LED on the Duemilanove that’s already connected to that pin. It shines in orange (just like the TX/RX LEDs) if you write to that pin, but, of course, one can connect something else to that pin to use it.

That little button is the RESET button
This one might just be me being an idiot. I thought that little push button was a general purpose one. Well it’s not. It’s a reset button – whenever it gets pressed it resets the sketch running to the start. Boy, did I spend a lot of time pressing it and trying to debug my code til I figured it out…

There are builtin “software” pull-up resistors
Once you get you should connect a push-button, you might notice that every tutorial says you should use a pull-up resistor. Well, it turns out you can simply use a software one on the Arduino, and there’s no need to conenct one. After setting up the push-button pin as input:

pinMode(buttonPin, INPUT);

Simply tell the Arduino you need a pull-up resistor connected to it:

digitalWrite(buttonPin, HIGH);

For more information, read here.

The “Serial” library doesn’t really require a serial connection
Even though Duemilanoves and other new Arduino-boards only have a USB connection, it turns out that the Serial library can still be used. Whatever you write using it shows up in the Serial Monitor in the development IDE and you can send data to the Arduino using it too!

You should follow me on twitter here.

→ 2 CommentsTags:

My “Hello, Arduino”

May 14th, 2009 · Uncategorized

I ordered an Arduino Duemilanove a few months ago, and other than simply testing it to see that it starts up I haven’t touched it. It’s been lying on my desk, making me feel guilty every time I saw it.

Today, having a few spare hours and because I just finished reading “Programming Embedded Systems”, I decided it was time to finally do something with it.

I spent ~3 hours soldering the Proto-Shield that came with it. It was the first time I ever did any soldering and I think it turned out OK, after some help from Dad.

Then, I made a simple ‘Hello, World’ application that changes LEDs according to a button press. What can I say, the amount of satisfaction from such a simple thing is so big! Maybe, it has to do with the fact that as a software developer, I rarely do things that have a physical effect.


Original Video – More videos at TinyPic

You should follow me on twitter here.

→ No CommentsTags:

Sometimes all it takes is a little push

April 4th, 2009 · Programming

Soon, I will be leaving my workplace for the past 3.5+ years, and that has got me to do some retrospective. One thing I’ve been reflecting on is how good programmers seem to move towards better programming/working habits that are shown to them and how easy it can be sometimes to make a difference.

On August, I moved to a new team. At the time, the team consisted of 3 developers (including myself) and a team leader. Both other developers have joined the project about a year earlier than me, and have been working in the workplace about 2 years more. They are really talented folks, and I’ve learned quite a bit working with them. But when I joined the team, it was in a bit off a “stop”. The team didn’t have that feeling of self-propelling inertia.

I knew that they used to do scrum in order to manage tasks and work, but that had stopped for some reason, and in my first weeks there I noticed how task management was at fault – sending emails to one-another, with things getting lost between mail-clients and no real way to tell where we are currently standing.

After about 3 weeks in the team I showed the guys a few links of agile teams and their cool whiteboards, filled with tasks and burndown charts. They immediately liked it and said that “it does look cool”. A few days later I brought some stacks of post-it notes and we spent an hour deciding how to partition the board and a simple convention for the post-it notes and actually drawing it on a board with permanent markers. We used an ugly picture-frame (with the picture inside flipped, so the white side was facing the glass) to draw a burndown chart on.

It was an immediate success – every time someone walked in we all enjoyed explaining how the board works. Moving a task to done was usually followed by a bit of celebration and everyone could see what was going on easily. Now, 7 months later, we plan our sprints, have daily scrums and continue to get better at planning and being more agile.

What I’m trying to say is, I guess, that sometimes all it takes is just a little push in the right direction to start something good going on. It may take some balls or reading some Dale Carnegie, but it’s worth it!

→ 1 CommentTags: