5 ms·
I've toyed with this idea too, but for a slightly different purpose. When junior developers join my team, I find that they're often shy about critiquing anyone
by mtlynch 6y ago
I've toyed with this idea too, but for a slightly different purpose.
When junior developers join my team, I find that they're often shy about critiquing anyone else's code because they assume they're the least skilled person, so they couldn't possibly find anything to be improved in anyone else's code.
I've considered sending developers like this a code review and including the note, "And just so you feel comfortable suggesting improvements, I've intentionally left in one mistake (not necessarily a functional bug)."
I've never done it because I worry it comes across as condescending. Like, "Obviously I'm perfect, but to give you something to do, I added a mistake, and now it's your job to go digging around for it."
Instead, I try to reassure junior developers that they should feel comfortable making suggestions and asking questions in the code review, even if they're not finding things that are officially "bugs."
- alisonkisk 6y agoJust put the mistake in quietly, and if they miss it, notice it yourself later or ask someone else to comment on it
- Hello71 6y agoI think a change of framing might be helpful here. Put in multiple bugs, and call it "training" instead. If you have multiple junior developers, have them all do it and compare results, reinforcing the idea of multiple reviews.
- guytv 6y agoThis is a very interesting idea to me. Over the years I noticed that reviewing the same code knowing a bug is there will increase my chances of finding it comparing to not knowing a bug exists. It would be interesting to measure if introducing a "catch" in every PR would increase the number of times the reviewer will find additional issues.
- Leherenn 6y agoI'm not sure that's particularly great for confidence. It will feel like a test, and they will feel dreadful if they don't find it. The whole process will be very stressful.