Certainty is a fickle friend

Later on my life, when I look back on this time of starting my job, I imagine I’ll remember a long period of mental haze.  Every day, the rug gets pulled out from under me in a new way, forcing me to adapt my working style to a new variable.  When I think I’ve found the last thing that could break, I inevitably discover a new ‘weakest link’, thus blowing all my earlier assumptions out of the water.

Before I got into software, I worked as a program manager at a mentoring program.  Part of my job was training team members into their roles.  Most of my team members were doing their first job out of college, so I got to play expert, not only teaching them best practices about mentorship, but also how to organize and schedule themselves.  I knew things, and I relished the opportunity to share them with colleagues.  I was a super-hero of information synthesis!

Those days are gone.  Now I only fantasize about knowing things as I dive headfirst into a bottomless pit of bug-wrangling uncertainty.

First it was string disappointment.  Of all of the JavaScript data types, I felt I could most depend on strings, because they were just chstick-man-with-capearacters between quotes.  Then I started writing keyboard shortcuts for a web app, and the browser threw an error because “a” != “a”.  WTF?!!  I had no idea where to go from there, until my colleague suggested that i might be dealing with unloggable unicode characters, wicked invisible entities that live to screw your validations over.  I left that experience feeling that my trust in strings had been misplaced indeed.

Next, my libraries let me down.  Although I painstakingly followed the exact directions of a d3 library, nothing happened on the canvas.  No error thrown either.  Just a whole lot of nothing.  I debugged, tried variations, checked the github issues to see if anyone else had this problem.  Then finally, on inspecting an object, I found that one of the methods in the library’s initialize instructions didn’t actually exist.  Library FAIL.

Finally, Chrome let me down.  After I pushed a big commit, I felt like an engineering superheo until my colleagues informed me that the commit had broken their apps in Chrome.  There was  no small amount of embarrassment on my part as I perused the code, trying to figure out how the changes I made could possibly be causing these errors.

As it turns out, Chrome had saved a JSON draft in local storage that was not compatible with my changes.  A quick localStorage.clear() was all we needed.  (Shouldn’t local storage be cleared automatically when one pulls from a github repo?)  From a new JavaScripter’s perspective, it seems that no good deed goes unpunished: tiny half-assed changes have tiny repercussions, but hard work results in big changes that lead to big, embarrassing errors.

But I’ve got to keep trucking.  I may not be a superhero of information-synthesis anymore, but I have Tom-Haverford-inspired hopes of donning a new cape: the superhero of information-FAILURE-synthesis.  Knowing why something is failing is the first step toward better understanding, which beats blind certainty by a long shot.

Fail early, fail often, fail purposefully: that’s the developer’s credo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s