‘Mine’ field or minefield?

Sometimes you write a piece of code or feature, or even a whole application by yourself. In some cases, no one else knows what you’ve written. Sometimes you are glad for this freedom. Freedom is the right word because you’re glad to have your code the way you want it: everything in its place and in proper working order. I say proper working order instead of perfect for a reason. Inevitably, one day you’ll return to this piece of code or application and wonder: “who the hell wrote this code?” And of course, git is laughing at you and saying “you, bloody bastard”.

Wouldn’t it be nice if you were able to ask someone to look at your code the moment it was written, and then together, be able to write this code in a way where you wouldn’t be ashamed of it in the future? Yea, maybe, but many programmers feel a bit guilt about showing their code to someone else while asking for a review. They feel like showing their code is a private thing, for some programmers it can feel like pulling down their pants and asking someone “hey, does this mole look weird?”

It’s perfectly normal to feel like this, but you know what? Fuck it. Ask yourself what really matters. Isn’t it good for you to improve and become a better programmer? Even more, isn’t it an asset to your company if you can create valuable code that is the best quality possible? If you have said yes, then you too can remove your pants for a minute or two and bear the shame of asking for help. Not to mention, there’s always the chance of someone giving you a compliment about other things while checking if the mole is serious or not. I don’t know about you, but I’d appreciate a compliment like that.

Often, I hear the sentiment: “It was hard to write, it must be hard to read.” Fortunately, I have heard this joke, but unfortunately, there are people who think this approach can guarantee a long lasting job in their company, because nobody else can deal with the code they have written. They naively think writing complicated code makes them indispensable. I beg to differ, and I believe this way of thinking is not only wrong, but antiquated. Let’s debate who is more valuable for the company with two scenarios:

1. Person A structures projects that are not only scalable, but also allows programmers to be added as needed, in addition to writing code that is maintainable. Furthermore, when they are absent or leave the company, you don’t need to worry because they leave a readable, maintainable code that anyone can dive right into comfortably.

2. Person B writes code that resembles ancients ruins that only they can maintain. You think this person is valuable to the company, but when they are absent or quit, most of their projects unravel or come to a standstill. It’s only when this person leaves that you realise the extent of how unmaintainable their code is. In essence, everything needs to be rewritten after they’ve left.

Now, honestly ask yourself which person you’d prefer to have in a company you own. Whether you want to or not, your code leaves mines on the field where you work. If you ask someone frequently to review your work, or if you work with someone else as a team, you will be alerted about these mines, early. When you work alone, quite often you are aware of the landmines that you leave, but you have the home field advantage and know where to place your steps.

However, it’s important to remember that someone else may have to enter your zone…and then what? Would you like to have someone’s life on your conscience? I don’t think so. You know they might be able to survive the explosion, but do you want them to seek revenge? It’s better not to leave landmines or defuse them as quickly as possible, and in this field, it’s indispensable to have the helping hand of another sapper/programmer.

If you’re not comfortable asking someone else for help, sooner or later you’ll learn to because without this skill you’ll create minefields which will blow many programmers out of the water. That’s a lot of potential enemies in a small industry. Open your field for sappers and open your mind to code review. Before it’s too late.

• Share this article: