Have you ever looked at the 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 they are my “favorites”, but I seem to make them a lot:
Overly complex algorithms
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 has yet to work correctly. But correct, simple code is almost always better than correct, complex code.
When I step away for a while and look at the codebase again later with fresh eyes, I often see a much cleaner solution.
Code “Working accidentally”
This one is kind of funny.
Reading the code, I can see what he was thinking at the time. And it actually works, that is, it meets the requirements, passes the unit tests, and behaves as it is supposed to.
But it’s clear that when I wrote that code, I totally misunderstood the problem I was writing to solve.
Actually, it should NOT work. Because I was writing code to solve a completely fictional 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, names of types and classes, methods, modules, etc.
This is because our clarity about what is going on 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.
Aim:
Even though I’ve been making this a top priority for years, I often refactor some code, or add a new feature or something, and think “I really should have called it 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 “technical” may be a design pattern; a language; or maybe even a language feature. Almost always, it’s just because I didn’t know it 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 these and continue to learn from them.