this post was submitted on 01 Sep 2023
254 points (96.4% liked)
Programming
17495 readers
147 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 !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Everybody trashing on code reviews has never worked with a shit coder before
I'm a shit coder and almost every single review I've made big mistakes like forgetting to delete debug/dead code and there's always meaningful improvements being suggested
I worked with a guy who brought 10k lines of code from various jobs over the years and slapped it all into a single commit second day on the job.
It was all VB.NET and looked like it was written in VB6 days because it was reimplementing functions that the .NET framework already provided us. And there were quite a few single line functions that did the simplest things like addition of two variables.
However my favorite function of all was IsMarksMachine() because it was used as a prod/dev switch. I ran into bugs testing the code and got the "Worked on my machine" line. Turned out the code branch under IsMarksMachine() somehow worked, but in all other cases, it didn't.
Mark is not the real name. But man was he a bad coder.
This was my experience too. At first I found code reviews to be an invaluable resource for improving my code. But I then reached a point where I'd learned everything I could from a particular reviewer.
I'd submit code that met every criteria, but the reviewer would still nit pick on tiny details that were entirely subjectective. It was no longer about the quality of code it became about the reviewer trying to put their mark on my work.
The only solution was to either ignore their nits or adopt the hairy arm technique whereby you include intentional errors for the reviewer to comment on so they feel their time had been valuable and you get away without yours being wasted.