Let's Graduate From "Coding by the Rules"!

A glimpse into tech history! "Old Computer Books" by Kevin Saetz. CC-BY 2.0.

I have a confession to make: I rarely read, let alone finish, books about software development.

I have been coding since I was 12 years old, and I can count the technical books I have finished on one hand. Since I became a professional programmer 10 years ago, the only tech book I finished is "Clean Code“ (and maybe only because I read it at work). And while I attend a lot of tech meetups and conferences, I don’t recall many times when I applied what I learned there.

Still, my technical skills allowed me to graduate with a master’s degree in Computer Science. And to work at some pretty selective tech companies. I used to feel very guilty about my apparent inability to learn from our body of "professional wisdom". But nowadays, I believe these means of learning are not very helpful, and might even be harmful.

Extensive verbal instruction considered harmful

Book cover of “The Inner Game of Tennis”. Source: Goodreads

On the blog of a fellow engineer, James Stuber, I discovered a 1970s book in tennis education. In "The Inner Game of Tennis“, W. Timothy Gallwey speaks about an embodied and an intellectual way of learning sports.

The embodied way is via personal experience and imitation. The intellectual via verbal instruction and reading. What surprised me: The intellectual way not only doesn’t produce results. It actually hinders effective tennis learning. It makes tennis students more critical of themselves, taking them away from reacting from intuition at the moment. Read that again: Most verbal tennis instruction is not only unhelpful. Because it feeds the inner critic, it is actually harmful.

“Hello, world!” in Turbo Pascal. Source: Progopedia

I believe something similar is happening in learning software engineering. My earliest successes learning how to code were not from reading books on PASCAL syntax. They came from playing around with short code snippets that my mom gave me. Specifically, from observing what happened if I changed different parts of them. Some changes would cause compilation errors. Some changes would change the text, the color of the screen or put the cursor on a different position. How exciting for a 12-year-old! I was building an intuition of what worked and didn’t, rather than receiving verbal rules about what to do and what not to do.

Now at some point, you have to learn the basic syntax rules of your programming language. And how to write your code in a way that your fellow coders will enjoy reading it. And how to design the architecture of your service in a way so that it doesn’t fall over when more than 100 requests hit simultaneously. But most of this can be learned much better from experience. From working with more experienced colleagues, From trying and failing. From trying and eventually succeeding.

Coding as a process of building an intuitive understanding

The book I discovered in my uni's library. It is sadly out of print now. Source: Goodreads

In my uni's library, I discovered an essay by Computer Science pioneer Peter Naur. He argues that the core activity of a software developer is building an intuitive understanding of the problem to solve. The resulting code is just an expression of that understanding.

Naur recounts a study where two teams were passed on a legacy software system to maintain. The first team was given extensive documentation of the system. The second team was given in-person access to the original developers. Only that second team could keep the legacy system running and extend it over a longer period of time. The first team couldn't access the embodied intuitions developed by the original programmers. They ended up damaging the original architecture with their changes. And turning the system into an unmaintainable mess.

Let’s all appreciate our intuitions as tech professionals more. And when we do want to pass on our experience to others, let’s do it in a way that builds rather than blocks their intuitions!

How can we lean on our intuition more?

Tennis educator Gallwey shares a lot of advice on how to instruct the embodied self.  “Embodied self” and “intellectual self” distinguish two different moves of learning and processing information. The “embodied self” is the self that operates based on intuition, fast reactions and physical movements. In contrast, the “intellectual self” operates verbally and through slow, deliberate thinking. (Gallwey calls them “Self 1” and Self 2” throughout his book.)

Galwey's examples for translating "Technical Instruction" into "Awareness Instruction". Source: Inner Game of Tennis, Ch. 5, "Discovering Technique"

 Gallwey recommends this process for changing habits:

1. Observe your current behavior non-judgmentally 

2. Picture the desired outcome

3. Trust the embodied self to make the desired behavior change

4. Observe the change and its results non-judgmentally

5. Give credit for any success to the embodied self rather than the intellectual self

In the table on the right, Gallwey provides some examples of how to translate “technical instructions” for the intellectual self, which you might receive in books or from instructors, into “awareness instructions” for the embodied self.

Coding lead by intuition

Now, tennis might seem pretty different from coding. But many of us use informal practices when developing software that are remarkably similar to what Gallwey suggests:

Whiteboarding in action! Source: UKBlackTech. CC-BY

• Observing without judgement: On my first day pairing with my tech lead Emily at ThoughtWorks, a code change didn't work out as we had hoped. That's not unusual in software development. What was unusual was her reaction to the failure. "That's interesting!" was all she said. She didn't complain, curse the computer, fret about it, blame anyone or anything. She just calmly moved on to analyzing what might have caused the situation. Adopting her attitude and phrase has done wonders for my ability to debug myself out of hairy situations. 

• Picturing the desired outcome: We sketch our desired software on whiteboards, notebook pages or even paper napkins. Often, we do this before we have even written a single line of executable code. Or sometimes we do it in the middle of coding, when we are deep down in a rabbit hole. While we might sketch for the sake of documentation, more often, sketching helps us clarify messy thoughts away from the keyboard. 

• Trusting our embodied self: This might sound a bit esoteric. But it is not. Writer's block is incredibly rare for software developers. I have met very few programmers who agonize over their code the way writers do about their words. Once we have a clear understanding of what we want to develop, coding is often the secondary act of typing up our ideas. Sure, these ideas will evolve as we code, but the physical act of typing code is not the most challenging part of software development. 

Technically, we have come a long way since the first computers. But our minds arguably still work the in similar ways. Image: A Colossus Mark 2 code breaking computer in Bletchley Park being operated by Dorothy Du Boisson and Elsie Booker in 1943. Source: The National Archives (UK) via Wikimedia Commons

These intuition-building practices are so similar to what Gallwey describes, that I believe they deserve more credit than we usually give them. Yet when software engineering teams discuss how they can improve "developer productivity", they are more likely to discuss tools and formal processes. 

Those tools and rational processes have their value. Development tools have helped us evolve from coding in assembler, punch cards or even by changing the physical wiring of our computers. And formal processes help software teams work together and interact with their stakeholders more smoothly. But such tools and processes only operate on the level of our rational “intellectual self”. 

Maybe we are missing out on some easy gains by not investing more deliberately into intuition-building practices?