4 ms·

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

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.
  - partycoder 10y ago
    The first thing you describe is a requirement analysis problem. Gather the requirements from the stakeholders, get them to reach consensus, then start your work. There are books on software engineering, with chapters dedicated to requirement analysis. You can review them to gather some useful ideas on how to proceed in these cases. If they disagree with each other, hold themselves accountable for being inconsistent by having them talk to each other. Organize a meeting. You have already expressed your opinion about nitpicky/egomaniacs/etc... enough. This way of addressing the problem is not helping you. Approach the problem in technical terms. If you are going to prevail in any way, it will be by defending your work in technical terms, not by dismissing the problem or name-calling people. I asked you to provide concrete code examples of what they want to try to understand if it's actually nitpicky or not.
    - seniorqhelp 10y ago
      Hey, thanks for the discussion, kind internet stranger. You are making me think more clearly. Should every other programmer on a project be considered a stakeholder? Or does trying to please everyone become a futile endeavour, at some point? I guess what I'm saying is I literally don't care about the technical upsides and downsides of writing code a certain way anymore. There was once a time where I searched for objective truth in software design, but no more. So it's impossible for me to discuss those topics without sounding like an ass. Does that make me a mediocre programmer? A lot of these same people have admitted to me personally that I do high quality work. I feel like that should be enough. I shouldn't have to defend every line of code like it's a PhD thesis. Am I wrong?
      - partycoder 10y ago
        I am afraid you are wrong. Requirement analysis is step #0 in the SDLC. You are failing to capture non functional requirements and moving a technical discussion to a interpersonal level. Until you understand that you will be stuck. In this thread for example. I have proposed different rational courses of action that you dismissed without providing a reason. This communicational style will certainly bring you issues at the time of capturing requirements for your deliverables. Ignoring requirements from technical stakeholders will only reinforce the idea that you need more feedback and more mentoring, or that you just need to be let go.

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.
- partycoder 10y ago
  The first thing you describe is a requirement analysis problem. Gather the requirements from the stakeholders, get them to reach consensus, then start your work. There are books on software engineering, with chapters dedicated to requirement analysis. You can review them to gather some useful ideas on how to proceed in these cases. If they disagree with each other, hold themselves accountable for being inconsistent by having them talk to each other. Organize a meeting. You have already expressed your opinion about nitpicky/egomaniacs/etc... enough. This way of addressing the problem is not helping you. Approach the problem in technical terms. If you are going to prevail in any way, it will be by defending your work in technical terms, not by dismissing the problem or name-calling people. I asked you to provide concrete code examples of what they want to try to understand if it's actually nitpicky or not.
  - seniorqhelp 10y ago
    Hey, thanks for the discussion, kind internet stranger. You are making me think more clearly. Should every other programmer on a project be considered a stakeholder? Or does trying to please everyone become a futile endeavour, at some point? I guess what I'm saying is I literally don't care about the technical upsides and downsides of writing code a certain way anymore. There was once a time where I searched for objective truth in software design, but no more. So it's impossible for me to discuss those topics without sounding like an ass. Does that make me a mediocre programmer? A lot of these same people have admitted to me personally that I do high quality work. I feel like that should be enough. I shouldn't have to defend every line of code like it's a PhD thesis. Am I wrong?
    - partycoder 10y ago
      I am afraid you are wrong. Requirement analysis is step #0 in the SDLC. You are failing to capture non functional requirements and moving a technical discussion to a interpersonal level. Until you understand that you will be stuck. In this thread for example. I have proposed different rational courses of action that you dismissed without providing a reason. This communicational style will certainly bring you issues at the time of capturing requirements for your deliverables. Ignoring requirements from technical stakeholders will only reinforce the idea that you need more feedback and more mentoring, or that you just need to be let go.