Surviving Software Heroes
There’s an entertainer named Garrison Keillor who talks about the fictional town of Lake Wobegon. At the end of live monologues on this subject, he ‘signs off’ with the following summation.
Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average.
Heroes of Software
Most of our life is spent in search of a place where all of the children are above average — a place where we can all grow up to be heroes. Society idolizes its ready-made heroes: royalty, athletes, celebrities, and even, to some lesser extent, great thinkers, executives, and artists. There are also situational, role-based heroes, such as first responders or even people who perform some bit of heroism in a pinch, such as pulling a potential drowning victim from an icy lake. The key here is specialness. Heroes are special.
For the rest of us ordinary mortals that don’t knock in World Series clinching home runs or play home run hitters in movies, we’re left to manufacture our own specialness narratives. Smartest lady in the room? The guy with the legendary collection of beer steins from each year’s Oktoberfest? Sometimes you have to dig pretty deep to find a venue in which you’re significantly above average. It is to this need that I attribute hardcore conspiracy theorists and people who fret endlessly about organic food, holistic medicine and ‘ancient’ treatments — being in possession of some kind of uncommon knowledge that the ‘sheeple’ lack is a path to specialness, if not heroism, per se.
We have heroes in the software world. They’re the ones with encyclopedic knowledge of the domain and the existing code base. They’re the ones who are known for being reliable when the chips are down — getting in early, staying late, and coming through in the clutch with a put-upon, but satisfied expression. They make project managers swoon and gush during their academy award speeches. They come in late sometimes and leave early other times, when there isn’t delivery pressure, because they’re trusted with the special privileges that fall to A players on teams. But they do it knowing that, at any moment, they might need to swoop in and take over entirely while the rest of the team twiddles their thumbs and gets out of the way.
And you know what? They love it. Because in the narrow scope defined by their cube farm, they are heroes. They are Michael friggin’ Jordan. They’ve found their specialness in life.
And Then, There’s the Rest of Us
Why the dime store psychoanalysis of software heroes? One of the questions that I received for the Ask Erik form (go ahead and submit at the right if you want to hear about a topic) went like this, paraphrased.
I tend to come on board with new teams, espousing software craftsmanship principles. The team members are initially receptive to the message, but the heroes push testing and refactoring off as lower priority items to be revisited at a later time. Someday never comes, and I get a rep for being a purist and not slinging code in volume. I get tired of this, move on, and hope for a better outcome. How can I change the game and gain credibility in these groups?
I know this and I empathize. I empathize because I’ve lived it. More than once. And so, the reason for the psychoanalysis is a variant of “know your adversary.” Heroes in software groups are those who have grown accustomed to the heady feeling of being special. You threaten that.
Heroes are not usually expert beginners. Expert beginners are often inept and universally disdainful of the idea that anyone can teach them anything in their little fiefdom. They view ever admitting a knowledge gap as a sign of weakness. Heroes, on the other hand, are happy enough to learn and grow, particularly because this growth gives them more ammunition for heroics. But, like expert beginners, they have a vested interest in you not being special. Special in this venue is their thing.
So if you just want to come in and practice your craft the way you think is best, what can you do?
Play It Cool
First off, when you come into a group with heroes, I wouldn’t wear your TDD on your sleeve. (I would argue that clean code practices and heroes are almost mutually exclusive, so if there’s a hero-driven culture, you probably don’t need to worry about them being serious about craftsmanship). If you come in talking about how software should be done or even just establishing yourself as being from a different school, you’re getting off on the wrong foot. You’re claiming specialness when you do this, and that’s their thing.
I’m not saying that you shouldn’t continue with your practices, but rather that you should do it quietly, going into detail only if asked. “What’s that?” “Oh, I do TDD, so those are my unit tests. I can show you how it works if you want.” If they ask you to stop, be a martyr. Tell them you’ll write the tests but just keep them on your machine. Tell them you’ll keep writing the tests and deleting them. Make it clear that you won’t budge on practices, but you’re happy to humor them.
Deliver, Even if It Hurts
To back up this stoic resistance, you need to make sure you deliver. If you’re new to the codebase and/or new to the craftsmanship practice, this might mean a lot of extra evenings and weekends. Invest these up front to cement your reputation (with the added bonus of improving your craft). It’s important to demonstrate that someone with a craftsmanship focus can keep up.
Note that you don’t need to kill yourself out-delivering the heroes. That’s not your goal, and it would just put them on the defensive anyway. The idea here isn’t to become chief hero but to prove that you can be productive doing things your way. Management loves heroes because it doesn’t understand that most of their heroics are dedicated to fixing problems caused by their last round of heroics. You’re not going to convince management to take your word over that of their software heroes, but you can convince them that you can tow your own weight, no problem.
Volunteer for Low Visibility Green Field
Once you’ve quietly and unassumingly demonstrated that you can test drive, boy scout, and still keep up, remove what the heroes might perceive as a mounting threat by making the (to them) bizarre offer to work on some internal tool or other inglorious, largely solo assignment. This will take you right off of their threat radar and give you a runway to demonstrate what a clean codebase looks like. (Alternatively, you can work on this in your spare time or on downtime at work so that you don’t need explicit allocation.)
This is a long play, but once it’s been going on for a while, schedule a demo for management and all other comers. Show them how you can fearlessly refactor. Show them how you can implement new features in no time flat. Show them what clean code can do.
If you do this well, you’ll wind up with a mandate to start expanding this new-fangled clean code stuff into higher visibility, higher priority projects. Heroes aren’t stupid and they certainly aren’t lazy. Once the tide shifts and management supports the idea, they will do a whiplash-inducing 180, burning the midnight oil to watch Pluralsight courses and read TDD books. Their goal: be the hero of the domain/codebase and good enough at this new clean-codey thing to retain their status as the go-to person in the group.
Be Pickier When Hopping
I’ll conclude by explaining what ultimately worked best for me. After years of working in places where getting clean code adopted was like wading upstream in a raging river, I stopped working in places like that. I’d make progress that was hard-fought and wearying but satisfying. Then I’d go on vacation for a week and come back to find 400 unit tests commented out. You can win battles over clean code in dink and dunk amateur shops, but it’s tiring and it’s maddening.
I don’t do that anymore — not for project work and not for W2 stuff if that were still my thing. I explain up front that I’m not interested unless a group has a craftsmanship mindset or else is bringing me in specifically to install it. And I have no regrets on that front.
But I learned this the hard way. I thought on more than one occasion that I’d knock it out of the park by going to work in a group that generated legacy code in real time and showing them automated testing. Interviews would be encouraging — “oh, yeah, we totally plan to get a TDD do agile driven development.” But then, when the rubber met the road, there was no time to do anything but copy and paste six more markup files that read directly from a database.
So skip the shops that are ‘interested’ in clean code, agile, TDD, etc. Interview the shops that claim to be doing it and ask questions that will tease out if they’re serious or if they’re just fudging it for marketing purposes. Sure, this narrows the field a bit, but it’s better to have a few high quality prospects than endless disappointing ones.
And, if all else fails, reach out to me if you’re looking for development opportunities where clean code is valued. I can certainly put you in touch with organizations and people that take this stuff seriously. There’s a market out there for it.
Want more content like this?
Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)