Don’t Hire Debuggers
Debugging is a valuable skill. Knowing your way around the debugger, building monitoring and administrative infrastructure to deal with errors in production, getting good at finding your way in a messy codebase are all useful. However let us not forget bugging precedes debugging.
Heroic cowboy coders write code fast and furiously. They will give 110%™ and do whatever it takes™. Because investor gods must be pleased and future of the startup depends on it. And how dare anyone question the reality bubble? In this period of industrious code accumulation, it is okay to cut a few corners. In fact it is encouraged. There will be plenty of time and resources to fix it later, right? These cowboys create messes so beyond redemption, cutting corners doesn’t even begin to describe.
Cowboy coders at work
Enter the debugger. Debugger is not to be confused with the healer. Healer’s job is to refactor code, implement sane procedures and generally breathe life back into the project. Debugger fights fires and comes up with more hacks to solve the issues previous hack created. Well, debugger will mostly be fighting fires. Not because it is repeatable, piling hacks on top of more hacks is also conveniently repeatable. It is because in an environment where the causes of a constant state of emergeny are not questioned, fire fighters are seen as the most valuable assets[1].
Originally I had a different idea for this post. I was going to write about the how. Clean design, TDD, separating essential and accidental complexity, on a lower level of abstraction executing the side effects separately and keeping the business logic pure, etc. Then I realized it is ultimately a matter of self control. Without getting too philosophical about things; debuggers are after instant gratification, healers aim for the delayed, but bigger prize. For example those who had not made the hard choice to build self control will simply not follow the three rules of TDD.
Chaos & Order
Most people make a weak attempt to have a less chaotic environment. Some people, mostly sociopaths, thrive in chaos and ambiguity. Fewer people strife for order, possibly because their need is greater. This disposition, as far as I can tell, is more of an innate trait than something that can be trained for. Unlike self control, there is no objective and non-contextual way to decide between chaos-seeking and order-seeking. Order-seeking is preferable when a cooperative strategy is followed. In other words, if your team is not moving towards more order, its effectiveness will suffer and you will find yourself debugging more. Software development is not a solo act[2].
If you have built your team from cowboys and debuggers, I have good news; they will continue to be valuable assets. Cowboys can rapidly convert buzzwords into product looking prototypes, while debuggers can keep patching their holes to preserve the apperance of delivering something of value.
The title says don’t hire debuggers, but what I really mean to say is you should be asking yourself some serious fundamental questions if you are looking to hire debuggers. If you are in a team where constant emergency is the norm, I wish you the best and I hope you can remove yourself from that environment as soon as possible.
| [1] | By the way, as portrayed in this post, healer is a unicorn. Sane people do not normally seek insanity. |
| [2] | Unless you are writing something exclusively for your own use. |
If you have any questions, suggestions or corrections feel free to drop me a line.