Episode 170: Code rage and code review etiquette

Vote for Soft Skills Engineering on the Hackernoon Noonies awards for best Dev Podcast!

In this episode, Dave and Jamison answer these questions:

  1. How do I stop getting angry at other peoples’ code?

    Often when solving a complicated problem or implementing a feature, I have to modify or at least use systems designed by someone else. Often I find myself thinking ““Why did they do it like this??? This is so dumb!”” and literally getting mad in my chair. This happens no matter who wrote the code, and occasionally I discover that the author of the code was in fact Past Me.

    I know logically that everyone codes the best way they know at the time. So how do I avoid such a visceral reaction? Is this a common problem? Is this why many programmers seem to be Grumpy? My frustration often derails my focus and makes problems take longer to solve than they need to.

  2. What is the right etiquette for a code review for a pull request? I recently had an amazing code review. The reviewer pulled my branch, make a branch for changes he suggested and those changes all led to better and cleaner code. I felt the reviewer really tried to understand my design and test every suggestion before he wrote it. I felt that my code really got respect from the reviewer. However, a lot of my code reviews are just passive aggressive nitpicking like the comment formats are not right, the variable names aren’t clear enough. The worst was when I got a comment saying “this is already implemented” which after hours of figuring out what it meant was a different thing that would not work in my case. It seems like people have different ideas of what code reviews are and the etiquette and the expectations for it. As a reviewer and a reviewee, what should ideally happen in a code review process? Right now most code reviews are exhausting and infuriating experiences.

Om Podcasten

It takes more than great code to be a great engineer. Soft Skills Engineering is a weekly advice podcast for software developers about the non-technical stuff that goes into being a great software developer.