How to Make Other Developers Hate to Work with You • Hacker News Board

Re: How to Make Other Developers Hate to Work with You

#91

Post by faster » Fri, Feb 22, 2019, 6:24 PM UTC

ltbarcly3 wrote: post #40

vharuck wrote: post #18

I thunk there's a second "flavor" of arrogance, where a person believes they're the smartest, but not most knowledgeable, in the room. These people will openly admit they can improve and seek training, partly because they believe they're capable of anything. They don't think they're at the top of the mountain, just that their mountain has no peak. The real problem is they believe "lazy" coworkers will eventually be b…

Arrogance has very little to do with thinking you know a lot, or disagreeing with others, and everything to do with failing to follow social protocol. If you let other people speak, pause long enough that they feel like you are giving their words a fair evaluation, and then don't use words that they must interpret as telling them they are wrong you will not be seen as arrogant. This is true even if you rarely or neve…

It has taken me a few years and I still fail sometimes, but I have learned to let people finish and then ask questions instead of telling them they're wrong, even when it's totally obvious to me. "What if that fails in this way?" instead of "that will fail in this way!". It makes the discussion collaborative instead of assuming that it's my job to point out everyone's failures. The punch line in one of my favorite comic stips is "It's not healthy to keep your problems bottled up inside me." It took me a long time to see how that applied to my own interactions.

Re: How to Make Other Developers Hate to Work with You

#92

Post by peteradio » Fri, Feb 22, 2019, 6:27 PM UTC

ltbarcly3 wrote: post #87

peteradio wrote: post #66

Earlier quoted context omitted.

Point 3 though. At some point how can you be so demure? Sometimes people are just stupid and wrong and need to get checked. Some guy working for a year getting nothing done and pretending like its some other problem than what it actually is needs to be forcefully briefed on their ignorance not 'hrmm well you see we tried it this way'.

> needs to be forcefully briefed This will let you feel superior and get the pleasure of making the dumb person feel terrible, but it really won't accomplish anything productive. What do you hope to gain by doing this? Will they start being smarter? Will they be better at their job? I'm sorry, doing what you describe is just being a bully. If management isn't dealing with the problem person you should privately make…

This is good advice.

Re: How to Make Other Developers Hate to Work with You

#93

Post by ltbarcly3 » Fri, Feb 22, 2019, 6:27 PM UTC

throwaway6734 wrote: post #68

ltbarcly3 wrote: post #40

Earlier quoted context omitted.

Arrogance has very little to do with thinking you know a lot, or disagreeing with others, and everything to do with failing to follow social protocol. If you let other people speak, pause long enough that they feel like you are giving their words a fair evaluation, and then don't use words that they must interpret as telling them they are wrong you will not be seen as arrogant. This is true even if you rarely or neve…

> don't force them to admit to themselves that they were wrong: if you let people 'save face' they can just get on board and agree with you. If you force them to grapple with being wrong they will be difficult and will hate your guts I think that an inability to admit a mistake is arrogant and results in a lack of accountability and ownership over individual's work. If someone makes a mistake they should be proactive…

I doubt you properly understand that other people are full thinking beings equal to yourself since you assume everyone secretly agrees with you about every detail of everything all the time and the only issue is whether they are going to admit it or lie.

Re: How to Make Other Developers Hate to Work with You

#94

Post by say-vagnes » Fri, Feb 22, 2019, 6:34 PM UTC

ltbarcly3 wrote: post #93

throwaway6734 wrote: post #68

Earlier quoted context omitted.

> don't force them to admit to themselves that they were wrong: if you let people 'save face' they can just get on board and agree with you. If you force them to grapple with being wrong they will be difficult and will hate your guts I think that an inability to admit a mistake is arrogant and results in a lack of accountability and ownership over individual's work. If someone makes a mistake they should be proactive…

I doubt you properly understand that other people are full thinking beings equal to yourself since you assume everyone secretly agrees with you about every detail of everything all the time and the only issue is whether they are going to admit it or lie.

Can you unpack exactly what made this comment go from 0 to 100? I didn't get any of that from the parent post.

Re: How to Make Other Developers Hate to Work with You

#95

Post by hinkley » Fri, Feb 22, 2019, 6:35 PM UTC

ltbarcly3 wrote: post #40

vharuck wrote: post #18

I thunk there's a second "flavor" of arrogance, where a person believes they're the smartest, but not most knowledgeable, in the room. These people will openly admit they can improve and seek training, partly because they believe they're capable of anything. They don't think they're at the top of the mountain, just that their mountain has no peak. The real problem is they believe "lazy" coworkers will eventually be b…

