When I worked salary, one of things I liked, but didn’t realize at the time, was the ability to solve a problem no matter how long it took. Granted, when it got out of control, my manager and team would find ways to bring it under control, but bottom line I’d be pointed at a challenge, let go, and I’d update my superiors on my progress.
I have a high willpower; it’s the only way I’ve been able to compete in this industry. It serves me well in solving challenging problems because the obvious is not always obvious, and you are constantly challenging your assumptions, testing hypothesis, and following stringent logical workflows… or not, depends on my mood. Typically, you are supposed to rule out the most obvious & likely problems first in any debug session. For example, some example code you try doesn’t work. More than likely, it is faulty documentation vs. the actual Flash Player not working… unless you are using an alpha build of the Flash Player.
Those 2 paths of debugging above can lead to further steps, and other test cases that can drag on your morning. Other problems can drag on for days, even weeks. A lot of times, you can only spend small chunks of random time throughout the day, never really being able to focus exclusively on the bug. Sometimes it has a lower priority, and you merely put it in the back of your daily queue, in hopes that other development will spark a reason for why it is happening.
All those things and more can either be full force, or backburner type tasks. Bottom line, you are paid whether you fix it or not, and the time isn’t really a big deal vs. the resolution. Depending on scope, the point of no return is measured in days or weeks, not hours.
Getting paid hourly, however, changes the rules. I cannot go off for days at a time trying to solve a problem. I need to document what I am doing, minute by minute, always needing to be aware of what I am doing, how long it is taking me, and how long it’ll take to get to a resolution.
Those of you who have been in software development for any length of time know that if you knew how long it was going to take you to solve the problem, then you’d know what the problem was. Debugging, however, is about finding the problem. You can’t solve a problem until you’ve found it, and if it were that simple, then application development wouldn’t always be over budget.
The solution is to keep an accurate assessment of progress, well spoken hypothesis on what the problem(s) could be, and put it in the client’s lap to decide on if you should keep going, or focus on other tasks. Before, it was, "Jesse, solve this issue, and report back to me when you’ve found it. If you don’t find it by lunch, let me know. We’ll discuss and see if we can’t try a few more ideas."
Now, it’s kind of like that, but with a lot more documentation, self-awareness, and less emotional investment. I guess that last part is what really irks me. I can no longer dive in head first. As a contractor, I’m now constantly nagged by my own psyche to remember to keep track of my time of how long I’ve spent, and being able to clearly articulate where I am at with the bug at the drop of a hat.
