Interesting. And there was I thinking "problem solving" was what made this gig interesting!
I guess this puts the emphasis on talking about problems over hiding in a corner and working through them into some perspective. But personally, I find programming under circumstances where I don't get to "spin my wheels" from time to time pretty frustrating.
That gets my goat is a problem that gets in a way of solving problem I was tasked to solve.
An example would be the test suite segfaulting on my machine while I'm responsible for hunting down a nasty bug. Often I'll take a stab at the distracting problem, e.g. reinstall Ruby and gems with native extensions. If that doesn't help
I'm faced with following choices (and due to time zone difference I need to decide before my manager gets online):
- give up investigating and suffer the segfaults (time already spend is a sunk-cost with nothing to show)
- disappear into segfault rabbit hole, all the time stressing that I should be doing something else
In isolation I'd be happy to focus on solving either problem.
Is the issue here really about problem solving, or about having to account for your time in excessively fine-grained increments? Given a coarser-grained model of dividing up tasks, wouldn't it be easier to solve the segfault and move on?
In general it's about pressue to get the main task done quickly. I thought of some common reasons I feel this pressure:
- external, e.g. bug hurting our clients.
- feeling bound by an overly optimistic estimate, like couple hours vs. a week
- can't focus, procrastinate and then rush to get the work done
- imposter syndrome and constant feeling that I should have done my assigned task long time ago
- personal issues forcing me to take some time off and delaying shipment
- having already spent considerable time in some other rabbit-hole, especially without asking for permission
- misunderstood something, wasted lots of time implementing wrong thing but don't want to admit
- scope creep, a feature that's too big and too long in not-yet-ready-for-deployment, risk of interruptions, merge conflicts and being too big to test properly grows
The first one is fundamental and sometimes things are simply urgent. Addressing rest of them is an ongoing effort.
Without this kind of pressure I often find solving problems like debugging library code or git forensics quite fun.
I'm fine with fine-grained time accounting. Part of a decade of remote freelancing. Nowadays I do it habitually without being required.
> That gets my goat is a problem that gets in a way of solving problem I was tasked to solve.
Amen. It's so frustrating to stretching the time involved in solving what should be an easy problem by 10x because of poor or inconsistent API documentation.
It's one reason I hate 3rd party libraries and the abstractions they cover - they always fall apart, and I have to spend an inordinate amount of time understanding why.
Problem solving is great. Getting stuck on a problem you cannot solve and not seeing any possible way to move forward is what the paper seems to be references.
I worked on project once where we had a single show stopping bug preventing us from getting our new release out. At first it was a really fun challenge, but as days turned to weeks and we where no closer to finding out what the hell was going on it got more and more dispiriting. If nothing else it makes you feel dumb as fuck and you start questioning whether or not you actually are a fraud after all.
It depends. Am I solving the problem of how to implement this feature in an effective and efficient manner? Or am I solving the problem of GOD DAMMIT WHY THE %^&# WON'T ANDROID STUDIO COMPILE NOW?!?!?
I guess this puts the emphasis on talking about problems over hiding in a corner and working through them into some perspective. But personally, I find programming under circumstances where I don't get to "spin my wheels" from time to time pretty frustrating.