So, I was musing in the bath (as one does) about things like theory of mind - that is, the concept that different people’s minds hold different information. It’s usually something that human beings develop early on in life when they’re constructing mental models of the world. And that got me thinking about how everyone’s brains do things a little differently, like how there are varying degrees of internal monologue or visualization in different people and how that drives and impacts their different modes of thought. And then, I thought about programming, and how little it seems that programmers talk about how it feels to write code and how that looks internally. So, I thought, hey. Maybe I should write a post about how it works for me? Maybe other people will also come forward with how they feel their mind works when writing code, too?
Note: apologies if I get a little abstract here. I’m trying to describe with words something that happens in my own head!
“The Structure” 🏗️
So, when I begin to write a piece of code, the first thing that tends to happen (after the usual fiddling with my editor and getting settled into my chair, getting a cup of coffee or opening a snack, getting some music on, etc) is that I start to conceptualise an abstract “structure” of ideas. It is The Structure. That is, some kind of organised lump of patterns and methods and data structures and functionality that I feel comprises a solution to the task at hand. It’s a part of my general problem-solving skillset, I think - the ability to start generating pieces of abstract “solve-agents”.
It starts off like a tight little curled-up ball of ideas, a cluster of too many things at once to really make sense. But it’s the start of something, a seed, and it is the basis from which I begin to write my code. And on some days, when I’m still sleepy or if I’m already tired, or if the weather isn’t right or I’m not feeling well, that’s how it stays. This little nugget of Idea, that stays as it is, not particularly useful. But when I’m in the zone, along comes…
The “Unfurling” 🪴
Code is a means to an end. It is not fundementally important to me which language I use - although I have favourites and arch-nemeses, just like anyone else, it only exists as a vehicle for me to explore The Structure. It’s a means by which I can translate The Structure into action, into intelligibility. And when I do that, when I start transcribing parts of The Structure, it starts to kind of open up, and unfold, and branch out. New ideas, new patterns, new areas spring up almost out of nowhere and I start following them - and like fractals or tree branches those blossom into more, smaller ideas, and I pick the paths I want to take and I transcribe those with code, fleshing out my initial ideas, and before long, I have a workable (if maybe inelegant or brittle) solution.
The branching and unfurling happens usually a few moments before I hit the keyboard - I can visualise and conceptualize the new solutions and ideas and evaluate how useful they might be before committing to them; I don’t follow The Structure blindly.
When I’m able to follow this process properly, in a language I know well, I find it is rare that the code doesn’t compile, or that the solution doesn’t work first time. Naturally, it doesn’t always shake out that way, and none of us should avoid writing tests and verifying the code actually does do what it should, but it’s something I find a great deal of joy in when things shake out right.
But sometimes, there are…
Mental Pitfalls 🕳️
As I carry on my merry way along The Structure, unfurling branches hither and thither like some druidic botanist, trundling along without a care in the world, I can find myself getting ensnared in what I can only describe as mental pitfalls. I’m going to see if I can come up with a quick taxonomy of these:
Extensively Long Branches
I fall victim to this one most of all; I can’t help myself but follow the unfurling of The Structure along some obscure path. I start writing in code for edge cases that bubble up out of my mind’s tarpit, to solve problems that I haven’t found yet, to put flexibility and functionality into code because “I’ll probably need it later.”. Usually, I do not need it. Usually, I either shoot myself in the foot with an architecture that does not work when I do need similar functionality in the future, or it becomes unwieldy and difficult to maintain for behaviour that is literally never used.
The dark twin of Extensively Long Branches, this is when I start implementing other supporting functionality for my new functionality (which, let me be clear, is useless), and then I need to write new functionality to support that one, and so on. I end up going around in circles for hours building and building and circularly coming back to these older ideas and rewriting or pushing on new bits. Ridiculous!
Sometimes, I’ll follow an idea out into its remote reaches, and everything seems fine - until suddenly, without warning, the branch seems to detach itself from The Structure. It feels like the code I’m writing is pointless, or cannot ever be finished, or that the work ahead appears too vast. I can’t discover why I wanted to write it, or what purpose it had, and sometimes this feeling is accompanied by a quiet dread. The temptation to just
Ctrl+A, Delete it burns very brightly, and I usually have to take a break when this happens to distance myself from it, and end my coding session. Sometimes on re-evaluation later, it looks fine and I can get back into it, and sometimes I realize it was one of the other pitfalls, and I sigh and wipe it.
Hyperfocus and Fervor
While I’ve never been tested or diagnosed for ADHD, I very much resonate with and understand the subjective experiences people share about the concept of hyperfocus; where everything but the task at hand is blotted out, even basic needs like eating or drinking. I am no stranger to this effect, and while at times it seems useful (or even fun), it is fundementally uncontrollable and unhealthy. At its worst, I find myself falling more rapidly into other pitfalls, but in a state of such fervor I merely carry on, tiring myself out and ultimately producing little of value.
These, I think, encompass the majority of my weaknesses in my mental model of how I problem-solve and write code. But there are also some advantages!
In a similar taxonomy to the above, here are some of my self-observed advantages to The Structure.
Symbolization and Syntactical Parsing
I find that when I’m at my productive peak, I tend to think less about the specifics of the code I’m writing and more about it in terms of “blocks” - the raw components of what I call The Structure. It helps me to distance what I’m expressing in code from the particular syntax of the language - once I know the rough analogues of how each language expresses the same ideas, I don’t find it difficult to learn that language, use it in earnest, or recall it when I need to. I attribute my recent enjoyment and success with assembly language to this concept; understanding how to express certain ideas in assembly enabled me to write things more complex in it than I’d previously thought myself capable of. This leads onto…
Comprehension of Other Code
While reading other people’s code and their codebases is always initially confusing, I’ve found that I can get to grips with a new codebase relatively quickly. I can “zoom out” from the names of variables and functions that are being used and see, in my mind, a hazy reflection of The Structure; I can make inferences about why and how parts of the code work together, and as I read, I am quickly able to adapt that model to adjust to the reality. I can hit the ground running and start contributing quickly, this way. I think this also helps me to write code in ways that express The Structure to other readers; to name my types and functions and organize my data in ways that may be more intuitive to others. Or, maybe not! 😜
On Joy and Wrapping Up 📦
In general, I’m pretty satisfied with the way I write code and how it feels to me. When I’m happily unfurling The Structure and mindfully avoiding the pitfalls, I get into a groove that leaves me genuinely very happy with the overall process. I find a lot of satisfaction and joy purely in those moments, and it’s a big reason that I sit down and code for a living, and as a hobby. Burning both ends of the candle, maybe, but I’ve learned a lot of lessons from burnout about both pacing myself and trusting myself when to stop. I realize this might be an alien expression of positivity to some programmers - I feel like I see posts and memes on social media more often about how coding sucks, only freaks enjoy it, and how it’s just something you struggle through and are relieved when it’s over, moreso than about how it’s fun or satisfying. But, please understand - nobody has to love it to be good at it or make a living from it! Personally though, I’m definitely one of those freaks who enjoys it.
This post got pretty long, and it might just be a bizarre ramble that makes little to no sense to you, the reader. Or, alternatively, maybe some of this rings true? Either way, please let me know on Twitter or email what you think, and how your coding process works. One day, I might write a follow-up post about all the different ways people describe programming to me!