2

As an early career engineer, what's the best way to deal with nit suggestions?

Profile picture
Mid-Level Software Engineer at Taro Community5 months ago

When I first joined the workplace, I used to push back on lots of nitpicky suggestions, just like how my suggestions were pushed back by peers who joined with me. I then switched teams and learned my lesson: to shut up and follow orders. Things were going well. Today, there's a small nitpicky suggestion that makes me feel unhappy once again. The suggestion is about a diagram. I think it's clear enough to have one diagram where newly proposed components are colored and existing components are uncolored. He thinks having separate diagrams for the existing state and the new state is clearer.

That guy looks like he's moving to a senior level, so I'm better off having a good relationship with him. He sometimes seems to be a nice guy and listens to ideas. I feel he is not that smart when it comes to coding and has difficulties understanding templates. His coding is not stellar. He is not a coding role model, but I actually learn soft skills from him.

Do I just need to accept that people are not equal in the workplace, right? It's a power struggle. Sometimes nitpicky suggestions feel like microaggressions and asserting dominance. I rarely see him make nitpicky suggestions to leadership. What's your approach to nitpicky suggestions?

Maybe the question could be split into 3 parts

  1. What's the best way to deal with nit suggestions from people above you?
  2. What's the best way to deal with nit suggestions from your peers?
  3. What's the best way to deal with nit suggestions from people lower than you?
53
3

Discussion

(3 comments)
  • 2
    Profile picture
    Staff Software Engineer [L6] at Google
    5 months ago

    This reminds me, one time, I was driving a project across my organization at Youtube, dealing with changes in a few sub-teams' systems. TLs of these sub-teams were leading the work in their area, and I was the "end-to-end" expert, ensuring all pieces fit together. But I was only an L4 at that time.

    Anyhow, at the last moment we discover a new requirement and I volunteer to make some quick code changes in another sub-team's (say A) codebase because engineers on that team were busy with other things. I sent my code for review to team A's TL and a fresh grad (say G) on team A, both of whom were staffed to the same project. Now, G, while extremely smart and intelligent, had some bitter feelings around how I, just an L4, could be "leading" such a big project and he didn't necessarily respect my authority or expertise.

    Now, this code change was pretty small, adding one or two new methods of 5-6 lines each. In the first round of review, he left a bunch of nitpicks around variable naming and such, which I happily addressed. Next round of review, one of his comments linked to a doc which rewrote the whole code by breaking it down into super-granular methods (of two lines each). I was flabbergasted! I felt like blasting him in the comments and asking him to write the whole damn code himself instead (which he's already done), but I held back. I copy pasted whatever he suggested to my change and went on with my project.

    A few weeks down the line, his manager (overall project lead) asked me for feedback, specifically about him. I wasn't surprised, because apparently there had been mentions of similar interpersonal issues impacting others in the team. I gave honest feedback, in typical sandwich style. I appreciate his good qualities, sprinkled in some specific and evidence based incidents of things he can do better, and wrapping up with how much potential he has.

    Long story aside, I learnt how to control some of my strong negative emotions in the moment. I can promise you that, never ever, has an outburst of expression of negative emotions in the moment has helped me. It always has become something I need to address down the line.

    For your specific scenario, I would like to share this pattern I've seen: seniors provide more feedback (including nitpicks) to new junior engineers. In some time, they start trusting them more, and provide more autonomy. So, do evaluate if you have earned that autonomy yet.

    With peers and juniors, it's a bit tricky. They don't have authority, but it's still good to have a good relationship. My formula is simple: if nitpick is easy to address and not completely absurd, I do it, no questions asked. This avoids unnecessary/futile conflict. But, if nitpick would take more effort to address, or doesn't entirely make sense, I explain my reasoning and gently turn it down. If they still don't back down, I meet in person to discuss to understand how important it is to them on a scale of 1-10. Then I evaluate how hard/absurd it is to me on a scale of 1-10. Based on these two numbers, typically we have an answer.

  • 0
    Profile picture
    Engineering Manager at Mistplay
    5 months ago

    This is really a stressful scenario to be in. If it happens over and over again from the same person to you but not as much others then I do think you are reading it correctly: this is a power struggle and this is aggressive behavior.

    I wouldn’t recommend learning too many soft skills from this person. In general it’s good to have a mindset that we win and fail as a team, and success is not a zero sum game. If that isn’t the case on your team and everyone is hyper competitive with subtle passive aggressive behavior, then it might be a team that you want to move away from.

    If it’s just this one person, I would collect some examples of how trivial the problems are and share it with your manager that this is a blocker for you.

    If it’s the first time a new person is nit picking your style or you are new to the team, my personal realization is that arguing will take way longer then even some slightly time consuming changes on my part. In general, assuming friendly colleagues, the goal is relationship building in the long run not what happens for this specific pull request or feature.

    Other things I’ve tried that have helped to varying degrees are:

    • Setting up a linter to take care of the easy stuff and avoid arguments
    • Ask for the teams guidelines for style: both code wise and system design docs. If they don’t have one, keep track of everything they’re telling you and make a guide.
    • If it doesn’t matter that much but doesn’t hurt anything, you can adapt to the new style and match it going forward to not keep repeatedly bringing up the same point
  • 0
    Profile picture
    Engineering Manager at Mistplay
    5 months ago

    To answer your questions specifically this would be my thought about nit picks that are repeated from one person and feel aggressive:

    • From people lower than you: politely fix a couple and ignore most of it, steering them back to what’s important about your work and a guide on how you are following best practices
    • From peers: if it feels aggressive try to repair the relationship. Don’t push back on the nits specifically but focus on connecting with them as a person and understand where they are coming from. Maybe it would be possible to have coffee and get to know them?
    • From people above: if it’s repeated for a long time and a manager isn’t helping I’d find a new team sooner rather than later