
How to Make Other Developers Hate to Work with You - turingbook
https://anaxi.com/blog/2019/02/20/how-to-make-other-developers-hate-to-work-with-you/
======
vharuck
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 below
them in every subject. They may seek out colleagues' advice some times, but
likely will never return because they "get it" now."

They'll act like a "jack and master of all trades." This can be nice in small
teams, but usually leads to components nobody (not even the arrogant one) can
understand let alone maintain. So experts need to be brought in, anyway.

These people let the quick ascent of "Mount Ignorance" multiple subjects get
to their head. No such thing as a Renaissance man anymore.

Sadly, I'm that flavor of arrogance.

~~~
ltbarcly3
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 never agree with anyone.

\- let people finish their statement: If you don't let someone finish and you
interrupt, they will decide that you are just refusing to hear them out rather
than disagreeing. It doesn't matter if you can prove mathematically with
extensive sources and footnotes, most of the time they won't be able to accept
that you understood their point and showed it to be flawed.

\- pause long enough after they speak: Again, if you instantly explain why
they are wrong, most of the time other people will not be able to handle this.
They will decide you didn't actually consider what they said. It doesn't
matter what is actually true, and if you somehow do convince them that you are
right they will be doubly resistant since you are making them feel stupid on
top of everything else. A huge benefit of this and the previous bullet is that
you will often find that at first you misinterpreted what the person was
saying, so you were about to disagree for no reason.

\- 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. It may seem silly, but replying 'I don't think that will work because
...' is going to be the source of turmoil, when saying 'Interesting.
Previously we did something similar to that but we had a problem where ...' is
going to win the other person over instantly most of the time. Later they will
see that they were wrong, but you didn't rub their nose in it and force them
to grapple with it in a social setting where they are going to have to feel
shame.

Failure to do these things is just what people mean whenever they say someone
is arrogant.

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

~~~
ltbarcly3
> 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 them aware of the
issues (in writing if possible). If management is aware of the issues and
won't do anything about it, well you did your part and you aren't allowed to
fix the problem. Unless it is a life and death or national security situation,
either accept that the dummy is going to be around or resign.

If they haven't done any work for a year their manager is useless. You work at
a place where managers don't do their job. If you take it upon yourself to set
this person straight, you are basically propping up this useless manager.
Useless managers hire useless people and chase away good people. Fixing this
problem treats the symptom and may let the bad manager last longer than they
would have otherwise, which means you are going to have to go set two
additional people straight about how useless they are next year.

~~~
cmurf
I agree it's a management problem. However, I've encountered the case where a
developer abruptly teleports from "plateau of sustainability" (high
confidence, knowledge and experience) instantly to "Mt. Stupid". And every
time it was a case of users becoming confused with UI and doing something that
caused injury (including data loss). In that case the developer consistently
blamed both the user and user advocate.

I do not think it's bullying to give a bully a taste of their own medicine. It
may not solve the problem, to be sure, but pushing back on bullies is not
wrong. Pointing out their cognitive dissonance, and drawing a line from their
stubbornness to being a bad developer is not wrong either. In particular where
the manager doesn't care because 90% of the time that developer is delivering
the goods, and just doesn't properly assess the ensuing (UI/UX) hostility.

Bad UI will piss off users. It's I completely expect they should express that
frustration directly to the responsible developer. If that developer can't
handle it, both accepting the criticism and making appropriate design
adjustments, get out of the UI/UX development business.

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

~~~
rojobuffalo
#9 for sure. Probably a side effect of being sloppy or writing bad code.

~~~
NedIsakoff
My version of #9 I'm dealing with is: Is this an feature that a customer will
use? Or is it internal improvement? Yes to first, no to latter.

~~~
justwalt
Are you saying that your team hasn’t done enough of the latter, or that they
don’t focus enough on the former?

~~~
NedIsakoff
We haven’t done enough of the latter. I’d love to automate and improve a lot
of stuff but our project manager is pretty much always client visible first.

