[apsurd]

I used to think this but you only know which were the right corners to cut after the fact. And most things are not obviously right or obviously wrong, instead it’s a slow zombie death by a thousand fuzzy signals.

And the management tier of the startup will too easily color the signal by the flavor they want to see.

My latest take on this matter is to separate speed as in fast from quick. Quick is the thing you want and almost always good. Fast is what usually gets lauded and measured but fast just gets you large volumes of fuzzy signal faster.

(quick means that something can take time and be measured, not rushed, things can bake, and the feedback loop is responsive quickly throughout the loop. while fast is looking at wall clock time and goaling on the end-result yield from the loop. i think it’s very misguided. things very often need bake time)

[lokar]

And sometimes the yak shaving side quest yields big improvements that were not even on the radar.

Good engineering intuition, the ability to learn new code/systems quickly and the ability to quickly validate ideas is extremely valuable.

[renegade-otter]

Yes, but it does get easier with experience and some battle scars. Telling a startup to stick to the problem and not go wild with microservices and event sourcing is not exactly a hot take.

[cucumber3732842]

Which is exactly why you need people who have a good gut feel for such things.