3 ms·

Ask HN: Fed up with the narcissism

3 points by seniorqhelp 10y ago

Hey HN, I'm on here seeking some advice in my job. I work on a software team that is so freakin' narcissistic it's unbelievable. For the past 2 months I've felt like I'm ready to scream at the first person who crosses me. I honestly could not care less how other people write code. I've been doing this for so long, I know that any given stylistic or architectural decision will cause me no more than 5 minutes difference in the time it takes to read a piece of code. Yet at this company, every senior dev or tech lead has their 2 cents about your work, and won't take no for an answer. This has burned me so completely out to the point where I don't even care anymore. My wife says I should just start telling people to leave me alone, because I've clearly got a lot of bottled up anger. But I know that kind of thing would definitely get me fired for being "closed minded" or "unwilling to learn" or some other bull-crap. And the truth is, I need the job. All the non-programmers like the product team, testers and managers are fine and wonderful people. I have no issues with them. I'm not on here to complain so please don't understand me that way. I'm here to find a solution to a problem that is really troubling me. Thanks!

partycoder 10y ago
As a person that works maintaining code, I think coding style does have significant impact in a project health, and I personally also emphasize it. Some people belittle the importance of coding style, e.g: the tabs vs spaces war, etc. But some guidelines do have a lot of impact in readability, e.g: guidelines for identifiers, for statement length, function length, cyclomatic complexity, nesting, asynchronous operations, error handling, etc... and all have an objective practical purpose. Now, to receive feedback: - Ask the person to focus on the perceived issue. If the person moves on to a personal level, ask the person to keep the conversation strictly technical and constructive. - Taking notes will help keeping the conversation professional. Later on you can count what topics appeared more frequently, and rank the issues according to their frequency. - Get specific and actionable feedback. What specifically needs to be addressed and how? Ask for examples, try to understand what the person is trying to say. - Do not be dismissive. This will only redirect all the negative feedback for you to other people, like your peers, your manager, technical stakeholders, etc. You can, however, based on your professional opinion, empirical evidence and facts, refute an idea, always providing a technical justification. Before upfront rejecting feedback, give their advice a try, form your own opinion and share your thoughts.
- seniorqhelp 10y ago
  I think you're making the assumption that the feedback I'm getting is valid and reasonable, and not just pointless nitpicking and technical oneupmanship. I was willing to give my co-workers the benefit of the doubt for a long time but I'm past that point now. I'm starting to think this behavior is normal in the industry, and it's making me not even interested in being a programmer anymore.
  - partycoder 10y ago
    - Can you provide an example of what the "nitpicking" feedback is? - Is their feedback consistent? Given the same code, will they provide the same feedback? If the answer is no, then it's not random. - When other developers submit code having the same elements being frowned upon, do they receive the same feedback? If the answer is no, it's not a personal thing against you. - Is it based on documented guidelines? If the answer is no, ask them to document it. - Do you test your work and stand behind your work? Or other people have to test it for you? If the answer is no, don't give others a excuse to criticize your deliverables. Test your code, stand by your work. I am trying to understand your situation. Sometimes it is easier to believe that others are wrong or ill-intentioned than accepting there's room for improvement in your work. But sometimes, people are passive aggressive and use any opportunity they have to cause you harm. Sometimes people seek to be perceived as more important and use these instances to establish a relative rank. I find both practices unacceptable and unsustainable. Sometimes it's all of the above. Let's find out what it is. If you are dismissing guidelines, you are basically disrespecting the organization. If you disagree with them, start a discussion/proposal to have them changed rather than ignore them. In your proposal, present viable alternatives and a reason of why they're better. I've personally been in both ends of the feedback process. Some people will just not take feedback at all, and take things personally, when you are just trying to improve code metrics and reducing incidents.
    - seniorqhelp 10y ago
      I recently was asked by three different people on the team to refactor the same code in 3 different ways, one after the other. There were no defects associated with this work, yet it was so urgent that I had to stop the feature I was working immediately and do it. It took a week to satisfy everyone and I was exasperated and engulfed in merge conflicts by the end. I don't think it is specifically directed at me. I think it's just the culture. I've seen them do it to others, i.e. someone will go on vacation and they'll take that opportunity to refactor their work. Objective things like metrics and syntax rules, I don't have a problem with. I'm talking about matters of opinion here. Things like architecture, as in, "I would have done it this way instead because DRY and SOLID and loose coupling, etc." Principles which can be used to justify practically any change. I feel like they associate being nitpicky and obsessive with producing high quality code, so the most nitpicky people are seen as having the highest personal standards. They don't consider it might be a form of egomania.

