Human code

A little-shared perspective on the nature of code is what you can learn about a person from the way they write it. I had something like this in mind when I wrote about Programming as Conversation, but at that time I hadn’t read as much code written by AI. I’m not going to get into issues such as productivity, code quality, software metrics or best practices; these are matters for the industry, and now I want to talk about programming as a human activity.

I think I can remember every time I have felt the impression of another person when reading their code. And I am talking about interacting with code on a daily basis; not reading a file or a pair of functions, but reading, day after day, the lines written by another person; understanding a system they have created. When we talk about narrative texts, poetry, diaries, letters… the presence of the person reaches us through human language, the same language they would use to talk to us on the street. However, in code, the impositions of a formal language and the definition of an algorithm are mixed together. Even so, the programmer’s personality shines through in their knowledge of their tools, their understanding of the problem to be solved, and the way they express these solutions, even when mediated by conventions and standards. Often, we programmers like the code to have a certain look, a certain way of reading; this then becomes style conventions, but it starts out as a personal choice pursuing some subjective legibility. Even the absence of this intention builds an identity. It happens to me even when I read my own code, that I feel a reminiscence of how I was when I wrote it; what I was interested in trying out, what techniques I had become proficient in, or what knowledge I did not yet have.

That’s why I’ve sometimes felt that reading code creates a small sense of intimacy. It’s a little window into how another person’s mind works. When working on team projects, you can recognise the author of pieces of code at a glance without having to ask. And I find this form of knowledge endearing, even when I curse the person who wrote such spaghetti code. Because other times, if it’s good code, the author tells you how to program better; and when it’s not, you get to share the confusion they may have had to endure, or at least empathise with their level of experience, because we all started somewhere.

When I am programming a slightly more complex system, I feel like I am holding a small building in my mind, and when I translate it into code, I leave it imprinted on it. Like any creative technical process, it can sometimes feel lonely. And when I read someone else’s code, when I see their choice of architecture, what practices they use and which they don’t, I reconstruct the building that they held in their mind at some point. It’s like putting yourself in their shoes. By doing this many times, you become familiar with their way of working, you recognise how they structure the code, how they name variables and functions, how they segregate responsibilities, when they decide to stop nesting conditions, what data structures they prefer, how they like to process data collections, their inclinations within programming paradigms…

Each programmer’s style is like a kind of calligraphy, a speech accent or a collection of catchphrases and even swear words. It’s not something that should matter in the industry, but it is something that sometimes just appears. And I wanted to talk about it, because from the outside, it seems that code is free from the humanity of its programmers; and nothing could be further from the truth. In the era of LLMs, this is changing; and I’m not making a value judgement, but there is something I wanted to highlight. Many human activities, even if they are delegated in many cases or automated for consumption, are not going to disappear from the lives of those who practise them, simply because they are inherently human; and as a technologist, I have always felt that programming is one of those activities.