This Is What Demotivates the Best Programmer in the Workplaces

When I entered software development, I wasn’t having in-depth knowledge of computer science. My software servicing firm hired me because I managed to find the maximum element in an array in O(n). Plus, I could answer some behavioral questions quite well (part of its stupid MBTI-based psychometric test).

But that was in 1999. It was the time when the world was more concerned about how computers will send mankind back to the stone age (aka Y2K). Unlike today, when companies have taken the best programmers for granted, despite COVID19 and a looming WW-III.

Everyone who could work around even the simplest of the MS Office Macros could be passed as a programmer. In a way, it was best: You got troubleshooters who got some analytical skills to convert real-world problems into software lingo.

What more do you need? (A perfect recipe for Dot-com bust, if you ask. But that’s a story for a different time.)

The problem of plenty (of helping hands):

At that time, when I was stuck with a technical challenge, all my more talented colleagues would rush in, to offer their help. “Tell us where you are stuck.”

When I described this workplace situation at home, the family would be awestruck:

We wish we had that workplace.

But I was a bit perplexed: Was I supposed to feel happy? Firstly, the problems didn’t require external intervention. If I sought someone else’s help in my troubleshooting a programming problem, that person would have to dig as much I did already. That would only add to more time (+boredom of myself and the helping hand).

I would have to live with the fact that I was being helped, at least for the time being.

I was experiencing what was already theorized as Brooks’s law as early as 1975:

Adding manpower to a late software project makes it later.

Receiving a helping hand isn’t impossible in today’s times too. In fact, the industry has become more collaborative, due to the extreme intrusion of company values into IT work culture. If you aren’t collaborative, you aren’t a good fit. Somehow, today’s programmers miss (or lack) the sympathy factor involved in helping someone else. They just point out where the problem lies, shrug, and move away.

But that’s not the point of this post. Whenever I receive technical help without apparent sympathy, I mentally reprimand myself for asking/requiring it in the first place, though I make sure I only seek help as the last resort, so as not to harm the company’s business objectives (deadlines). Being technically competent is my job requirement, stated in the contract I signed. If I required help, I already wasted a few company resources, which would also compromise the promises it made with its customers, on my behalf.

So, the problem isn’t receiving unsympathetic pieces of help. The problem is indifference.

The indifference is ever-present:

Every 2nd IT programmer I meet nowadays (especially a younger generation) has an air of indifference around himself. (Yes, I am yet to see it in female programmers. And to be honest, I haven’t been around many recently.)

Indifferent ones aren’t cocky. I have seen those cocky guys, too. Those having an I know it all swag, or I can manage you better air. They come off as odd-man-outs sooner than later. And the whole team is with me in showing them their true places, before I know.

The lot I am talking about is mostly mute, maintaining an air of a proud scientist. They move as if they have written the Apollo 13 Lunar module all by themselves. They exude nothing but authority. In reality, they have barely coded a function or two. (Best, 1–2 classes in a software filled with 1000+ files).

They know enough technical terms by heart, to be brandished in meetings whenever they see fit. It is mostly to avoid work or thwart somebody’s efforts at betterment.

When you ask them something, they would give you nothing at first.

When you ask it one more time, they will give you a confusing answer. Even when you supply them with all the reference information, and only ask for the missing piece of information:

I looked at A, B, and C, and after that, D is missing. Somehow, E is present. Why?

They act like looking all of that up is a strain you are causing, and they aren’t getting paid for it. If you figure out your way without waiting for their answer, and if it turns out to be better than how they would have done it, they would be the first one to shout from the rooftop.

Again, they wouldn’t be quick to throw away their cloak of indifference. They would shrewdly let the whole team know how you are acting without taking everyone into trust. Or, they will make a stern argument. Something like:

It’s too much to do at this point. Don’t do it.

The only time they fold up the indifference cloak is during the fun Friday company events, where some ice-breaking happens. But it mostly fails to reach the next Monday.

Sometimes, they show their better side when they are in serious need of help. Just like today’s volatile jobs, those collaborations span mostly a sprint (at best, the project), but rarely a career.

Jealousy is the worst form of indifference:

I have seen many haughty, blood-sucking managers. But that’s normal across all industries, not just software. Probably, we are off with better ones.

Also, managerial authority is designed by hierarchy, and you accept it when you join an organization.

But when it comes to colleagues, I would go as far as to state that coders are an extremely jealous bunch.

When you reach up to a point wherein your code improvements can make life better for the whole team (including themselves), the indifferent ones are the first ones to prevent it.

But we have never done it like that.

Sure, if we continue like that, we will be worse.

We are in the middle of a burning release. Can’t you hold off big changes until we are through?

Sure, now you know my idea. Instead of giving me points for the initiative, you would steal it someday without crediting me. And claim it as your own.

If you continue with your initiative anyway, they will sabotage meetings to make you explain the merits, instead of analyzing code that’s visible even to the blind eye. If you submit a PR, they will argue about the architectural diversion, even though no consistent architecture may have existed up to that point.

It’s despisable when your senior role is weightier than the merit of your initiative.

If you are a senior, you may have to a sword in the name of your position, to wield against their indifference. You can have your way in things that you truly think will make the whole project better — not just for you, not just for the indifferent peers, but for your future coworkers and successors, too. That’s the whole point of software development: Making yourself obsolete gracefully.

But as a senior developer, I hate doing it. It means that my senior role is weightier than the merit of my initiative. When I wield my role once, I tend to do it again. And again. Until I stop looking at the merit of my initiative at all.

At that point, I end up converting myself into that same indifferent, jealous peer I once despised.

Conclusion:

Managers suck. Meetings suck. But jealous peers suck worse than all of them combined.

That’s what, sadly, indifference does. It’s perpetual and contagious.

It’s hatred in disguise. I wrote about it earlier too. It causes a lot of stress in genuine, initiative-taking coders. It kills them young.

Managers suck. They define and design processes that often pits devs against each other.

Meeting suck, too. They kill the flow — the very thing that a programmer craves since his teenage years of all-night game-dev.

But jealous peers suck worse than all of them combined. For they know, how everything else sucks already. And they know, why it is that way, in the first place. Yet they play this game among each other.

They gamble and hope their future will be better as an ostrich, who thinks that neglecting or downplaying their hardworking peers’ initiative will make their survival easier, the growth quicker.

The bitter reality is that the ladders they are holding onto are made for temporary climbing. Even if you climb successfully, you have no hands to hold onto.

Your only possession is what you carried with you at the top.

Is it an awesome product? Is it a lot of money?

Or is he/she a colleague whose enthusiasm you shared?

The end of your career will depend on one or more of those choices. Choose them wisely. And choose them today.