Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Make Other Developers Hate to Work with You

anaxi.com

Post reply on HN
Print view View original

121–130 of 191 posts

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

#121

Post by neilv »

Dzugaru wrote: post #65

> Developers can’t easily go back to where they were right > before an interruption. They need to get into the mindset > for development and then slowly trace back to where they > left off. And every fellow developer knows that. I used to think like that too, but after 10 years programming in many environments, now I'm inclined to disagree. If I cannot refocus immediately after interruption - I know I'm doing somethi…

Being able to reliably refocus after interruptions is an enviable skill.

I've learned some of that (especially when I was an intern divided 50/50 between development and interrupt-driven sys-admin :), but for me, interrupt cost seems to vary widely with the demands of the task and the nature interruption.

Web/GUI front-end work is usually very interruptible for me, for example. Usually, most of the time, I have in mind "I want to get to roughly this, and I just need to spend time getting or making the tools get there", and it's often easy to see where I left off. Coding seems usually mostly proceeding along a series of small tasks ("those controls are done, and next is that control"), or iterative refinement ("these two elements could be combined", or "this part of the layout is poor when rotated"), which are often very visible, and easy to get into.

However, if, for example, I'm in the middle of designing an algorithm, and trying to cover every case in a good form, and trying see opportunities, and I've mentally "paged in" a lot of domain-specific information and scenarios and such... an interruption at that moment with something that requires a very different domain to be paged in, and substantial thought... could really ruin the roll I was on with the algorithm. Even if I have a tentative skeleton with quick comments sprinkled through it, for the current thinking and known questions/opportunities. I'm simply not smart enough that I can't sometimes lose something with a big interruption at the wrong moment.

There's also the theory and meme of "flow" [1], but I don't understand it well enough to say whether it covers the impressions above.

[1] https://en.wikipedia.org/wiki/Flow_(psychology)

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

#122

Post by bgroat »

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…

I'm the worst for this. I firmly believe that given a totally novel problem in any domain that neither of us are familiar with. I will always solve it before you.

I also believe that whatever domain you're currently in I can outperform you in 5 years MAX.

It's crazy the bullshit we believe that 'feels' right day by day

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

#123

Post by mjsaah »

stcredzero wrote: post #100

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:…

Uh, Dev A should take the time to understand Dev B's argument before writing it off as esoteric excuses.

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

#124

Post by ajdecon »

stcredzero wrote: post #100

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:…

> What's the takeaway?

"Unfortunately this tool doesn't exist for blb++, but we should still improve our coding style for this application. Is there another way to improve our correctness testing? If we allocate some time to improving unit testing, maybe we can do this refactor once we have X% coverage in these critical parts of the codebase."

I.e., acknowledge that both goals are valid, and look for alternate solutions to make incremental progress towards both. Finding middle ground is unlikely to be satisfying from either viewpoint. In this example, Dev A isn't getting a quick win from fixing the coding style right away, and Dev B needs to allocate some time to improving testing. But especially when working on big teams and projects, this kind of piece-wise progress is where I've seen most things get done.

This kind of solution might be pointed out by either Dev A or B, or they might need to bring in a fresh pair of eyes if they're both already frustrated. :)

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

#125

Post by thegayngler »

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…

Thank you for your admission. I too am naturally arrogant. People think I'm being weird if I'm not arrogant. I get weird people saying they don't believe me when I'm being humble. Probably because arrogant is who I am as a person. I feel people like me more when I'm being my arrogant self. Oddly, when I was my least arrogant and most humble I exhibited most of the traits in this article.

I was quite sour over the fact that I felt like during the interview process I was lied to about the position and what it would entail. Naturally, I was a bit salty about it and the fact that people were doing things that I would get criticized for. It ultimately hurt my confidence in myself. This made me exhibit most if not all of these traits during my stay at this company. I was trying to make lemons into lemonade. Ultimately I was able help us get on the right path and I was happy with my contributions to the team even if it did ruffle feathers and those people hated me afterwards. I took their criticism and I still try to use it to be a better person to work with.

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

#126

Post by whttheuuu »

finaliteration wrote: post #63

I’ll add another one: Nitpicking constantly. I’ve worked with people who will fight and argue over every. Single. Detail. It drives me insane and usually makes me quit faster than anything else when I encounter those people.

This.

There are 2 types of developers: those who enjoy philosophizing about programming minutiae and then there are those who enjoy shipping products.

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

#127

Post by gerbilly »

scandox wrote: post #71

Here's a profile of a developer: - Easy going and pleasant. - Really interested in programming and tech in general - Talks intelligently about the problem at hand. Asks all the right questions. Agrees a plan of action in collaboration with colleagues. - Creates systems that definitely appear to work - Code looks pretty sane. Structure is right. Style seems good. - Always very responsive to problems. Jumps straight on…

I have definitely experienced this.

Imagine a competent developer writes a mostly correct system with few bugs, and that requires few fixes over time.

Management will likely perceive the first incompetent developer as better than the more competent one.

Why? Because the incompetent developer is seen to be fixing problems all the time, which is a positive thing.[1] (You could say his work is more 'salient' to management.)

Frustratingly, the incompetent guy comes off as a rock star.

[1] Ignorant of the fact that the problems were created by the developer himself.

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

#128

Post by gerbilly »

kyberias wrote: post #102
scandox wrote: post #71

Here's a profile of a developer: - Easy going and pleasant. - Really interested in programming and tech in general - Talks intelligently about the problem at hand. Asks all the right questions. Agrees a plan of action in collaboration with colleagues. - Creates systems that definitely appear to work - Code looks pretty sane. Structure is right. Style seems good. - Always very responsive to problems. Jumps straight on…

Yes. Very enthusiastic, outspoken, easy going, pleasant to work with, but really can't complete the tasks without someone going back and fixing it.

> easy going, pleasant to work with

This is a survival tactic, and in a way it's a dishonest put on.

If the same developer were abrasive arrogant and difficult to get along with, then the other programmers, who always have to fix his work, would have him run out of the company.

Meanwhile, sometimes the crustiest curmudgeons in a team are the ones who have the most experience and knowledge to impart if you get to know them.

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

#129

Post by cmurf »

peteradio wrote: post #66
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…

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'.

Sounds like they have a bad manager. Yes some people are bad at their job, and that includes developers, but in every case I've encountered it, their manager enabled it. It could be an equally arrogant bad manager, or a milquetoast bad manager. Servility in a manager is a bad attribute. They should be someone who seeks out the demure contrarian and acts as their advocate, should the manager find their position compelling. Not everyone is confrontational, that isn't the problem though. If the manager isn't seeking out contrary opinions, and only acts obsequious to their developers? That's a stool pigeon of a manager. Bad manager and bad developer? Good luck with that combination.

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

#130

Post by finaliteration »

whttheuuu wrote: post #126
finaliteration wrote: post #63

I’ll add another one: Nitpicking constantly. I’ve worked with people who will fight and argue over every. Single. Detail. It drives me insane and usually makes me quit faster than anything else when I encounter those people.

This. There are 2 types of developers: those who enjoy philosophizing about programming minutiae and then there are those who enjoy shipping products.

Don’t get me wrong. There are times when details should be discussed, but not when it’s coming out of some desire to engage in a power struggle and show everyone else how smart and in control you are.
Post reply on HN