How to Make Other Developers Hate to Work with You

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.

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.

why does it "say more about the author"?

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

The whole point of the arrogance / humility axis is the awareness that there is not a destination to be arrived at named "expert". The DK graph goes up and to the right, to infinity and beyond. We must merely try to do our best, and try again.

This take can cause a pretty unproductive worldview. The trouble is, we've all met different people who fall into broad categories like "jack of all trades". A lot of morons will say this sort of thing. Sometimes it's because they think you think they are dumb, so they want to show you that they are good at other stuff so as to keep their ego happy.

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? ;)