I’ve increasingly noticed a clear bisection in how I think about writing software. On the one hand there is a broad ‘system level’ of thinking, used for architectural work, sketching out infrastructure and deployment plans, structuring APIs, finding root causes for wider problems, etc. On the other, there is a detailed ‘low level’ mode of thought - how to name variables, where to split up functions, when to make a new class, what needs what kind of documentation and what to put in it, when to make a commit and what to call it, and so on.

These modes are quite distinct, but definitely not separate; there is constant interplay between the two. For greenfield or feature work, it tends to start at system level, where we first consider the problem at hand, forming, discarding, and refining solutions that fit into whatever currently exists, and that are feasible to do. The process of discarding, however, often involves following the thought down the detail rabbit hole to a logical conclusion. Eventually we run into a problem that this solution won’t quite work for (or, sometimes, is a complete show stopper for the whole idea). At that point, either some change suggests itself and we loop back around with a solution refined to fix that problem, or we’re stumped and have to start over. ‘Starting over’ is not really a bad thing here - you still carry over all of the context and can generally much more quickly find more viable options, and end up with a better solution.

For debugging, it’s often the other way around. System level thought is probably sitting behind the scenes, guiding the search, but fixing bugs almost always starts with hunting through details for the cause of the problem. Then we continue into why it’s happening, often via what are the possible states at this point, and do we handle them correctly, and then starting to form a broader picture of how the bug can happen. It’s somewhere around here that switching back to system level thought is useful. Your detail brain has hunted down exactly why there’s a problem - but solving it is another matter. In a rush it’s tempting to stay in the detail mode, hack in a solution that works for this particular case, and move onto the next item on the todo list - but this often causes worse problems down the line. For a visual description of the process, it’s hard to beat this classic.

Beware too much of either mode. Overuse of the system level thinking will often get you precisely nowhere as you founder in architectural paralysis. Fixation on low level thinking, on the other hand, is the cause of big balls of mud (and other related patterns) where structure is sorely lacking, understanding every tiny detail is a must for even trivial changes, and you hate your job and whoever wrote this damn thing.

For me, getting into either state seems easier in different situations. Most of my system level thought is done walking, or in the shower, or laying on the floor. I’m not sure what these have in common, except possibly that they’re away from a keyboard. Also, they’re things our ancestors would probably have been pretty happy to be doing, probably leaving a bit more brain space free from worry, to explore. Rich Hickey’s hammock driven development is maybe the ultimate word on this. How to come up with an evolutionary, maybe revolutionary, and now much loved new programming language? Spend as much time in a hammock as possible for two years, and think really hard.

Low level thinking, on the other hand, happens almost entirely at the keyboard (except when it’s interspersed between systems thinking, as mentioned). I think the power of comfort with the likes of vim or emacs, maybe, secretly (?), come from their magnification of abilities at this level. By freeing programmers from worrying too much about the tedium of textual manipulation it frees up a little more brain space to work with the ideas of code, not just the strings of characters on the screen. Source control definitely does this by freeing us to never be scared about changes, and to be free to rework and combine them in whatever order makes the most sense.

Interestingly, I find writing follows a similar pattern but on a much more condensed timeline. The system level thinking is about the topic, and the overall structure of the writing, whilst the low level thinking is concerned with individual word choices, tenses, sentence structure, use of punctuation, and so on. The two maybe have the most cross over when considering ‘tone’. How your writing ‘sounds’ is very much a product of the low levels details, the craft work of stringing words together in the right order into (semi) coherent sentences, but at the same time it must feel correct on a wider scale. Mixing tones too strikingly in writing is an excellent way to neuter the point of whatever you’re writing. Small bits of tongue in cheek here or there in a serious essay, or an important point written somewhat more seriously in a casual message provides good tonal variation to hold a readers interest, and convey subtle queues that are often missing from written communication, but adding one liners to a company financial report is unlikely to go down well (unless it’s been a really good quarter), no matter how well written.

Indeed, writing so closely involving both these modes of thought probably explains the common idea that writing and thinking are largely synonymous. Thinking clearly at both, conflicting but complementary, levels of thought is necessary to write well, and often the process of engaging in that thought brings forth ideas as if of their own accord.