[dizzant]

> many programmers are smart, and if instead of creating a magic system they have no access to, you show them the data structure, the tradeoffs, they can build more things, and model their use cases in specific ways. And your system will be simpler, too.

Basically my entire full-time job is spent prosecuting this argument. It is indeed true that many programmers are smart, but it is equally true that many programmers _are not_ smart, and those programmers have to contribute too. More hands is usually better than simpler systems for reasons that have nothing to do with technical proficiency.

[latenightcoding]

>> More hands is usually better than simpler systems for reasons that have nothing to do with technical proficiency.

If you are working on open source databases, or something close to the metal I agree with antirez, if you are working at some established tech business (e.g: a very old ecommerce site), I agree with you

[dizzant]

To be clear, I'm not disagreeing with antirez at all. I feel his argument in my bones. I am a smart programmer. I want simple, powerful systems that leave the kid gloves in the drawer.

The unfortunate reality is that a large cadre of people cannot handle such tools, and those people still have extremely valuable contributions to make.

I say this as a full-time research engineer at a top-10 university. We are not short on talent, new problems, or funding. There is ample opportunity to make our systems as simple/"pure" as possible, and I make that case vigorously. The fact remains that intentionally limiting scope for the sake of the many is often better than cultivating an elite few.

[Karrot_Kream]

I'm really curious about the shape of your problem. I was an early hire at a tech unicorn and helped build many high scale systems and definitely found that our later stage hires really had a harder time dealing with the complexity tradeoff than earlier hires (though our earlier hires were limited by a demand to execute fast or lose business which added other, bad constraints.) I'm curious what your iteration of the problem looks like. We managed it by only trusting the bedrocks of our systems to engineers who demonstrated enough restraint to architect those.