Hacker News Reader

Yeah, no.

Even with a team of experienced engineers we find bugs and mistakes in PRs daily.

Having reviews encourages knowledge of the entire system and why things work the way they do, or, why something was designed a certain way.

For a two person write and sell beta level code as fast as possible startup maybe this approach is fine, but mostly it is not.

Go slow and make things work/last.

View on HN

Go slow and make things work/last.

I find this approach leads to resistance to fix all the mistakes the will undoubtedly get added over time.

Maybe because to fix those mistakes is an acknowledgement going slowly didn't pan out.

We aren‘t two engineers anymore, we are seven. We still apply the same processes. I‘ve worked with huge codebases where you often you can’t know the entire system. Focus on what to build and do it well. If you touch something new, collaborate with others who know the part of the codebase. Either through PRs, pair programming or anything else that gives you confidence.

Seven is still a pretty small team. One of the apps I'm working on has commits from 400 different developers over the past few years. It would be an absolute disaster without code reviews.

Reply on news.ycombinator.com