On the Activity of Programming

Watching Ruby on Rails: The Documentary, and hearing David Heinemeier Hansson sharing how he sucked at programming reminded me of my own experience.

Learning — early struggles

It’s strange to recall how much I sucked at programming myself in university. And I was in the computer science curriculum! I think I was simply unable to write any functional program. Small functions were OK. In retrospect, I think it was hard for me to build a significant construct, without having seen one, i.e. having read and studied existing code. Also the jump from simple functions to a whole program was a pretty big leap.

I specifically remember about a Pascal assignment in the first year, where I was completely helpless. The tutor was kind enough to pair with me and actually coded most of it. I thought: “OK, it’s clear I’m never going to make it if I ever have to program again!”.

From that moment on, for programming assignments, it so happened that I joined groups where I restricted myself to administrative tasks like writing the report. I remember about an assignment in C where we had to write a simple in-memory database for a wine store. I was very impressed by the code written by my group mates, I thought again: “I could never have written anything like this, not even contributed!”

So basically I spent my education years in computer science avoiding programming and succeeding pretty well.

Practice — a different angle

The curriculum included two internship semesters. The first internship was great as I got to contribute to an existing project in Perl, which I found very straightforward to work with. The second internship was a failure, because I was asked to solve problems in a technical environment and a business domain which I knew nothing of. So without proper mentorship, I did not do great.

Eventually, soon after university, I landed a job as a system administrator. This was for me a very interesting segue into the professional world.

First it helped me understand the context of many things we learned in university. Networking and Unix for example. I remember compiling and running the Apache web server one day and having an “aha” moment: O-K so this is how everything fits together (source code, C programming, operating system, network stack, browser, internet, etc.). I’m very grateful to open source by the way, as it helped me learn a ton by myself all along.

Secondly, the job didn’t require much programming but, being exposed to so much great open source software, I grew a keen interest for it.

I believe this experience was a pretty strong differentiating factor, in a good way. I think most of my peers go the other way around, when they do: from the specifics of programming to making stuff run in production, from dev to ops if you prefer. My path gave me a good holistic view early on. I also usually get along well with SRE people.

At some point I shifted to proper programming. So after around 8 years of professional experience, I felt proficient enough to write some kind of useful software by myself.

But enough with historical context. What about the activity of programming itself?

State of mind

Programming is a peculiar activity I find. It’s very intellectual and abstract. I wasn’t really aware of this until, one night of programming, I realized I had lost awareness of the surrounding reality for a moment: pausing and emerging from coding, I wasn’t sure what time or day it was, nor where I was. It really only lasted a couple of seconds. This is called derealization.

Let me elaborate. So when I dive into a project, I have all these files open in my text editor, which I navigate constantly to build a living understanding of the program. The files are also open in my mind in a way. Code and ideas accumulate in mind. I try to focus on what I want to achieve, like implementing some functionality, but at the same time, I keep my mind open to emerging ideas (“oh I need to check this later”, “oh this could be interesting to explore”). It is liberating in a way: having the freedom to explore all options and refine the solution as much as I want, at my pace. As if there was no time.

More often than not the challenge is to build an understanding and reach a clear vision of what to do and write. For me this requires a lot of research, exploration, experimentation.

It’s important to note that this derealization experience is about programming late at night, on personal projects. This is quite different from programming during the day for a living.

Programming is also usually a lonely activity. I do love pairing, which we do very often at work. But when working on personal projects, I found it hard to find mentors or even just peers interested in the same topic at the same time. Essentially, hacking on personal projects is for me a learning process. So it’s expected that the progress is individual, but it’d be nice to have some collaboration, like a study group. In this regard, I love MOOCs.

I recall movie scenes of people working on a computer, hackers for instance. The camera revolves around them in overlapping fade in-and-out’s, maybe also with overlaps or incrustations of windows or terminal output. As an attempt to express the passing of time and the isolation of the mind I guess…

I feel like this doesn’t render the activity accurately. And I was never impressed or captivated by these scenes to be honest. The way I see them, these scenes show things from the outside. So how would we render the act of thinking? Maybe like in documentaries where the narrator’s or interviewee’s explanations are illustrated with some sort of animation? But how do you illustrate the evolution of abstract ideas captured by code? I don’t know. Maybe this activity is simply outside figural visual representation, or auditive for that matter.

I mean programming is obviously very concrete and precise, it’s just that the mental state is less… palpable. Which is, I realize, probably the case for many (all?) mind activities: they can only be represented by their physical manifestations, if any.