------
expertentipp
Sorry, but real life situation is infinitely more complicated.

Crybullies, manipulative people, people driven by greed to have power over
others, hazing the new team member for whatever reason. Some are much more
likely and zealous to report colleagues to the supervisors, some less. Some
are more likely to be listened by the supervisors, some less.

In unlucky circumstances, couple of rounds of conversations with managers and
suddenly _you_ are the asshole nobody wants to work with.

------
Dzugaru
> 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 something wrong. Maybe the thing is too
complex and must be cut down to smaller pieces, maybe I didn't keep enough
notes or thinking through - anyhow nowadays I cannot work without a clear
understanding of what simple piece of what complex piece I'm doing and where
I've written down the other pieces I should do next.

~~~
lolc
To me that just sounds like you don't have tasks that require deep thought.
And that you've developed habits to cope with interruptions, such as note-
taking.

To turn a complex thing into a list of simple things can be done by experience
as well as by deep thought. But don't think you could get that experience in
5-minute chunks of thinking. To get the experience you need deep thought.

Maybe set your sights higher if it's all easy to you? Or enjoy the fruits of
experience, of course.

~~~
stcredzero
_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.

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

~~~
stcredzero
_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.)

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

\- Every problem fixed another one seems to pop up.

\- Eventually you dig into the code and problem space in detail and you find
that in a very subtle, even complex way the whole thing is completely wrong,
the problem space misunderstood and everything patched over with little fixes
to get things working for a particular case.

In the end no system created by the person is useable without major
remediation by another developer.

Anyone experienced this?

~~~
mahemm
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 tests caught system-level
issues that the dev has pushed in the past.

~~~
potta_coffee
Could also be organizational. Constantly shifting whims of stakeholders, etc.
Yes, requirements change but changing major requirements without a major
refactor can cause these kinds of problems with the code. Or if the developer
is being given unreasonable deadlines, no time/resources for testing, etc etc.

------
asabjorn
> A team with a bad developer is way better off short one developer than it is
> with a bad element.

How do you know that you just didn't communicate your issues well to the
person? Is there a way to help them, you and your relationship improve so that
you can be a stronger team?

We all have blindspots and weaknesses, and weaknesses that fit together like
puzzle-pieces tend to find each other until you resolve them.

The half-moon is only an illusion, the whole moon is still there. You just
don't see it, and you need the whole.

~~~
stronglikedan
> How do you know that you just didn't communicate your issues well to the
> person?

When you encounter that person, you'll know. Some people just aren't _capable_
of grocking certain things.

I had a guy on my team like this. He just wasn't _getting it_. At first, I
would spend extra time with him, communicating the issue from every possible
angle. He would almost always end up producing something so far off base.
Everyone else on the team was sync'd but he just never _got it_.

The best part is that he refused to believe that he was incompetent. I say
"best", because that gave me an easy way to get him to move on without firing
him. I knew if I wrote him up one time, his pride would kick in, and he would
start looking for another job. The plan worked perfectly.

------
giancarlostoro
I think #1 and #6 go hand in hand, and usually results in #2. If you disregard
your team, and you're arrogant, your code will likely be sloppy as hell. In my
opinion that makes you the worst member of the team.

I spoke with a coworker about this and we agreed that you just need to be
humble as a software developer: we all are going to screw up, we don't all
know all the answers, and we don't know why others in our teams say / know
specific things, but we should not take their advise lightly it might of been
a painful lesson for them to begin with!

~~~
flr03
My girlfriend being a developer also we end up having this kind of
conversation very often and we agreed to say the developers we enjoy the most
to work with are knowledgeable but yet humble persons. In my opinions
personality traits are often disregarded over technical skills during
interviews.

~~~
giancarlostoro
The best places to work for try to balance both.

------
koboll
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 reorganizing data structures or renaming variables so that it
becomes more difficult to reason about the flow of data

