4 ms·

I've found that if part of a codebase is truly shoddy or just plain badly written, the developer who wrote it generally knows how bad it is, or at least that it

by J5892 6y ago

I've found that if part of a codebase is truly shoddy or just plain badly written, the developer who wrote it generally knows how bad it is, or at least that it's not up to snuff. Criticizing the code itself (with useful feedback), and not the person who wrote it, gives them a chance to own up to it if they're comfortable with doing that. And if not, you're still able to improve the codebase without directly calling them out. If they get pissy about it, that's on them.

vinay_ys 6y ago
For someone to see your criticism as objective, the objective standard should be established ahead of time. For design/code reviews this means having coding standards/guidelines and training everyone to stick to them – rules of the game are known ahead of time to all participants. Then it is much easier to convince someone that it is objective feedback. A critical skill for a senior engineer in a team is to define and establish such standards for the team. Rather than reacting to each design/code review, taking the time to setup these process mechanisms is a lot more productive and healthy for everyone involved. This requires strategic thinking (a skill that comes with practice) towards how you choose to spend your time at work to accomplish anything.
- berkes 6y ago
  > as objective, the objective standard should be established ahead of time. A lot of projects lack that "objective standards". I've been helping to solve exactly this. But code can be messy without having a clear defined "clean code" standard. And a project can perform horrible, without having minimum response times docutented. Often my job was to define all those. And often those definitions already hit a nerve. When suddenly your code is marked as "far too tightly coupled" or "too complex: AB above 34" when you thought it was neat and smart code, that is confronting and, I've seen, is often felt as personal critique.

by J5892 6y ago

vinay_ys 6y ago

For someone to see your criticism as objective, the objective standard should be established ahead of time. For design/code reviews this means having coding standards/guidelines and training everyone to stick to them – rules of the game are known ahead of time to all participants. Then it is much easier to convince someone that it is objective feedback. A critical skill for a senior engineer in a team is to define and establish such standards for the team. Rather than reacting to each design/code review, taking the time to setup these process mechanisms is a lot more productive and healthy for everyone involved. This requires strategic thinking (a skill that comes with practice) towards how you choose to spend your time at work to accomplish anything.

berkes 6y ago
> as objective, the objective standard should be established ahead of time. A lot of projects lack that "objective standards". I've been helping to solve exactly this. But code can be messy without having a clear defined "clean code" standard. And a project can perform horrible, without having minimum response times docutented. Often my job was to define all those. And often those definitions already hit a nerve. When suddenly your code is marked as "far too tightly coupled" or "too complex: AB above 34" when you thought it was neat and smart code, that is confronting and, I've seen, is often felt as personal critique.