“This code I wrote six months ago is terrible.”

– Every programmer at one time or another.

Admit it, at some point when you came across some truly atrocious code, you pulled out git blame, only to be slightly ashamed to find out that it was you who wrote it.

This is a fairly normal experience. As we come across interesting concepts and practices, we try to incorporate them into their own practices.¹ Over time, our set of practices grows, and eventually what we wrote six months ago is almost unreadable.

The lessons from the other side of the coin are far more painful. It’s only when we have to clean up some horrendous code that you come to face to face with what happens when you do it badly. And chances are, it wasn’t your code. The successive layers of cruft and hacks built on top of code that charitably could be described as stupid was written three years ago by a contractor who has since left the country have finally fallen over, and it’s your job to refactor it.

In this instance, it’s really easy to pick out the mistakes and stupidity, because it wasn’t you. The problem is, you are probably also writing bad code, and you don’t even know it.

Being able to write useful code in any decently sized project requires a certain brain type that most of the population doesn’t seem to have.² This isn’t the same as being actually smart, but from the outside it often looks like it, because if you have a skill that nobody in your peer group growing up can acquire, you will appear to be smart.

The downside is that when everyone tells you are smart, you’ll start to believe it, and stop trying, and never get better.

When you encounter better coding practices, you will invent reasons why those practices don’t apply to you, or are otherwise unreasonable. You will become attached to your code, and get upset when anyone changes, or suggests changes to it.

If instead, you accept that there’s always a better way to write code, and that you can always improve, then you will see everything as a work in progress, and view any given piece of code with a bit more objectivity.

Besides looking at what works and what doesn’t in the code bases you work on, the best ways to improve are to read, and to seek feedback from others. If you haven’t read Clean Code by Robert C. Martin, I would strongly recommend starting there. In later posts, I’ll talk about feedback via peer review, and why you should have a mentor.