4 ms·
If you are reviewing implementation semantics after someone has already coded a feature, I'd say it's too late. You might catch issues, but the loss of goodwill
by alexjurkiewicz 3y ago
If you are reviewing implementation semantics after someone has already coded a feature, I'd say it's too late. You might catch issues, but the loss of goodwill and wasted productivity will make everyone hate code review.
I think this pyramid is accurate but better framed as a "review pyramid". Catch semantic issues in an earlier phase (informal discussion or rfc-style proposal document).
- dbish 3y agoThat really depends on the size of the feature, but imho we should be reducing the need for meetings/reviews, not adding more. Forcing design reviews just slows people down. Jeffy B's "communication is terrible" are words to live by if you want fast moving engineers.
- tkiolp4 3y ago> Forcing design reviews just slows people down Sure, but the price is worth it. If we have a design session before you start coding, it definitely will make the feature go “late” by an amount of time proportional to the design session… which is less time than the required to fix the design after the PR is open. “Fast moving engineers”: I can only imagine managers advocating for that. As an engineer, I can only but express disdain for such a mentality.
- dbish 3y agoI disagree, as someone who has been both an engineer and manager, if you want feedback one on one from someone who you know would be valuable, always go for it, but official design reviews end up including many people who don’t matter once it becomes a required process. The people who most love taking your time for design reviews tend to be architecture astronauts, not fully grokking the real nutty gritty or caring about things that don’t matter.