How to Make Other Developers Hate to Work with You

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

I'm not suggesting you transition into becoming a PM or Architect or anything like that, just saying that developers like you count, too. If you have a decent work ethic, then you and your unique brand of knowledge-seeking have something to bring to the table.

As you advance up the mountain, you will learn to see complexity simply. When you make this realization, your components will simplify dramatically. You must learn to see simply before you can design simply. It just takes time. There's nothing wrong with this, humility doesn't mean giving up your belief that you're capable of anything.

We were all born without any knowledge. We all learned everything we needed to know to get where we are today. We've put men on the moon. We've sent probes to escape our solar system. We've sent submarines to the bottom of the ocean. Humans have the capability to do anything we put our minds to. You can too. Everything you understand today, you've learned in the short lifespan you've had. Today you will learn more, and tomorrow and the next. Just because you find humility in your place, doesn't mean you're not capable of anything.

In fact, I wonder if the narcissism you speak of might have more to do with insecurity, deep down. In my experience, when I see myself taking a behavior that I consciously am against, the cause tends to be emotional and the solution tends to be to gently, curiously observe those situations and start questioning how I feel. When I love and take care of my emotional world, it becomes way easier to interact in a way I feel is more optimal on the fly.

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.

However, generalists are a very useful component of a team. They tend to be able to have a higher level view of all the moving parts, and typically are great for, say, proposing integrations, or high level system design. Also, often specialists will solve a problem in their specialization, fit be damned. They need someone to derail them and say e.g. "this would be much, much easier if we leaned on MySQL to do this".

So, this feels like a baby and bathwater situation to me.

I'm sorry to read so deeply into your anecdote, but there's some interesting stuff to unpack.

> This can be nice in small teams, but usually leads to components nobody (not even the arrogant one) can understand

This describes nearly every company's MVP, so if you're thinking of a person in particular who had to cobble together some dynamic mess, chances are they have great regret for their design. But remember, tech debt is a luxury in these cases - often the alternative is no job or company, as the runway was exhausted, or investors were not impressed.

> A person believes they're the smartest, but not most knowledgeable, in the room.

I think there's no getting around this. In fact, TBH I hope my colleagues feel this way - I want them to advocate for things they think are better, and I don't want them to instead fall prey to their own insecurities.

It's actually kind of a little self-help bullshitty -- the "you can do anything" stuff -- but truly it's actually not awful advice. I guarantee there's someone you work with who has a better way of doing things, but isn't confident enough to endorse it.

Anyhow... thanks for the writing prompt? ;)

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

"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 an a patchwork fashion, yet zero budget for planning ahead for the maintenance phase, or for scheduling preventative maintenance. It's the equivalent of never going to the doctor for a checkup, and only going to the Emergency Department at the nearest hospital when an organ explodes. Nobody wants to be in a long-term relationship with an exploding-organ person, and it's the same for code.

---

#10 is an organizational issue. If a dev has "ownership" of a particular domain, they will naturally work very hard in the short run at setting it up so that they may be as lazy as possible in the long run. But if they are continually kicked off their catbird seat of smoothly-running machinery in order to clean up other people's messes, then there is some incentive to exaggerate the effort it takes to clean up their own mess. Or to make it appear as though they have a mess to clean up.

Even worse, if no one has ownership over anything, there is incentive to always drag heels on the current thankless and tedious task just to delay assignment of the next thankless and tedious task. Do the minimum amount of work to fix the current issue, and let the next guy deal with the fallout, even if the next guy is also you. Because if you bust your ass to fix it right, the next guy won't thank you, because there is no next guy. You can only work on the stuff that is broken, and if there's not enough work to do, people get laid off.

And that is the equivalent of under-staffing the POS cashiers, so that none of them are ever idle. That strategy results in fewer customer transactions, because when cashiers are never idle, that also means that there is always a wait for customers to check out, no matter what size the order, and the cashiers have zero individual incentive to complete an order quickly. Monitoring scan rates only covers the problem, which is that employees are implicitly punished for doing their job too well. Go to Wal-Mart, and all the cashiers are always busy, but also always dragging ass, and all the check-out lines are three customers deep. Go to Publix, and cashiers with empty lanes cheerfully offer to check you out the instant you have found everything you need, and will direct you to the correct aisle if you haven't. Idleness is not just doing nothing, but is also customer responsiveness.

When other devs do this, your best tactic is probably just to follow their lead, and possibly collude with each another against management for your own benefit. The org is broken, and you won't be allowed to fix it.

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)

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.

This can be a sign that code needs to be reorganized. I've seen a number of really good coders in their 20's who are admirable for brilliant insights. However, they fall into this pattern of thinking of themselves as invincible, and they take on tasks where they are doing the "heavy lifting" of remembering tons of details all at once.

If you can lift 400 X's by hand, then you could easily lift 4000 X's with the right tool.

One of my bosses kept a stack, explicitly, and used that to keep track of his excursions into sub and side tasks.

I used to say that being a good programmer was being a professional forgetter as much as a professional memorizer. Basically, you should be constantly reorganizing your code as you go, so that there's no danger that forgetting a detail will result in an error. In a way, it's like people who work on high platforms who take precautions so that one drop or one slip won't result in injury or fatality.

In other words, work smarter, not harder.

i suspect that for many, it's not necessarily their fault Thing is 'too complex' (though perhaps this is tangential); nor are they necessarily provided the opportunity, time or even permission to 'cut down to smaller pieces'. piles of work, looming deadlines and all that.

In the course of figuring out something complicated, it's sort of like a tree traversal. If I take good notes on the leaf nodes I need to fill out, then it's easy to just resume right at the leaf node. If I don't take good notes, I have to retrace the rest of the tree.

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.

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.

Patches and fixes have accumulated in response to strange edge case and bugs you wouldn't believe if told.

The organization and the problem space have shifted somewhat over time. A few things could have been done differently in the new environment.

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.

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.

  MSA: MSA subject analysis

if(!FeatureNotDisabled){ .... }

It drives me absolutely bonkers!

  class TheRpcThing
  {
    object TheRpcThingHost
    object TheRpcThingHostTimer
    class TheRpcThingValidationException
    {
      object TheRpcThingHostValidationException
      object TheRpcThingHostValidationExceptionErrorMessage
      object TheRpcThingHostValidationExceptionErrorMessageFormatter
    }
  }

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

Even future me hates me.

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

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

Dev B gets laid off, and Dev A works until burnt out.

Game over. Everybody lost except management.

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

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.

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

It does if you have engineering goals and the _manner_ in which you are being a negative or critical to other people is preventing the team from achieving those goals.

Negativity does not always come with skepticism, by the way:

Some people are negative in the sense that they demoralise others, yet are full of uncritical enthusiasm to use every random idea and technology they hear about. Which may be what is demoralising others :)

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.

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.

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.

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.

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.

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

does your comment about Dunning-Kruger "say more about you" than the author?