Driving Isn’t Like Riding; Building Isn’t Like Using

I’ve made no secret of the fact that, at 55 and after 35 years in I.T., I’m learning to code “for real." And some of this journey is far from comfortable. Some of it is downright frustrating and difficult in ways I didn’t expect and feel (albeit without justification) it shouldn’t be.

It took a drive in the car with my son to put it into perspective.

My son was learning to drive. Out of the “roll around the parking lot” phase and beginning the “let’s drive some back streets,” he’d already shown a thoughtful and measured approach to the process. He wasn’t timid, nor was he overconfident. So, after tooling around a bit and making sure he had the basics of stop signs and right-of-way, I asked him where he wanted to go. He said, “How about the comic shop?” (my kid, right?). I said, “OK, let’s go.”

He pulled over, thought for a long few minutes, and then said (somewhat sheepishly), “How do we get there?”

Mind you; this is a place he rides his bike to WEEKLY. And we were right around the corner from our own house, not in some strange part of town. I figured I just had to get him moving in the right direction. But even after a few streets, he was still asking me where to go next. It was like he was navigating a different planet. Which, in a way, he was.

Everything looked different on the driver’s side, he later explained. The mental load of operating the car made every single street a new and somewhat foreign experience.

This brings me to my main point, the part that’s probably most relevant to folks reading this:

I’ve been using software for over 40 years — from the time programs ran off cassette tapes and you accessed remote systems through 300 baud connections. I’ve been identified as an “expert,” a so-called “power user” of various applications across those four decades. Figuring out the most complex, nuanced capabilities and commands was exciting. Learning about so-called “undocumented” features made me feel like an elite, almost wizard-level operator of the software. The drive I felt was so powerful I was able to transform a high school hobby into a career.

But now I’m moving from a user of software into roles where I’m learning to actually create my own applications. And as I begin to learn how to really code (more than just the simple and simplistic scripting I’ve done in the past), I find that creating the interfaces, workflows, and routines like the ones I navigated with such ease as a user is a completely different world.

First, there’s an entirely new set of interfaces that are essential but new. IDEs and their methods of displaying and formatting code; repositories and their unique terminology and commands to add, change, and remove files; the culture and process of participating as part of a development team — contributing discrete elements instead of just writing the whole thing yourself; and the necessity, let alone the process, of using other people’s work in the form of libraries, modules, and code snippets.

Next, I have to contend with the situations and assumptions of the world I’m now navigating. It’s no longer a given that a program, application, or even a web page will even start, let alone run the way I expect or intend. In fact, it’s far more certain that it won’t work correctly, at least initially.

The harsh truth of the innate broken-ness of things was captured perfectly by my friend Yechiel Kalmenson in his talk “Talmudic Truths For Programmers," when he quoted Rust core team member Steve Klabnik:

Programming is a movement from a broken state to a working state. That means you spend the majority of your time with things being broken. Hell, if it worked, you’d be done programming.

Finally (for now), I’m experiencing the same disorientation my son did when he first sat behind the wheel of our car. Getting to familiar locations — like a sorting function, text formatting, or even “find and replace” — feel alien, as if I were navigating familiar software but with all of the menus scrambled and written in Hungarian. I find myself asking coworkers and mentors for the equivalent of turn-by-turn directions.

What am I — or indeed anyone who is starting their journey into the world of development — supposed to do? Certainly, the idea of giving up is no more valid here than it would be to stop your car in the middle of the street and walk away from it.

Instead, we have to accept that just our work building new applications is “…a movement from a broken state to a working state…” so, too, are our journeys. We have to trust we’ll move naturally and at our own pace — from the awkward stop-and-start jerkiness of new drivers programmers; to slowly navigating side streets of the code base with a “student developer” sticker in our back window, all the way to being confident coders who can parallel park pair program with the best of them.