
Ask HN: Fed up with the narcissism - seniorqhelp
Hey HN,<p>I&#x27;m on here seeking some advice in my job. I work on a software team that is so freakin&#x27; narcissistic it&#x27;s unbelievable. For the past 2 months I&#x27;ve felt like I&#x27;m ready to scream at the first person who crosses me.<p>I honestly could not care less how other people write code. I&#x27;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&#x27;t take no for an answer. This has burned me so completely out to the point where I don&#x27;t even care anymore.<p>My wife says I should just start telling people to leave me alone, because I&#x27;ve clearly got a lot of bottled up anger. But I know that kind of thing would definitely get me fired for being &quot;closed minded&quot; or &quot;unwilling to learn&quot; or some other bull-crap. And the truth is, I need the job.<p>All the non-programmers like the product team, testers and managers are fine and wonderful people. I have no issues with them.<p>I&#x27;m not on here to complain so please don&#x27;t understand me that way. I&#x27;m here to find a solution to a problem that is really troubling me.<p>Thanks!
======
partycoder
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
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
\- 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
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
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
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
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.

~~~
seniorqhelp
Okay, well, at least I know that now. Thanks again.

