I recently listened to a great podcast – Lessons from Code Reviews with Shawn Wildermuth on .NET rocks. My favourite quote from the show was by Shawn:

“No matter how good you are, your code will look bad to you tomorrow.”

This was just a passing comment but it really got my attention. I’ve often looked back on code I have written with horror, and it was a relief to hear that it wasn’t just me. In fact, it is all programmers who experience this feeling, even the best ones.

Intellectually we know that nothing is perfect, and our code is no exception. But look again at Shawn’s wise words.

…your code will look bad to you tomorrow.

He’s not saying that your code will be bad, he’s saying it will look bad. It’s an observation on our perception.

So why will today’s code probably look bad to us tomorrow?

One reason is that programmers tend to be perfectionists. If kept under control, this trait can be a positive one, driving us to produce high quality solutions. However, we need to remember that perfection is not attainable. There has to be a point where we let go and say “that will do”.

I am not saying that we shouldn’t try to make our code good. On the contrary, I believe code quality is extremely important and we should strive to write great code every day we work.

But we ought to acknowledge that at some point we need to settle for what we have in front of us. Especially when there is a deadline to meet and other tasks to complete.

A slightly more sinister reason why we might look unfavourably upon our own code is fear of criticism, or even ridicule. Us programmers can be quick to criticise. John Sonmez discusses some possible reasons for this in his article, the dark side of software development.

We’ve all done it – looked at someone else’s code and tore it apart, or laughed at it. The Daily WTF is of course built on this position. Some things on that site are funny, but I do wonder if it contributes to a culture where programmers are fearful of ridicule. Jeff Atwood has touched on this aspect of the Daily WTF.

Certain philosophies or approaches attract fan clubs in programming. TDD is of course the classic example. I am a fan of TDD, but I’m not on the bandwagon where it is considered the answer to all of life’s problems. It is easy to get caught up in the emotion behind practices or frameworks which seem to be promised as a silver bullet.

But this only leads to programmers who would rather look down on people not doing things their way, than question themselves and their own methods.

When starting work on a legacy codebase, the programmer’s first reaction is usually “what were they thinking?”. I’ve certainly been guilty of this myself, on more than one occasion.

If we were actually interested in the answer to this question, we would realise that what they were probably thinking was “I have a deadline to meet”, “I’m feeling under pressure”, “I’m not sure I’m doing things right”, “I don’t have time to do it properly”.

The part of us that looks at legacy code and thinks “what were they thinking?!” also causes us to worry about someone looking at our own code and thinking the same thing. It’s the other side of the same coin.

Again, this attitude isn’t all bad. We should try and make our code easy for the next programmer to work on, but it’s not productive to panic about code quality.

And this really gets us to the heart of the matter. Don’t panic and don’t worry. If you’re concerned about the quality of your code, address these concerns in a constructive manner.

Here are some steps you can take when feeling anxious about the quality of your code.

1. Create a List

Make a list of everything you are concerned about, and be specific. If there is nothing you are specifically concerned about and it’s just a general feeling of unease, then review your code for ideas. Is code duplication the problem? If so, where exactly? Is it commented out code? Inline CSS? Failing unit tests? You will probably notice more and more things on a daily basis - keep adding to the list. By creating this list, you are not necessarily saying that you are going to resolve all these problems. That will depend on the time available and other priorities. But the list enables you to start to regain control of the problem.

2. Actions and Estimates

For each item on your list, write down an ideal solution, what actions would be required to get to that point, and how long you think it would take. Take your time with this to build your understanding of the problem, and your ability to decide whether or not you want to address it right now.

3. Prioritise

Organize your list in order of priority. Which items are most likely to cause difficulties somewhere down the line? Given the estimates you have produced, what would give you the biggest bang for your buck? If you had nothing else on your plate, which problem would you work on first? Do these tasks have to be done or are they ‘nice-to-haves’?

4. Schedule, or Don’t

For those items which have to be done, work them into your schedule. Your estimates will help you with this. You may decide you want to cross one item off your list each week. Or you may choose to work on tasks as and when you have time. Just be aware that if you do choose this approach, there is a chance that you will never get round to doing them.

5. Relax

Most importantly of all, relax. Stop taking yourself so seriously. Your code probably isn’t as bad as you think it is, and even if someone does tear it to shreds or ridicule it, you can cope with that, you can tame that mammoth. Any ridicule will probably be behind your back anyway. Take the high road of learning from your experiences, and accepting your mistakes along with your strengths. If you can stay positive in this way, you will naturally become a better programmer with every working day.

The post I Hate My Code appeared first on The Proactive Programmer.