Fast and Good

This is bullshit, but it’s popular bullshit, because it’s both funny and it makes programmers feel better about themselves.

When I first learned to write code someone hammered it into my head that I should format my code neatly. Consistent indenting, sensible use of whitespace, consistent placement of brackets, all that stuff. Before long, it had become second nature. I can’t write code and not format it neatly anymore; even if I’m typing in Notepad I’ll maintain indent discipline without even thinking about it. The time it takes me to do this is negligible, and when I’m working in my home editor it’s nonexistent. On the other hand, the time I’ve saved from from never being misled by poor formatting – a second or two here and there, compounded over thousands of hours – is immense. Good code made me faster.

Over the years, I expanded my pursuit of good code to higher and higher levels of abstraction. I learned how to split my code into modules as it grew larger. I learned how to name variables meaningfully. I learned to encapsulate knowledge inside of objects. I learned how to make those objects talk to each other with minimal coupling. I learned how to give my methods a consistent narrative structure. I learned how to write tests first so that I wasted less time over-engineering the code beforehand and fixing bugs after the fact.

I started to learn broad rules of thumb about software architecture that hold regardless of the domain. I learned to identify choices that would lock me in to a particular path, and choices that would make adjustment easy as requirements changed. I learned how to choose a language and a framework that suited the job at hand. I learned to tell if a framework was too old to provide the needed flexibility, or to young to provide the needed stability, for the project I was undertaking. I learned that sometimes, the perfect framework is still the wrong choice if there is an off-the-shelf product which will do the same job. I learned how to manage a team’s work in ways that would embrace change rather than being tripped up by it.

None of these lessons came free. I made mistakes, and I still make mistakes. But each time I learned, and I internalized the lessons as mental guidelines. The choices which were once time-wasting head-scratchers became second nature. Good became fast.

I’m not special. Any developer who cares about his or her craft does the same thing. At each level of abstraction they learn new guidelines, until they are able to intuitively make good decisions the majority of the time. And then they move on to internalize lessons about the next level up.

There’s an old saying in the software industry (as well as many others, I’m sure): “Good, Fast, or Cheap: pick two”. You’ve probably noticed I’ve only been talking about fast and good. And it’s true, that at this point in my career, I don’t come especially cheap. But I’ve found that there are plenty of clients and employers who understand that in the long run, good and fast are usually cheaper in the long run. Especially when the alternative, in the words of the comic, is to “throw it out and start all over” a few times.

EDIT: A point I left out —

The effect of quality on speed is cast into stark relief once there is more than one programmer on a project. You may find that at your current level of expertise, you can go 10%-20% faster if you take certain shortcuts. But once you add new members to the team who have to work on that code, any time you saved will be dwarfed by the 100%-500% speed reduction incurred by the others trying to understand your bad code. Of course, this is an excellent job security strategy since you can then point to the floundering n00bs as evidence that you are the only developer smart enough to get stuff done.

1 comment

Comments are closed.