Have you ever looked at code you wrote six months or three years ago and wondered, “What the hell was I thinking?” We all have.

Reflecting on my own pythonic abominations, I’ve noticed a few trends. I don’t want to say that they are my “favorites”, but it seems that I do them a lot:

Algorithms too complex

This is a big one. I look at the code I wrote: the classes, the modules, etc. – and I can see that it works fine.

But it could be MUCH simpler.

Simpler often means more readable, easier to maintain and, surprisingly often, less brittle. I mean, the code still has to work properly. But simple, correct code is almost always better than complex, correct code.

When I step away for a while and look at the code base again later with fresh eyes, I often see a much cleaner solution.

Code “Working accidentally”

This one is kinda fun.

By reading the code, I can see what he was thinking at the time. And it actually works, i.e. it meets the requirements, passes the unit tests, and behaves as it is supposed to.

But clearly when I wrote that code, I totally misunderstood the problem I was writing to solve.

Really, it should NOT work. Because I was writing code to solve a completely fictitious problem, not the real problem! But somehow, it solves both.

I admit to being embarrassed that this is happening.

Still, I’m amazed that this happens, and more amazed that it seems to happen repeatedly.

Misleading Identifier Names

I put a LOT of effort into choosing good names for things. Variables, type and class names, methods, modules, etc.

This is because our clarity about what is happening is directly proportional to the clarity with which we understand the role of each component. And choosing good names for all of them can help a lot.

Objective:

Even though I’ve been making this a core priority for years, I often go back to refactoring some code, or adding a new feature or something, and think “I really should have called this SomeOtherName”.

Perhaps the lesson is that improving readability is a never-ending process. We can always improve.

getting lost

This one is quite interesting.

What I found is that I can look at a code base that I wrote some time ago. And I’ll see that I could have used some technique to really improve the quality of the code. But I did not.

That “technique” can be a design pattern; a language; or maybe even a language feature. Most of the time, it’s just because I didn’t know at the time.

With my current wisdom, it would have been much easier. And it would probably be more robust, maintainable, readable, etc.

The good thing when you realize this: It is a sign that you have improved as a programmer.

So celebrate when you notice all of this and continue to learn from them.