Co-de/velopment
GINNY FAHS

When you’re bored on the hiking trail after a long day, inevitably, a few things can happen. Someone might propose a singalong. Someone might introduce a riddle. Or, the recommendation will arise to make up a story as a group. This is never a good idea.

You’ll start by taking turns, each person contributing a single word. Wobbly sentences will take shape. Mere minutes in, everyone will secretly hope their turn lets them contribute something easy like a preposition — nouns and verbs require work. Eventually a noun is needed, and someone throws out “zombies,” and things get especially terrible. We don’t know how to write stories together.

But this is exactly how we build software.

Software development has a reputation of being a solo endeavor: the lone hacker typing fiendishly in a dark bedroom. But like stories on the trail, any notable app was built incrementally — tiny piece balanced on tiny piece — by a team of individuals.

If the process of software development had a shape, it would be a braid.

Cloud Cities installation by artist Tomás Saraceno at SFMOMA in 2016 | Source: SFMOMA/Instagram

I’ve just enrolled in my first online coding class. A history and literature major, I had always been the least tech-savvy person I knew, and I decided that was something I wanted to change. I stuff coding tutorials into my early mornings before work and develop a taste for coffee. Bring on the accidental infinite loops, the tragically misplaced semicolons.

I’m starting with Ruby, an object-oriented language, which essentially means that the code creates “objects” that hold data and pass messages to each other. It reminds me of writing fiction: objects are characters, their traits vivid personality quirks, their behavior scripted. You set them up, give them rules, then press play and see what happens.

Seven weeks in, it’s time for an assessment. We’re asked to use Ruby to model a spaceship that can depart and land in different cities, making deliveries within a max weight capacity. Cross-legged on my green velvet couch, I write rules in different combinations, trying to get my spaceship moving. The program starts behaving just as I hit the three hour time limit. For the first time ever, I feel like a computer charmer.

[The] imaginary world of [the] application takes shape, its topography faint but visible.

Fast forward seven days. I’m between errands, flipping through my phone at a crosswalk, and receive the undesired news: I failed. It wasn’t until a phone call with my advisor the next day that I understood how I could get so much “right” and still fail the assessment. Indeed, my code had run. Indeed, my spaceship had satisfied all the criteria. But the code was sloppy and unintelligible — something that would be nearly impossible for other programmers to work with.

Programmers have terms for this. “Spaghetti code” refers to code that runs fine but is so messy that it’s incomprehensible to other people; “code smell” describes the feeling programmers get when they sense something in the code is off, even if the computer is unaware. To become an effective programmer, I’ll need to internalize programming conventions I didn’t realize were there, developing a style that is meaningful to both people and machines.

Goto (Source: XKCD)

Goto | Source: XKCD (CC-BY-NC-2.5)

In August, the sun breaks through San Francisco’s fog; strawberries and cherries line the farmer’s market. At this point I’ve left my marketing job, and I’m in the thick of a “coding bootcamp” program, working on my first ever group project.

We’ve agreed on our objective, but before writing a single line of code our group huddles around a whiteboard. We decide on the structure of our database, its shape, the names we’ll use to refer to its parts, how the parts will talk to each other. We draw pictures of how the application will look to users and map how the database will feed our designs. Slowly the imaginary world of our application takes shape, its topography faint but visible.

Until now, the act of coding has felt like writing a diary entry: I’ve had free reign to code without worrying about voice or presentation. But a group project is like contributing a new middle chapter to an already-written novel. I need to read my teammates’ code, develop a sense for who our characters are, how they interact, their comings and goings, before adding a new plotline.

A work by digital artist & software developer Casey Reas | Source: Casey REAS (Archive)/Instagram

And when I do add a new part, I need to be careful not to overwrite or contradict my co-authors’ work. We have one codebase and five people who want to add new code at the same time — like five people all simultaneously trying to amend a static Microsoft Word document. Programmers overcome this limitation with something called “version control;” it’s a system for recording changes to your files over time, so you can easily recall past versions.

