Why are coders bad customers? First, let me say that even though coder-customers are a hard group to work with, they usually have really interesting problems to solve. After all, if it was simple they’d usually do it themselves. But, being coders, they think it’s acceptable to tell you how to do your job.

When you work with coders, the usual ticket/email/water-cooler chat will be of the form “you need to add an option for specifying X of type Y instead of the current options”. At this point they’ll usually start telling you how to implement that and how easy it is. If you’re like me, at this point your instinct will be to crank out the code and make your customer happy. Resist that urge like the plague!

Whenever I receive such a ticket, I dismiss everything in it. What I do next is come up to whoever suggested it, and ask “What is it that you’re trying to do?” Usually, this will result in exactly the same technical do-this-and-that explanation. Take a deep breath and ask the question again. This will usually be enough, but sometimes may require a couple more tries. That’s how you’re supposed to gather requirements – understand the problem at hand.

The main advantage of being a pain-in-the-ass and making sure you understand what it is you’re supposed to implement is because every coder should know exactly what his code is doing. A lot has been said about understanding the domain you’re working in, and simply implementing things handed to you is not the way to become knowledgeable in your domain.

Furthermore, once you hear what people are trying to do you might think of a better way of doing it, you being fully immersed in the existing code. Actually, more often than not you’ll see it’s actually already possible to do it! And best of all, you might simply decide that’s not a fair use of your code, and reject the ticket. How could you have made such a decision without knowing the actual problem you were asked to solve? No way.

Saying “no” to features is one of the most important design skills to master, and a tricky one. After all, turning to your keyboard, hacking the code and saying “presto!” is more fun at first. But that way of working leads to a code-base that you don’t really know. I’ve seen systems that were driven this way by technical users. 3 years later, there were rogue database fields that no one knew why there were being updated, and weird log files in awkward formats. Whenever someone tried removing one of those he found out it broke some dusty cron-job that seemed to use it instead of doing something sane (and do I really need to mention the code was a tangled, convoluted mess?).

Ask why, mindfully consider and then decide. There’s no really other way, unless you’d like to meet Code Cthulhu.

You should follow me on twitter.

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.

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!