Software is Made by Humans. Part I.

The reason I got into programming as a teenager was because of video games.

I mean, I always liked computers generally–I was fortunate to grow up in the Cupertino area, and my dad was a software developer who would build random computers for my brother and I out of old hardware from work–but it was really video games that got me excited about computers.

In particular I loved Blizzard games: I remember begging for the Warcraft II Battlechest at Costco, Starcraft, Diablo II (which I was not “allowed” to play so played at friends’ houses). These were all games that I spent many of my waking hours obsessing over. When I would hit my limit for hours I was allowed to spend on the computer, I would pull out the manuals and read them over and over, trying to understand the mechanics and analyzing the rules systems, copying the art in notebooks, and imagining playing and making my own games.

In middle school a group of my friends made a website for their Diablo II clan, and it was rad. It had all these cool dropdowns, little animations and dynamic widgets, persistence, authentication… I asked them how they made it and they were like “wouldn’t you like to know.” I had done some HTML, but didn’t know about Javascript or any backends or databases. This exclusion from some secret knowledge, in tandem with the announcement of Warcraft III¹, drove me to ask my dad for some help. My dad responded by printing out a stack of pages for a PHP tutorial from the PHP DevShed forums (I didn’t have internet access on my computer). He had a very throw you in deep end of the pool and let you drown for a bit style of teaching.² This was my introduction to “real” programming.

Growing up in Silicon Valley I learned all about certain software legends, and slowly an image formed in my mind of what it meant to be a great developer: you were sort of an opinionated mad “genius” and you would do things like write your own operating system, programming language, version control system, etc., in a few days of caffeine driven rage.³ Then people would praise you for being so smart and you would get to tell people how to pronounce the name of the thing you made.⁴

Almost 2 decades since I decided I wanted to make video games when I grew up… where are all the video games I wanted to make? 👀

Turns out making games by yourself is hard. I didn’t know that I needed so many skills to make cool art, models, rigging… Not to mention the game design, the graphics programming, the music. There is a lot more to making the kind of game I want than one person can handle. That truth holds for more than just game development: it is the truth of most all software development.⁵

My teenaged mental model–the lone wolf code hero unix hacker chugging Code Red and eating pizza by the light of their dark themed text editor and listening to some sweet beats uninterrupted in their audiophile headgear–was wrong.

And that long winded intro brings me to my theme.

Do you believe that taking time to think before writing code is unproductive?

Do you believe that teaching, learning and elevating those around us is a waste of time?

Do you believe that you can make better software by routinely burning the midnight oil?

Do you believe that sacrificing a healthy life and balance will make your software better?

Do you think that if everyone just left you alone in “the zone” to hack that you would make a great product?

I see lots of conversations around these questions, and others like it. And it seems that the majority (at least in my circles) would answer with a resounding “no” to all of the above questions.

I think most of us agree: software is a collaborative effort, and we can build better software together. We agree that making a great product is not a sprint, and that as knowledge workers, our value is not in lines of code written, tickets completed, or widgets produced.

High performing teams will out perform any single individual. This is why businesses build teams.

Then why do we still use tired arguments like “X slows ME down”?

For X we could subsitute Test-Driven Development, Pair Programming, Open Offices, Meetings, code reviews, design reviews, pretty much any part of any process ever… the list goes on.

This is not an effort to sweep all critiques of the aforementioned under the rug. But, if you truly believe that software development is a long term, continuous team effort, then you must be willing to sacrifice your perceived optimal personal productivity.

You must optimize your processes around the values and goals of the team, not your individual “flow.”

Too often, despite our agreements and platitudes on teamwork, we sometimes seem to still struggle to discard the last vestiges of my teenaged software development mental model.

It turns out that my teenaged myth of the programmer god was not just wrong, but often toxic. Look at the damage in certain communities, e.g. Linus Torvalds’ notoriously abusive behavior. We have probably all seen or been on teams where the “smartest” person on the team was a person that maybe most needed to be fired.

Many of us have felt unsafe or uncomfortable when we think about that critical piece of code that one person wrote and no one else understands (please don’t leave). Some of us may have been awoken in the middle of the night by Pager Duty and tried to figure out what was going on in some of that code after they have left.

To be clear, I don’t believe you are toxic if you don’t agree with me about TDD or Pair Programming, or that you are a bad person if you have written that code (I would like to officially apologize to all my Instructure iOS colleagues for rewriting all our networking code in Reactive Cocoa).

What I do believe, is that we need to stop framing criticism of practices in terms of personal productivity and the coveted state of “flow.” Instead we must focus on the practices that will help our teams achieve “flow.”⁶

There is an analogy I heard once about oxen and yokes. Now, don’t read too much into this (human workers are certainly not livestock), but the analogy goes something like this:

A yoke slows down the fastest ox to the speed of the slowest ox, but allows them to collectively pull more than they could individually.

Reframing every practice and process in terms of the values of your team and organization, rather than your personal values, is key to the success of your team.

Thank you for coming to my Ted Talk.

This has been Part I of “Sofware is Made by Humans”, an introduction to a series in which I am improvising as I go along. I want to talk about a few things in later segments: at least Pair Programming and Test Driven Development. I also want to touch on themes around eliminating team silos, diversity, inclusion, open offices, and meetings (collaboration). To talk about these, this initial framing of the conversation is crucial. Practices must be aligned with your organizational values. If they are not, they will fail. Also, practices will require an understanding of the principles upon which they are built. I hope to discuss all of these in more focused blog posts assuming I don’t get burnt out on blogging. It’s been a long time though since I’ve blogged consistently and I am trying to rekindle my passion for writing, but I am having fun for now.

1. I sometimes forget in those days how pliable Blizzard release dates were. I would check almost daily on the development blog for any tidbits, screenshots, any update. And all it did was get delayed and delayed (who knew software was so hard!). By the time the game was released my original clan website I made had been done for years.
2. I actually gave up for a while trying to learn PHP because I wrote all the code in a text file but it didn’t tell me I needed to run a CGI server (or how), so I kept trying to load my PHP files in a browser like I had done when learning HTML.
3. I wrote this blog post in such a fit of rage. Forgive my lack of editing.
4. My image of a great software developer at that point was always a white man, likely largely due to the fact that all the “legends” I was exposed to were also white men. I didn’t become aware of the problematic nature of this common image til later. Diversity and inclusion are an essential thing to remember as we discuss “Software is Made by Humans.” I hope to tackle it later.
5. and probably all product development, every business, every community, society, and the world.
6. I used to be a huge fan of the idea of flow, and now I use it in air quotes because I am mostly critical of many of the concepts and surrounding culture. I feel like it is one of the the snake oils of the productivity nerd community.