Naming things isn't just the hardest problem in programming, it's also the
quickest way to piss off your peers if you're lazy about it.

~~~
vidanay
A former primary developer of my code base had something wired backwards in
his brain. The code is full of double negatives:

if(!FeatureNotDisabled){ .... }

It drives me absolutely bonkers!

~~~
rabidrat
For me this often happens incrementally. Like they started with "if
(FeatureNotDisabled)" and then locally refactored the code until it was "if
(!FeatureNotDisabled)". The problem is that they then didn't go back for
another pass before commit, and reverse the double-negative by changing the
variable name and semantics. This could be due to laziness, ignorance (it
works, what's the problem?), fear (it works now, let's not break it), or time
mismanagement (it took long enough to get it working, no time to make
everything "perfect").

~~~
vidanay
I could understand that evolution, but I have become convinced that this
particular developer simply worked with negative logic in his brain. Even the
configuration files will have:

Feature1Disabled=False

Feature2Disabled=True

Feature3Disabled=False

Instead of using feature flags to enable a feature, he used feature flags to
disable features. He was very consistent and the logic is all correct, simply
inverted.

------
braythwayt
There's not a single thing in there that I don't recognize in myself at one
time or another.

I sometimes feel like I don't see anti-patterns as I go through my career, I
fall over them and sprawl on the floor.

~~~
mont
The important thing is that you can recognize your own problematic behavior,
and actively work on fixing it. Nobody's perfect, but I imagine there's a
reason the author put #1 as #1 ;)

~~~
P_I_Staker
Yup, looking at common problematic behavior without reflecting inward, is an
issue in and if itself. People often behave this way for a reason. You're
liable to for the same reason.

------
ourmandave
As a solo developer who does all these, I have a lot of self-loathing.

~~~
duxup
The worst are the "What the hell was I even doing here?!?!? / What does this
even mean?" moments.

Like at one point I thought this code was obvious and worked great. I remember
feeling that way about it and feeling all accomplished here, but now I don't
feel that way and this code seems impenetrable or at least a big hassle now...

~~~
widforss
Software development is the continual discovery that you were an idiot two
weeks ago.

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

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

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

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

~~~
whttheuuu
This.

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

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

------
stcredzero
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?

~~~
ashelmire
Dev A is a junior developer that doesn't understand the time and opportunity
cost of rewrites. Or that projects and managers don't care about style, they
want new features and stability. Doing things better going forward is great.
Going back to change legacy code for style? Frankly, that's a big waste of
time, and management will not look fondly on your lack of visible or impactful
progress.

I was Dev A a couple of years ago. Don't be Dev A for too long.

~~~
user5994461
It can be done in a way that show massive visible progress and impact. Just
have to fill plenty of tickets for doing plenty of changes. Adding new
features that are already present, sometimes renaming the file that had them
if necessary. Fixing bugs, possibly freshly reintroduced because the existing
fix was purposefully ignored or removed.

Do you know that progress report and commit messages don't even have to match
what was actually done or committed? The project is your playground.

------
arandr0x
In my experience people provide excuses because they're being addressed by
management in a way that is unnecessarily negative and/or management is
wanting to find "guilty people" and not work out which is the best person for
the job of fixing things.

That the article is clearly refusing to even mention this casts a big shadow
over the rest of its conclusions. Some of the other things are the result of
personality (like taking credit or sloppiness) but making excuses is 100%
context and a defensive coping strategy literally every time I have seen or
done it.

~~~
P_I_Staker
Yup, "no excuses" is a stupid attitude. Say I wanted you alone to get me to
Mars tomorrow. It's absurd to say "no excuses" when you fail. It's possible
that you're making understandable demands, or they just don't know how to do
it faster.

------
fromthestart
>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 make
one stupid, on the contrary, I would argue that the skepticism that comes with
negativity is an asset for engineering. This advice is carte blanche to
dismiss criticism.

