The Types of Programmers I Don’t Want to Work with Again – (But probably will have no choice but to endure at certain points)

The Types of Programmers I Don’t Want to Work with Again – (But probably will have no choice but to endure at certain points)

Programmers are mythical creatures, ancient beasts and often enough the villains of their own stories.

Over the years I have worked with quite a few of them and here are some archetypes that repeat themselves and don’t get any less annoying with time.

I realize that things are rarely black and white, and that people are not always at the height of their game, I sure as heck ain’t. That being said, there is a predisposition to handle certain things in certain ways, and some of them are detrimental to other people.

The two-steps-ahead

It took me two months into my apprenticeship before realizing that the world of programming exists of two separate streams: What I jokingly call real-world programming where people make the best of what they have and the innovation-driven who see fancy tech on the horizon and try to get permission to throw away the whole architecture to rebuild it from the ground up.

Of course both of these extremes are flawed, the balance point in the middle constantly shifts — but man do those people at the far end of innovation throw bricks into everyone’s window. 

It takes just one, or worse yet, a handful of programmers who go around acting like everyone around them are hillbillies to undermine moral. They create animosity and vocal pushback, make people withdraw from the discussion and wait for the inevitable end — I’ve seen it enough to no longer care for it.

We had a coworker once who said “y’all code like feral animals” at least once a day and said it less and less jokingly until he eventually quit, and popular sentiment was that it was for the best.

Since I started out completely fresh I know how the other end of that spectrum feels, constantly trying to catch up with a world so far removed from the reality that we struggle to keep working — it’s overwhelming. And then, as soon as you start seeing some light, you get a fancy new tech slapped on top, half-implemented and then treated as if you are stupid for not already having built it yourself.

That is not the right way to drive innovation, just in case it isn’t obvious. If you keep facing upcoming traffic, you might just be driving in the wrong lane.

The lazy busybody

These types have a lot of big words to make up for their small output. We all bullshit our way through meetings sometimes, we all have the occasional downtime to kill and need to “run some database queries” during those rare times when the mountain of work is suddenly a hill and everything hits roadblocks and waits for feedback. I have had full days of downtime in the middle of incredibly stressful projects, that may just be the weirdest feeling I have ever experienced at work.

But this type of programmer has one task in life: To spend as much time on as little work as possible without getting fired. When they see that working they often get arrogant and gleeful and start manipulating on top of that, but even the base form of the lazy busybody quickly starts clawing away on team morale as everyone else asks themselves why they work hard when they clearly don’t have to.

The know-nothing team lead

The best bosses in my experience are former programmers who accept that the moment they stop coding the world of actual code starts to move on without them. That gives you someone who has technical knowledge but doesn’t think they know everything and comes to you to ask about the real world or brings you along in meetings to offer detailed information where needed. 

This can be a dream-team of productivity, and since I worked under people like that I know they exist.

Then you have the former programmer who thinks they know everything — which can work for a while. I would take a micro-managing tech lead over the next category of people on the other end of the spectrum who have no clue at all.

I once worked under a team lead who jumped from a marketing job to leading a team of developers and sure enough that turned into the exact mess that you’d think it would. When upper management asked for something we would get yelled at for not telling what we had no way of knowing, and when the bosses wanted something we would get yelled at for not having done it already. 

Our team lead was constantly stressed out, the team was stressed out, and I was glad to sit a good bit away across the room because we had too few desks. The team splintered apart in months as people switched teams or left the company altogether, and I faded out of that team myself thanks to the ever-changing team structures at our company that paved the road for me to leave without drama.

The mentally retired cynic

Oh hey, the ever-looming fate all of us face the moment we stop coming to work with fire in our eyes. I sure have flirted with that addicting darkness at times, but there are plenty of programmers and tech folks in general who have just given up.

They become black voids, a tornado of hatred, disgust, disillusionment. They only still work this job because they know all others will be just as shitty, they look at the good and see just the bad.

And everyone else gets inevitably dragged down with them, to a lesser or stronger degree. I went through a phase like that, found my way out into a new wave of motivation, but then the whole company took a turn for the worse and more and more people around me started drifting into it, to the point where you would great the coworkers you liked with „oh hey, you’re still here?“. So in the end, I left and now live a happier life elsewhere, remembering the war time stories that I’m unlikely to forget.

