One very unproductive, even harmful behavior in the software development is the tendency to “protect” our code from critics.
Sure, we give it a lot of thoughts and sure it’s a snapshot of our way of thinking at the current moment, but… let’s face the facts, shall we? Given there is no way to know what the future brings and how the code would have to change to accommodate new requirements, our code is probably not the best it can be. I still have nightmares involving snippets of code i wrote a while ago.
So, what can we do?
First, let’s throw it to the critics and try to learn from them. If the code is really that good, then it should be easy to understand, do the job, consider all the edge cases, be prepared for changing requirements, be time and memory efficient, integrate seamlessly in the application and be consistent with the code base. Does it do really all of that? Unlikely.. So now we start with the mindset “there is space for improvement” and are open-minded to critic. Listening and learning. Some of the obvious benefits: we see problems before the customer runs into them. Also we build better interactions with the peer software devs, being able to break out of the “defender’s mode” and openly accept help or challenge.
Second, we can use our code as the best measure of technical growth. Looking at code from the last year and thinking it is good means we’ve lost an year learning nothing (as if we didn’t have enough bad news). The best proof that we are on the right track, getting better each day is being ashamed of the work from yesterday. That’s the delta. Knowing it, enables the calculation of speed and direction. It is pointless to compare ourself with other people, since everyone has different start, different prerequisites, different story. But comparing today’s and yesterday’s me, is easy and meaningful.