3 ms·
I mean - this assumes the person is solving the correct problem and that everything is easily testable or being tested correctly. I’ve reviewed many PRs where
by bradlys 4y ago
I mean - this assumes the person is solving the correct problem and that everything is easily testable or being tested correctly.
I’ve reviewed many PRs where they were trying to add a feature or solve a bug but were not achieving the goal. It passed everything by whatever standards but only reading the code made you realize - it wasn’t going to give you the result you desired.
- mixmastamyk 4y agoThen you send them back to the drawing board, presumably with better information this time. If this is happening regularly you need better training, etc. If they still can't handle it, let them go. Not an unexpected issue in my experience, the price of doing business.
- 100011_100001 4y agoThis is so true. The hardest bugs and usually the ones that can get caught with a good code review are misunderstandings from the developer or business analysts not making the expected behavior clear. Tests don't catch that. Unless the tests are written by someone other than the developer, which honestly I haven't seen. As a contrived example if a developer interprets that they need to multiply instead of add, their method and tests might work 100% but they will give the wrong result. Even worse, in certain cases 2 * 2 = 2 + 2 so they will give the right result with the wrong calculation.
- mixmastamyk 4y agoSteve McConnell covered these common failure modes in his book series, which I recommend if your team is encountering them. Paraphrasing, "you should be endeavoring to make unique mistakes…"