How to Make Other Developers Hate to Work with You

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.

That take might be overly cynical. People who have a jack-of-all-trades skill set might not necessarily build the best components themselves, but might be able to bring some big-picture insight that more specialized developers don't have the awareness for, leading the team in the right direction.

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.

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

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.

>> will fall victim to this culture

The issue with this culture is that using optics to achieve an advantage generally works, but is not a good long-term--big-picture strategy.

So reasonably, of course you need to learn all of these quirks, just to be able to get rid of the vermin in your org.