- Damian Płaza
Imagine that someone from a "business" or a "product" team approaches us, the team, and asks about our "feeling" (that will become an feelstimation) of a new functionality in one of our products.
"It seems fairly "simple" and almost no logic there, I sense a bunch of new CRUD endpoints", someone anonymously says.
"I've something similar in the past, it looks almost identical", another person continued from the previous conclusion.
"Yeah, it might be a couple of ifs here and there, and of course we need to write new k8s manifests", an unidentified voice, from the group of people, said.
It's too slow
Imagine that we hear a discussion of two young IT undergrads, in a local mall.
"Hm, maybe you are right. "
Imagine that we observe a pair programming session of two fellow craftsman.
"And now the argument: length. I am creating a class for it.", said one of them.
"Wait, a class? It's a simple double. There are no rules, other than it must be positive.", quickly replied another one.
"So maybe a record?", continued the first one.
"Don't overcomplicate, this gives us no benefits at the current moment. It's overengineering.", urged the second one.
I believe all of us witnessed similar scenarios. The content of the situations might have differed, but the form, the frame, was gravitating around the same thing.
What's a common thing?
King of the Kings is missing - the context.
The great aspect of writing is that I cannot provide entire state of my mind so that even by this activity itself the King gets lost, somewhere.
Of course, each scenario is a bit exaggerated and no one would ever do such a naive assumptions (really?). I've heard once that "exaggeration promotes understanding" (thanks Anders!).
It is easy to do premature evaluation without taking the details of the current situation into account.
It is easy to say that Angular is the best and alpinejs sucks, not asking the question what's going to be built it with.
CUPID is wrong and SOLID is the way to go.
Unit tests are pointless, long live integration tests!
Opinions are good, until they are not.
Contextless evaluation is the root of (almost) all evil.
This does not mean we need to stop ourselves from evaluating tools, methods, components, etc. - remembering that next to the technical aspect, there are other too - like sociopsychological perspective (I wrote a bit about some useful approaches in Software Engineering for busy parents)
Is it possible to orient ourselves toward context seeking? To seek it, desire it, like a drowning person wants to take a breath?
I am using two mental models that help get the details. (by the way, did you notice that I didn't say WHEN I am using them? Did your brain add "always" somewhere? This is what I am talking about!)
They are not very imperative steps, more a declarative way of how one can operate.
"I don't know"-ism
The first one is actually really simple - it is enclosed in the title of this blog post. Putting yourself in the frame of not knowing. As it was adviced in the Introduction to EventStorming by Alberto, "be the dumbest person in the room".
Becoming the student of the current moment is the key. A perfectly curious human being, watching all the gestures, facial expressions, and words used.
This is the mindset we want to employ. When I "don't know", things are getting magical because we actually we might get to know!
It also puts the perspective of being humble - as I "don't know", I need to pay attention.
Is it really a next CRUD-ish app, we will build? I don't know.
Is Rust a better choice than JS? I don't know.
Is double enough to represent a length? I don't know.
Contextless evaluation is the root of (almost) all evil.
Of course, it doesn't mean we "don't know" technically. Widely opening your eyes, heart and arms to absorb, to feel and to understand what problem we are trying to solve right now - it doesn't mean we need to leave our experience by the door.
What about Cynefin? Not all contexts are complex or complicated. And that's also true. But without doing an initial analysis, openness for the exploration - we might be pretending that we know. That might be harmful.
"I don't know, let's figure it out" is one of the proper answers.
That's also an interesting perspective in terms of agile thinking. Knowing things (or rather pretending knowing things) beforehand might make us stiff, fragile and not observing the reality. We are becoming (Fr)Agile.
We need to start somewhere, that's true, but rather than pouring concrete form, made of assumptions, what about sensing and feeling - knowing that you truly don't know.
I like to call such a philosophy "I don't know"-ism. It helps becoming compassionate, empathy-oriented one, that simply wants to understand!
"Boring? I don't know what's that"
I have been observing that starting with "I don't know, need to figure out" gives space for exploration. It puts one in the position of a truth seeker.
On the other hand, starting with "Yeah, that's simple" or "I know how it works" shrinks the possibilities and works as a great tool for reinforcing confirmation bias.
It is easy to assume, but it is hard to drop the anchor.
I want to be the beggar of understanding, asking for breadcrumbs of knowledge, and stop being the baron of assumptions, the richling of biases.
"How?", that's what I am imagining you are now asking me (I hope you do, don't you?)
There's one simple sentence that describes this attitude - "That's interesting, could you elaborate?".
It sounds naive and fairly simple, but the depth of this weaponry of curiosity is still being explored and discovered by me.
People are revealing their intentions, thought processes, contextual reasoning and many, many more.
Combined with "I don't know"-ism, it is a perfect combination for becoming the curiosity-driven scientist, that is enthusiastically waiting to learn.
I might sound like a hoax life coach (please, don't get me wrong, life coaching might be very, very useful method!) that tries to sell you his training for money (additionally with access to the great community of learners, along with lifetime access to the coaching platform!).
Remember, I am a beggar of understanding, so I don't know your problem or situation (or, wait for it, context!).
"I don't know"-ism and "That's interesting, could you elaborate?"-ism might not suit you. And that's fine.
But, if you find it doesn't fit your case, that's interesting! Could you elaborate? 🤔
How to move forward? How to train the muscle of "I don't know"-ism? I don't know so let's figure out together!
- when you are getting a service from someone, ask about the work (e.g. electrical work) they do - what could you learn from it?
- get yourself involved in pair programming! There's enormously huge potential to use "That's interesting! Could you elaborate?"-ism!
- when you got a question about the area of expertise of yours, try restraining from giving an answer - instead just say "I don't know, let's figure out together" - and flow with the process.
And one last thing. All those mental models we talked about do not mean we must drop being professionals, stop having an engineering mindset, or forget about behaving empathetically. This must deliver value to our recipients, customers, or relatives - by understanding what is the context we might provide an even bigger "impact" and help!