3 ms·

Code reviews. There's good reason for them to exist, but in practice at best they're a waste of time, and at worst an exercise in narcissism. People nitpicking

Code reviews. There's good reason for them to exist, but in practice at best they're a waste of time, and at worst an exercise in narcissism. People nitpicking the way a statement is written because they feel like their subjective preference is objectively better. Perfectionists who block forward progress in attempts to pick out every possible detail that doesn't matter in the big picture, instead of moving forward with 80% good. Choosing a worse solution that a reviewer suggests because you know they're always the last to back down. And code reviews rarely catch the bugs that actually matter. Tickets, JIRA, daily standups, scrum masters, sprint planning, backlog grooming sessions. Why does nobody question any of this "best practice"? Why do we all just collectively accept these processes that take any and all enjoyment out of the profession, and makes every person feel like a replaceable cog. Is it because of this industrial age idea that work is supposed to be boring, that we should just suck it up? Aren't we way past that now, in the 21st century? Are there others out there who don't hold such a defeatist view of work? Where are you all? I know some of you may say I should go get checked out for depression, and I do appreciate the concern. In the past I've had years of therapy for depression/anxiety, and it has helped me cope. But I know what depression is, and this isn't it. I spent years believing that the problem lies with me, but I'm finally starting to get the courage to see that maybe it's the industry that needs therapy too. I took quite a few months off between jobs recently and felt the passion start to come back. I felt great, excited about work again. I got some projects off the ground (and much more quickly than I ever could in a job) but they didn't really take off. Now I'm back at work and the passion is evaporating again. I know that there's still a passion under there. I know that work doesn't have to be like this. I'm increasingly convinced that 90% of modern software "best practice" is bullshit that has moved our industry backwards, not forwards. It's as if we've collectively turned ourselves from craftsmen into factory workers. I appreciate you reading this far into this huge pile of negativity. Now that that's off my chest, what do you think of "best practice" in software in 2021?

wreath 5y ago
> Code reviews. There's good reason for them to exist, but in practice at best they're a waste of time, and at worst an exercise in narcissism. People nitpicking the way a statement is written because they feel like their subjective preference is objectively better. Perfectionists who block forward progress in attempts to pick out every possible detail that doesn't matter in the big picture, instead of moving forward with 80% good. Choosing a worse solution that a reviewer suggests because you know they're always the last to back down. And code reviews rarely catch the bugs that actually matter. I found that code reviews without a design review or at least a description of the proposed design in the PR itself, is nothing but a waste of time the way you just described. Imagine a Civil Engineer being walked through a construction site and making comments right about work, while even though he knows the fellas are building a bridge, he has no idea how that bridge ought to look like etc. This becomes a waste of time because I have to read the diff and build a mental model, which is at best a guess, of what the author wanted to build/change based on just the diff. This is even worse with code bases I'm barely familiar with (which is increasing since we have a bunch of "micro services").
afarrell 5y ago
Thats because “best practices” only apply in simple situations. In complex dynamic situations made of humans with feelings, there are only “good practices” which might be applicable in context.
massung 5y ago
Re: Code Reviews Like anything there are good versions and bad versions. I think we've all been through bad code reviews and bad code review processes, so let's skip talking about those. On the other side, here's what good code reviews/processes I've been a part of accomplish: 1. The give the creator of the code the opportunity to rubber-duck. I've found that 80+% of all bugs found in code (before merging) are found by the programmer themself just by talking through what each change is meant to accomplish. 2. The give the reviewer(s) the opportunity to ask very simple questions and questions about how the code change relates to other major systems that the PR creator may not even be aware of. If there are any remaining issues with the change (the last 20%) this is usually where they are found. This isn't about where to put curly braces. If your team cares about that, use auto-formatting tools or something. 3. It gives somebody... ANYBODY... other than the PR creator, some idea of what the code does and why. This is absolutely critical as it spreads the bus factor. When something goes wrong and a programmer is sick, on vacation, or has left the company, it's critical that there be one or more other programmers who can pick up the mantle. They may not have deep knowledge, but they aren't coming into the code blind either. 4. Building on 3, it spreads the architectural knowledge and decision making of the code base among all the programmers. Code reviews shouldn't only be "run" by senior/lead programmers. Senior programmers should be getting reviewed by junior programmers as well. It's not ego or about teaching. It's about realizing we all make mistakes and we all contribute to the same end goal. Over time, everyone becomes aware of the systems at play and what's going on. When they are presented with a task, they have a much deeper understanding of what's involved, they can estimate better, and they are aware of who else to talk to or involve in the process. Junior programmers will get comfortable speaking up in architectural meetings and bring up good points. This is one way they become senior programmers.

wreath 5y ago

> Code reviews. There's good reason for them to exist, but in practice at best they're a waste of time, and at worst an exercise in narcissism. People nitpicking the way a statement is written because they feel like their subjective preference is objectively better. Perfectionists who block forward progress in attempts to pick out every possible detail that doesn't matter in the big picture, instead of moving forward with 80% good. Choosing a worse solution that a reviewer suggests because you know they're always the last to back down. And code reviews rarely catch the bugs that actually matter. I found that code reviews without a design review or at least a description of the proposed design in the PR itself, is nothing but a waste of time the way you just described. Imagine a Civil Engineer being walked through a construction site and making comments right about work, while even though he knows the fellas are building a bridge, he has no idea how that bridge ought to look like etc. This becomes a waste of time because I have to read the diff and build a mental model, which is at best a guess, of what the author wanted to build/change based on just the diff. This is even worse with code bases I'm barely familiar with (which is increasing since we have a bunch of "micro services").

afarrell 5y ago

Thats because “best practices” only apply in simple situations. In complex dynamic situations made of humans with feelings, there are only “good practices” which might be applicable in context.

massung 5y ago

Re: Code Reviews Like anything there are good versions and bad versions. I think we've all been through bad code reviews and bad code review processes, so let's skip talking about those. On the other side, here's what good code reviews/processes I've been a part of accomplish: 1. The give the creator of the code the opportunity to rubber-duck. I've found that 80+% of all bugs found in code (before merging) are found by the programmer themself just by talking through what each change is meant to accomplish. 2. The give the reviewer(s) the opportunity to ask very simple questions and questions about how the code change relates to other major systems that the PR creator may not even be aware of. If there are any remaining issues with the change (the last 20%) this is usually where they are found. This isn't about where to put curly braces. If your team cares about that, use auto-formatting tools or something. 3. It gives somebody... ANYBODY... other than the PR creator, some idea of what the code does and why. This is absolutely critical as it spreads the bus factor. When something goes wrong and a programmer is sick, on vacation, or has left the company, it's critical that there be one or more other programmers who can pick up the mantle. They may not have deep knowledge, but they aren't coming into the code blind either. 4. Building on 3, it spreads the architectural knowledge and decision making of the code base among all the programmers. Code reviews shouldn't only be "run" by senior/lead programmers. Senior programmers should be getting reviewed by junior programmers as well. It's not ego or about teaching. It's about realizing we all make mistakes and we all contribute to the same end goal. Over time, everyone becomes aware of the systems at play and what's going on. When they are presented with a task, they have a much deeper understanding of what's involved, they can estimate better, and they are aware of who else to talk to or involve in the process. Junior programmers will get comfortable speaking up in architectural meetings and bring up good points. This is one way they become senior programmers.