~~~
say-vagnes
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".

~~~
jlokier
True enough, but it's not just about making anyone happy.

Even thick-skinned people have a hard time with another type of negativity:

"Negativity" doesn't only mean high quality criticism, or pessimism.

It also refers to low quality, demanding, draining, and often competitive and
repetitive discussions where critics are full of it.

Sometimes there is also bullying, always talking over, making out that
coworkers are stupid, taking credit for others work, not pulling their own
weight, trying to trick people, manipulating people to their disadvantage,
insinuations, word-twisting and game-playing, that sort of thing.

That sort of negativity is draining. It's negative in an energy and morale
sense.

That's not about hurting anyone's feelings, and it's not even about sadness
and happiness.

It's just that some ongoing interactions drain everyone's energy without
giving much back in exchange.

Everyone does it occasionally. Some people do it a lot - those can destroy a
team and a company.

------
kakarot
I thought I would make an addendum:

> We all know at least one developer who ... will always insist on following
> “best practices” without understanding why those practices are considered
> “best” (there is no such thing as best practices that adapt to every team)

For any developers out there recently starting on your path, I cannot stress
the importance of taking the time to seek out best practices for new skills
and technologies you pick up.

Find all the "best practices" you can, then ignore some of them for a while
with some pilot code, then try to follow a combination of the ones that make
most sense to you. Compare the two modules for legibility, clarity,
maintainability and conciseness.

If, however, your team already has an entrenched way of doing things, don't be
that jerk who comes to the party blasting their own music. Follow the existing
style guides to a T and only offer advice for improvement after you've spent
some time working with them.

Even if you immediately recognize a glaring problem in the way things are
done, no one is going to take you seriously and you'll just come across as
arrogant unless you already have rapport as a perceptive and helpful team
member.

Take time to understand the culture around you, but don't, as this author
suggests, ignore the tried and true devices of other cultures.

~~~
jlokier
I agree.

I'd like to add, in my experience some developers firmly (and sometimes
loudly, judgementally) join a working environment and espouse best practices
they've acquired from a cultural background they've worked in so far. Or read
about, or watched a training course about. And they don't know (or care if)
they are pushing things which are advertised as "best practice" in some domain
or other, but aren't half as universally agreed upon as they think, and aren't
half as effective or appropriate as they think in the new job.

My point is: Some "best practices" aren't as universally agreed upon as people
think, and people are often thinking in a bubble.

If you're at a new job, and you see a glaring lack of what you've learned is
"essential" best practice, I'd urge caution in assuming your new team are
ignorant or that your managers are as clueless as you think at first, even if
it looks messy and disorganised.

Of course they might be clueless! But it takes time and deep questioning to be
sure.

Of course your experience should be brought into each new place you work.
You're hired to bring in what you know, not just to fill a seat. By all means
talk about your experience, about things you have actually done which worked
well, and about what industry leaders are currently talking about.

