Other people's heads are systems to be understood first (6/30)
I'm writing 30 posts in 30 days. This is number 6.
Developers produce software. So you would expect that most of their time is spent writing code, yes? Well, not exactly. They spent most of their time in comprehension, figuring out the system. Even if there’s no existing software system to figure out because the developer has to write a brand new software system from scratch, there’s still some existing manual system of work that needs to be understood before that developer get to the writing. Nowadays, with so many platforms, and open source code, the figuring out has increased. You have to spend time figuring those things out too before you can use them in your newly created software system.
I used to make the same misunderstanding. I have an impetuous nature. I cannot wait to jump into the writing code part. When Eric Ries talks about validating your assumptions in his Lean Startup, or the Agile manifesto talks about customer collaboration and responding to change, they are actually talking about the same thing — understanding a system before writing the final software.
Sometimes, you write a throwaway to understand
I emphasized and used the word final in my last sentence for a reason. Sometimes, you have to write some prototype or throwaway version to increase understanding. But the eventual software you do settle on writing may have zero to do with those throwaway versions. So, don’t be too invested in the initial versions. That was a lesson that was easy to intellectually know but incredibly hard to emotionally accept and execute in real life.
In other words, there are two tenets:
Seek to understand first before writing serious code
Part of understand better may mean writing non-serious code
Other people’s heads are also systems waiting to be understood
My favorite part of the article Developers spent most of their time figuring out the system has this paragraph and diagram
Understanding a system or the situation around a system — the situation around a system is, to me, a bigger system — is so part of my day to day, I don’t even realize it until I started using the same technique in other contexts.
Recently, I am trying to train young people to work as data entry contractors to help me maintain the quotation software systems I built for my customers. The issue is that feature requests come in faster than I can implement them. At the same time, customers still have the day to day needs for these features and cannot wait for me to finish in order to do their work.
So, the temporary fix is to manually help them make data changes. I used to do that personally until the load became so much that it started taking away valuable time for me to fulfil those very same feature requests. Hence, I’m trying to hire and train data entry workers to alleviate the load for these data change requests so I can eventually write the features for the customers to self-serve.
The Training of the Data Entry Hires
While training these data entry hires, I find myself constantly checking their mental models. Initially, I do it to understand them first as people. Subsequently, I do it to see if the new models I’m installing into their heads are buggy. After training for about 2 weeks, it hit me that I’m essentially doing the same “understand the system before writing the code” technique when it comes to training these hires.
First, I seek to understand their motivations and expectations for the tasks. Then, I seek to understand their prior knowledge. I quickly dispel irrelevant fears or concerns they might have. I focused on their strongest motivations for taking on the work and get a rough understanding of their prior knowledge before taking this on. Knowing their prior knowledge helps me to plan how detailed I want to get into certain topics. For example, one hire has zero concepts for shortcut keys. She was not aware of the most frequently used shortcuts like Ctrl+C, Ctrl+V, and Alt+Tab. Another hire knew basic shortcut keys but had the impression he had to be so well versed with the data entry work that he needs to remember all the minutiae by heart (not necessary). Also, he has the tendency to want an overview or framework to hang the facts and details of the tasks around it.
Based on my understanding of their characters and prior knowledge, I can adjust their training on a day to day basis. The training is analogous to me writing software into their heads. Similar to writing actual software for machines to execute, the outcome of the software might still differ from my expectations. I again need to constantly validate what they newly learned against my expectations — just like testing a piece of software’s outputs.
I feel I have more to speak about this general principle of understanding systems, mental models, and in software related activities such as writing code, training people, and understanding users. For now, I want to wrap up today’s piece that it’s second nature to me that understanding people means understanding their mental models and the way I go about understanding their mental models feels like trying to figure out what a software system does and why.