Related  Selenium Is Not A Sedative

The unpragmatic perfectionist

Everyone knows this type and sometimes they are just what is needed. A software architect who isn’t a perfectionist will implement framework choices that hurt everyone for years to come.

But there are programmers who will write a single function in the time others write the rest of the program — and then often enough act as if their contribution saved the whole thing from collapsing.

They will sit on pull requests for days, then send you a completely rewritten suggestion that looks fancier and you have no choice but to accept them — and then you can finally clean up the mess that was left behind by leaving the bug unfixed for a week.

I once left a meeting where I started out proposing a change that would have made our whole life easier, but then I made the mistake of illustrating my idea with some pseudo-code. My favorite coworker got so agitated about the way I wrote this pseudo-code because it didn’t fit his idea of how temporary code was supposed to be formatted. The whole conversation got derailed from actually solving the problem into me trying to defend my „coding style“ and trying to lure the conversation back on track. Eventually I got up and left and we never really spoke again after that point.

I ended up implementing this change through a backdoor pullrequest on an unrelated change later that week, and it worked flawlessly for the remainder of my days there, and probably still does. But we never got to the point where I could explain my idea, because my pseudo-brackets were pseudo-superfluous and could be simplified to inline-ifs using the colon-questionmark notation. Thank you, Mister ReSharper, very helpful.

The elitist

The other types explained in this post are annoying, but they can also be good folks with part of their mind. The elitist is probably the worst, because they do not help themselves while throwing bricks into other people’s w/Windows. They are the late-stage capitalists of the programming world, and there is no redemption arch planned for their character. They exist solely for the viewer to forget how shallow the other characters are written because this guy is too annoying in comparison.

Vocal Mac/Windows elitists, those who insist that one text editor is superior and refuse to help you until you install it on your machine, and those who come into a project and rewrite half the working code because they feel their chosen ORM is a better choice in all cases.

People like that, man, I get angry each time I look at a smug face that feels pride over insignificant choices they made and try to force on others. Lower yourself on their level („so what does Mac / Windows do that mine can’t?“) and you’ll get something like „man, just, just no, I have no idea how you can even work with that“, with no actual explanation given for their vocal, yet unfounded belief that anyone who actually uses either tech to its potential could disprove.

Again, very helpful, we are light years ahead from the point where we started. I guess I’ll work with someone else, then, to solve the problems you won’t touch.

The secretive

Ask a question and you shall receive — silence. Ask for help and they will tell you where to look for assorted documentation and do it yourself, they can’t do everything for you.

These type of people have to be forced to give up everything, I had times when I had to bring my boss with me just to have a relaxed chat about fixing that burning problem that cost us thousands per week. I talked into a void until I started bringing my boss, and tediously looping him into the cc of every email I was writing. The moment I stopped doing that, they stopped answering questions again, because they were so busy.

At one point, I started downloading and investigating the repository for their system, because it was miles faster for me to ask their code than to ask its developers. Code don’t lie, and it talks to anyone who’s willing to listen.

I am a strong believer in the line of thought that transparency is one of the best parts about programming work, not the worst. I have fixed plenty of problems precisely because I could access other people’s repositories and look at the source of the error that was referenced in the error message that popped up on my end — all without needing to even go to them until I knew where the problem originated.

When someone tries to put you as lazy you can always point at your GIT history and shove their faces into where it says that you worked ten hours yesterday and committed dozens of changes. Transparency is a mighty sword to wield — and a shield at the same time.

Takeaway: Being hired as a programmer puts a lot of power and choices in your hands, use it wisely

I hope this was an interesting overview of some (arche)types of programmers who are at least partly detrimental to the team effort. I realize that we can all have aspects of this either knowingly or accidentally in our own approach to life, love and code, but since I have actually worked with each of these folks in their distilled, pure form I know how much of a human roadblock some people can be.

When pushed to the extreme these bad habits make good people switch teams or move on completely — and the detrimental developers will eventually leave themself, or worse even stay on until their retirement.



No Comments Yet!

You can be first to comment this post!

Post Reply