But if you feel the need to "teach" everyone straight away how to work better,
give it time and consider the possibility that people might have given it
considerable thought and experience of their own. They might even be familiar
with much of what you're talking about, and rejected it or found a different
approach. (Or they might not - that's to be discovered.)

I say this because I've seen people turn up and, in effect, try to start
fights long before they have spent the time to figure out (a) others in the
team are quite experienced and familiar with the same practices but have
decided on something else, (b) different industry bubbles actually do have
different best practices for similar problems, and (c) they can't see some
kinds of development strategy that are in use, because subtlety.

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

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

------
rojobuffalo
I was just imagining the opposites of these and remembering some of my
favorite people I ever worked with. I've only ever worked with 2 developers
who I didn't like, and they fit this list almost perfectly.

Be humble, be kind.

------
harlanji
Individuals often have little control over these things, and they are
indicative of deeper cultural incentives. Without transgressing some, nothing
will get done in many orgs. I see it a lot in big money VC backed startups,
much less so in bootstrapped businesses. It’s important to be non-judgmental
of people doing these things and simply leave or master Machiavellian moves to
clear a path to promotion as other players are, eg. via optics or rallying
support to oust “toxic” rivals for the good of the team.

~~~
okaramian
I agree. The system in place is to blame, and those people rose because they
are just playing the game that is dealt to them.

I'm not so good at the Machievellian political aspect, so I personally opt to
leave when I notice behaviors like this are rewarded in the current system. I
also wonder if I was able to rise in an organization that functions like this,
if I would b the type of person to actually root out that toxicity in the
first place.

~~~
NedIsakoff
You won't be able to because the people higher are doing the same thing.
Unless of course you make it to the top.

------
neokantian
_As mentioned above, either the code works or it doesn’t … but it needs to
work in combination with all the code being added to the codebase by your
teammates._

That is Linus' job (or one of his trusted lieutenants). Kernel contributors
generally do not interact with each other directly. There are simply too many
kernel contributors to hold all kinds of "team meetings". The problems that
the article mentions, exist mostly in a corporate environment. Virtual,
distributed teams generally do not have these problems.

 _Software engineering is probably the most collaborative work in today’s
world._

Yes, but successful software, such as the linux kernel, is not developed in
the way he believes it is. What corporate IT typically does, is certainly not
a reference.

 _A manager who doesn’t understand this is a manager who doesn’t understand
software engineering._

A manager who does not read, evaluate, and merge pull requests, is not a
manager; and does indeed not understand software engineering. The article
complains about the side effects of one particular, rather outdated approach
to software engineering. You will, for example, not hear the PostgreSQL or the
Debian team complain about that kind of issues.

~~~
drugme
_What corporate IT typically does, is certainly not a reference._

The article was in no way specific to "corporate IT".

But, literally by definition -- we're talking about the huge mass of
applications that run most of the planet, here -- overall, "corporate IT" is
way more representative than the handful of elite open source projects you're
referring to.

------
CodeSheikh
From my experience at various companies, "technical managers" fit well into
most of these categories. Because actively coding and managing a team of
multiple developers can bring most of these issues out of you. Example:
"getting away with your architectural decisions because you are presenting
your ideas with a managerial authority and ignoring better solutions presented
by other senior developers."

------
say-vagnes
Good article. However, I'd like to talk about documentation and comments, as
they were mentioned a lot.

I think the industry should rely on them less. The trouble is, nobody updates
every comment, and documentation is even more out of date. They cannot be
automatically verified either.

Getting worked up about it is just going to give you stress. Further, it is
terribly subjective. Instead, advocate for the other good practices - variable
names, clear separation of concerns, single responsibility, functional purity,
etc.

I have this inkling, actually, that the more comments there are in a function,
the worse it is. Even high level overview comments, like some outlining an
algorithm, could instead be high-level code, composing the various pieces
together.

It is very rare that a concept is actually nuanced in code. Instead, it is
usually the implementation - and you can improve it.

That said, it's a ton of work, and we have to ship a product at the end of the
day.

So here we are again, discussing tradeoffs in tech, and I think in these cases
a comment block is an OK compromise. Just be cognizant that it _IS_ a
compromise.

------
meuk
Common misconception, but that graph does _not_ explain the Dunning-Kruger
effect. It's actually more like a linear curve, it's just a little flatter
than the graph of y = x.

The Dunning-Kruger effect is that the best people underestimate their relative
abilities, and the worst overestimate. So, the worst 10% may estimate they are
about average, while the top 10% might estimate they are in the top 20%. These
are more realistic figures than the graph used in this article.

~~~
ltbarcly3
People try to shoehorn Dunning-Kruger into situations where it doesn't make
much sense.

Dunning-Kruger boils down to something a lot like "people tend to think other
people are like themselves". So if you are low-skill at some task, you tend to
think other people are low-skill, and as a result you see yourself as roughly
average. If you are high-skill at some task you tend to think that other
people are also high skill, so you over-estimate the average skill level.

This article is an example of shoehorning it in when it makes little sense,
and I argue that they are claiming that Dunning-Kruger says the opposite of
what it actually does. Yes, people can be arrogant and incompetent, but they
can also be arrogant and highly competent. Dunning-Kruger would imply that
someone who is highly competent would not be likely to be arrogant, since they
would overestimate other people relative to themselves, and as a result they
would give more credence to the ideas of others than is warranted given their
relative skill levels. A total incompetent would indeed overestimate their own
ability, but they would still see themselves as roughly average, which you
wouldn't think is likely to be the trigger for an arrogant attitude.

All people will from time to time feel like the ideas of another person are
silly or not worth listening to, but of course it is considered extremely rude
to express those feelings. I think arrogance is just the expression of those
feelings, which makes it a symptom of poor socialization.

~~~
zzzcpan
> So if you are low-skill at some task, you tend to think other people are
> low-skill

Dunning-Kruger effect is not a way of thinking or reasoning about yourself or
others, but a cognitive bias. You need to be put into a quick decision making
mode where you have to compare your skill to others for it to skew your
assessment.

------
mnm1
Love the article except for the part that encourages developers to rat on
other developers. No. Unless another developer is so bad they are putting your
job in jeopardy, let them be. It's the manager's job to sort that out and do
something about it.

Throwing other developers under the bus when ones own job security is not
threatened should be the number one thing on this list of asshole things a
developer can do by far. By very, very, very far.

------
john-radio
This writer stole "Mount Stupid" from Zach Weinersmith (Saturday Morning
Breakfast Cereal) without crediting him! [http://www.smbc-
comics.com/?id=2475](http://www.smbc-comics.com/?id=2475)

------
crdrost
Example of the arrogance mentioned in the first point: I have met folks who
have seriously argued to me that their code contained no technical debt
because "We wrote it right the first time." The code at the time was something
in the range of 50,000 lines (so assuming 30 lines of code per page, 500 pages
per textbook, you'd have to read ~3 textbooks on the subject of what their
code does to understand it) and contained no test suite... and maybe 5% of the
code was comments.

Sloppiness seems to come with enough examples... but I must say that it's not
really a direct problem _unless_ you are in a supervisory role and
_nevertheless_ insist on modifying the codebase, as that makes it
significantly harder to correct you on your sloppiness.

Disrespect of others' time is being directly connected to meetings here -- I
sympathize but I do think that the bigger issue is that "deep work" is best
done in ~2-hour uninterrupted batches, and so a company culture which
encourages actively scheduling those on shared calendars so that we can have
"open spaces" for meetings during other parts of the day, would help a lot.
Especially, I am growing more confident that meetings which exist should
revolve around some decision to be made that needs input from a bunch of
people -- in other words, every meeting is a negotiation and if it's just a
"progress update" or a "question and answer" session it should be moved to an
asynchronous medium like Slack or (to a lesser extent) email. If you insist on
daily standups at least have the courtesy to schedule them in the afternoon so
that when I come in off of my morning commute having thought, "I am going to
do X, then Y, then Z" I am not burdened by "I have only 1 hour to work on X
before I have to drop everything for the daily standup..."

I am probably more guilty of the constant negativity, I think a piece of
wisdom from Seth Freeman is helpful here: that one wants to separate problems
from people and be hard on problems, soft on people. You can be constantly be
negative towards a problem and this will be tolerable if you are consistently
cheerful towards the people who might have other needs with which they pursue
those ends. "I am really worried that without a proper auth strategy we may
get hacked, I know that you all strongly value being able to go forward
without wasting time on such a frustratingly difficult problem, I fully
understand that, but there has got to be some way that we can get a proper
auth strategy which doesn't bog us down so that we're also not trivially
hackable" is a very negative position but it somehow doesn't carry the same
"drag" as "you're so stupid, trying to implement this insecure thing, you're
going to be the reason we get hacked."

Greediness is a hard thing, definitely, but I would observe that all of the
examples seem to have to do with private communication channels, and I wonder
whether that's endemic to the situation. I also wonder how it subdivides with
a manager taking credit for the successes of their team -- in some cases this
respect is due and in some cases you feel like "we spent more time evading my
boss than being led by them!"...

I think the weakest part of the article was "disregard for the team," I feel
like that's just a catchall for "doing anything that was annoying to me
personally" and it's like "well yeah but that's not helpful." I think any
friction can be couched as "disregarding the team" whereas true disregard has
something to do with "you went off and made your own decisions and never told
any of the rest of us about it and we could have told you that they were not
wise decisions because of needs that you would not have been expected to
anticipate" \-- but the sin there is really just falling out of step with the
community and thinking "I can sail this ship entirely on my own!" and I think
it's less disregard-for than lack-of-community-with. Like it's great to have
ownership of some problem, but keep in constant conversation as well.

Lack-of-focus is I guess an irritant but I've never worked with someone where
it was so bad as to "hate to work with you"... I think some of that is a lack
of leadership-focus, if you have an aggressive timeline to deliver an
aggressively minimal product then there is very little room to dither? But
that may just be that I have not worked on a hard enough problem where one
needs to upfront a serious enough amount of investment to force such
dithering.

I was also frustrated to see "lack of accountability" defined as "more focused
on making excuses than solving problems" because to my mind those are two
separate issues, the "I am never to blame because I will point the finger at
someone else!" is toxic, but it doesn't become less toxic if someone is like
"yeah I mean I was just doing my best with the API results that Phil was
giving me, Phil really screwed us over with this one, let's solve the problem
by creating an API v2 that doesn't have his shitty endpoint in it, instead the
endpoint will work like this, and then I can write code that's actually
correct." That revolves around a solution while still having the attendant
point-the-finger-and-blame attitude and I don't think that the solution-focus
really removes the awfulness of the negativity.

Kind of my take aways are:

1\. Keep learning and growing, shun practices which set you up as someone who
knows everything and has nowhere to grow.

2\. Keep honest with yourself about what's really going on, you can massage
the description to others but you should be clear on 'we are not meeting this
deadline because our contractor is two weeks late delivering this component
and we cannot start building this next part without it' \-- use that clarity
to try to creatively evade those restrictions in the future, 'can we agree on
a black-box specification so that you are not blocking my peer developers from
working? Like, here's an example JSON file or two that your API will return in
response to this query?" \-- Do not lie to yourself in cases of "I am screwing
this up" or "I am overburdened" or whatever, as those lies breed bigger lies
later, that developer who is like "It will be done this week!" for weeks on
end.

3\. Keep compassion in your heart for everyone else. I am trying to separate
that empathy as much as possible from these other criteria and just dump it in
one. Do not be aggressive or negative or so with others, they are not the
problem, they are not to be recipients of blame... they are fellow human
beings who need to also grow and be respected just like you do. Don't say
anything which you would not want someone to hear if you said it to their
face, for example.

4\. This was not really discussed explicitly in this article, but don't settle
for mediocrity. Go out on a limb, take a risk, try to do things that might
fail. I think one of the things that can really make me hate to work with you
is that you would rather copy-paste some convoluted solution that worked once
to a problem with considerable limitations, rather than that you're really
trying new things, refactoring, simplifying. One thing I perversely love to
see in source code is a brute-force approach. Just an "I don't know what the
right way is to solve this but there are only 8! different ways this can
happen so I'm just going to iterate through the 40,320 of them and see which
one is best, we can improve this with some heuristics later." But it has to be
an interesting problem of "which of these things is going to be most effective
for our users?" for me to have that respect. You stuck your neck out and did
something that other people would have just shrugged and said "that sounds
impossible, let's move on" and I love that spirit.

5\. And finally there is some sort of pride/humility thing going on, don't
think that you are the center of the universe and that every other developer
exists to make you effective, but rather give up your ego in service of the
art that you are creating. If you understand this code as a vehicle for
yourself to be validated then I will probably not like working with you, if
you understand this code as a joint effort of love and service, I will
probably call you my brother or sister.

------
jd75
People love to work with me, but managers love all of those flaws.

~~~
tome
Did you mean "People hate"?

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

------
blindwatchmaker
Re: documenting code, I've gotten a lot of conflicting advice over the years,
with some people insisting code should be documenting, and others insisting on
docstrings.

~~~
timw4mail
Best to have a balance, I think:

For loosely typed dynamic languages, docblocks on interfaces (function/method
definitions, interfaces, etc) are a good idea.

For languages that require types in their interfaces, it is helpful for larger
units(classes, functions, methods) to have a summary comment.

Inline comments are still very useful for explaining how and why of
implementation details.

While I reject the stance that you should never have comments, I also see
cases where better names and simpler logic can alleviate the need for more
comments.

------
cde-v
This sounds more like how to make anyone hate to work with you.

------
qrbLPHiKpiux
I'm in healthcare and this translates wonderfully into my field. Especially
with being one staff short than have all, and one be negative.

------
deckar01
[https://web.archive.org/web/20190222151703/https://anaxi.com...](https://web.archive.org/web/20190222151703/https://anaxi.com/blog/2019/02/20/how-
to-make-other-developers-hate-to-work-with-you/)

Edit: The domain is unreachable for me, I assumed it was for others also. It
is still unreachable for me for some reason.

------
darkstar999
Ironically this domain is blocked at work for being a "spam url".

------
sonnyblarney
'Arrogance' is more often than not mostly a matter of perception. Truly
arrogant people can seem nice - so we generally don't want to ascribe negative
qualities like 'arrogant' to them.

'Real arrogance', and even greed, backstabbing - those can also done by people
who seem to be well liked.

'Perceptive arrogance' I think is mostly a matter of posture, demeanour and
communication. If you smile, let other people talk, have an easygoing manner,
and are agreeable, you will not be perceived as 'arrogant' even though you may
have all of the qualities of a truly arrogant person.

I don't think 'perceived arrogance' has anything to do with actually humility
or gauge of one's own abilities, or of one's sense of self importance in the
group.

If you're terse, blunt, dour or gregarious ... it can be perceived as
arrogant.

'Real arrogance' i.e. the notion that one's thoughts and ideals matter more
than others etc. I think is not even correlated with posture and communication
style.

The most successful people in the corporate world are pure political players,
and have never cared about outcomes, doing a good job - anything. All they
care about is perception and their careers. But they are actually nice enough,
generally charismatic.

Actually caring caring about a product can simply cause contention, and
possibly give the perception of arrogance.

I prefer to consider arrogance in terms of measured behaviours, outcomes etc..
Glib political climbers to me are arrogant. Anyone actually trying to 'do a
good job' and stepping on toes is just a bad communicator.

------
stephsmithio
A lot of good nuggets in here. Dunning-Kruger and Mt. Stupid is one, but I
especially like this quote "meetings are just scheduled interruptions".

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

~~~
throwaway29492
Also the "Negativity is infectious." feel-good bullshit.

"If someone complains, it focuses the attention on the negative side of
things."

(...after a whole article complaining about behavior s/he does not like,
ironically)

If you want to see big disasters look in organizations where warnings are
ignored as "negativity" and people blame the messengers.

~~~
P_I_Staker
Also, sometimes relentless negativity has some fringe benefits (moderate
perfectionism). There's pros and cons. Just don't share that attitude with
your coworkers. Hold yourself to a high standard, but be more relaxed with
others.

