Matt Waldron

I'm a lifelong learner, currently looking for my next interesting role

Imposter syndrome and the egoic engineer

June 24, 2020

3 min read

Finding symptoms of an egoistic person in software engineering might be a signal they’re highly self-critical. Being self-critical can be a useful skill, but can be easily amplified to a paralysing extreme. Not including other well-defined mental health issues, imposter syndrome is a condition that shares strong parallels.

I’ve never really made a concerted effort to understand imposter syndrome further than having an explanation for some behaviours that can also be explained through social anxiety. But it’s useful to have a term to relate to others who share this experience.

It was only really after briefly reading about the Freudian theory of the Id, Ego and Superego, I noticed the similarities between the qualities of someone who is egoic and someone with imposter syndrome.

If you prescribe to it, the ego is the interface between a persons’ basic needs and the real-world, including all social contracts. If the Id desires something, the Ego attempts to provide a low cost solution, prioritising previous experience, to satisfy that desire.

An egoic person is someone whose emotions, thoughts and behaviours are processed in the context of themselves and their interface with the world. It aims to reinforce previous experience and beliefs. This is not necessarily through a positive lens however.

Might imposter syndrome be described in a similar way? Thinking about accomplishments and experience through a very self-critical lens, where autonomous processes promote existing perspectives for a person, but in a very negative way that devalues accomplishments and minimises success.

This might imply that to mitigate imposter syndrome the interface at which the ego conforms to the real-world requires some TLC.

I suspect imposter syndrome is prevalent with reduced domain knowledge, often occurring when moving from one industry to another.

A person may conflate a lack of domain knowledge with their skill level in a particular function, when these are indeed very different things. So future contributions and success are increasingly likely to be cast through this initial lens, decreasing the change of personal positive recognition.

A good change to this interface might be to on-board to a domain model prior to engaging in responsibilities of the role. Ideally with ubiquitous language and well-defined customer journeys. Familiarity with the domain would reinforce new understanding of the product and serve to slowly increase confidence alongside an internal model with every increasing resolution.

I wonder if there might be a use case for cataloguing domain models and defining ubiquitous language for each, like a library of generic domains. Where a generic template can be taken and used as a base for companies to personalise.