I ran into the following issue where a keyboard shortcut I was used to was no longer working in Ubuntu. That's just an example. For programming, this kinds of thing happens a lot, but it also happens in any aspect of work and life.

I'm always tempted to fix it right away because I have an idea of what might fix it in a few minutes. Of course, a lot of times the idea is wrong, and much more effort is required.

I basically go through an optimization process where I continuously ask myself "Did I spend too much time looking for a fix already?" in trying to decide whether to abandon the effort.

I think any one issue can be abandoned, but I think that if I do it for all of them, my life will be a mess of inefficiencies.

Question: How do you effectively approach this temptation of small problems?

As I wrote up in the above rambling blog post the pros and cons for the decision to pursue any one individual issue are:


  • I fix the small problem the "right" way, so I don’t have to settle for a half-ass sweep-under-the-rug solution.
  • I get to spend an hour being open to the possibility of learning new things relevant to my work and exchanging information with the community of fellow Linux users. The computer world evolves on a daily basis, with new technologies, approaches, ideas constantly emerging. So, it’s important to stay connected to the latest developments.
  • I get to practice persevering in dealing with frustrating issues.


  • It is not guaranteed that I find a solution.

  • It always takes longer than you thin. At first, it seems like the fix would not take more than 5 minutes, and when it does (50+% of the time), I become progressively more invested in it as time goes on. It’s the same principle that keeps you gambling in a Casino until all your money is gone.

  • Perfectionism is an addiction. We live in a world of inefficiencies that could be easily optimized if you just give it a few minutes. Sometimes it does take minutes, but sometimes it may take days. The more you feed this addiction, the harder it becomes to exist peacefully in an inefficient world.

  • 1
    Problems like these are economic and involve weighing whether the cost of spending the time to solve the problem outweighs the cost of living with it. As you point out early in your question, that's not a programming-specific problem. – Blrfl Dec 23 '12 at 22:23
  • 1
    @Birfl, yes but the question is asked on a programming site, and therefore the "cost of living with it" that's being discussed is specific to programming. This is a practical problem faced by many programmers. I don't see why it would closed as not constructive. Let's not confuse the philosophical side of the question, with the fact that it's also very practical and has many practical answers (as you see below). – Alan Turing Dec 24 '12 at 21:38

For these types of things, I recommend that you file a defect, issue or an enhancement request as appropriate so that it can be tracked, scheduled if need be, and not forgotten.

Get your primary and most important work done before you start tackling the extra. Not only does this help ensure you hit your own deadlines, it also gives others a chance to evaluate what you have found.

In the end, it might not be worth it, or even desirable to fix it. Then again, it might. A little distance/time can help provide the state of mind to best evaluate it.

  • I like this idea. Of course it assumes that you work for a sensible company. – Wayne Werner Dec 24 '12 at 2:28
  • @WayneWerner, otherwise he can just drop in a //FIXME comment and get back a it... when it matters. If. Ever. – ZJR Dec 24 '12 at 3:08

Let them go.

Concentrate on the bigger things. You'll end up wasting half your time on unimportant things. It's not a bad thing to work on a smaller issue itself, but it could be if you end up missing out on the more important stuff.

Get comfortable with your own personality so that you are aware of this tendency. Don't beat yourself up about it, don't fret, but remind yourself occasionally to work on the bigger picture stuff, and that sometimes the smaller things really don't matter.

Remember, software that people use only has to be good enough. It doesn't have to be perfect.


I feel your pain and find myself in that situation a lot.
I try and do that small stuff "as time allows", but that's very vague.

To the question of how to approach the situation: Triage them is my approach.

You take a quick look - very quick - and it gets classified as Emergency, Urgent, Routine or Minor. I often do this list/log in excel. Emergencies may get done immediately and bypass the rest of the processes. These are always judgment calls (your 'urgent', my 'routine'!) and the key is to adapt them to the circumstances - classifications in a startup will be very different to those in a more established company.

Then, I do an initial review of the details, the complexity, etc. I'll frequently review items with the product manager.

Then I enter the our issue tracking system (Pivotal Tracker) and give more thought to priority, effort, details, resources, etc.

Our Ticket Tracking System is then used interactively throughout the day (you even see other peoples 'actions'!).

  • Triaging is nice. Makes lots of sense, yet, I've never heard of the term used in this context. It should. For example, one could triage a fix, without ever scheduling it. There's a nice concept in there. Thanks for sharing. – ZJR Dec 24 '12 at 3:12
  • Sure, I probably picked it during 14 years working at IT in hospitals... also our morning scrum was called 'rounds' ! – Michael Durrant Dec 24 '12 at 3:31

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