3 ms·
I personally review all of the code from anyone on my relatively large team when they check it in. When I first started at my current organization everyone thou
by trcollinson 11y ago
I personally review all of the code from anyone on my relatively large team when they check it in. When I first started at my current organization everyone thought this idea would be absolutely crazy. The objections were usually in one of two categories. From engineers it was "My code doesn't need reviewed! Why would you review my code? Do you not trust me?" and from management "There is no way you will have time to review that much code! You'll slow everything down!" Neither of these is true.
First of all I let every engineer review my code (and encouraged it). They found problems. They laughed. They realized I wasn't embarrassed by having to fix my code... and they realized it was ok for them to do the same with theirs. As for managers, if you review code early in the development process there just isn't that much to review. I wouldn't go line by line and check every possible thing. I generally am looking for code smells. If tests are there and CI runs then my biggest concerns can be found relatively quickly, commented upon, and then I can move on and so can the engineers.
6 months later, I have had a number of engineers say that would never want to have it any other way again. Frankly, that's how it started with me too. I really enjoy code reviews.
- lifeisstillgood 11y agoI am enjoying Ex Catmull's book "Creativity Inc" about his time founding and running Pixar and his struggles to build a creative company that keeps being creative. The parallels to software engineering are many and obvious, and I encourgE you to read it (candour, search for quality etc). But the big one that struck me and I am looking for a way to try it is in "the brain trust". A group of 20 or so directors and producers gather every three months to watch the latest version of a film (I guess they all meet more than three months as they make more than one film at a time but whatever). The goal is to give feedback on what does and does not work as story arcs and emotional content and so forth. Not to fix it, but to raise the issues, and not to proscribe solutions but to point out blind spots. Daily code reviews are great, but stepping back every few months with comfortable peers and just looking around a system is something that I would love - it seems to only happen after six or more months when things are starting to break.