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

141–150 of 191 posts

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

#141

Post by blackflame7000 »

lolc wrote: post #110
blackflame7000 wrote: post #33

Earlier quoted context omitted.

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.

Are we talking about a physical skill or a personal capacity for knowledge? Because while your argument might have merit when applied to something like sports, it doesn't hold much water when talking about accumulated knowledge. Yes, I might forget how to do a math problem the way I could when studying for a test in college, but I'll never forget that knowledge exists and where to find it if I should need to relearn. The metaphorical peak I'm speaking of relates to a person's ability to index knowledge like a search engine for the internet.

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

#142

Post by lawn »

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.

Not just nitpicking either. It's enlarging a minimal problem to make it a major problem that must at all costs be solved.

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

#143

Post by ozim »

gerbilly wrote: post #127
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 manageme…

In big companies maybe, in small company I would say I took over job of guys that were firefighting awesomely.

If they would continue doing that, company would go under. When I joined, big customer was already starting to pull out because there were constant issues, though fixed by brilliance of those guys.

With me on board and those guys gone there is a lot less issues and guess what... My boss has time to drive around country to bring in new customers and we are growing.

When there were issues my boss had to stay around in office to keep track of problems and fight hard to keep customers from leaving.

I don't say that your story is not true, but those guys in your management are lamentable, they don't understand how much more could be done if they would not have those problems in first place...

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

#144

Post by zimablue »

gerbilly wrote: post #114
zimablue wrote: post #73

Earlier quoted context omitted.

I relate to this. I think one of the symptoms is not picking up enough detailed understanding of anything because you keep moving around and don't believe in most external knowledge anyway (eg. don't want to learn [beyond a certain depth] SQL, it's so ugly on some inner level I'd much rather start with datalog and build my own up, don't want to learn economics I don't trust those science cargo-culters). But the other…

> SQL, it's so ugly on some inner level I'd much rather start with datalog and build my own up SQL syntax may be ugly, but for once , it's an example of a widely used technology that is based on a very firm and well thought out theoretical framework. As a developer, it is definitely worth investing time in understanding relational databases and the theory behind them. https://en.wikipedia.org/wiki/Relational_calculus

Thanks, I've read arguments both ways and am trying to study logic/logic programming.

https://airbladesoftware.com/notes/relational-databases-are-...

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

#145

Post by logfromblammo »

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

Devs A and B collude to convince manager M to fund development of the nonexistent tool. They use it to update the code base with confidence. Dev A supports the new code. Dev B supports the tool. Dev B and sales S team up to sell licenses and migration support to other companies that use blb++. M pockets a nice bonus, and gives A and B 2.5% raises. When the corporate well runs dry, S moves on to something else, and B open-sources the tool. A and B get invited to blb++ conferences to earn peer recognition and prestige. They co-author a book, and then pocket a bigger windfall than M's bonus. A and B get hired by another company to support a fork of their tool. Then blb++ loses popularity, B goes into consulting, and A becomes the B' to someone else's A'.

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

#146

Post by magduf »

jcranberry wrote: post #44
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…

Just don't settle for being a 'jack', become an expert, and produce something you think is maintainable for yourself and your colleagues.

The problem with becoming an expert is that you greatly limit your marketability and pigeonhole yourself into a small niche. When that niche loses demand, or you want to move someplace where there's no jobs in that niche, you're screwed. A generalist has a much easier time changing jobs and therefore more job security.

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

#147

Post by SketchySeaBeast »

blackflame7000 wrote: post #141
lolc wrote: post #110

Earlier quoted context omitted.

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.

Are we talking about a physical skill or a personal capacity for knowledge? Because while your argument might have merit when applied to something like sports, it doesn't hold much water when talking about accumulated knowledge. Yes, I might forget how to do a math problem the way I could when studying for a test in college, but I'll never forget that knowledge exists and where to find it if I should need to relearn.…

>Yes, I might forget how to do a math problem the way I could when studying for a test in college, but I'll never forget that knowledge exists and where to find it if I should need to relearn. The metaphorical peak I'm speaking of relates to a person's ability to index knowledge like a search engine for the internet.

The answer to your problem is actually and always "the internet". There, you've peaked.

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

#148

Post by jancsika »

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…

> - Code looks pretty sane. Structure is right. Style seems good.

You're attributing that bullet point to the wrong developer.

Here's a profile of a reviewer:

- Isn't paying sufficient attention to the code being submitted.

Don't get me wrong-- I've ripped away drywall to reveal nastiness before. But what you've described is systemic, and for that the reviewer must share some responsibility.

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

#149

Post by chooseaname »

logfromblammo wrote: post #139
chooseaname wrote: post #4

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

#9 might be a symptom of a structural problem. If developers routinely encounter problems arising from technical debt, and are continually asked to fix those problems, but are somehow never afforded the opportunity to retire the technical debt, that creates an aversion to the maintenance work. "If it ain't broke, don't fix it; if it is broke, just use duct tape." A lot of places have infinite budget for fixing things…

> #9 might be a symptom of a structural problem. If developers routinely encounter problems arising from technical debt, and are continually asked to fix those problems, but are somehow never afforded the opportunity to retire the technical debt, that creates an aversion to the maintenance work.

I've seen a couple fresh grads come in with that attitude and get away with it. I think it is more personality type than anything. What I saw usually happen was they were allowed to work on a new feature as kind of a treat for joining, but after when tasked to start fixing issues from legacy, they flat out refused. Even taking it to the head of engineering and making a stink.

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

#150

Post by [deleted] »

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…

[deleted]
Post reply on HN