Reflection: Engineering is Metacognition

Learning is essential:

The ability to effectively disagree with another person is an analytical skill. Not a communicative one, not a social one, but a cognitive capacity that directly determines how well an engineer manages complexity and extracts knowledge from others. Anyone who can do this well learns to sharpen their ideas and ways of thinking, every time there is counter-pressure. Anyone who doesn’t, solves problems the same way as always.

The validated learning loop is embedded in how we think about software development: every decision is a hypothesis, every release is an experiment, every retrospective is a measuring instrument. But applying this to the reasoning behind our choices, let alone to assumptions we don’t recognize as such, is where valuable growth is hidden.

In contrast to other things in software engineering, this does not get easier with more knowledge or experience. In fact, that actually works against us. This is the result of how analytical competence and identity relate to each other, and how we deal with intellectual friction.

Value in Ignorance:

Software development requires precise, defensible choices in an environment that is constantly under pressure. This attracts people who build a career around in-depth knowledge and thorough analysis. We are accustomed to having answers and the availability of unambiguous data to test those answers with.

Chris Argyris observed that analytically competent people are particularly poorly accustomed to contradictory information. The experience of insufficient insight is rare for them (and therefore stressful). Consequently, the learning ability of competent analysts shuts down at the moment an open attitude is most needed.

Carol Dweck adds to this: Anyone who views knowledge and skill as a fixed entity experiences every situation in which that capacity proves insufficient as evidence of a shortcoming instead of information about their hypothesis. Argyris and Dweck describe the same phenomenon from organizational psychology and developmental psychology: engineers who become assertive under pressure do not look for alignment or consensus, but for certainty. With limited data, they draw a conclusion and steer discussion toward shortcomings in the data, while reflection on their heuristics is needed.

Adam Grant reveals why this mechanism is so persistent and outlines this in four reactions to differences in opinions. Anyone who operates in politician, preacher, or prosecutor mode protects the underlying assumption. This does not happen actively, but it is structural. The politician uses social tension to reach consensus. The preacher reformulates his argument to be more convincing. The prosecutor seeks weaknesses in the counter-reaction to refute objections. None of these modes reconsiders the framework that led to the conclusion.

To learn more effectively, we must build tolerance for ambiguity and begin to see not-knowing as a productive state, instead of a threat.

An Idea or Skill is Not an Identity:

Grant describes the scientist as the fourth conversational stance. The scientist also has a hypothesis but is more motivated to refute that hypothesis than to confirm it. After all, if the hypothesis is refuted, the intellectually challenging step of revising the analysis and refining the thought model follows.

This requires a specific relationship to knowledge: what I know is not who I am. Dweck’s growth mindset describes the psychological foundation for this. Many engineers derive self-worth from performing the right analysis, giving the correct answer. Instead, our identity must be anchored in the learning process, in not having the right answer, but having the means to continuously improve our learning. That makes ‘being wrong’ informative instead of threatening.

The difference between ‘I am wrong’ and ‘my hypothesis is incorrect’ seems semantic but in practice determines whether someone enters a disagreement as research or as a debate.

Research by Porter and Schumann on intellectual humility adds a third layer to this: those who score highly on intellectual humility more actively engage with opposing views. And what turns out: engineers generally score low on intellectual humility.

Self-Reflection is a Skill:

Chris Argyris postulated that learning takes place at multiple levels. The extent to which someone learns is related to how often someone questions themselves.

Single-loop learning corrects outcomes without testing the assumption that produced them. A recognizable pattern: an engineer adjusts the structure of a solution after a comment about excessive coupling. The coupling disappears. The assumption that responsibilities should be divided along technical boundaries instead of over concepts in the domain remains. In fact, a lack of insight into how the domain is structured is fundamentally present, but this is not recognized.

Double-loop learning asks a second question: “is the reasoning that produced this implementation correct?” That question requires conversation partners to be willing to go deeper than the code, to personal convictions. This is precisely where the mode with which they enter the conversation becomes decisive.

In short: self-worth anchored in learning instead of knowing makes double-loop learning structurally accessible, and that is an attitude that can be consciously cultivated.

Metacognition:

In practice, we can distinguish not two but three levels. At the first level, you adjust your approach based on the outcome (single-loop learning). At the second level, you question the assumption that produced the approach (double-loop or reflective learning). At the third level, you reflect on the reflection itself: How does my self-worth shape the way I process feedback? Which assumptions guide my self-reflection?

With this third level, we can develop the capacity to see counter-pressure as new information. We call this ‘metacognition’, thinking about our own thinking.

Most engineers never make this third level explicit because no one has ever asked them to do so. After all, their reasoning is reliable in the daily sense, so why would you? People who learn early on that they make good analyses learn to rely on those skills and learn not to revise their way of thinking. In school, the teacher rarely asks the student how they arrived at the correct answer. That is why they get stuck later in life when their analytical approach falls short.

Research in engineering education consistently shows that engineers with strong metacognitive skills navigate ambiguous and poorly-structured problems more effectively because they recognize when they are solving the wrong problem.

Metacognition is nothing more than the engineer questioning himself because he wants to understand how he functions. He essentially does nothing other than apply elicitation techniques to himself: he helps make knowledge explicit that otherwise remains implicit.

Theory of Mind:

Metacognition strongly rests on an analytical competence: Theory of Mind, the ability to model the mental state of another (or ourselves)—i.e., their knowledge, assumptions, analyses, intentions, and blind spots—in our reasoning.

In the context of elicitation, this is recognizable: a good requirements engineer continuously reflects on what a domain expert knows, what they implicitly assume, and where their thinking stops. That is both an empathetic skill and heavy analytical work.

In a discussion about software implementation, exactly the same thing is happening. Anyone who only activates their own mental model misses half the information. The assumptions of the other person, which constraints they consider given, which previous experience informs their position, are just as relevant as their technical arguments.

Anyone who models that assumption asks different questions. “Why do you think that?” becomes a gateway to honest reconstruction of a reasoning that both parties do not yet fully comprehend or experience. Effectively disagreeing requires that two mental models are kept active simultaneously by both parties: one’s own reasoning AND a representation of the other’s reasoning. That is cognitively heavy work, but it can be developed.

If we extend this to self-reflection, the same applies. Then an engineer also keeps two models in their head: The first can be seen as the testing system, the second as the system undergoing the test.

Employing Friction as a Tool:

Low agreeableness in the Big Five-model describes the willingness to create friction, communicate directly, and challenge positions. In contexts that require analytical rigor, that is useful, provided curiosity is the foundation.

Asking further questions and critically scrutinizing the analyses of others enables us to make implicit assumptions explicit. That is the heart of knowledge elicitation. Friction and tension are the instrument, but require that both parties are willing to change their viewpoint.

A sharp question in a technical discussion is an opportunity to learn. To effectively utilize this, an engineer’s identity must therefore not depend on their knowledge, nor on their skills. So, do not be proud of your capacity for analysis. In a world where AI services offer on-demand knowledge and skills, these are aspects by which we distinguish ourselves less anyway.

In Short:

A modern engineer must derive self-worth from the capacity to continuously improve at revising analyses and recognizing factors that influence thinking. As Dave Farley says: Software engineering is about managing complexity and learning. I think we must go further: Software engineering is about managing complexity and continuously developing metacognition.

The willingness to create friction, combined with genuine curiosity about what that friction reveals about our problem, as well as how our self-worth and assumptions shape our analysis, is a strength. Anyone who masters this not only sharpens their own thinking but activates metacognition in others on their team.