Comment by TrackerFF | Hacker News Reader

Comment by TrackerFF | Hacker News Reader

Hubris, to the point where everyone around you must be a moron.

I've seen very talented developers fall prey for that one. They seem to fit the pattern of your typical "hacker" type that grew up spending all their youth on coding, and thus binding a lot of their identity and self-worth to their coding abilities.

They blaze through college, being extremely competitive among their peers, and are often among the "go-to" students in class, which only boosts their ego even further.

Then they join the workforce, and find themselves having to work with other people - and they hate it. Any hint of criticism is taken deeply personal, like a sledgehammer to their self-worth. Tips and tricks from others are equally bad - who are they to teach you anything? After all, you've been banging out code and reading books since you were 9.

Code review is like walking on eggshells for the others - they know you'll roll your eyes, chuckle and snort, and just shoot down any incoming comment.

If only you didn't have to work with all these morons around you - the very people that are slowing you down. Move fast and break things, isn't that the motto?

What if the guy who thinks everyone is a moron, is the moron?

I have a team leader right now who blocks all of my PRs and always demands rework, despite the code functioning exactly as intended and being performant and efficient as well, and maintainable too.

Even a talented developer who can't get along with others even on a minimal basis ... may as well be the moron.

At some point you've got a job, and code alone is not the whole job. Can't do part of it, then you're not doing a good job.

A job is almost never just code.

Some of my coding jobs are no code

or put differently - learning how to code is table stakes. It's boring and not impressive.

That team lead might have insecurity issues. It will not get better. Switch teams asap.

Thanks so much, I'm working on that!!! Good to hear the confirmation of my suspicions..

I worked for a guy like that. I even tried going to him before I implemented anything try and get it to his liking the first time. He would still demand rework after doing it his way .

This same exact thing is happening to me! Like man, I implemented your sequence diagram your way!

This. So much this. I have worked under countless team leads who are like this.

At first I thought I was just hopelessly bad at coding/following instructions, but even when I pair programmed with these folks and followed their every instruction, they'd still want to refactor all of it the next day.

Some people are just never content unless it's 100% written by them.

> He would still demand rework after doing it his way

I sometimes do that with contracts drafted by junior lawyers — and often it's due to having had additional thoughts after seeing an actual "product," in sort of a fail-fast mode of drafting. Could that be part of the explanation in your case?

> He would still demand rework after doing it his way .

I've dealt with this before by documenting everything they told me to do differently, with date and time.

Always fun doing code review in a group, having the lead point out a number of problems they have with the code, especially actual bugs, and pulling up the changelog which includes notes from the one criticizing your code, telling you to make those design choices. I've collapsed whole meetings this way, with people walking out and going straight to HR with requests to transfer teams. Really helps to remove the poison from the group.

You just got to add a duck.

If it's really an issue, get a trusted 3rd party (or two) in the team or organization to evaluate your PRs -- and the team lead's feedback. Eventually with a few iterations of this, the reality will become evident for everyone. There should be an engineering manager above the lead that is vested in this process being successful.

I'm gonna guess they have a bit of oppositional defiance disorder. I'd probably try to change teams because that's not going to change.

A pretty specific guess for someone we know basically nothing about!

Leave something obvious and easy to fix on each PR. This lets them get their 2c in and you can move on with life.

I've found what always works there is

var string = "";

instead of

String string = "";

My teammates waste their time focusing on the most inane things.

Is your code actually correct, efficient, and maintainable? Does the rework improve its correctness, efficiency, or maintainability?

There are members of my team whose PRs are rarely approved without rework. There are other members of my team whose PRs almost never require rework.

It's just a gut check question. This guy could be totally wrong and a jerk. Or he could be right and a jerk. If he's right and a jerk, then internalizing that feedback might help you (even if he's still a jerk.)

I've been struggling with the same issue. I have a team lead who, if they have no good feedback, will fabricate an issue with my code during PR reviews, no matter how trivial. I sometimes have to take a step back and laugh. I understand some people may be under the illusion that they must give feedback no matter what, at the risk of seeming unsavvy, but it's starting to become ridiculous, and it seems more about competing with me rather than giving me genuine, constructive feedback.

I make sure to thoroughly document my changes in my commit messages and sometimes in my comments, especially documenting who requested the change so that there's a nice paper trail. I also push back often, but the mere act of responding to feedback that does not seem honest from a team lead is traumatic.

My problem is: how do you report such a passive-aggressive person? A single request or question on its own seems benign and not particularly harassing, but the overall trend is a huge red flag. To be honest, I'm not sure much can be done.

If you decide for whatever reason that you cannot leave, the best way to deal with a passive aggressive person is to erase from your memory that they are passive aggressive at all. It is a test of wills that you will win, just don't lose your cool. Never forget that a passive aggressive person is a fundamentally insecure person, and then you will always have the upper hand.

I am simultaneously sad and a bit relieved that others are also struggling with a problem that I thought was uniquely mine!

This is genuinely just an example of bad management and bad workplace politics. If the code is working and checks all the boxes, nobody in the organization should be allowed to say "I personally do not want your code to be deployed", especially if other developers dont face such restrictions.

The simple solution is to leave, but I am growing tired of job hopping. If I can land a job as a lead, or at least a place that has autonomy, I am pledging not to do such things to those "beneath" me, as if that word was even true.

The real purpose of a good engineering leader is to help mentor people like this to become mature. They have talent -- they just need everything else (humility, social skills within the team, shared vision, whatever).

With good mentoring, I've seen a few of these so called "hacker" types transform after a few years. Also when you are 20 you're into one thing -- competition for the ego -- and 10 years later into something else -- collaboration for the group. Responsibility and experience are great transformers.

But someone has to actively give that feedback, and the "hacker" type has to be willing to learn, it's true. Some engineering leaders lack the courage to do so and this really is where the problem starts.

Reply on news.ycombinator.com