Perhaps this is an overloaded question. Some may say that as they write more code throughout their career, that their code does get better over time. But what I am referring to is that 30,000 or more Lines of Code (LOC) that you’ve written for a particular system. Is it better today than it was last week? Is it better today than it was six months ago? How about a year ago?
Sadly, for many people who are reading this, the answer is no. Hence their code base continues to degrade over time. However, for the few and the proud (aka: craftsmen) who are meticulous about their work, the answer is usually yes.
Improving your code over time
So what can a person do to reverse that trend? The answer is easy.
TAKE PRIDE IN YOUR WORK!
I’m sorry for screaming at you. However, rock-stars typically become rock-stars as a result of being obsessed. They don’t do it for the money, they do it for self-expression. They do it for the energy of karma. Their psychosis bleeds onto the notepad. Their adrenaline takes possession of the drums or the guitar strings and they just rock-out. Yes. I am describing a direct connection between the rock-star and their tools. They become gods of their domain for that one session of that spiritual, sick-sense, expression.
What’s preventing you from Rocking- out?
I usually rock-out with my code not when I am implementing something new, but rather when I am refactoring something old. I reimagine what the code could look like. I reimagine what my solution folders could be structured like. I reimagine how elegant my automated tests could be. Once I fixate on these thoughts, I then spend the next three hours or so in the zone making things cleaner and just overall better. And that’s how your code can get better with age. You revisit what is old and make it new again throughout the software development life cycle (SDLC).
In conclusion, I asked the question, does your code get better with age. I then drew an analogy of rock-stars that just rock-out for a session. I believe that as developers we can improve code overtime by routinely allocating sessions to just rock-out with existing code to make that particular section of the system (i.e. code, solution structure, automated tests) cleaner.