It usually doesn't happen for me, but when it does, it's because the seniors are out of options.

The safe, tried-and-true way to build typical web crap is to stick the one, blessed database in the middle, and then dangle all the dependencies off that. Everything is synchronous because it's simpler, and it's what the seniors grew up with.

And then one day you won't be able to run your new history feature, because it's locking up the database for too long and new transactions are timing out.

The juniors only get to run the show and introduce exotic, non-boring technology (asynchronicity, event-sourcing, eventual consistency, CQRS etc.) after the seniors have admitted defeat.

> The juniors only get to run the show and introduce exotic, non-boring technology (asynchronicity, event-sourcing, eventual consistency, CQRS etc.)

That’s decade old technologies. So is most of the functional niceties which are somehow finally hype nowadays by the way.

The idea that junior are somehow better able is as old as the field and every junior ends up seeing the light at some point.

It generally goes like this: junior thinks they are smart and have a good solution for an apparently new complex problem. They build it and it fails because of some unexpected edge case. They reluctantly go to see the senior expert with the problem who immediately understands the issue, tells them not to do what they just did - they tried this apparently good idea ten years ago - and proceed to give them a solution which will work. Junior dev finally realises that senior are just people who have been there long enough to already have done the obvious mistakes and they can gain considerable time by just learning from them.

Obviously it only works if your senior are actually senior and not slightly older junior with ego boosting title.

> The juniors only get to run the show and introduce exotic, non-boring technology (asynchronicity, event-sourcing, eventual consistency, CQRS etc.) after the seniors have admitted defeat.

lol. This is definitely not my experience. Most problems are pretty boring and can be solved with a judicious use of boring tech. It isn't until you get to a sufficiently large scale where you need to introduce these techniques. And only if they actually further the goal.

Many times the existing system is doing something in a really dumb way because the original authors were organically growing as they explored the problem domain and that puts the system into a box of thinking, similar to your LLM spitting out trash because the context got polluted, or simply inertia. So the exotic tech is introduced to solve a symptom to the underlying issue without the crucial step of reconsidering the box the system sits in. The requirements at scale are now fundamentally different and therefore the solution should be reconsidered.

If the seniors involved completely miss this step then I question the breadth of their experience because this is common when crossing a scale threshold. Being old or having worked at the same company for 10 years doesn't automatically mean someone is truly skilled and could actually mean their experience is extremely limited.