2009
08.09

Please leave comments and criticism here

I spent most of the last couple of weeks dealing with car issues.   Fortunately at this point they are mostly resolved. At the onset of my troubles a good bit of help from dad and some thinking, listening, and researching I got a pretty good diagnosis before I took it in to the shop which was a win for everyone. I could give the shop a much more detailed description of the symptoms which let them diagnosis the problem faster. I knew ahead of time a suspected cause, which helped me make sure they were looking at the right thing and let me expect how much it was all going to cost.

The whole process got me thinking about how much I enjoy/enjoyed debugging code. Yes, this makes me a huge nerd, but it’s also probably the skill I most highly valued in my computer science education. Debugging code, particularly tricky, frustrating, impossible bugs is a skill that I feel translates well outside of programming.   Sometimes bugs just refuse to manifest themselves when you have the debugger on, much like that noise your car makes right before you take it in to the shop for repairs.  Sometimes the tools you use to check for the problem makes the problem disappear.  Sometimes the bug (or car problem) only shows up on the second Tuesday of July at 12:01 pm.

Learning to debug frustrating bugs taught helped to teach me to logically examine a problem,  eliminating possible causes until I reached the root cause.   It also taught me that sometimes you have to examine all the assumptions you bring to the table before you can solve a problem.  Case and Point:

Probably the best debugging story I wrote at CMU happened during 15-410 Operating Systems (a great class!).  The details are not particularly important but my partners and my OS was crashing when running a certain test.  We worked on debugging it and eventually using all the techniques referenced above narrowed it down to one line of code that was supposed to be reading an instruction from a particular memory address, but instead of an instruction is saw all 0’s.  I smugly thought “gotcha” and I told the debugging tool to flag the address and tell me anytime my program read, wrote, or executed anything in that particular address.  I stopped right before the offending line of code and double checked that the address had a valid instruction…good to go.  Then one more step and BOOM…the program blew up.  Needless to say, I was perturbed.  No flag, no message, but suddenly, where my data had been…all 0’s

Frustrated I retraced everything I’d done thus far.  All my data structures looked fine,  everything was up to date.  Clearly I’d found a bug in the simulator/compiler, I told myself (hint, 99.999% of the time, the bug is in your code, not in the compiler or OS).  My partner and I trooped down to our professors office to explain our bug.  He patted us on the head and told us to get back to it, that we’d probably find the issue in an hour or two.   Gently chastened, I got back to work.  1:20 later, my partner and I came to the stunning conclusion.  We had accidentally been using an address that should have been reserved privately for the Operating System in our code.  When the OS decided to use that address for it’s own valid purposes, it simply zeroed it out and our tool never saw the change.   The failure hadn’t been in my debugging technique but rather in my assumption that I was the only one who could validly access that memory address.

That long story had really did have a point.  The kind of thought processes required to be proficient at debugging code are really useful in resolving most problems in life.   It makes me think that maybe this kind of problem solving should be introduced earlier in school curriculum, even down at the elementary school levels.  Probably not something as complex as writing an Operating System but I feel like some type of more open ended problem solving strategy would have been a very valuable part of my education.  It would certainly have been more relevant to my everyday life, even outside my job, than calculus ever will be.

Also, if you happen to live in or near Charleston, SC and happen to need any mechanical work done, I’d recommend Burke Motor. The garage staff was thorough and knowledgeable. I’m sure there are cheaper places around but they seemed to really know their stuff.

2009
07.25

One of the primary traits that drew me into becoming a programmer my interest in laziness efficiency.   Even as a kid I was always interested in finding the best way of doing a particular task.  I think it probably ocassionally drove my dad crazy because I’d happily spend twice the time the task would take trying to think of a better way to do it.  That being said, given the sheer amount of  interesting things there are to do and see in the world I want to maximize my available free time, which means cutting down on time spent doing the boring parts.

That leads me to two related questions the first is directed to people who work in software:

How do you set up your development machine/ Desk area to maximize your useful time.  Personally I work in .NET on Win32 but more generally what tools and techniques help you maximize your use of time and hence productivity at work.

The second is more general.  What are “life hacking” things you do to maximize your free time?

I feel like this is the kind of soft knowledge that everyone develops through experience but as mentioned about I like being lazy efficient and so I’d like to collect what I can by absorbing other people’s hard earned experience.  I know one of mine is that I all my bills online via my  bank rather than individually mailing checks which cuts down both on the amount of time it takes to pay them but also saves me time balancing my checkbook at the end of the month.  This feels like something that should be collected somewhere in an easily referenced wiki style website…

(and yes, I recognize the irony of taking the time to write on the internet about how not to waste time.  At least I’m improving my writing skills right?)