This week marks the completion of my tenth year at Turbulent as a software programmer. It also marks the completion of my tenth year as a software programmer, period. Time to reflect on that period a bit.
When I first started at Turbulent, I had no prior professional experience as a programmer, other than a brief three months intership at enGenuity Technologies (it does not exist anymore). I had never done any kind of web development, and I didn’t even know the difference between a backend and a frontend developer. I just wanted to program.
Very quickly my boss (who was, and still is, the CTO of the company) identified me as a backend developer. After a few small projects he gave me a monumental task for a junior dev: generalize the PHP code that we kept copy-pasting between projects and package it into a re-usable web framework/CMS. This was in 2008, before PHP even had a proper package/dependency manager, and back when SVN was still the de-facto revision control system.
I didn’t realize it at the time, but the complexity and importance of that mandate was a testament to his level of confidence in my abilities. In the end, I managed to do it, and he humorously baptised the project Heap.
Fast forward three years later, and after some lobbying I am given the green light to rewrite Heap into a more modular framework and CMS. We simply named it Heap 2. The fact that we are still using it today on all our projects is an immense source of pride for me.
A lesson learned along the way: You never know which projects are going to last, and which ones are going to die a quick death. Case in point: the very first project I worked on, Cinéma Québécois, is still online even though it was just a website attached to a TV show that’s not even on the air anymore. On the other hand, the official tourism website of the Lanaudiere region that I made in 2010 was quickly replaced because the client decided to switch contractors.
Now it’s 2018, and I am leading the dev team and all internal software projects. If you had asked me last year what I thought of my current trajectory as a software developer, I would have told you that I had pretty much tapped out web development and that I probably needed to move on to another field in order to progress further. What a load of bull! It turns out that I hadn’t even started being a real programmer yet.
I had an epiphany this year. We started watching the excellent Clean Code video series at work, and in one of these videos Robert C. Martin makes an excellent argument in favour of Test-Driven Development. I decided to try it out on a new project, and what a revelation! I really feel like this was the missing link in my career.
Allow me to explain. Even though I always considered myself a good programmer, I was always perplexed about the code rot in my projects, even those that were considered successful by the company. As the project grew larger in size and scope, my level of confidence in its ability to deliver value was always falling. This happened on every project, even Heap, the project on which I have written the cleanest code.
The reason, of course, is that code rot is unavoidable. The software you write usually ends up being used far longer than what you first anticipate. In order to maximize the longevity of the software I write, I have always followed these two golden rules whenever possible:
- Crime (bad code) doesn’t pay. Always write clean code. ALWAYS. There is no excuse.
- Prioritize flexibility and ease of change over fulfilling all requirements up front.
In practice of course, the longer the project lasts, the harder it becomes to follow these rules. How ironic! Turns out, the only way to ensure that these rules are always followed, from the start of the project to the very end, is to do Test-Driven Development. It’s hard, it really is. But it’s the only way to achieve the discipline described by the two rules above.
And it took me ten years to realize it. Now I feel like I’m starting my career for real.