"It's flaky' often used as a rebuttal to integration tests. But I think flakiness is the point. Maybe this feature is just unstable or indeterministic and you're choosing to ignore it. Granted testing async flows or time-based interactions can be hard, but flakiness is more often than not an excuse.

I also think this unit testing dogma is a symptom of the pendulum swing to dynamic programming languages. With it swinging back to static type checking, you can get very far with no unit tests.

I think people get duped by ease and volume of writing small isolated tests. You point to the "test pyramid". You feel good about Best Practices™. It's like the junior engineer comfort blanket. But the fastest way (IMO) to demonstrate what you've built works is to go straight to integration tests.

I tend to want to work with 1 more. They tend to make better decisions. Don't cargo cult. Are not afraid of digging into code. 2 might lead to faster promotion and an identity as someone who "gets shit done" but I think you hit a ceiling.

The reality though is there are things eng can do and imagine that non-eng functions cannot. DX is a classical example where it often suffers. But technology advances from research is another (local first, react, gmail, etc.). Eng sometimes needs space to broaden the solution space for product.

Engineers classically struggle to communicate the value of their work due to differing levels of abstraction from management. I've found that when managers used to be eng ICs, the translation cost is lower, and empathy is higher, creating a sweet spot for collaboration/stress.

Not saying eng is good and product is bad. But its just this natural divergence of perspective on whats valuable is what causes these micro boom/bust cycles as there's a push/pull. But I'm worried that with this mode of operation thats so common everywhere, we create a lot of burn out.