Mētis
Throughout Deconstruct, an uncanny number of talks referenced the book Seeing Like a State
After picking up a copy for myself, I learned that book comes to a focal point around this Greek word called Mētis.
Although it might sound like the space on the inside of your elbow or a dish from Epic Meal Time, this term helps describe what you often see among experienced craftspeople.
From Seeing Like a State:
Mētis is typically translated into English as “cunning” or “cunning intelligence.” While not wrong, this translation fails to do justice to the range of knowledge and skills represented by mētis. Broadly understood, mētis represents a wide array of practical skills and acquired intelligence in responding to a constantly changing natural and human environment.
I will often use the phrase “muscular understanding” with my coworkers to touch on the same thing. It’s someone who knows their tools and the domain so well they hardly need to think. This word is great because it gives vocabulary to something we struggle to communicate as engineers: “I don’t think this is going to work, but I can’t quite explain why” or “What if we did this instead? I think it just might work.”
I also like mētis because it sounds a bit more sophisticated than gut.
Maintaining Intelligence
Much like muscles, mētis must also be maintained and fed. Up-front processes ignore and punish developing an understanding of the problem: the processes demand that crucial decisions be made with incomplete information.
The problem spaces inhabited by software continue to multiply. Because of this, there is almost no limit to how we can develop as engineers. Diving deep to understand the internals of MySQL or heading to the clouds to develop a Ubiquitous Language can both improve our understanding of the craft.
For myself, so much learning in software is regret-free: I will always find lessons to learn as I wander.
We can sum up the many criticisms of new technology as a disregard for mētis. One of my previous posts, Do We Need GraphQL?, outlines this thinking. Do the new things we introduce reflect a deeper or more shallow understanding of history? Do the things we build reflect an evolution in thinking or a regression?
This also explains the failures of the Big Rewrite. The Big Rewrite is a disregard of this developed understanding. This unfortunately wipes the slate clean of any learned understanding. Build one to throw away, but don’t discard your mētis in the process.
Instead, look to build the understanding into the systems you create. Build any mētis you develop as an individual directly into the code that you write.
Leaning on Mētis
Organizations can forget to tap into their employees’ mētis. In The Design of Design, Brooks outlines examples where entire design processes are created to discourage any use of critical thought. You may often see this as everyone covering their ass rather than adapting and changing to new information within the creation process.
In some ways, mētis is at direct odds with processes that need a majority of the design up-front. Instead, it prefers an evolutionary design. This system of organization and building can be maddening to an organization looking to suss out structure. The question of “When will Project X ship?” seems to be always met with weasel words and hedges.
A more effective question—although equally infuritating to the non-engineering members of the company—would be “When will our understanding of the problem increase an order of magnitude, and when will that understanding be built into the product?”
Certain processes and tactics, like those outlined in Extreme Programming Explained, look to exploit each engineer’s mētis or further develop it if it does not yet exist. XP and the concepts within Domain-Driven Design succeed because they look to bring the whole organization in on the learning process, not just the engineers.
Conclusion
Seeing Like a State yields a few recommendations for creating state-led projects in its conclusion:
One might, on the basis of experience, derive a few rules of thumb that, if observed, could make [state project] development planning less prone to disaster:
- Take small steps
- Favor reversibility
- Plan on surprises
- Plan on human inventiveness
These rules have clear analogues within the world of software:
- Release work incrementally
- Allow for easy rollback
- Plan on learning as you go
- Trust your team
In the project alluded to in my previous post, Embracing Functional Programming in Ruby, our team only discovered some of these patterns after a month of working in the trenches. After that month of being face-to-face with our problem, we were able to develop a much deeper understanding. With this deep understanding, we were able to tweak our proposed solution to be even better than originally conceived.
As my boss, Omri, likes to remind us, “Too much process dummy-proofs an organization. Eventually, only dummies will want to work there.” Organizations unwilling to lean on the mētis of their senior contributors or develop the mētis of those earlier in their career will always find themselves frustrated, asking:
When is that going to ship?
Special thanks to Justin Duke for providing feedback on early drafts of this post.