For this project, we decide to use git and GitHub as our version control systems. Managed by a series of ‘git’ commands, our workflow has a rhythm: download the most up-to-date version of code from GitHub in the cloud, perform a spiffy “Save As” (called branching), make changes and additions on our personal computers, then “push” the branch full of new code up to the cloud, and check to make sure there are no conflicts when we merge the code together. The workflow demands constantly comparing one’s personal version of the code to the group’s collective version, and only letting the two combine when it’s productive for all.

If the process of software development had a shape, it would be a braid.

There’s an element of citizenship embedded in strong collaborations — a commitment to making the working relationship sustainable and smoother overtime.


A few more months pass, and behold: it’s my first day as a bonafide software engineer. I’m working for a tech giant and will finally be entrusted with “production code” — code that is part of a product people use every day. This is a huge responsibility. A single typo could bring down the entire system and cost the company millions. For every minute that Amazon was down in 2016, the company lost over $203,000; so in 20 minutes of outage, $3.75M evaporated. Our orientation teacher kindly reminds us that within a minute of a major mistake, we may no longer be worth our salaries.

Good Code (Source: XKCD)

Good Code | Source: XKCD (CC-BY-NC-2.5)

As such, the process of contributing new production code is stringent. The version control we learned in bootcamp is the tip of the iceberg, floating amidst a vast sea of rules and checks. First, all new code we contribute needs to be thoroughly tested. This means that every time I write new code, I’ll also need to code up test files that ensure the code is working properly. There’s a metric around this, “code coverage,” which expresses the percentage of the codebase that can be linked to an accompanying test. Code coverage will be used to indicate the overall health and quality of our codebase.

Once the code and tests are submitted, they are formally reviewed by other software engineers to confirm human-friendliness. We check one another’s work for appropriately-named variables and logic patterns that are easy to follow. It’s important that we all become acquainted with new code, because as soon as it goes into production, we work together to maintain it. Similar to how doctors go on-call, engineers have on-call shifts. We get paged at all hours, day and night, to revive broken programs: the coding equivalent of CPR.

Teammates aren’t the only collaborators in software development. Developers also write pre-programmed bots that serve as allies and partners in the process. Before “landing” new code in the live, functioning codebase, the bots run scripts to check for the proper authorizations and configurations. They will literally block the code from entering production until every automated rule is satisfied. With humans programming bots that check the human-created code, code contribution itself becomes a feat of engineering.


One would think that for a system this intricate, errors would be a rare occurrence. Not so. The codebase changes rapidly — engineers deploy new code every 5 seconds at some of the larger tech companies. And since new code is the most likely culprit of any bug or outage, things constantly break. I suspect that the apps you use most regularly withstand dozens of outages every week.

Fixing broken production code is time-consuming and pricey, but each bug unfurls precious information to an engineering team. It is a case study in how to slither past the tests, the human brains, and the army of bots unnoticed. A bug signals to engineers precisely where the system is failing.

We get paged at all hours, day and night, to revive broken programs: the coding equivalent of CPR.

There’s an element of citizenship embedded in strong collaborations — a commitment to making the working relationship sustainable and smoother overtime. Engineers take this very seriously. In the face of an error, an engineer’s immediate job is to fix the bug. Her second priority is to adapt the team’s workflow such that the same mistake can never happen again.

It feels fanciful to believe that a bug could truly make the codebase stronger, but for the best engineering teams, it is a fantasy within reach. To use Nassim Nicholas Taleb‘s term, good codebases exhibit antifragility. Contrary to fragile things that break irreparably, ‘antifragile’ systems experience more upside than downside from a destructive event; the stress invites a better process. The Greeks had another word for this: hormesis — getting stronger under harm.

 Network

In being stretched to your limits, you might be at your strongest

Back on the hiking trail, the group story has fizzled out and you’ve settled into easy silence. Without the distraction of language, you’re more focused on the terrain and surrounding chaparral. That banana slug stuck on redwood bark, the subtle bubble of root structures that have anchored storeys of trunk and billions of leaves for thousands of years.

This forest has persevered through fire, rain, drought, and bolts of lightning — growing stronger and more magnificent through it all. It’s taken an entire ecosystem, working together, to protect its beauty. If nature can adapt to the chaos, perhaps one day we’ll get there, too.
 





Leave a Reply

Your email address will not be published. Required fields are marked *

*
*