The Types Of Programmers I Don’t Want To Work With Again

The Types Of Programmers I Don’t Want To Work With Again

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.

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 who 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 a handful of programmers who go around acting like everyone around them are hillbillies to undermine moral, create animosity and vocal pushback, make people withdraw from the discussion and wait for the inevitable end — I’ve seen it plenty of times.

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.

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 — and then 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.

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.

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 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 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 — and on the other end of the spectrum you have people 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, when the bosses wanted something we would get yelled at for not having done it already. The team splintered apart in months.

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.

Related  Surprising Lessons From Nine Years Of Coding

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

And everyone else gets inevitably dragged down with them, to a lesser or stronger degree.

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.

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 the only kind that routinely makes me consider violence because they don’t help themselves while hurting others.

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, the guy who in a meeting hacked apart my pseudocode until nobody was interested in the idea behind it anymore.

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.

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 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 type of programmers who are at least partly detrimental to the team effort.

When pushed to the extreme these bad people make good people switch teams or move on completely — and they will eventually leave themselves or worse even stay on until their retirements.



No Comments Yet!

You can be first to comment this post!

Post Reply