Background

As a consultant, I’ve rolled onto many projects. You get one chance to introduce yourself, and the way I like to introduce myself when I get the chance is “I care about these things in this order. 1) I care that it works. 2) I care that it is tested. 3) I care that it is pretty.”

Introductions

There are all types of computer programmers out there, and most programmers of any experience have worked with developers that maybe don’t have their priorities in order. Or there is an excess of negativity. Maybe there is too much focus on particular aspects of the software design. So whenever you see that a new programmer will be joining your team it’s natural to wonder, “What kind of programmer will this be?”

Or specifically, “Will this programmer criticize my code?”. The answer to that question is yes. As part of the process of reading code, I’m naturally going to form opinions about it, every programmer will. Those criticisms might be the collective negative tradeoffs as I see them for the programming choices that have been made. Those tradeoffs exist for all the code that anyone has ever written. So yes, I have opinions on the choices that have been made for the code that has been written.

Now, how to express those opinions is an area where I’ve grown. I’ve had to grow, because in the past I’ve used harsh words to criticize code. Harsh words may gain attention but they are typically counterproductive. Harsh words do not engender trust. When I’m introducing myself, I want to reassure my new collaborators that I’m reading code with the right priorities and intentions, and always that 1st priority is: Does it work. If it works it is good.

Any programmer that has tried to maintain someone else’s code know that “Does it work” is not the only thing that matters. What matters next is: Is it tested. If it is tested, I have a much higher chance of understanding and changing the code successfully than I would if it was not tested. Tests give the confidence that I can change the code in a number of different ways to satisfy whatever new requirements I have been given.

Does it work, is it tested, then great! But we all know that there’s another level. And this level encompasses the entire art of programming. This is where things get murky and subjective. My first two priorities are fairly objective, which aids there efficacy. This 3rd priority is where the twin demons of readability and maintainability fire vitriol into our hearts. The choices that we make to serve these masters have long lasting impact on how the software changes over time and how expensive it is to change. This is where we shake our fists at the sky due to a choice made 5 years ago that prevents us from making simple changes. This is where our heart rate accelerates with the physical reactions our human bodies go through when handed challenging circumstances. As programmers, we get emotional here and those emotions drive responses that could bury the tenuous beginnings of new collaborations.

And so… It is important to remember that working, tested code is good code. I care about these two things more than all the subjective choices made in circumstances that are soon forgotten. I will assume that everyone did the best job they could and I will not turn opinions into judgements. My unspoken number one priority is a great working relationship with those around me and that is why it is important to me that I communicate my software priorities when we are introduced.