Software Developer Archetypes I Dread Working With

Long Slack threads, walls of impenetrable text, maybe even tears - what was originally a simple plea for help, a call for debugging expertise, veers into pent up emotions and after-work exhaustion. Feeling familiar? I've been lucky enough that most of my coworker interactions have been uneventful, but there are ones that stand out and stay with me whether I like it or not. Let's see who some of them are.

The Responsibility Deflector

The best software developers that I've worked with are the ones who are egoless (or as egoless as one can be). It's clear in every interaction with them that their focus is on the problem. It doesn't matter if the issue is in or out of their domain or outside their team - they ask concise, precise questions to define the problem space, they provide data points to help you move forward, and you can feel good working with them knowing that they are on the same "team".

The worst are the opposite of this, where a simple plea for help devolves into finger pointing at others or even the customer before you've even had the chance to put together data points, or to verify assumptions about the problem you are trying to debug. It initially feels like they are too busy or are simply trying to avoid work, besides, there is some truth to the notion that the onus of proof is usually on the bug reporter, but as you ask more questions to their ambiguous responses, and poke at them with additional data points to try to bring them back into the mindset of debugging the actual problem, back-and-forth messages devolve into long chat threads about how "this isn't an issue with us" or "you're using it wrong". But you realize the time they have wasted may well have been spent on time helping you actually debug the issue thus canceling any notion that time was an issue to begin with. Their ego is simply more precious.

The Best Practices Lecturer

You join a meeting to help another developer debug an issue they have with something you built, but you leave the meeting feeling like shit. You didn't expect to hear a lecture on software processes and practices bordering on the philosophical. Who is this person to think that they have all of the historical context of the tradeoffs of your codebase and what you're trying to build? It is easy to pontificate when you don't know what led to all these decisions. In these situations, you just nod your head and grunt in agreement to quickly get out like you would the Linux yes command and move on. It may bruise your ego a little bit acting as the subservient sponge of a developer you purported to be but it's a small price to pay to be able to cut the meeting short and get back to doing some real work.

The Visionary Orator

You join a meeting to learn how to integrate into this new system another team has built. You expect a walkthrough with the developers of the APIs and maybe some code examples. Instead, you are met with words that make your stomach churn: "let's look at the big picture". "Oh no", you gasp, as the mythical "big picture" guy introduces themself - the PM who probably attended Toastmasters in college and has an air of faux Steve Jobs about them. You brace for what inevitably comes next - a grand plan about 'canonical this' and 'canonical that' and how it could solve all of your problems. Sprinkled in between is yogababble that could make Softbank investors weak in their knees. For the final coda, a mandate to migrate your entire system to said 'canonical that'. You're exasperated as much as you're confused - how did a simple ask to understand how to use their APIs result in such complexity and ambiguity? Even the developers on their team, who are in the meeting, seem confused. Later that day, you schedule another meeting with those developers alone and solve the issues in less than half an hour.