There's nothing "wrong" if someone is an anxious wreck socially while being an amazing engineer. It just means that the company also needs to hire a good manager to take care of this brilliant individual. VS if they could hire someone who's maybe not as brilliant, but still sufficiently good to execute the engineering tasks that the company requires, but doesn't need a manager or anyone to tell them what to do, just does it and makes everything run smoothly. In fact, maybe even communicating with other teams and helping them run even smoother than before.

Then you can see where in the first scenario you had to hire two people and only one in the second case, and in the second case you're getting even more additional value with your senior engineer doing partial manager-y things. So now the second individual is maybe 2x as valuable to the company as the first, and you can see it's a no-brainer for the company which to go with.

Both of these are true but I don't think either one could be a very good senior engineer (passable, maybe) and probably not even a passable principal/staff engineer.

An engineer who can solve a hard problem is better for a project than a team of great people who just can't figure out how to do it.

A senior doesn't have to be a leader.

In most cases there becomes a point of diminishing returns in terms of pure engineering skill. At that point it is far more efficient to be able to improve over all output, not just your own. That's where these skills come in.

Think of these as things which become critical after the engineer has mastered the skill of solving a hard problem.

> At that point it is far more efficient to be able to improve over all output, not just your own.

There's only so much you can improve if the output is low. After all, if all your seniors spend their days managing, who does the actual coding? Juniors. And what happens with them after they've "mastered the skill of solving a hard problem"? They become seniors, stop coding and start teaching the next batch of juniors.

This seems like purposefully limiting the quality of the work, and increasing the time it takes.

> there becomes a point of diminishing returns in terms of pure engineering skill

It's quite surprising, if we think about it - software engineering is about as close as you can get to pure productivity multiplier. It shouldn't have diminishing returns, not so soon. It should have exponential returns. After all, the same skills that can be applied to a problem, can be also applied to a meta-problem of solving the problem faster.

As I have learned in offshoring projects, that is a matter of scale, you just need to scale the amount of juniors carring stones, the quality is overrated as long as the product line (completly unrelated to software) keeps working.

In software engineering what 1 person can do in a day 2 person can do in 2 days.

I agree. I disagree with the forced rat race perspective that elevation of engineering is management.

By that town, all managers need to go do some technical work and get better at that.

Yes but someone who can't effectively determine what problems need to be solved doesn't scale, not does this engineer scale to problems big/hard enough that they require more than one person

One can also take one skill out of the list as goal to achieve. I don't think an engineer is able to be perfect in all skilset. This kind of list should be seen as an inspiration and challenge you in the skill we are lacking from.

This was written with the tunnel vision of a middle manager. Take it with a grain of salt

There is such a thing as a Mendoza line, though.

Being mediocre at coding is fine if you can make up for it with other skills. Being downright bad is not.

Same thing for running meetings, writing passable English, being able to explain technical concepts to laymen and so on.

The Mendoza Line is an expression in baseball deriving from the name of shortstop Mario Mendoza, whose poor batting average is taken to define the threshold of incompetent hitting. The cutoff point is most often said to be .200[1] (Mendoza's career average was slightly better than that, at .215)[2] and, when a position player's batting average falls below that level, the player is said to be "below the Mendoza Line".

I was not familiar with the term, but useful concept. Reminds me of something I read recently about the “Goat”, the West Point cadet finishing at the bottom of his class.

If you are running meetings I'm not sure you are still in the senior developer category.

These are more lead developer skills.

Junior level developers at companies I've worked at are often taught to run meetings as part of helping them grow. If a couple junior developers work on a project then having them take turns facilitating the meeting was common. My team's meetings at my last company we also had everyone take turns facilitating it. There were some pre-meeting tasks that the facilitator was also responsible for like organizing some documentation related to last week on-call alerts + commenting on any product metrics for the main product we worked on (most of the time it was looks normal).

A lot of growth I've seen is about having people get opportunities to do things more commonly done by people at higher levels. While most design documents are written by seniors or above sometimes mid level/junior engineers get an opportunity to write one and all design documents get a lot of feedback anyway.

That doesn't make sense, leading meetings is a basic skill. Unless you mean something else then what I think you mean by meetings. This is stuff we've been doing through high school and college doing stuff like group project meetings. Personally I've lead meetings at all levels in my career so far

I think the author means "senior" as a concept (For varying levels of seniority, from senior, to staff, and beyond.) and not just a point on a progression path.

#1 Running meeting and knowing how they work is a really good skill for every one to have

> You can be a mediocre coder but amazing at social aspects and mentorship.

I don't think you can. You can be good developer and amazing and mentorship or social aspect. But if you are mediocre one, you can teach others what you dont know.

When I was a university student we had teacher assistants, who were more senior students. In most cases the best teacher assistants were not the brilliant students but rather the more mediocre students. The cause is that these mediocre students had really struggled to understand the material and therefore could really understand our problems in learning it. Many brilliant people are really lousy teachers.

Teacher assistants are not recruited from mediocre students. They are all good students and all above average interested.