Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I was in college writing papers I would literally write one sentence, then go back and re-read the entire paper that I had written up to that point. I would do this over and over again.

Thankfully I'm not writing papers anymore, but I've noticed a similar habit when coding - if I'm working on back end code I'll go through a bunch of other files to make sure they are organized and complete. If I'm working on front end, I'll make a change to one page, then I'll go through the entire website to make sure everything looks good.

This is really annoying and time consuming but I can't seem to get myself to stop. I think part of it is being a perfectionist, part of it is not knowing exactly what to work on next, so I go back and review previous stuff instead. Any suggestions for dealing with this?

share|improve this question
up vote 4 down vote accepted

You might be suffering from some mild froms of OCD (compulsive obsessive disorder). Try to read about this disorder. There are many ways to modify your behavior and you can find them online. Also note that between "absolutely not redoing tasks" and redoing tasks so many times", there is not necessarily a definite right number of repetitions. Moreover, be inform that many masterpieces (both in painting and poetry,etc) have been done by people who had redone and repeated their work so many times (we know that by looking at their notes and/or X-ray imaging from their painting). Thus, you need to figure out how many repetitions is necessary to have a piece of code with acceptable quality.

share|improve this answer

I don't have a generalized suggestion for the overall issue. For the specific cases of coding, I suggest adopting a Test Driven Development or similar methodology. (Google for definition and explanations). Then develop the habit of running your tests after a change instead of looking at the code. You won't break the habit, exactly, but you'll be doing something much more effective than looking at files. And a TDD approach is very good at resolving the issue of not knowing what to work on next.

share|improve this answer

I don't know what language and IDE you are using. but the following is a microsoft visual studio developer view which also might be useful for you:

start using unit tests and FxCop

FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. Many of the issues concern violations of the programming and design rules set forth in the Design Guidelines, which are the Microsoft guidelines for writing robust and easily maintainable code by using the .NET Framework.

With something similar to FxCop you enforce yourself using a coding standard. And as Dennis S. pointed out TDD with unit testing ensures that you do not break anything.

share|improve this answer

When you go back over the website, do you find things to improve?

I am not sure how extreme it is what you do but isn't it possible that it isn't bad? I know that quick is considered an ideal these days but I've wondered a lot whether or not we aren't being pressured to work in ways that don't work for all of us.

For example, I write very slowly. I read my stuff a million times before I publish it. I move things around and change things a lot. And I find that my writing gets tighter and better the more I do that. So is that bad?

share|improve this answer

I know your problem, everything has to be perfect. But of course, everybody knows, that there are a lot of possibilities how to write code and it can be done better or worse. Many time we see the better opportunity after some time, when we have already done it, when we have to implement something new to it. But that is normal. Therefore re-factoring exists ;) Try to believe more in yourself, that you are writing good code. First, make good analysis of work you have to do, to see as much connections as possible, and then improve your skills by studying code writing rules, new techniques and various practices, where you will learn how to code better.

When you find some bug, it is good to check all places, where can be the same problem. But normally, when you don't find any problem, don't bother yourself be scanning already done work and continue coding. You will find those problems after some time and then you will know what to do.

It is good practice to write down all issues you want to check, implement, or fix. In some moments, when you are doing something else, you will get a good idea, what to check or do, so write it down and then do that. In this way you will fix a lot of problems and you won't stay in one place by finding some problems, because you "feel" there must be something wrong.

So don't try to have everything perfect, just start to work in the best way you can!

These your attributes - to check everything, to have everything perfect - are great attributes of testers. It is their responsibility to find every problem, to test every feature in all ways and try to have everything perfect. Maybe you can try this kind of position and be satisfied with your habits...

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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