2 ms·

It probably makes sense when all the developers are experienced seniors with deep knowledge of the codebase, but often it's not the case. I don't think it scale

by kgeist 5y ago

It probably makes sense when all the developers are experienced seniors with deep knowledge of the codebase, but often it's not the case. I don't think it scales beyond a small team of senior founders who only start making their first MVP. According to Crunchbase, they were founded 2 years ago and have below 10 employees. At our company, code reviews help: 1) onboard new devs and teach them about the codebase, catch silly rookie mistakes early on 2) code reviews encourage to write readable code, what I write is readable to me, but can be incomperehensible to others, and code reviews help figure it out 3) seniors make mistakes, too, and it's nice to have another line of defense (some mistakes can be ticking bombs and not catchable in testing immediately) In my opinion, as a developer, you shouldn't even trust yourself, let alone others, to deliver good product (especially if it's mission-critical software with a large userbase), because errare humanum est.

fjfaase 5y ago
The article is not saying that no code reviews are done, but that it is not manditory. For on boarding code reviews are useful, but you could also do some pair programming or work together on the code.
- kgeist 5y ago
  We have not only code reviews, but also mandatory architecture reviews. Everyone dumping random code to main doesn't scale in the long term without a coherent architectural/technical vision. Without it, it's very likely to end in a Big Ball of Mud. We started that way too - faster iterations, little design, and it did help us gain some foothold, but after a few years it became unmanageable and hard to extend/mantain. It's been 3 years since we started untangling our legacy system built that way and our growth is still impeded by it. Context matters: their approach works OK if you're only starting out, but at some point you're going to rethink your processes. Many (most?) companies start that way, foregoing code reviews, even tests and proper QA, to release earlier; but eventually you start to appreciate them as your product matures. It's important to not miss the moment when your codebase becomes large/complex enough that you need to rethink your processes.

by kgeist 5y ago

fjfaase 5y ago

The article is not saying that no code reviews are done, but that it is not manditory. For on boarding code reviews are useful, but you could also do some pair programming or work together on the code.

kgeist 5y ago
We have not only code reviews, but also mandatory architecture reviews. Everyone dumping random code to main doesn't scale in the long term without a coherent architectural/technical vision. Without it, it's very likely to end in a Big Ball of Mud. We started that way too - faster iterations, little design, and it did help us gain some foothold, but after a few years it became unmanageable and hard to extend/mantain. It's been 3 years since we started untangling our legacy system built that way and our growth is still impeded by it. Context matters: their approach works OK if you're only starting out, but at some point you're going to rethink your processes. Many (most?) companies start that way, foregoing code reviews, even tests and proper QA, to release earlier; but eventually you start to appreciate them as your product matures. It's important to not miss the moment when your codebase becomes large/complex enough that you need to rethink your processes.