The box on the code review tool? Check. ✅
One on one with your team? Went to lunch, avoided tough issues. But check. ✅
That Trello card? The build passed, so check. ✅
The other night, I was helping my second grader with her math homework. Problems like, “Johnny had 39 fruits in his basket, 5 were strawberries, 10 were grapes, and the rest were blueberries. How many blueberries did he have?”
In class, she learned some efficient “strategies” for recognizing the problem and setting it up. It was quick, effective, and dead on right. (For example, add 5 and 10 and then subtract the result from 39.) They’re good strategies.
But I was encouraging her to try to understand the concepts a little better than simply applying pattern recognition and then raw compute power. Computers can do that better than she can and always will.
That’s the way to separate herself from the machines and her classmates. I don’t care what grades she gets or how fast she can calculate numbers. I want her to ask more questions about it, to bring more curiosity to the problems because, frankly, that’s what makes humans so wonderful when they work.
But she just wants to get on with the task because she’s little and there are other things she’d rather be doing. I understand. But really, what could we be doing that’s better than bringing all our curiosity into our work?
I love to use code review as examples where check the box behavior is notorious in our roles as tech leads. They’re such powerful ways to bring a team together, but they also consume time and risk contention within the team when you get together online to do them. As a result, it’s tempting to use some automated tool like Crucible to literally “check a box” and say, “See? I run code reviews.” But don’t do just that.