Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I could see this working well for teams that are engineering led and where customers don't expect a ton from the software. If you're trying to ship fast and get to market quickly, then fine, skip the tests, skip the code review.

Once you have lots of engineers shipping many different apps and need to work within and across teams. This system is not going to be fun. When a nasty bug ships and you're responsible, you'll wonder "should I have requested review for that one?" When one of your colleagues ships a few bugs that force you to paged during your on-call. This system is likely to erode trust on both ends. IMO, a no code-reviews model is going to stunt junior engineers career growth as they will not be performing what is common practice on software engineering teams. It's also going to keep out many other stakeholders who may wanna weigh in on the software you're delivering, be it UX, Accessibility, Security, Documentation, Product experts. Pull requests keep others on your team in the loop and educated.

I agree that this model gives you the advantage of speed, but I don't think it builds trust. I trust my colleagues and we do pull requests. I don't feel like I'm missing trust because I can't push to `main`. Code reviews have very little to do with trust. They serve as a communication tool and serve a tool to give the best possible experience for customers and provide an opportunity for alignment with our colleagues.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: