[marcosdumay]

It's not the culture of anti-competence (although, yes, that exists).

How many times have you tried to communicate a novel idea to competent people just to have them dismiss it with obvious problems that clearly don't apply to your idea? That doesn't happen because they can't evaluate your idea, it happens because they don't understand the idea itself.

When the innovation is small you can get away by repeating it again and again. At some point people stop, take your idea into account, and suddenly understand why none of what they said applies. But when it is something too different, you can't do this one either.

[cuddlybacon]

One thing I've noticed is the better an engineer gets, the better they are at shooting down every idea they see. While I have seen many cases where a person did it anyways and failed, I have also seen many cases where they did it anyways and where massively successful.

[js8]

Indeed, I suspect there is a curse of expertise. If you're an expert, you begin seeing everything as so nuanced, as so fragile, that you will dismiss lots of radical innovation as too simplistic. (And I think especially it affects motivation to actually try something new.)

But if somebody somewhat naive comes along, and just pushes through with sheer effort, they might succeed where many experts have predicted a failure.

[efitz]

Or more likely, the newbies will solve the “unsolvable” problem by removing some of the constraints that the old guard was holding inviolable. The newbies crow about their success for a few years while everyone struggles to work around the constraint violations.

NoSQL is the biggest example of this. Ignore everything we learned about ACID and just use key-value stores with no transactions or relations. People can build their own if they need them, right? And duplicating data to work around missing relationships is not a problem because storage is cheap? Then we get an explosion of new databases, each of which solve a subset of the missing functionally problems, with varying degrees of success.

I suspect this came across as more snide than I meant it. Sometimes holding a treasured constraint is the wrong thing and the old guard of experts failed to understand that not every business problem needed the full solution. But it annoys me for some reason the attitude of “we just solved this problem that experts could not solve for decades” when the nuance is that only a subset of the problem was solved, with potentially extraordinary effort required to re-introduce those missing constraints.

[js8]

I can't quite buy your example, because NoSQL is pretty much a reinvention of VSAM and IMS DB (not IMS DC).

Regardless, I don't think it's necessarily that the expert would not want to drop some design constraint. It's more likely that it is genuinely hard to decide, which of them to drop and which of them to keep, because there are so many and problems are complex.

But if you're somewhat new (not a beginner either), you don't see all these, and you can benefit from the ignorance. Unfortunately, I think it cuts both ways, it's far more likely that ignorance will actually hurt you. But for a small number of people, ignorance can lead to lucky innovation.

[msla]

I call that the Procrustean Bed: Simplify the solution by cutting pieces off the problem.

[cuddlybacon]

There doesn't even need to be great effort. Sometimes the experts are just so good at making every idea look like shit that they don't even try.

[Melkman]

Neh, the better an engineer gets, the better they are at asking questions which make the person with the idea realize there are some problems with his idea. These problems may be fixable.

Shooting down ideas is not productive. Making sure ideas are realizable is.

[dvtrn]

One thing I've noticed is the better an engineer gets, the better they are at shooting down every idea they see.

This was two jobs ago. Razor sharp developer, could come up with any feature you asked him to. Which was the problem, if ideas didn't originate from him, good freaking luck getting him to work on it. He cost us to miss a few critical deadlines because of his refusal to let other people do their jobs unless it satisfied his demands, company refused to fire him because he had been around so long and carried institutional knowledge about the application but also refused to de-silo himself-thereby making the entire engineering effort dependent on his knowledge.

Guy went from a severely annoying veteran on the team to being given management duties over the team once our old boss retired due to health concerns (irrelevant to the job itself-he just drew a very unlucky health card). I and several other developers were out the door soon after because none of us wanted to report to him.

Company later got acquired. I like to peep in on their "About Us" company roster page every now and then. He's still there. But I've seen 3 different people in three years in my former role reporting to him show up on the roster, and then disappear and then get replaced by a new face.

"People don't quit jobs, they quit bosses".

[techopoly]

One obvious example of that is when Dropbox was presented here as a startup and was shot down in glorious fashion.

[cuddlybacon]

That is a great example. The only ones I could think of were internal to my office, and didn't want to go posting about them on HN.

[throw681158]

I would amend this to: the better an engineer gets while still staying a salaried engineer.

Calcified engineers are more likely to enjoy the high-level corporate environment. Flexible ones leave to start companies, contract, whatever.

[Rexxar]

  > the better an engineer gets, the better they are at shooting down every idea

Are they really better or just more confident with time ?