Sep 2, 2021
The diferent levels of understanding a system
In my career as a programmer and engineer spanning close to 20 years, one of the most recurring daily tasks was finding why something that was working went bust.
Of course, in tech circles they manifest as bugs, issues, regression, or field tickets.
In the role of a triager, its not uncommon to be thrown to the deep end and expected to hit the ground running.
I recall my very first day on a new job in a Fortune 500 company being asked to figure out why one of our TEA ( Top Enterprise Accounts) wasn’t having a great experience with our software suite.
I guess my manager felt it would be a great learning and ramp-up opportunity for me. So I rolled my sleeves up and went about the task with great gusto. Over a couple of weeks and over a hundreds of “silly questions”, I’d learnt more about the product than I would have otherwise learnt by just going through the ramp-up modules.
Anyway, back to the learnings.
The 3 levels, in my opinon are :
- The What
- The How and
- The Why
The ‘what’ is the first stage where you ask, “What is this thing and what is it supposed to do”. “What inputs does it take and what is the end goal of the system”. In other words , its a gentle day one introduction to the system where you get to say hello to it and size it up.
At the ‘what’ stage you are just looking at the big picture, the 10,000 feet overview, and treating the system like a blackbox, where the system takes a set of inputs and produces an output. At this stage, we do not need to know how the system works, but just acquaint ourselves with what it does.
With the ‘what’ out of the way, the next level involves asking “how does it do what its supposed to do”. This involves high level design and then drilling down into the low level nitty-gritty details. Often it involves rolling up your sleeves, breaking it down into smaller sub-systems to get a better understanding of the modules, phases and stages, what works in parallel, what needs to work all alone, what depends on what and in general how the different pieces interact with one another.
If you’ve understood the What and the How of the system, you’ve understood fairly well to have ramped up in most organisations.
But the holy grail is knowing and understanding the ‘why’. ‘Why a particular design choice was made, ‘ why are certain idiosyncracies present’, ‘Why certain anti-patterns exist’, ‘why the system follows a certain doctrine’ and perhaps even ‘why people in the org follow a certain process and a certain mindset’.
Usually to get this understanding, it needs scouring lines and lines of code, comments and commit history. But the secret sauce is being able to interact with the early engineers and founders of the system, the ones who are the plank holders. This process of knowing the ‘why’ usually takes the longest but once done puts you in a state of nirvana or complete bliss, with respect to knowing the nuances of the system that you are trying to get acquainted with. In summary, here’s my takeaway:
“To understand any system,
start with asking the what,
then dig deep to know how,
and then get a real high,
once you know why.”
