September 13, 2017 // By Paul Grizzaffi
“Why so serious?” That’s one of the more quotable lines by The Joker in the movie The Dark Knight. I find many of us are too serious about the code we develop, at least when it comes to the aspects of changing it, sharing it, and owning it.
I’ve been meaning to blog on this topic for quite some time, but other things kept demoting it on my alleged To-Do list. Not long ago, I was inspired to promote it higher up said list due to a tweet by Trish Katz:
“Don’t tangle your ego up in the code you write. There are always ways to improve it. Getting feedback is a gift.”
She’s got this totally right.
As developers, we need to remember that when we write code, whether for a product or in support of product delivery (such as for testing or DevOps purposes), there are two things we need to remember about that code:
- The code is extremely important
- The code is rather unimportant
I know, I know, let me explain…
The code is important for obvious reasons: if we are delivering a solution to our users, clients, or customers and that solution has a software component, the code must work in some form or fashion. If we deliver code that’s inappropriate or not sufficiently functional, the recipients aren’t going to be able to use it. In this respect, the code is highly important; this means we must take appropriate care when we create and deliver it. Having a “second set of eyes” look over our code (either formally or informally) can make the code better and can make us better programmers. This, I believe, is the message behind Trish’s tweet.
The code, however, is also unimportant. How can that be? Our users, clients, or customers really don’t care about the code. They don’t. They want a valuable solution for their situation and if software is a part of that solution, so be it. They certainly don’t care about the seniority of the author, whether it was implemented using design pattern A or design pattern B, or whether it had one author or ten. They only care about whether or not it’s fit-for-purpose, i.e. their purpose.
A friend and former boss of mine (Hi Mike!) says, “the code is merely interesting”. I used to think he was undervaluing the coding part of the job. What I now think is that he was striking this balance between being appropriate with our development and keeping mind the software is a means to an end, not the end itself.
To further Trish’s point, when I write code is not “my code”; though I wrote it, I can’t consider it to be mine. Most often, I wrote that code on behalf of my employer to help our users, clients, or customers achieve some goal. It’s not my child; it’s not a reflection of my value as a human. The code doesn’t belong to me; it belongs to my employer, and as such, it is incumbent upon me to facilitate that code being as fit-for-purpose as possible, even if that facilitation includes involving other team members in its creation, review, or maintenance. We need to keep this mindset even if, horror of horrors, we have to end-of-life some of our code. I took me about 5 years into my career to understand this; for others, it’s takes even longer.
Obviously, there are exceptions to this, such as “I wrote this code at home, by myself, to help me achieve my goal”. If that’s the case, then the code is yours and you should treat it as you see fit. In this scenario, you are, after all, employer, user, and author.
The same can be said for “non-code things” that we create as well. Documents, processes, and approaches are all means to an end, that end being user, client, or customer success. So let’s leave our egos at the door (as best we can), understand the code is not our baby, and that feedback is a good thing. Many thanks to Trish for giving me the nudge I needed to finally publish this!