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:

Pros:

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.

Cons:

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.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

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.
–
BlrflDec 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 TuringDec 24 '12 at 21:38

3 Answers
3

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.

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.
–
ZJRDec 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 DurrantDec 24 '12 at 3:31