Aren’t you sick of wasting your time, your team’s time and precious build cycles for finding the stupidest mistakes ever? I know I’m far more interested in solving the real problems at hand than chasing stupid syntax errors. And even if you don’t mind, you really shouldn’t let your teammates substitute for a decent tool.

Up until 15 years ago, I think it was very common for people to hack away at code for a good length of time, and once they got enough done, they’d try and compile the damn thing and start correcting the syntax errors, import things they forgot to, etc. This probably was because 15 years ago is the middle ages in computer-land, and compiling constantly was something people couldn’t even dream about on the little PCs we used to code on.

Nowadays, you can’t find more than a handful of static-language coders that won’t use a full featured IDE. C, Java, C# – other than a few freaky kernel hackers, I doubt anyone does real development outside an IDE in those languages. Today’s IDEs will tell you that you made a mistake about 2 seconds before you did. I never stop being amazed at how smart Eclipse is – and the first time I had to whip up some Java code in Vim, I felt handicapped.

What I find puzzling, is that people that are using the best available languages today, have suddenly decided that using the proper tool isn’t that important. Dynamic languages like Python and Ruby are not as easy to write awesome IDEs for, and therefore there aren’t many around that are mature enough, which is why it’s very common to see people use Emacs/Vim for coding them. Now don’t get me wrong, I’ve tried a few Python IDEs, but I’m still sticking with my Emacs. But when you use dynamic languages, you have to keep in mind you are even more prone of errors that will slip by. Even if you TDD, and your test coverage is extremely high, a typo might still get past your tests. Do you really want a production failure because you forgot to import an exception? (And do you really want to upset Agnes?)

About 2 weeks into my decision to stick with Emacs I started searching for simple tools that will protect me from my stupidity. It takes 10 minutes to find and install flymake with pyflakes (Python tool) support. Presto! No more typos in variable names, no more useless imports lying around. What surprised me is that a lot of my teammates, which I have respect for and are good programmers, did not use any of these. Time and time again our continuous integration system will report an error on a file and once I opened the file Emacs would show me the bad line marked with red, with no way of not noticing it.

I don’t like wasting my time, and I’m sure you don’t either. Stop being lazy (in the bad way). Stop making me angry. Get out of the middle ages. Yesterday we got everyone on my team to add pyflakes to their vim. Took 3 minutes to install. The problem is that it took more time to get them to install. “Nah, Vim already highlights syntax, there’s no need for more”. Oh really? After 10 minutes of searching I found a file that pyflakes showed a real problem in, and another, and another. “Hmmm, where do I download that plugin?” Win!

Do yourself, your team and your build slaves a favor, and start using some modern tools. I promise it will be worth it, money-back-guarantee. And remember, if your team is still churning butter, sometimes all it takes is a little push (and sometimes you can plant bugs in their files).

You should follow me on twitter.

As coders, we should always strive to get as much feedback as soon as possible. Agile tells us we should get frequent feedback from our customers in order to make sure we’re always on track. Unit testing and the green-bar loving are all about knowing exactly when your code breaks and when you’re safe.

A kind of activity for which feedback is harder to get is our design. A big part of TDD is refactoring frequently. Refactoring often allows us to smooth out the design continuously as we work. The problem is, how can you tell you’ve done something good? On the one hand, creating abstractions is something good programmers do. On the other hand, taking that too far will usually cause more problems.

When making bigger changes, the best feedback will be from getting another pair of eyeballs go over the change. Pairing is the best way for getting a second opinion. Code reviews can be effective too. Problem is, a lot of people don’t get to pair or review most of their code (and yeah, I know that makes Corey Haines a sad panda).

When I work by myself about the bigger things, there’s a handful of things I try to keep in mind, like the SOLID principles. But, the measure I like the most of how much shorter am I making the code. I’m not talking about obfuscating code. Readability is a must. I’m talking about abstractions that are really useful right now – they already make the code base smaller. Refactorings that make the code DRY and thus shorter.

Whenever I commit and git tells me I deleted more code than I inserted I get this fuzzy warm feeling. One of the agile manifesto principles says “Simplicity – the art of maximizing the amount of work not done – is essential”. Problem is I’m not a perfect coder, and because of that I often perform more work than necessary. But I try to simplify my code when I notice this.

Paul Graham has an essay where he once showed a way for him to know he’s making good progress with Arc, the language he created. He kept track of the number of lines it took him to implement an application (Hacker News) and whenever he made some changes he checked to see if they made the application simpler.

Of course, as any rule, this one has exceptions. Eventually, you will need to add code! But, it always helps me see that what I thought was really good just adds clutter. Try and take a look at the output of git log --shortstat – do you tend to add more lines whenever you clean up?

You should follow me on twitter!

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 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.

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.

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.

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.

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.

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.

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).

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.