3 ms·
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
by 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 agoThe 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 agoHey, 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 agoI 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.
- seniorqhelp 10y agoOkay, well, at least I know that now. Thanks again.