Since I can remember, designing solutions to complex problems was my favorite software development-related activity. The conceptual shaping of elegant, fit-for-purpose thought constructs was always (in my case) much more pleasant than coding itself. As my work-products were (IMHO ;>) polished to the finest detail, turning them later into syntactic constructs & compilation artifacts wasn't that satisfying at all (even if it's the final product & the value it creates that truly matter ...).
As I moved towards more leadership-related positions, the rules of the game have changed. These days it's usually someone else doing the design/modeling stuff, while my role is to jump-in, comprehend what's on the plate, provide insights/feedback/comments/etc. Which is surprisingly much harder (that's why they pay better for that ;P). But why? The hard work has apparently been done, someone has found a way (solution) to address the problem already, now you just need to follow the same thought path ...
Which is EXACTLY the root cause of the problem. Let's talk dive a bit deeper then.
Into someone's head
Have you ever wondered why sometimes it's so hard to comprehend a theoretically simple solution while at times you pretty much instantaneously grok through something incomparably more complicated? Of course, there are several factors to be considered:
- the context you're presented with (information "pushed")
- your experience (did you do anything similar in the past?)
- quality of description/documentation/experts you have access to (information "pulled")
- presence (or lack) of accidental complexity - aka quality of the design itself
These are all true, but there's one more - probably the most important of them all. Namely: your "compatibility" with the mental models used.
What does it mean?
A mental model is how an individual is representing the perceived reality conceptually ("depicts in his/her head"). It's how you "translate" what you sense/experience into atomic, understandable constructs that are the most convenient to YOU explicitly. It's a collection of your thought "design patterns", "building blocks", "workshop tools". It's the alphabet of your means of conceptual expression. It's how you'd describe something with your own "words" (or rather - thoughts) to yourself.
People may use VERY different mental models. I've learned it very late (when I was 25 or so), because during my whole education period (primary/secondary school, uni) I was always surrounded by people who were thinking very much likewise. With very similar backgrounds, education, inspired/influenced by the same sources of knowledge. Yes - uniformity of background/experience usually means that:
- two individuals share more mental models
- but also - their (joint) palette of mental models is limited (& not every mental model is suited to describe some particular stuff)
The autonomy of understanding
So, when you're crunching through something, you're facing TWO consecutive challenges, not just ONE:
- to embrace (probe & apprehend) the mental models used (the "language" or "dictionary" used to define the solution)
- and next - to use the acquired mental models to understand the actual solution
If you fail at the 1st one, you'll never get through the 2nd one (& there's no partial success). If you succeed at the 1st one, beating the 2nd one is just the matter of time (& you can achieve even the partial success fast).
And that was a super-fascinating conclusion (in my case) - because I was thinking about it context of ... creating good documentation. If you want to build decent docs it's far more important to set up a proper foundation (the "map", the "legend", the "structure", the "helicopter overview") - by clearly presenting all the utilized mental models - than to describe fully every detail (that can be easily & quickly found - once you know how to navigate across the solution built with certain mental models ...).
Yes, it's probably the initial 10% of your effort that truly determines whether the effect of your work will be useful at all.
That's why people have always loved thought constructs like:
- UML's static & dynamic views of the system (well, this mental model has appeared too complex & unapproachable for many - in the end ...)
- common three-layer architecture
- GoF design patterns
- DDD tactical patterns
- event storming
These techniques/forms give us NOT JUST the common language, but also the common & easy-to-grasp WAY OF THINKING (/approaching the solution-crafting).
P.S.
That's why it's so important to be generally curious and to look for inspirations everywhere. New experiences (out of your strict comfort zone) frequently come with unique mental models.
P.S.S.
Btw. that's also why strict, rigid, forced-down architectures straight from 80s/90s (e.g. how the mainframe systems were built) were much better in terms of handling the technical debt & cognitive load limitations (but also incomparably worse when it comes to flexibility & velocity of change) - they've forced the "one & only" way of thinking (& building solutions). Those days you were attacking development problems with mass, not flexibility/creativity.
