How to avoid getting carried away with details? [duplicate]

Question

When I program, I often get too involved with details. There might be some little thing that doesn't do exactly what I want it to, or maybe there's some little feature I want to add. Either way, none are really essential to the application - it's just a minor niusance (if any). However, when trying to fix it, I may happen to spend way more time on it than I planned, and there are things much more important that I should be doing instead of dealing with this little detail.

What can I do to avoid getting carried away with details, when there's more essential things that need doing?

(I didn't know how to tag this question, so feel free to add whatever appropriate tags that are missing.)

Answer 1

I try to keep a list of TODOs to avoid this. Whenever I am working on a task and noticing something which would take some improvement but is not directly related to the actual task I am working on, I may fix it right away if the fix is trivial. Otherwise, I try to resist the temptation and instead make a note to return to this. (It could be a TODO comment in the code, a note on paper, a new entry in a text file etc. Note that the first works only if you don't already have dozens of unhandled TODOs sprinkled all over your codebase. I am working on a big legacy app with hundreds of TODO comments inherited mostly from prehistoric times, so I use paper.)

Once I finish the immediate task, I return to my notes and take the most important which still relates to the wider issue I am working on, and is doable within reasonable time limits. And so on.

In the end, when I finalized everything and committed the whole work, I may still have a few tasks left which are either not related to the current issue or too big to be done right now. I usually feed these into our issue tracker.

Answer 2

Todo lists with a priority level can really help with this.

Any random thing that comes into your head that you want to add/fix/change/investigate, add it to the list, but make sure it gets the right priority level. Then just start from the top!

Answer 3

Walk away from your desk and get a glass of water.

When you realize that you have spent way to long working on one thing. Walk away from your computer and think about what you were doing and ask yourself if it is really working towards completing your primary task.

Don't go back to your desk until you have a game plan on what you should be working on. Sometimes it means you will back out ALL the changes you have been working on so that you can refocus on your main task. Sometimes it means saving out the code you were working on and adding a new task to the project. And sometimes it means you will finish what you were working on.

Answer 4

In my experience it's always worth the time to figure out why it's doing what it's doing, because that improves your understanding of the system, and makes you better in the long term. After you understand why, then you have to make an educated guess: is it most cost-effective to fix the problem, work around it, or just document it and move on. This is a business decision.

If it really is an annoyance for the user, I'd err on the side of fixing it, or else you end up with "death by a thousand paper-cuts". Details matter.

Answer 5

Strange as it may sound, boredom can be your friend.

Try to enjoy the moment when an application/module/library "comes to life", when it first starts to operate, even if it isn't flawless yet. Once you get used to that feeling, you'll find that fine details, while interesting for some time, eventually get boring.

Another observation is that it's easier to let go of a small-scale problem, if you document it and file it in your todo list. Make sure you do revisit these problems though. After all, you don't want to hand over code that isn't quite up to scratch.

Answer 6

If you're getting things done on time, you're not spending too much time on details. Hopefully, this is not a result of fooling your superiors/customers into believing your time estimates are normal.

Sometimes it's easier to stick with a task that you know is completed by everyone else's standards and just keep tweaking some small piece of it then to get started on the next task which is not as much fun/is going to be very difficult. Some people are just detail oriented/borderline OCD.

I have the opposite problem and tend to want to get things done and miss out on some of the details. I force myself to hold off submitting things, and after a short break, go back and review.

In your case, once something 'works', take a break, and force yourself to move on to the next task knowing you can go back and work on some of the details if you have time. If you get things done on time, it's not really a problem, but a good trait to have as a developer.

Answer 7

What do your "customers" want you to work on? While we sometimes write software strictly for our own use, most of the time we are writing software for someone else to use. Listen to them and set your priorities based on their feedback. This is where agile programming becomes helpful, a series of short releases giving you quick feedback.

Answer 8

Build in a delay for working on any new feature except those items which truly need immediate attention.

• Saves from jumping around on details which later prove insignificant
• Allows staying focused on the big picture -- the stuff that really matters

A lot of those new features are just distractions along the way. Very few items truly require immediate attention, and when they do they're obvious.

Stay focused by using a ticket managing system, like Trac or Jira or even a sheet of paper and a pencil. Continually re-prioritize in light of the main focus of what you hope to accomplish. It's amazing how many distractions can be eliminated this way.