[int0x80]

I find this as being indirect and dancing around the issue. When I do e.g. a code review and I see a glaring defect on it - I point it out very clearly and directly to make sure there is no misunderstanding - I say, XYZ is incorrect. Because of blah-blah. No feelings attached to it, just a fact.

[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.

[barbarbar]

Maybe it would be better if you worked alone then. The advice you are responding to is much better.

[Cyph0n]

That's fine, but only as long as "blah-blah" explains why the code is objectively incorrect. I usually start by writing out the explanation to help with phrasing the review comment.