Daniel Irvine on building software
17 February 2015
One of the most important lessons programmers can learn is to slow down.
Slowing down is the opposite lesson to what many programmers learn first: speeding up. But it’s slowing down that produces the best end result. Slow and steady wins the race.
Do you remember that burst of euphoria you felt when you built your first working program? Your brain registered it--hey! that felt gooood--but the euphoria didn’t last long and so you immediately started looking for the next hit. The next problem you could solve, the next feature you could build, the next bug you could squash. Each finished feature is another little rush. And that’s how many of us become, quite simply, addicated to programmming.
When we chase that rush, we learn how to race. We choose tools which make us the most productive. We learn bleeding-edge languages. We read books to help us improve our skills. But this type of rushed coding is suitable for amateurs only. Amateurs don’t write tests, and they certainly don’t clean code. Amateurs write whatever code will get their current feature working, and once its done they move right on to the next one.
When I landed my first full-time job as a developer, I was still very much an amateur. I had never written a test in my life! But that was fine, as neither had many of the seasoned developers who worked there. Fortunately for me, my first role was writing automated tests and I quickly learned the value of testing: our users generated a seemingly never-ending torrent of bugs which cost the company a huge amount of time, money and effort to fix. Being an automated tester meant I was acutely aware of the benefit of well-tested code.
After a year or so of writing tests I realised that slowing down and taking the time to do up-front testing was essential to professional software development.
Soon afterwards I was moved to a new team with a new role: I was now a junior developer, and I found myself with a new boss. I made my first steps with C++, dutifully submitting my code to him for review. He would respond to my submissions via email. A typical email would be page after page after page of corrections. Sometimes these corrections were pointing out large, glaring errors, but more often than not they were tiny, inconsequential corrections like missing space after if keyword on line 26 or poor capitalization on line 78. One recurring correction that always annoyed me was header comment not house style, which meant my function header comments weren’t written in exactly the style dictated by the coding standards: “This function is responsible for...”.
I remember the feeling of frustration--sometimes even rage--that arose within me when I read these emails. It would take me many minutes, perhaps hours, perhaps even days to go through and make every single correction, despite the fact that my feature worked as advertised! I’d tested it! And yet my code wouldn’t be merged into trunk without addressing each one of my mentor’s concerns.
Even though I knew that testing was important, I was still hooked on that euphoric feeling of building working stuff. I was chasing that high. My object-oriented design skills were fine and I knew all about SOLID, but once my tests were passing I was straight on to the next feature. There was no time to reflect. I was pretty careless. I was rushing, and that necessarily meant being sloppy.
At the time, I wondered how my boss ever found the time to write me these long, arduous code review emails. He had clearly spent a lot of time pouring over my code, and I can only assume he also spent a lot of time pouring over his own code too. I was puzzled how, despite all that, he was still the most productive programmer I’d ever met.
He must have been doing something right. So I followed his advice and diligently made the corrections he suggested. As time went on, I learned how to slow down. I hated it at first, but under his guidance I practiced cleaning my code. We never used that term--clean code--but that’s what I was doing. I took the time to stop, really stop, and to do lots of critical thinking.
The code review emails gradually became shorter.
Craftsmanship and cleaning code
It takes discipline to clean code. When your feature is done, you’ve got to put the breaks on and not rush straight into implementing the next feature. Sure, you’ll lose that euphoric rush, because getting something to work is no longer enough to say “done”. But in return for trading in that instant gratification you’ll build up long term happiness in the from of a simple, maintainable code base.