[torben-friis]

My point was not really for a mistake caught in code review, more for a “not sure this approach is correct, in a design I’m not sure is a good choice, over legacy whose quality I can’t vouch for, for a feature I’m not sure should be prioritised”.

Context: After spending a few years in a well managed unicorn, I joined a small-ish startup that had managed to stay afloat with average engineers operating under constant pressure.

After getting decent funding, they decided to hire people to improve quality overall, and that’s when I came in, among others.

I have to admit it was hard for me to adapt from “I’m adding features to a well oiled machine” to “everything is full of rust and leaking and I’m supposed to build a product on top it”.

That’s why the change of mindset helped: switching the “this is shit” gut reaction into improvement plans helps you focus, prioritise, and avoid assigning blame. It also keeps the former wave of engineers from feeling attacked when they were involved in the original design and hear criticism.