3 points by seniorqhelp 10y ago

partycoder 10y ago

As a person that works maintaining code, I think coding style does have significant impact in a project health, and I personally also emphasize it. Some people belittle the importance of coding style, e.g: the tabs vs spaces war, etc. But some guidelines do have a lot of impact in readability, e.g: guidelines for identifiers, for statement length, function length, cyclomatic complexity, nesting, asynchronous operations, error handling, etc... and all have an objective practical purpose. Now, to receive feedback: - Ask the person to focus on the perceived issue. If the person moves on to a personal level, ask the person to keep the conversation strictly technical and constructive. - Taking notes will help keeping the conversation professional. Later on you can count what topics appeared more frequently, and rank the issues according to their frequency. - Get specific and actionable feedback. What specifically needs to be addressed and how? Ask for examples, try to understand what the person is trying to say. - Do not be dismissive. This will only redirect all the negative feedback for you to other people, like your peers, your manager, technical stakeholders, etc. You can, however, based on your professional opinion, empirical evidence and facts, refute an idea, always providing a technical justification. Before upfront rejecting feedback, give their advice a try, form your own opinion and share your thoughts.

seniorqhelp 10y ago
I think you're making the assumption that the feedback I'm getting is valid and reasonable, and not just pointless nitpicking and technical oneupmanship. I was willing to give my co-workers the benefit of the doubt for a long time but I'm past that point now. I'm starting to think this behavior is normal in the industry, and it's making me not even interested in being a programmer anymore.
- partycoder 10y ago
  - Can you provide an example of what the "nitpicking" feedback is? - Is their feedback consistent? Given the same code, will they provide the same feedback? If the answer is no, then it's not random. - When other developers submit code having the same elements being frowned upon, do they receive the same feedback? If the answer is no, it's not a personal thing against you. - Is it based on documented guidelines? If the answer is no, ask them to document it. - Do you test your work and stand behind your work? Or other people have to test it for you? If the answer is no, don't give others a excuse to criticize your deliverables. Test your code, stand by your work. I am trying to understand your situation. Sometimes it is easier to believe that others are wrong or ill-intentioned than accepting there's room for improvement in your work. But sometimes, people are passive aggressive and use any opportunity they have to cause you harm. Sometimes people seek to be perceived as more important and use these instances to establish a relative rank. I find both practices unacceptable and unsustainable. Sometimes it's all of the above. Let's find out what it is. If you are dismissing guidelines, you are basically disrespecting the organization. If you disagree with them, start a discussion/proposal to have them changed rather than ignore them. In your proposal, present viable alternatives and a reason of why they're better. I've personally been in both ends of the feedback process. Some people will just not take feedback at all, and take things personally, when you are just trying to improve code metrics and reducing incidents.
  - seniorqhelp 10y ago
    I recently was asked by three different people on the team to refactor the same code in 3 different ways, one after the other. There were no defects associated with this work, yet it was so urgent that I had to stop the feature I was working immediately and do it. It took a week to satisfy everyone and I was exasperated and engulfed in merge conflicts by the end. I don't think it is specifically directed at me. I think it's just the culture. I've seen them do it to others, i.e. someone will go on vacation and they'll take that opportunity to refactor their work. Objective things like metrics and syntax rules, I don't have a problem with. I'm talking about matters of opinion here. Things like architecture, as in, "I would have done it this way instead because DRY and SOLID and loose coupling, etc." Principles which can be used to justify practically any change. I feel like they associate being nitpicky and obsessive with producing high quality code, so the most nitpicky people are seen as having the highest personal standards. They don't consider it might be a form of egomania.