What Motivates Junior Developers To Make Fun of Someone Else’s Code | by Jesse Langford | Mar, 2022

And the ways they’re damaging their careers

Whatever the motivation, making fun of someone else’s code achieves nothing.

Big thanks to Brian Christensen for inspiring this article.

A while ago I wrote an article about three habits junior developers should avoid. Bryan commented on the post about his experience with junior developers trashing the code of others and how annoying it is. That got me thinking about the times it has happened to me, and times when I have done it.

I felt the topic deserved its own write-up because the act of trashing the code that others write is not a bad habit — it’s a destructive one.

Below are a few motivations I believe junior developers act on when they make fun of someone else’s code. I’m basing these on my own experience as a junior developer making the mistake myself, and on my experience mentoring junior developers. If you feel there are others, please let me know.

Before I continue, I want to present this article in a diplomatic fashion, but if you’ll forgive one outburst, I feel it’s important to get my raw emotional feelings across on this: If you are a junior developer, and you have a habit of making fun of other people’s code, stop, it makes you look like an idiot.

You are not gaining clout with anyone; you are doing the opposite. I promise you your superiors think less of you every time you do it.

With that out of the way, let’s continue.

I was guilty of this one a few times when I was a junior developer. I wanted to impress my boss so I made fun of some code that I had come across when we were doing consulting work. It felt like an easy way to get a laugh out of him and demonstrate my programming knowledge.

Now that I have been on the other side of the interaction, and had developers come to me and make fun of someone else’s code, I am confident I achieved the opposite.

I would love to hear feedback on this, but I have never once been impressed when a junior developer showed me someone else’s code and told me how bad it is.

To this day, I get a feeling of shame and cringe when I remember it.

There have been a few times when the code being made fun of is actually poor quality. In these cases, I err on the side of empathy for the developer who wrote it. I’ve released code I’m not proud of because of crazy time pressures or app requirements changing mid-development. I would hope if someone saw it they would give me the benefit of the doubt.

In these cases, the junior developer making fun of the code has never been given a really challenging project. Their journey thus far has been in controlled environments where the stakes are low. For them, the only explanation for bad code is incompetence. They don’t yet appreciate that at some point, everyone is asked to build something they don’t fully understand, with less time than they need. Not everyone who has written bad code is incompetent.

I remember the project where I finally understood this. A few years ago, I asked our CTO if I could be more involved in frontend development at work. I was looking to expand my knowledge and capabilities. HTML, CSS, and jQuery were all that I had experience with.

I was then asked to build a Monorepo with React and TypeScript. For those unfamiliar with JavaScript and web development, that’s like having experience building wagons and being asked to build a car. In the end, I was able to get everything working and the project is live to this day, but parts of that codebase are not optimal, to say the least.

I’ve had this one come to me in two forms: The first is when a junior developer comes across code that is more complex and nuanced than what they are used to seeing. They mistake this code for poor quality because they are unable to read it.

Not all code is written with readability in mind. Sometimes it’s written to be as efficient as humanly possible. Normally I find this to be true with expensive database operations or complex asynchronous logic. Anywhere that efficiency and cost are closely related.

The second form is when they see code that is not overly complex; it’s just written in a style that they don’t recognize. When you first start out it, can be easy to think that the only way code is written is how you do it. If the only code you ever read is your own, others will always look foreign. With more exposure to the work of others, this notion should go away.

Hopefully, this topic was informative. My intention is not to put down anyone who has this habit. I more want to give them an insight into the mind of someone who is watching.

Leave a Comment