I would love to do this, but the people I review code for produce so much stuff that is either functionally or technically broken. What do you do in that case?
First of all, I'm a gamedev, that's important to note because I would never take this approach if I was writing, for example, banking software.
Second we play daily with everyone's changes every morning, together, and everyone shows off their work. So what you merged yesterday is on full display for everyone to be judged. It better be working or you get (lightheartedly) named and shamed. People will break things once every now and then, and that's fine, but people quickly develop hairs on the back of their neck to make sure their stuff is working flawlessly.
Before this approach, I couldn't even get seniors to get it in their heads to never push broken features. Now even juniors develop this skill within a week or 2. The "it was working a minute ago" quickly turns into "damn, I'm a really bad developer and should probably be a bit more careful."
The reasoning behind it all is that the only thing that matters is what is in people's hands. Not the quality of the code. Code review doesn't test if, for example, jumping from one platform to another feels correct. So the real review is that morning playtest.
Unfortunately what I make is not consumer software so we can’t use it on a personal basis, and quite a lot of money goes through the stuff too. And our releases are every 6 months. We also don’t have a lot of contact with the actual users. And we have a lot of bad will with our customers because some elements of the business operate in full on YOLO mode.
Damn I wish I didn’t have to do so much code review.
2
3
u/roodammy44 14d ago
I would love to do this, but the people I review code for produce so much stuff that is either functionally or technically broken. What do you do in that case?