Fighting over Crumbs

In software companies, management lets precious little control fall to programmers. They gobble it up themselves. This is a big problem! It turns programmers into assembly-line, knowledge workers—managed by tasks rather than projects or delegated responsibilities.

In this desert of autonomy, one of the saddest things you'll see is programmers fighting over the few crumbs of power that happen to fall from the table.

Of course, if programmers had access to real power, they'd stop fighting immediately. Who has time to wrestle over mere tokens of control when there are actual responsibilities to attend to?

But, conditions being what they are, software engineers ache from a lack of autonomy, a state that drives them to a handful of micro-power-grabbing behaviors:

Land Grabbing

When some question arises, such as which XML library to use, or package manager, or documentation tool, developers race to set up camp first in the new territory. Frantically, they research, make suggestions, write code samples, often on their own time.

This is all in hopes of being put in charge of this tiny decision. A kind of squatter's rights—to become the new documentation tooling czar or XML parsing king. Feel. The. Power.

This frenzied competition is unnecessary. Undecided questions should fall to individual teams; think states' rights. No need to standardize. Programmers will naturally converge on the best solutions while still leaving room for individual circumstances. We're better off sharing these decisions—no czars or kings necessary.

Code Review Camping

For most developers, code reviews are their only chance to flex the muscles of compulsion. Because they can hold a pull request hostage for any reason at all, sadly, many are all too willing to take the opportunity.

Perhaps they view it as their chance to show commitment to a greater cause or show they are ready for a greater responsibility. Or maybe it's simply because, in that shining moment, they're the boss; their vision is most important. Whatever the reason, every detail must be scrutinized. Even adjacent code must be scrubbed, because "we might as well, while we are in there." Suddenly they’re Anna Wintour and you’re the intern, grabbing coffee and picking up clothes from the dry-cleaner.

I honestly think this is the reason so many developers religiously defend the practice of code reviews, no matter how inefficient they are. It's their only chance to feel respected. I understand; but I hate it. I look forward to a time when we can quit this stupid game.

Committee Forming

Power-starved developers often look to form committees to wrestle some control back. Architecture committees are the most common. However, this rarely gives developers any extra power from above. It only consolidates the little power that remains into the hands of an "anointed" few.

The result is added bureaucracy—extra standards, layers of pre-approval, and bottlenecks that slow down decision-making. Committees add more friction than value.

"Mentoring"

I cringe when someone says they're skilled at mentoring. It feels so paternalistic. First, it assumes there are only two groups of programmers: teachers and learners, parents and children, those who know and those who don't. Second, it positions the speaker as one who knows, placing them above the rest.

I'm sure for some this is an innocent statement about a desire to teach, but I'm suspicious that more often than not it's a political maneuver: Hey boss. Send me the juniors. I'll tell 'em what to do. Lemme take that off your plate.

I, for one, have no interest in being mentored. I'll collaborate with anyone, but if someone wants to pat me on the head and tell me how the world really works, they can give their blessed knowledge to someone else.

Overzealous Team Leading

Team Lead is the only non-management role allowed to boss other programmers around; and boy do they! By the time they get to be a lead, many are so thirsty for responsibility they drink it all up. Any minor technical issue (and at their level, most issues are minor) must be pried from their white-knuckled, death grip.

Curly brace position, tabs or spaces, functional vs. OOP, raw SQL vs. ORM, Jenkins vs. CircleCI. Don't even ask; the Team Lead's going to make that decision. They're not letting go. The Team Lead can be more stubborn than anyone else you report to. They've spent years as a peon and they'll be damned if anyone's going to take a slice of their new shred of dignity.

Sometimes you'll catch them hunched under their desk, clenching their fists, chanting their mantra: "mine... mine... mine..."

We Are Better Than This

I’ve fallen prey to these behaviors as much as anyone else; I can’t judge. But, I think we can do better.

Programmers are natural self-organizers (look at the open source movement). We don't need to hoard control. We don't need to tell each other what to do.

I know we’re starving for autonomy, something to call our own. But the ways we've chosen to satiate our hunger will never bring long-term satisfaction. They only distract us from making a real play for control.

We can be better than our circumstances; we can share our (admittedly limited) power evenly across self-managing individuals and teams. We don't need team leads or committees. We can stop the land-grabbing and the mentoring. We can even trust each other enough to forgo excessive code review requirements and pre-authorizations. We can work as peers, allowing each other an equal portion, and stop wasting energy grasping at crumbs.