Arrogance has very little to do with thinking you know a lot, or disagreeing with others, and everything to do with failing to follow social protocol. If you let other people speak, pause long enough that they feel like you are giving their words a fair evaluation, and then don't use words that they must interpret as telling them they are wrong you will not be seen as arrogant. This is true even if you rarely or neve…

The thing that gets me is the same thing I hate about politics. You build an elaborate plan on a bad supposition, and people hear the whole plan and forget it’s based on nonsense.

If the ground premise is wrong, and you see where they are going with this silliness, it’s challenging on multiple levels to “let them finish”.

Re: How to Make Other Developers Hate to Work with You

#96

Post by zzzcpan » Fri, Feb 22, 2019, 6:37 PM UTC

hnbroseph wrote: post #86

zzzcpan wrote: post #24

Referencing Dunning-Kruger effect in any topic on software engineering is very arrogant and pretentious on itself. This says more about the author, than other people's stupidity. The article is just bad.

why does it "say more about the author"? does your comment about Dunning-Kruger "say more about you" than the author?

Well, if you use a fictional interpretation of something known as a justification to claim that other people are stupid - you provide nothing of value regarding other people. And the only thing that can be extracted from this is that you feel the need to claim that other people are stupid.

Re: How to Make Other Developers Hate to Work with You

#97

Post by widforss » Fri, Feb 22, 2019, 6:38 PM UTC

edmundsauto wrote: post #64

duxup wrote: post #38

Earlier quoted context omitted.

God knows. Especially when you're new like me. I go back even after a month and "Oh man I'd never do it like that again." No to say it didn't work or was even bad but I just found a better pattern to handle that case that I'd use by default now and it changes so much.

My advice: see if you can rewire your internal rewards. That feeling is the acknowledgement that you learned something. The fact our ancient rewards system considers it embarrassing is of little importance.

Thank you, I'll keep this in mind for the next time it happens.

It's just that the code is still there, and will need to be replaced in due time. Over and over again.

Re: How to Make Other Developers Hate to Work with You

#98

Post by lolc » Fri, Feb 22, 2019, 6:40 PM UTC

balabaster wrote: post #32

vharuck wrote: post #18

I thunk there's a second "flavor" of arrogance, where a person believes they're the smartest, but not most knowledgeable, in the room. These people will openly admit they can improve and seek training, partly because they believe they're capable of anything. They don't think they're at the top of the mountain, just that their mountain has no peak. The real problem is they believe "lazy" coworkers will eventually be b…

> "usually leads to components nobody can understand let alone maintain" As you advance up the mountain, you will learn to see complexity simply. When you make this realization, your components will simplify dramatically. You must learn to see simply before you can design simply. It just takes time. There's nothing wrong with this, humility doesn't mean giving up your belief that you're capable of anything. We were a…

As individuals, there's damn little we can achieve.

Re: How to Make Other Developers Hate to Work with You

#99

Post by balabaster » Fri, Feb 22, 2019, 6:41 PM UTC

lolc wrote: post #98

balabaster wrote: post #32

Earlier quoted context omitted.

> "usually leads to components nobody can understand let alone maintain" As you advance up the mountain, you will learn to see complexity simply. When you make this realization, your components will simplify dramatically. You must learn to see simply before you can design simply. It just takes time. There's nothing wrong with this, humility doesn't mean giving up your belief that you're capable of anything. We were a…

As individuals, there's damn little we can achieve.

Nobody said you must do it alone.

Re: How to Make Other Developers Hate to Work with You

#100

Post by stcredzero » Fri, Feb 22, 2019, 6:41 PM UTC

How everyone can be right, but everyone gets annoyed anyways.

Cast:

Developer A, a younger developer who is recognized company-wide as an expert in the latest features of blb++.

Developer B, an older developer who maintains widely used legacy code in blb++ involved in about 80% of a billion dollar multinational's profits.

Dev A: Your group should change the coding style in this application to the new standard.

Dev B: Sure. But since we don't have good Unit Test coverage in this area, we shouldn't just go in and do it by hand. I need to guarantee correctness. I've done a change this big before using a syntax driven automated code rewrite tool, and one can guarantee correctness if the code structure allows it. If you know of such a tool for blb++, you can help me out and we can do it.

(Background for the reader: No such tool exists for blb++ which can guarantee correctness. Such tools do exist for other languages in Dev B's work experience.)

Later on, Dev A is grousing about how Dev B is just coming up with esoteric excuses to do nothing. She's kind of put off. Dev B is put off, because he's kind of been accused of making stuff up, even though he's talking from a particularly interesting and valuable part of his work experience.

Dev A is correct, in that the new coding style is better, more efficient, and would even prevent mistakes going forwards. Dev B is correct, in that he really needs to guarantee correctness, especially if he's going to make a change that big which has no visible benefit to stakeholders. What's the takeaway?