I usually encounter two classes of bugs on a regular basis. The first is of the form “I think I know where this is” which won’t take long to find. The steps are pretty easy: Figure out how to reproduce it. Set a couple of breakpoints. Add some caveman debugging. Find the problem and fix it. These are my favorite kind of bugs because they’re over and done with quickly, I can get a quick hit of that “you done did good” glow from making a software system better, and then move on to some more interesting problem.
This past week I came across the problem of debugging multiple mobile devices. Again. It seems that when things go bad with good programs, seldom do any suggestions reveal themselves. Instinctively I turned into the itinerant detective, searching for the clues that would lead to a smoothly running program. Like any good engineer, I try to keep abreast of the best tools available, so it seemed a good time to reacquaint myself with the Chrome Inspector, looking for more tools to sniff out bugs. I found that a great introduction to the Chrome Inspector in Paul Irish’s A Re-introduction to the Chrome Developer Tools at Google I/O.
When I’m developing new code, my usual habit is to do a lot of small iterations. That gives me a little bit of success fairly often. I’m not as happy if I have to work for a long time until I can see something appearing on the screen.
There are a lot of ways to measure an individual’s work performance. When you think of a manager, perhaps you imagine her stopping by an employee’s office to see if he’s in his chair during work hours, or checking whether he’s spending too much time on Facebook.