So let’s take a closer look at this quote from Michael Sinz. What does it actually mean? Why do we have to support mistakes for the rest of our lives or at least a very long time?
Looking at my own experiences it all has to do with the programmer himself.
When I was fresh out of college 10 years ago, just started as an intern I wrote code with only one thing in mind. Accomplishing the functionality that was brought to my table within the given deadline. I didn’t care how I wrote my code and I certainly didn’t care if the code was maintainable.
Delivering the functionality on time so that it could be released was my biggest adrenaline rush. It felt like winning a soccer match for the championship!, or that other great feeling 😉
At some point during my first year the company gave me a big project to work on. It was the kind of project that would be extended year after year. And while I was still a novice programmer I got the job done.
But I neglected to see the first signs of pregnancy….
Until I was struck by lightning a few years later. The team got an assignment to extend the project that was developed and maintained by myself for the last couple of years.
We sat down to analyze the existing code to map out our technical options to bring this assignment home. The meeting was off to a good start, but after an hour it became VERY clear to me that the code that I had written was not suitable for incorporating the new functionality. The main reason; I had created a big ball of mud…
The best approach would have been was to refactor all of the code. If we had enough time, money and resources, but sadly we didn’t have that kind of luxury.
I also neglected to write unit tests (or any kind of test for that matter). So every change had to be tested manually with the possibility to inadvertently breaking things that used to work. Furthermore my code was all over the place. Think about no consistent indentation, weird method names, files with over 50.000 loc, methods with over 1.000 loc. You name it I wrote it.
The team and I saw only one solution. Keep the existing bbom code alive and setup a second system, that would inherit some of bbom functionalities in it. Knowing we had to maintain two systems in the future. So basically we had to support it for the rest of our lives…
I felt bad for days, we delivered the functionality on schedule but there was no celebration of any kind. I also kept asking myself; “why did I not see or recognize the bbom?” Or to stay more in context of the quote; “why did I not put on a condom?”
The answer to this question had everything to do with my mindset, experience and skillset. I was a selfish programmer, writing code for me wasn’t a team effort. I was to proud to ask for help and wanted to show off my accomplishments that way I could say; “I wrote that fantastic new functionality!”
Maybe this attitude could be justified if I had the right experience and skillset, but I hadn’t. I had no clue what I was doing.
Basically I had no idea what programming is really about.
So with these new insights I started to read books, articles, fora like a mad man. With only one goal in mind: becoming a better programmer. Think about S.O.L.I.D, design patterns, pair programming (eXtreme), communication skills, refactoring, logic/problem solving etc…
Everything I read I put into practice. Carefully writing down everything that worked and didn’t work for me or the team.
For me everything I learned in the past couple of years can be brought down to one sentence:
“You don’t write code for yourself, you write it for the next person changing it.”
For me this captures everything you need to be as a programmer. Every time I write code and I’m finalizing it I ask myself the following question;
“If I saw this code for the first time would it make sense to me and does it give me the confidence to make changes to it?”
Most of the time I finalize some code and let it sit for one or two days, before pushing it. And in most cases I make some final adjustments in the readability of the code. Just to make it more self explanatory and maintainable. This way mistakes could easily be fixed.
This methodology gives the team and myself enough confidence to alter existing code and try out new techniques. Simply put; it provides us a condom while programming.
So putting this in perspective of the quote I can say: “yes programming is like sex, it is nice and it does feel good, but equip yourself with the right toolkit so you don’t have to support mistakes for the rest of your lives.”