Intermediate Ego, the awkward phase between being an intermediate, and a senior. Generally after the hump of the intermediate journey. Where successful solutions have been steadily stacking up. However, experience has been limited. The ego, unaware. The Dunning-Kruger effect hasn't quite struck and the ego is convinced it can solve all problems. They've mastered their stack - but they've only ever been in their stack.

Their ego has grown from their successes, but now, it's their bane

Ultimately, Intermediate Ego arises from inexperience. It's a misfire from taking the initiative and trying to problem solve. One thing we have to all be wary of, is that we in fact stand on the shoulders of giants. Experience comes in many forms, and it's important to listen to the experienced members of your team.

How an Intermediate Ego interaction will go

The formula is broadly similar, it begins with:

1. A suggestion on a technical solution.

• The solution is what was used in their previous role.

However the solution is shut down in this context, as it's not applicable, or the appropriate course of action. Really for for any number of reasons. However the developer in question, doesn't let it go.

2. The suggestion is brought up again, and again.

Regardless of having been explained as to why it's not the right course of action. The developer is frustrated, as they feel they have the correct solution but nobody is listening to them. Unfortunately this is the ego aspect of Intermediate Ego. They can't let it go. Rationally, the right course of action is debating the merits of the provided solution. Unfortunately, that can lead to a situation where

3. The developer insists they're right, and that you're wrong.

However they don't provide the technical detail to be convincing on their solution. Instead they resolve to 'we did it before and it worked', and 'just trust me bro'.

4. Then, instead of trying to convince the technical lead of the project, they push their solution to anyone who will listen (technical, or not).

This can even extend to people outside of the project. Generally with a misrepresentation of what the problem is, and what the solution is. Often leaving out the key reason to why it's not applicable.

Extending an olive branch

It's frustrating to deal with. It feels like they're just dragging their feet for no good reason. They haven't provided a convincing argument, and they're not letting it go. Even worse, they've blown this out of proportion.

It's important as a lead to flip the narrative here, and see the merits of where they're coming from

• They are trying to help the team/project
• They haven't framed their solution appropriately

The appropriate way to reframe the conversation from one that is frustrating, and obtuse is to instead extend an olive branch

• "I think what would help convince me on the solution is.."
• "How about we go through and analyse the pros and cons of the solution together?"

The ego aspect of Intermediate Ego being that they won't let go of their idea, regardless of its merits. Ultimately this boils down to not understanding how their solution fits into the grander context of the project. Really, if they did, they may realise that it's not the best path forward. Regardless, you have to tread carefully. It's a delicate balance. You don't want to come across as condescending or dismissive, nor as someone who is seemingly against them. It can be worthwhile to reiterate that you're on the same team.

Extend an olive branch, and go through a technical analysis of the change:

• Define the problem.
• Help them prove if their solution does solve the problem,
  • and that it is 'better' than what's currently in place

What I've found each time I've come across Intermediate Ego is that the developer is shoe-horning a solution that's been used in a previous project to this new one. However, what they're missing is the context. The context of why it was used in a previous project, and why it may be not appropriate for a different project. As they've mastered the stack they've come from, what they've fundamentally misunderstood is that not all projects are the same.

How does Intermediate Ego develop?

I believe people end up experiencing Intermediate Ego from gaining confidence with a tool chain/stack in a narrow context. This builds up the ego (not necessarily a bad thing). However, due to having limited experience it causes them to overestimate where their technical skills truly are. Their ego becomes larger than their skillset. Unfortunately, they haven't realised how vast programming is as a discipline, and the amount of factors which can influence how things operate, from tooling, to process. Along with the contextual difference in projects, and work places. Last, but not least, they haven't mastered how to work with others, especially when it comes to managing disagreements.

The factors that influence why a project, or team should use a certain tool, pattern, or process are multiple, varied, and experience-driven. Somewhere we can all get to in time. However the developer in question has generally only experienced generally one tool chain, or stack, and has come to understand it to be only way to implement solutions.

But now, they've joined your team. Your codebase has most of the same stack they're used to, however it's a different kind of project to what they've worked on in the past. As a result, with their inexperience they haven't come to understand the differences yet. Eager to impress with their elevated technical skillset, they recycle solutions from a previous project. However it isn't applicable, but they can't see why not. That's the key thing - they can't see why not.

Personal experience of Intermediate Ego

As I said above, I've experienced this with many developers over the years. Here are two examples of times it's happened:

1. Developer suggested using type guards via novel library used in their previous role.

The issue was two-fold, we were already using both Zod and Typescript in the project. Together those technologies provide type guarding at build, and run time. So our bases were covered. The developer in question disregarded that fact entirely, and then began to add and use the library in every subsequent pull request they made. They misrepresented the problem to stakeholders, and kept pushing for the library to made it into the codebase.

2. Developer suggested using multi-tenancy, an architecture that was used in their previous role.

In this upcoming project, we were to make three CMS driven websites. Which shared some, but not all UI (user interface). Using multi-tenancy rather than consolidating a shared UI package, was overkill for the project requirements. The benefits of a multi-tenancy approach wouldn't have been advantageous in this situation, and instead would have become a hindrance. However the developer, undeterred, then proceeded to just tell other teams, and departments that we were going to use a multi-tenancy approach. Which lead to a lot of unnecessary and undue confusion.

The takeaway

Being a good Engineer doesn't end at the technical understanding of programming, frameworks, and tools. It also encompasses working with others, and working well with them. It's a muscle that you have to work on to develop, all the same as your actual programming skills. Two heads are better than one, and many hands make light work. Being difficult to work with makes you less employable, and ultimately more frustrated when you are at work. I love programming and engineering, however, it's people that make jobs worthwhile.

It's frustrating to not get your way, especially when you believe it's the right choice. But insisting on being heard on the same topic over, and over again doesn't curry favour with people. Instead it pushes them away, and frustrates them. Sometimes you just have to cut your losses, and accept that you're not in the position to do the thing you want. Regardless of it was ultimately the correct choice or not.

Save yourself the headache.

Always remain open to being wrong - while being willing to prove that you are right.