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

181–190 of 191 posts

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

#181

Post by blackflame7000 »

SketchySeaBeast wrote: post #147
blackflame7000 wrote: post #141

Earlier quoted context omitted.

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.

Well at least it was after high school

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

#182

Post by skj »

hinkley wrote: post #95
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…

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

It's mostly about letting them finish the sentence, rather than the plan.

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

#183

Post by jancsika »

scandox wrote: post #155
jancsika wrote: post #148

Earlier quoted context omitted.

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

Look I'm happy to take my part of the blame but some of what was wrong was so damn subtle. Ultimately one does trust people to make design decisions at some level of code that one does not second guess...

But you wrote that none of the systems this developer implemented were even usable without intervention. What's the point of reviewing code if you don't eventually read some of it in enough detail to clamp down?

Or at least revisiting the design of your tests.

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

#184

Post by throwaway6734 »

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.

Your claim was:

> 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

Your response to my post:

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

To me, you're contradicting your own position. It also seems to me that you're the one that doesn't "properly understand that other people are full thinking beings equal to yourself" based on the arrogance and condescension of your response.

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

#185

Post by stcredzero »

Insanity wrote: post #157
stcredzero wrote: post #120

Earlier quoted context omitted.

To me that just sounds like you don't have tasks that require deep thought. If everything you do requires deep thought, this is possibly a sign of bad code design.

Not _everything_ but a large part of what I do does involve rather deep thought. But indeed, what helps me is to pick one of the things that is easy to 'refocus'.

Not _everything_ but a large part of what I do does involve rather deep thought.

Anyone's ability to think deeply and pull out feats of clever is a limited resource. A well designed project tries to optimize this. Think of it as martial arts. It's good to be strong. The techniques are there to use your strength more efficiently.

I was once in an Aikido class with someone who lifted. He had to constantly remind himself to use the technique and not just strength. (As Ramsey Dewey likes to point out, technique plus strength is pretty darn awesome.)

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

#186

Post by stcredzero »

user5994461 wrote: post #178
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:…

>>> the new coding style is better, more efficient, and would even prevent mistakes going forwards. Except that's wrong. The new style is not "better" at all. Replacing CamelCase with underscore_variables and forcing brackets on new lines make no practical differences. All the time to rewrite hundreds of files was just churn.

Except that's wrong. The new style is not "better" at all.

RAII is tons better than older memory management styles in C++.

The newer styles of C++ initialization are tons better than the older ones, which seem to inevitably result in a dozen ad-hoc mini-initialization frameworks.

Replacing CamelCase with underscore_variables

That is indeed arbitrary and useless.

forcing brackets on new lines

Forcing brackets on new lines is useless. Mandating the use of brackets has been shown to be very useful for reducing bugs.

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

#187

Post by avinium »

jboles wrote: post #170
koboll wrote: 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…

Another one is giving insanely long names but only changing one little part, instead of taking advantage of the heirarchical nature of programming languages and coming up with a nice nested structure. Example: class TheRpcThing { object TheRpcThingHost object TheRpcThingHostTimer class TheRpcThingValidationException { object TheRpcThingHostValidationException object TheRpcThingHostValidationExceptionErrorMessage obje…

I actually use the number of capital letters in camel-cased variable/method names as a signal that the code might need refactoring.

Generally, every capital letter indicates another hierarchical relationship from left-to-right. Usually these are implementation details that shouldn't be publicly exposed, or at least could be separated out/encapsulated better in a different object/function structure.

Obviously it's a rule-of-thumb and there are exceptions, but I've found this works pretty well.

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

#188

Post by dang »

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.

Please don't cross into personal attack like this. Comments here need to be civil and substantive.

https://news.ycombinator.com/newsguidelines.html

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

#189

Post by [deleted] »

jd75 wrote: post #132
tome wrote: post #39

Earlier quoted context omitted.

Did you mean "People hate"?

No, I mean I don't get promoted for trying to hear what other people say, while managers can't say enough nice things about the hipster-ass who breaks everything he touches trying to turn it into GraphQL no matter what. But I didn't write that very clearly the first time.

[deleted]

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

#190

Post by mgkimsal »

pnutjam wrote: post #55
mgkimsal wrote: post #52

Earlier quoted context omitted.

> Just don't settle for being a 'jack', become an expert Expert in what? There will always be people "more expert" than me in any particular domain (specific tech, hobbies, whatever). At some point, there's diminishing returns in becoming 'expert' in things you don't need to be an expert in, when "competence" is enough.

In many offices, mere competency makes you the default expert.

Sure. Was just pushing back on the "don't settle for jack-of-all-trades - become the expert". Well... that's a never-ending goal. Perhaps I want to be an expert jack-of-all-trades?

I can't be the expert in all things, or even most things I want to be. There's simply not enough time - people with 10 years of experience on me will always be 10 years ahead - and usually that means there's more 'expert' than me on XYZ (not always, time != expertise exactly, but it's often an signal).

Post reply on HN