Hacker News Reader

Comment by fidotron | Hacker News Reader

There is clearly a major problem with this in SV. A lot of people seem to confuse confidence with expertise, and fail to grasp that a scary proportion of the time the individual is so confident because they don’t understand the problems with what they are doing.

Furthermore, modern software management practice doesn’t want this because it wants replaceable cogs. If you can recognize expertise you have to appreciate that teams where everyone is good at everything are nonsensical, and that you need actual balanced mixes of personalities and specialists, which makes hiring a far harder problem. As such recognizing expertise is very much not the order of the day.

View on HN

I actually think ageism is a huge component of this.

In classical engineering fields, experience was highly valued. In some it still is. In civil engineering, no 24 year old will be able to bullshit their way into senior level roles. It just doesn't happen. The senior guys get more and more valuable. A big part of that is that it's very hard to bullshit your way through that field without at least 6-8 years of experience, and by then you'll hopefully have been humbled enough not to try and bullshit it.

I think missteps and mistakes hit differently when someone traceably stamps their name on a finished product and takes personal liability for it in perpetuity.

I've seen this happen in my career. In a previous life we hired a person just out of college into a "Senior" developer role. Sure, the person was smart but they didn't have the experience, they hadn't made the mistakes or seen the outcomes of various decisions to be called "Senior".

I've struggled since then describing why I felt this way and I think the essay helps immensely. In my recollection that developer didn't reach a software vocab point and couldn't really understand the difference. The pain point for me was that I could spot the difference and no one (in management) really cared.

Expertise makes sense in larger teams and companies. The smaller you are the more one person has to do. The larger ypu are the more you can afford to have a few people who are absolute experts of a small section but can't make a project complete end to end. But at a large enough company it doesn't matter.

If you have 10 engineers, you need generalists.if you have 1000 engineers, generalists generally are smart people who are potential experts, but not really that useful.

Wouldn't it be better to hire a mixture of specialists and generalists especially today when diversity should be focused in thought rather than looks. Someone not me said that specialists are a master of one and connector of none.

Sure, ideally. In the real world hiring managers have to take what they can get from the applications that come in. And in a rapidly changing industry the specialists that you need today might be useless in two years. One approach that can work in some organizations is to hire mostly generalists as employees, and bring in specialists when needed as temporary contractors.

> Furthermore, modern software management practice doesn’t want this because it wants replaceable cogs

In my mind that was always just an excuse to hire as many people as possible to grow their org and get promoted to n+1. But hey it worked with 0% rates!

Dunning-kruger strikes again

it's not DK, it's sales. It exploits substitution bias: https://en.wikipedia.org/wiki/Attribute_substitution

"Thinking Fast and Slow" has a whole chapter on this with ample evidence

Major problem on HN too. You can't even mention expertise, experience, or credentials here without someone screeching "fallacy! appeal to authority!!"

Reply on news.ycombinator.com