3 ms·

This isn't specific to code comments, but one soft skill that everyone should learn is how to have conversations with high stakes. The code changes might not be

This isn't specific to code comments, but one soft skill that everyone should learn is how to have conversations with high stakes. The code changes might not be high stakes, but having a good relationship with your peer is very high stakes. I recommend a book called "Crucial Conversations". You can find it on Amazon. It's a fantastic book about how to recognize that you're making "The Fool's Choice" (their words)... and how to get out of it. To apply the book to your case, you've boxed yourself into two options (I.e., The Fool's Choice): 1) I can argue with this person and could have an unfavorable outcome, or 2) give in and just do what they want. This is actually a false dichotomy -- there are other options! One of the possible options is to turn that choice into a question by turning them into an AND option instead of OR options. In other words, instead of asking yourself "Should I make the code change OR make them hate me?" you should ask: "How can I nudge them toward my way of thinking AND _not piss them off_?" This alters your frame of mind, and you would approach the conversation much differently than you would before. Anyway, that's the gist of it. The book is fantastic, though, and I recommend you read it. It's a pretty easy read. Good luck!

samstave 7y ago
I have managed senior engineers in almost every discipline who were SMEs in their area, and either much smarter or skilled than myself. A way I dealt with this was to ensure the discussion was on the project/problem - and that people had input on the solution regarding its feasibility. i.e. "OK, team, tell me why or how this solution can fail" and "OK, what is the negative impact of doing it this way?" "Can you see any holes in this method?" The idea is that people can voice concern about failure conditions for a solution - and it keeps them focused on the project/problem/solution and less on their ego or interpersonal communication between team members. So if an engineer wants to do something that will have an impact on someone else should that thing break, then it can be weighed into the value of that solution.

samstave 7y ago

I have managed senior engineers in almost every discipline who were SMEs in their area, and either much smarter or skilled than myself. A way I dealt with this was to ensure the discussion was on the project/problem - and that people had input on the solution regarding its feasibility. i.e. "OK, team, tell me why or how this solution can fail" and "OK, what is the negative impact of doing it this way?" "Can you see any holes in this method?" The idea is that people can voice concern about failure conditions for a solution - and it keeps them focused on the project/problem/solution and less on their ego or interpersonal communication between team members. So if an engineer wants to do something that will have an impact on someone else should that thing break, then it can be weighed into the value of that solution.