4 ms·
I’d argue that if any of those reach production it’s never going to be the junior dev’s fault. Where’s the review process? Stronger point even: it is beneficia
by torben-friis 4y ago
I’d argue that if any of those reach production it’s never going to be the junior dev’s fault. Where’s the review process?
Stronger point even: it is beneficial to have a person capable of messing up that way so you can check that your quality control is working.
- josephg 4y agoA tiny minority of places I've worked do code review for every commit. Or have careful enough processes that they would catch every mistake made by incompetent engineers. Most companies simply trust their employees most of the time. Hardening a process against programmers you don't trust has a massive cost.
- mavelikara 4y ago> A tiny minority of places I've worked do code review for every commit. In the past three jobs I have had, over 13 years, all changes were code reviewed before merge. I don't know the industry's general stance on this, but I wanted to describe my experience here which is very different from yours.
- torben-friis 4y agoSame here.
- nicoburns 4y ago> I’d argue that if any of those reach production it’s never going to be the junior dev’s fault. Where’s the review process? That's true, but issues getting into production isn't the things that might be problem. Junior devs requiring hours of review time for relatively simple tasks can also cause a lot of problems for an organisation, bringing productivity to a halt in extreme cases.