Dev Doctor: The Prelude

Recently my work hosted a Fix Hack Learn event, where it had some of the characteristics of a hackathon, but included the flexibility for folks to work on some postponed, work-related tasks or learn something new. For me and my small team (just me and a colleague), I chose to start on something to help with developer setup. I call it `dev-doctor`.

Don’t just install things

We’ve all been there. That one weird bug that seems to signal something systematic is wrong with your app. That boilerplate code that makes something more tedious than it ought to be. That inscrutable thing that makes you want to stop trying and *gasp* search StackOverflow or read a blog post for an answer. And while sometimes the answers you’ll find there might tell you how to better use what tool or framework you have at hand, occasionally they will suggest you simply install some tool, which will do the trick without any consequences.

Don’t. Just don’t. Here’s why.

Twenty Years Of Programming

Twenty years ago, I took a programming class in high school, and I have been programming ever since.

I wish it were that simple. Back then, I wanted to study something creative. In my heart, I loved drawing and considered art school, or following my brother into theater. But in my mind, some technology field seemed sensible. After all, I appeared to have “The knack.” Our barely functional, barely one-year-old home computer was still working. I had figured out how to make simple games on my calculator. And, the dot-com bubble was bubbly. I was unsure.

In spring of 2001, one high school class triggered a fear in me, and helped me make a choice that shaped my career path to this day. This class presented interesting bio-ethical dilemmas with no clear right answers. Consider, for example, the best courses of action regarding euthanasia, or accounting for patients with conflicting medical and religious needs. Issues where either side could be supported or refuted. I found it unsettling that everything was subject to debate in this class, and worried that it was only preparing me for pointless discussion. In truth however, I was afraid of being wrong in an environment where right seemed not to exist or be certain. I balked and asked to switch classes. I did not realize at the time how long-lasting and short-sighted this decision was.

The programming course was split into two sections. The fall half focused on learning basic concepts using Visual Basic, and the spring half was data structures taught via C++. I had already missed that first part, but could switch if I successfully completed the upcoming assignment by the due date. Desperate to switch classes, I set myself to the task. After two weekends of playing catch-up, I turned it in. While the code for that first assignment was obviously uninteresting, it was good enough that the teacher allowed me to switch. My escape from uncertainty and subjectivity was underway.

I learned a lot that spring. I discovered that compiler errors were amazing. My early impression of programming was that almost everything I tried to do failed. I actually found this comforting; there seemed to be a definite limit to what was allowed to run. Making any assumptions was foolish. Programming was mathematical, scientific, and needed to be learned and understood. It was consistent, and unflinchingly fair with its feedback, and there was a permanence to “correct.” Instead of debating with a classmate or some teacher, I was locked in battle with the language and its acerbic compile-time messages. I also realized that my understanding of the problems always seemed to be ahead of my understanding of how to input the code into the computer. My early habit was to “program in English” first. I would write (on actual paper) what I was trying to do as an outline. And if I could not, I knew that I had no chance of teaching the computer how. These lessons remain with me today; the stacks of scribbled-upon papers and fondness for considering every possible outcome are a lingering testament to my hasty upbringing.

I did not continue enthusiastically into college, however. As I mentioned, my fears drove me. Some were reasonable, like concerns of success, or wanting to help my family financially. Others were problematic. I fixated on the lost time, and eventual poverty that creative pursuits might lead to. My young mind found comfort in the cold hard algorithms, and the safety of a field of expertise with unlimited growth. Between semesters, I did wonder what I would have done had I not taken that bioethics class. I wondered what I would have chosen to do if I were less sure that a creative field was so risky. As college wrapped up, I felt confident that I was still traveling an objective path of definite rights and wrongs, and that I had made a wise choice.

Time would teach me that many parts of being a software engineer can be equally subjective. In college, I saw the beginnings of this. I started hearing people debating programming languages and platforms. Later in work, the same thing would happen for frameworks or even tools for frameworks. What’s so bad about writing code you fully understand and control? Why is the popular technology also the best to use? For me, the calm came from creating things I fully controlled and understood. As I gained more experience, more time went into justifying technical decisions, and not whether they worked. I had not avoided subjectivity at all. I just delayed my confronting it.

Things changed again when my career success and progress gave me the illusion that I had escaped my fears. I got reacquainted with my loves and gravitated to the natural intersection of my skills and passions, focusing my growth around user interface development. I started to share my thoughts and opinions on related topics. I discovered whole disciplines focused on just interactions and interfaces. I went back to school for a Masters in Human-Computer Interaction, and broadened my depth of experience with User Experience Design. For years, I immersed myself in the subjective, and tried to fight through the discomfort of the unknown and unknowable.

My main output today is still software, but knowing these other worlds exist is still a big part of my day. When leading projects, I lean on the early lessons. I focus on how to describe goals primarily in human language. I fastidiously document what I do. I work as closely as I can with design and user experience. I play the part of the eventual user in discussion. I do all of these things, so that when I finally get to the code, I can focus solely on the therapeutic translations from idea to intent.

So, yes, I am still programming. But when subjective ambiguity creeps in these days, I tackle it head on.