Pair programming, writing, and mental models. Sometimes, you are just worse than you think. Way worse.
Illusory Superiority.
I always thought that I was a better than the average writer. This egocentric belief lent me a sense of satisfaction, without any tangible output. It was a satisfaction that came from my alleged potential, as opposed to my work. Only recently have I recognized how wrong I was.
In the past year, I ended up reading many books on our thinkng, psychology and biases. I have come across mentions of Kahneman more than I care to remember. Yet, I never could connect these biases to my assessment of my writing prowess. I am not a good writer, let along above average.
This revelation came as a result of me reading On Writing Well. William Zinsser makes a very good case on stripping writing to its core, and why a lot of writing is about rewriting. I have never once proof read any of my writing. Me putting out my work has always been the equivalent of me regurgitating my thoughts online, with all its septic structure and putrid grammar. Sometimes I read my work, and find sentences that bring to mind a visual of the bits of undigested carrots that are scattered in a bucket of puke.
I need to rewrite better
On Pair programming.
Some notes.
On the surface, taking a systematic approach to pair programming seems like an erudite practice, but we often overlook that we naturally tend to do this in a haphazard manner when solving a particularly hard or new problem. Here, I want to list down certain pointers, and ideas that have come from prior pair programming experiences. These ideas are guidelines informed only by mild experience, which should be kept in mind while incorporating them in practice.
Why you should pair program.
Doing some back of the tissue math yields unfavorable results on slapping two programmers on a single task, one sitting with his hands on his lap, while the other codes (goes without saying, this is only figurative, nobody has any hands on any laps, but if they do, they are not doing things right).
This is a fallacy, and I want to present some simple arguments for pair programming to further motivate a systematic practice:
-
Pair programming has a certain basis in psychology, especially when using the driver-navigator approach. The navigator (the one not coding, but seeing the screen) is activating the part of the brain which allows for more higher level, connect the dots kind of thought, while the driver, the one coding, primarily activates the more verbal linear mode. This allows for a tiered approach to the same problem. [src]
-
Pair programming saves on the code review process to a great degree, since the code has undergone scrutiny by two people.
-
Lower bus factor.
-
Higher productivity in tasks that are more challenging/unfamiliar.
When you should pair program.
-
When either one, or both members of the pair are unfamiliar with a part of the code base.
-
While on boarding someone.
-
While solving a particularly tough problem.
When should you not pair program.
While writing things that are not hard, but time consuming. Here, the gains diminish rapidly to the point where its not worth putting two folk on one problem. Things like writing simple CRUD APIs fall into this category.
Recommended approach.
-
Navigator should be the one who is really quick at navigating code (should know her/his shortcuts well). Also, it is preferred that the navigator having some prior experience with the code base.
-
Block out at least 2 hours, recommend 3-4 hours. Time flies fast.
- Before the session begins
- Decide roles.
- Identify an outcome for the session. (Notes must be taken at this stage)
- Identify roughly, the parts of the code base that would need the changes to achieve the outcome. (This should ideally be done by the navigator, while sharing the screen)
- Finally, both participants can share screens (my preferred platform for this is discord, but anything works). The driver concentrates on their own screen, while the navigator has the codebase open on monitor, and the shared screen on another.
The navigators main job here is to be several steps ahead on things like where to find parts definitions, which file to make changes, and other such project level details. Its is extremely essential that the navigator knows all the shortcuts, so s/he is in a position to respond adequately to the driver’s question at all times. This setup isn’t unlike that of a rally car racer, and her navigator.
Occasionally switch roles, to break the monotony. But avoid if a rhythm is established, and both parties are working well in their roles, with no saturation.
That’s it. Remember, a bad navigator greatly slows thing down. A driver codify ideas quickly, and act on them. The driver’s main responsibility is to write legible, runnable code quickly, which can be scrutinized by the navigator.
Pair programming is about teamwork. Establish a rhythm or else you would end up something like this:
Caveats
The guide here is a highly opinionated guide. For a more complete guide, on best general practices, see the the first article in the references.
References
Martin Fowler / Pair Programming Pragmatic Thinking and Learning
Mental Models.
Every mental read is a write.
Off late, I have been conscientiously writing down thoughts and ideas in a systematic way. The tool of my choice is logseq. I am not going crow about the greatness of the tool, but it combines the best of Roam Research and org/markdown flows.
There is a sense of peace when things are off your head, and onto a tool explicitly designed to hold data - some place that is yours; a personal wiki.
“The palest ink is better than the best memory.” - one of those proverbs.
An advantage, apart from permanence of thought, is that putting things down helps me rewrite a thought and better make mental connections. Associations are the brainchild of great ideas, in the same sense that a good analogy can really cement a concept in your head. It is well known that having a very basic heuristic in place of “experts” yields better result in a majority of scenarios. Writing down ideas, is, in my opinion, a rough parallel to such a heuristic.
Don’t be stupid.
Another concerted effort I have been making is to apply inversion as a mental model to decision making and inferences. This is something I picked up from Pragmatic Thinking and Learning and internal objectives planning at the company I work at. Examples of practical ways this could be applied would be:
- If don’t start an initiative, what am I losing out on? (As opposed to what am I gaining if I start it.)
- I want to live a happy life. Instead of thinking of the ways that I could lead a happy life, think of the way that could lead to a sad life.
The core idea of inversion is to you avoid stupid decisions.
“It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.” - Charlie Munger
I want to seek brilliance, but not at risk of going down stupidly.
Its wise to remember that a public toilet is as smelly as its smelliest stool. (To clarify the bad analogy, you are the public toilet, and your decisions are the stools.)
I hope you enjoyed this weeks letter. The first 100 are going to be bad, so might as well get them out of the way as soon as I can.