5 ms·
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
by 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 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.