Live data from Hacker News

How to Make Other Developers Hate to Work with You

anaxi.com

101–110 of 191 posts

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

#101
post #49

Holy crap, is >gives cryptic names for variables, or at best not self-explanatory sure a big one. It's part of a category of small decisions that dramatically increase cognitive load when accumulated. Along with it: >Passing many arguments into functions with names that have no relevance to their role inside the function, so you constantly have to look up which argument maps to which function param >Needlessly reorga…

Gah, naming! It feels like a sign of a lack of empathy to not at least give some semi-meaningful name to a variable. "x" is only acceptable if you're literally writing a function to perform algebra.

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

#102
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.

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

#103
post #82
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…

Sounds like insufficient testing to me. This kind of deep/far reaching issue should have been crashing tests written before others would have seen it. Assuming that there is some testing in their work (if not; there's the answer), my guess would be that it's largely sanity testing of each functionality in a vaccuum. The coaching would probably be to demonstrate more integration-style testing, possibly using whatever…

No, it's just lack of true skill.

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

#104
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…

Nobody’s mountain has a peak unless you either stop learning or die.

Everyone's mountain has a peak. We have a finite amount of compute power in our heads, and a finite amount of time on the earth. That means we have a fixed amount of complexity we can work through.

That said, fixing someone's shitty microservice code is probably not bottlenecked by our cognitive capacities. It's probably bottlenecked by financial constraints.

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

#105
post #69

9. Refuse to do any maintenance and only work on new projects. 10. Hide your actual productivity. IE: get done with your coding tasks in half the time, leaving other devs have to fix all the bugs that QA kick back. (This is probably a managerial issue, actually, but perpetuated by devs who do # 9.)

Or, augmenting #9, the team lead who takes all the interesting work and doles out compliance etc to everyone else.

I really don't know how a team lead would find the time with all that turnover. Training is a bitch.

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

#106

It's very weird to describe arrogance as a problem only for people near the bottom in terms of ability. Arrogance is an issue at all skill levels.

This, so much. It's where review comments like "why don't you just do X?" come from, where "X" is a systematic change. Condescension coming from a place of strength doesn't make it okay.

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

#107

>Most developers are enthusiastic people, but sometimes you may have the chance (or misfortune) to work with a negative one. Negativity is infectious Western society has a weird optimism bias. I think it goes hand in hand with extroversion bias, and it keeps many people from being genuine. >those developers are clearly at the top of Mount Stupid Frankly, that's insulting. Being a negative or critical person does not…

Sometimes we need to remember that positive interactions make people happy, and negative ones make people sad. And that's what they'll remember about the interaction afterwards.

For a lot of people, these basics apply even to technical discussions. Criticizing their code makes them feel bad, and so you are a jerk. Meanwhile, you think you are criticizing their design to help them improve it. This is a mistake on the part of the person receiving criticism, but it's very rare to have a manager or mentor who can point this out to them, and help them dissociate their implementations from their self worth.

Couple into this other culture's aversions to even just saying "no", and we have a complex and challenging world to navigate. I'm constantly in search of the team where we don't have to do silly social dances to make sure everyone feels valued, and can just criticize and fix, since the members know they're valued by virtue of being part of the team to begin with.

But that is asking a lot of people - they have to have reflected on these issues. Since this is rare, and the larger a team gets, the more likely you'll have to deal with those who haven't dissociated yet. Makes for a great mentorship opportunity if you can find a way to have them "let you in".

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

#109

Earlier quoted context omitted.

Nobody’s mountain has a peak unless you either stop learning or die.

Yes, but different people are climbing different slopes; everyone can keep climbing, but that doesn't mean they'll reach the same height.

Yes, but those slopes are indeterminate from an outside observer because success comes from within. For every person you think you might have pigeon-holed, I'll show you another that broke the mold. You see everyone starts off facing a metaphorical vertical cliff in anything they attempt. It's over time that you learn the passages and tools that make it easier to climb; that lessen the slope. Unless we're talking about physically dunking a basketball, anyone can be a savant in something with enough effort. But again that future effort is not knowable to a 3rd party, they can only base opinions on past observations. People can change and they can change in an instant.

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

#110
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…

Nobody’s mountain has a peak unless you either stop learning or die.

At the point where all your practicing is just maintaining your performance, you've reached your peak. You can stay there, or you can go higher if you practice more (or better). But there is a finite amount of practicing you can do each day. (Studies argue that 4 hours is plenty.) So there is an absolute limit per individual.
Post reply on HN