Week in Review: Where Does It Hurt?
Something we’re proud of at The New Stack: we advocate for developers. Your job is often thankless: delivering valuable features under tough deadlines, untangling spaghetti code in legacy codebases, and meetings, meetings, meetings. Whenever possible, we try to zero in on your pain points and offer remedies.
This week, one of those articles aimed at solving a common pain point caught fire with TNS readers: a contributed piece by Ankit Jain on why code reviews can be so slooooooow.
Jain, co-founder and CEO of Aviator Technologies, a dev productivity startup, also leads the Google Alumni network. He knows a thing or two about being a developer in an enterprise.
Jain’s story unpacks the reasons why code reviews can take so bloody long. Maybe there’s confusion over who “owns” the code? Or there’s no incentive to prioritize approving someone else’s code? Or the guidelines for code quality are unclear or nonexistent?
And most importantly, he lays out some remedies, indicating what should and shouldn’t be changed to speed things up. “Knowing what to improve is more important than learning how to improve,” he writes. “Unlike CI/CD system performance, code review performance depends on people — not machines.
“Therefore, instead of looking at ‘code review time’ as a whole, breaking it down into distinct areas where you can make improvements — keeping in mind the social and cultural aspects of the process — can help you optimize code review times.”
I suggest you check out the whole article to get the benefit of Jain’s advice. Also, like other recent stories that have been popular with TNS readers, Jain’s piece is part of our newly expanded contributor program, run by our colleague Matt Burns, which is helping us glean best practices to alleviate Dev and Ops headaches. You can start sharing your own pain-point cures here.
— Heather Joslyn, editor-in-chief, TNS
|
