I have been working on my hobby project in C++ for more than 2 years. Whenever I write a module/function, I code it with lot of thinking. Now see the problem,

do {
  --> write the code in module 'X' and test it
  --> ... forget for sometime ...
  --> revisit the same piece of code (due to some requirement)
  --> feel that "This isn't written nicely; could have been better"
} while(true);

Here 'X' is any module (be it small/large/medium). I am observing that, this happens no matter how much effort I put while coding. So mostly, I refrain myself from seeing a working code. :)

Is this a common feeling for many people ? Is this language specific phenomena ? (Because in C++ one can write the same thing in different ways).

What should I do, if I get this re-factoring feeling for a real world production code, where changing the working code will not earn me much accolades but rather it may invite troubles if it fails.

  • 14
    I would be more concerned if I never found issues with my older code. This shows that your skills are developing. Commented Jan 22, 2012 at 18:55
  • 1
    If you look at old code of yours and do not think "darn, why didn't I do it this way back then?!", then you haven't learned enough since you wrote the code.
    – sbi
    Commented Jan 22, 2012 at 22:37

7 Answers 7


This phenomenon is very common and not specific to programmers. Whenever you perform an intellectual task, you will notice dozens of places where you could have improved -- after you got some distance. Ask any wise (wo-)man who ever wrote a thesis, and they'll tell you one thing: "Don't look at it. You will find an error on the first glance."

There are basically two things to avoid the refactoring loop:

  1. While writing and designing, try to get the distant perspective as early as possible. Have a colleague look at your design/code. Look again after a weekend. Look at it when drunk or high (but beware: don't change anything until sober).
  2. Live with imperfection. If it is merely not pretty, but works well (read: does a good job at fulfilling all requirements, including extensibility and readability), let it stand and be content with the good work you did, not striving for the perfect work.

Continuous refactoring is the way to go. Changing working code would not cause problems and it should be encouraged if done properly. If your code is fully unit-tested, you can re-factor your code with confidence.

The only thing you can predict about real-world production code is, that is WILL change. Don't try to guess at how it will change, what new techniques you will learn tomorrow. In short, don't make try to make your code "perfect". Just make it as good as you can with your present knowledge. Also, make sure your code is thoroughly tested and extensible.

I spend 20%-30% of my time refactoring existing code. I work in a tech company and the "management" has never complained about changing existing code. However, I realize that this can be a problem in some companies. Martin Fowler even has a section on it in his refactoring book.

In summary, it is a common feeling in my experience, but it is not a negative one.


Every module/function is born and evolves in a world of priorities. Once it suffices to serve the outer worlds goals it is often left to stagnate. Its all ultimately scaffolding in service to the higher purpose. Yes, we need to be obsessive about code, and yes that can cause us to stagnate too. Maybe it would be a good move for you to shift your focus away from the code itself a bit, and ponder more on the processes that go on inside you, the producer of the code.


Is this a common feeling for many people? Is this language specific phenomena?

That means you are expanding your knowledge and views.

If you have no tasks of higher priority, you should always go back and improve your code.

  • "... go back and improve your code." - who will pay you to do this? Once your code works, move on. As you learn and grow as a programmer, you will ALWAYS find better ways of doing things, and feel that your earlier efforts could be improved upon. Resist the urge to do anything about that - going back and improving your old code is mostly a supreme waste of time. Commented Jan 22, 2012 at 20:27
  • 1
    @David Wallace - If no one ever had to go back to old code, we wouldn't make such a fuss about it.
    – JeffO
    Commented Jan 22, 2012 at 20:54
  • 1
    "Once your code works, move on" - you wouldn't believe what kind of bugs I saw in the production code, because the code worked ;) Commented Jan 22, 2012 at 20:56
  • @Jeff O - that's very true. If I'm going to be maintaining old code, I would consider fixing it up, whether it's my code or someone else's. But unless there's a project with some dollars behind it that requires maintaining that code, then there's no way to justify the time spent tidying it up. Unless it's buggy, of course. Commented Jan 22, 2012 at 22:40
  • @VJovic - if there were bugs in production, it's because the code DIDN'T work. I think the OP was talking about code that works correctly, but is ugly. Commented Jan 22, 2012 at 22:40

I always though that a person takes a math class to strengthen their skills in the previous class. Algebra seemed hard, until you took Algebra II; Then the skills you learned in Algebra became useful. It is the same thing in programming, writing, woodworking, or anything else.

When taking a programming course you learned about If-then-else, which did a lot of things until you learned about switches. When you are learning anything new you go through this progression, everybody does.


I get the same feeling whenever I read most code written by myself in the past. This is a good thing, it means that your knowledge and coding style has improved over the years.

As for changing working production code, that is a big no-no unless you have spotted obvious bugs. Not only because it might be a waste of time, but more importantly since the vast majority of software bugs created are of the kind that is introduced when changes are made to released programs. Statistically it is likely that you will introduce unforeseen bugs. If it ain't broken don't fix it.


Developing an application means improving it and making it better; this is a continuous process so while you're programming you gain more experience and knowledge. It also means you're developing too, so when you look back at your old code you may find out it can be improved.

If you don't have this feeling, it means one of two things:

  1. You are still at the same level of skill.
  2. Your code is already perfect (unlikely).

Not the answer you're looking for? Browse other questions tagged or ask your own question.