this post was submitted on 29 Mar 2025
61 points (100.0% liked)
Programming
19825 readers
335 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Everything the author describes can still be accomplished by being diplomatic and understanding without being confrontational and direct. Plus, you build a better, more resilient team that way.
I'm not really sure the author learnt what he thought he learnt.
What's the alternative to being direct? Being indirect? Dropping hints? Spreading a rumor?
Being direct is good. But 'too complex, refactor' as an explanation is just one word longer than 'fuck off'. You need to explain in detail why the solution is bad and which parts should be changed, in this case it just shows that the reviewer did not actually read the code.
The problem there is not the directness, but the terseness. This is something I had to learn myself, and fortunately was able to get feedback from colleagues who appreciated my directness and wanted more elaboration.