Why does everyone else’s code suck?

Developers sometimes have a hard time taking projects over from others because the code simply hurts their eyes. Weird. Why is that? I’m not a developer, but I can take a look.

Projects often have tight lead-through times, leaving no time for polishing the code. In those situations, you prioritize and knowingly take short-cuts to get a working product released on schedule.

And that’s not all, folks.

After release, it may transpire that the product does not actually work as intended and requires a major overhaul on many fronts. When a new developer steps in after the project has been pivoted on the fly, the old code can easily look like an illogical mess – particularly if the comments have been written carelessly.

At other times, there is nothing much wrong with the code itself, it’s just annoying to read. This negative emotional reaction to code written by others can be explained by a few practical matters and cognitive distortions.

Reading is harder than writing

When writing code, you know what you’ve set out to do and how you’re going to achieve it. Sometimes, you take a detour or jury-rig a thing or two along the way, but the writing logic is sound – at least in your eyes. But when someone else begins deciphering your code, it’s a whole new ball game. Abstruse Goose has made a famous comic about this.

And it’s not only the work of others that can be painful to read. Your own past code can look awful too, if you can’t remember why you originally made the choices you did. Some think the only valid measurement of code quality is the number of WTFs/minute.

“At its highest level, writing code is communication. The most important thing is telling what the purpose of each string of code is and why it is there. When you make this clear in the comments, it makes reading your code easier and less annoying”, says Software Architect Kaarlo Lahtela of Qvik.

Next up, three cognitive delusions that often contribute to this phenomenon.

1. The Ikea effect

People assign more value to products if they have contributed to building them – regardless of how the project went. It’s the same with code: your own work is easier to appreciate than that of others.

“It helps if you have to present your code to other developers every now and then. When the new developer doesn’t have the silent knowledge accumulated over the project’s history, you find yourself saying ‘well, this is actually not quite as good as it could be, but it works and we’ve had more important things to do than cleaning this up’ often enough”, says Qvik’s Principal Software Engineer, Pertti Kröger.

“That’s given me the insight that code written by others looks shit in precisely this way, and for precisely the same reasons. The essential thing is to trust in the professionalism of other people and realize that there’s always a reason.”

2. The mere-exposure effect

We like familiar things. Research has shown that this applies to everything from words, sounds, images, figures and faces to foods and brands.

When reading code, the writer’s logic may feel strange, making it harder to like. Your own code and logic, on the other hand, are more familiar and thus more likeable.

Technology companies usually have their own, slightly different guidelines according to which code is written. As a result, the code produced by your own company can look better because you’re accustomed to it. For example, Qvik’s Swift style guide looks like this.

“It’s easy for developers to understand and write code with a familiar architecture, style and libraries. This can be facilitated by formatting the code automatically to a familiar style, such as with the Prettier tool”, says Qvik’s Head of Front-End Development, Jani Mikkonen.

3. The fundamental attribution error

It is typical for people to evaluate the actions of others by different criteria than their own doings. You tend to emphasize the impact of outside factors on your own work, particularly if things didn’t go entirely to plan. But it does not come as naturally to us to explain the actions of others with outside influences.

When reading code that has aged even a little, for example, you would do well to remember that programming languages do improve and best practices change.

“Sometimes, code that was written according to the best practices for the programming platform just a minute ago can appear obsolete, if the platform or library has changed”, says Senior Software Engineer Jussi Pekonen of Qvik.

“This can cause frustration if the person reading the code is not familiar with the platform’s development history. Likewise, cutting-edge solutions can appear daft to someone who has not yet come across them.”

Here’s the disclaimer

Not all programmers detest reading code written by others, of course. Code written by someone more experienced can offer important lessons and insight to the reader, particularly in the early days of your career.

“Code literacy is part of a developer’s professional competence. By learning from the mistakes of others, you can ultimately improve your own code and its legibility”, Kröger says.

Nor are the feelings of anger necessarily focused on the person who wrote the code, but the emotion is more akin to tech rage.

“Reading and evaluating code written by others becomes easier when you recognize this phenomenon and the reasons behind it.”

Illustration: Aija Malmioja