[nomilk]

> think of this as the just-say-no engineer, as opposed to the just-say-yes engineer. The just-say-yes engineer is obsessed with moving fast, approves code changes by default, values MTTR over MTBF, and tends to ship a lot of code. The just-say-no engineer is obsessed with quality, is happy to move slowly, and blocks code changes by default.

Love the concept of the 'just-say-yes' engineer vs 'just-say-no' engineer (and corresponding prioritisation of MTTR over MTBF).

I'm definitely a 'just-say-yes' with the caveat that bad architectural choices can be super painful to fix later, and features become a lot harder to fix when they have users as opposed to before launch (so I'm a little bit 'just-say-no', or at least 'just-think-for-a-bit-first').

I also think the balance between 'just-say-yes' and 'just-say-no' really depends a lot on the project. If it's finance or healthcare, perhaps 'no' by default is best. But if it's a silly startup idea, YOLO.

[gmueckl]

A "just say yes" attitude leads to certain disaster then because the time to fix the product never comes. Demanding the time to clean up is equivalent to saying no. Whoever is in charge of development needs to have the power to do that and actually use it (if they don't ever use it, they effectively don't have it).

[nomilk]

> A "just say yes" attitude leads to certain disaster

Disaster's a possibility. But if an idea has a 1% chance of success, "just say no" usually assures failure, whereas "just say yes" is a shot at that 1% chance.

[gmueckl]

If there us a 99% chance if faulure, the rational response is no unless the rewards are absolutely, insanely huge (at least about 200x the cost of every resource used) and the org can take the failure.