This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
@msarit starts things off with their reply to What are some common falsehoods about working as a software developer?:
That the increased salary is worth anything you give up or endure ... in my short time as a dev, I've realized that balance and mental health are every bit as important as the paycheck.
When you have a distro that comes out of the box with basically nothing but a package manager, you need the wiki.
Need sound, read the wiki, need a UI, read the wiki. Ran into an error, read the wiki.
Few docs are written by those who have sloshed through pain and misery building your own Linux distro from the bottom up.
Hell, the wiki is a great resource for basically any Linux distro.
shares her answer and rationale in response to What software development tools (libraries/frameworks/apps/whatever) make you feel most anxious while you're working with them?:
Because at that point, something is VERY wrong.
@molly_struve drops some serious knowledge to an anonymous poster, answering the question How would you handle a conversation with someone who thinks "respecting an opinion" means "agreeing with it"?:
First off, as a less experienced dev, it is your job to question all of us with more experience so I commend you on doing that!
I guess the only way I would have approached the situation a little differently would have been to ask more questions. If two more experienced engineers than yourself share the same opinion that is opposite of yours keep asking why so that you can hopefully better understand where they are coming from. I find it also helps to always remember that everyone wants the same thing, a well functioning code base. The vast majority of people out there aren't trying to write bad code or make bad decisions on purpose, they are doing the best they can with what they know.
Beyond that, there will be times when you will disagree with coworkers and you have to pick your battles in those cases. Usually when it comes to little things like code organization or implementation I let those go. If its something I think would potentially be problematic to the code base in the future I will argue for those. I have always been on teams where people are very receptive to collaboration so I have never had to go up against an "asshole" who won't budge just because. Most the time everyone hears everyone out and we pick a solution.
Notice I said "a solution". You may think you have the best solution but the team may decide to implement another one instead. If that is the case then go with the team and trust that they picked that other solution on its merits. There are a million ways to do things in our industry and hundreds of ways to do them "right" so you always have to be open to those other methods.
That got a little rambly but TL;DR only thing I would have done differently in your case is asked more questions and taken the conversation to in-person immediately after the disagreement started bc PRs are horrible for back and forths a lot of the time. Talking it out I find is better.
Hope that helps! 🤗
Personally, the weirdest and hardest to solve bugs for me are when the C++ optimizer takes a shortcut that ends up ignoring my code. These are usually cases where, for example, a pointer cannot be NULL according to the standard and therefore my NULL check is ignored.
I know of two other bugs which are gloriously Byzantine. I don't know Trey Harris, but his bug is legendary: The 500 Mile Email
I do know (and used to work for) Dave Baggett, and have heard this story first-hand. My Hardest Bug Ever
See you next week for more great comments ✌