I used to romanticize the idea of the “lone wolf developer”.
Maybe it was watching Matthew Broderick, the loner high school teenager, holed up in his man cave bedroom, festooned with hacker computer equipment, use his hacker skills to penetrate the NORAD computer system, and inadvertently almost destroy the world, but end up saving it, in the movie “Wargames”.
Drunk with the power of the computer at my fingertips, while chugging down massive quantities of soda and cheap junk food, I fantasized I was that same hacker kid Matthew Broderick was, making the computer do my bidding, holed up in my own man cave.
Now that I’m all grown up, I know that computer programming is very different than my childhood imaginations.
Yet surprisingly, the idea of the lone wolf developer, the programmer who shuns social contact with others and hunkers down in their little cubicle dwelling till the wee hours of the morning, still has a grain of truth to it.
I’ve come across more than my fair share of former (and current) coworker software developers who exhibited lone wolf developer tendencies.
Ironically, lone wolf developers often are able to burrow themselves deep within their organization. Organizations adore lone developers because of their willingness to completely own an application’s codebase. Rain or shine, lone developers will own a problem or bug … maybe it’s partly a sense of pride in their “baby”.
Organizations might see this behavior as admirable. After all, who wouldn’t appreciate a software developer who puts 200% time and effort into working on a project? Or fixing an urgent production issue?
Having personally engaged with lone wolf developer types, I can honestly say there’s a catch to that sort of single mindedness type dedication to the work.
Yes, lone wolf developers often pour lots of time and effort into the projects and applications that they “own”.
However, the lone wolf developer type often is possessive of their own work.
Unless a company has a one man shop doing software development, most organizations employ multiple software developers who must work together on the same projects.
This is where the trouble and personality conflicts can start.
Lone wolf developers, by their very nature, typically don’t like working with others. By the very definition, a lone wolf developer PREFERS to work alone, and not with others.
A successful software development team depends on teamwork, sharing of ideas, and a cooperative sense of teamwork. Every developer on a team has their own unique strengths and weaknesses. The benefit of working with a diverse team is taking advantage of other team members’s unique knowledge and experience that you may not have.
There’s also an old saying that two heads are better than one. When a developer encounters a tricky and particular tough technical issue or bug, they don’t have to act under the assumption they are the only ones who can fix the problem.
You can bounce ideas and ask questions of other team members and there’s a good chance at least one other person may be familiar with the same problem you’re dealing with and offer a potential solution.
Lone wolf developers typically don’t share that same attitude. I’ve personally dealt with developers like that. They tend to hoard their knowledge. Even get upset when you try to ask them questions about their codebase, or something in general about their projects.
I’m no psychologist, but I’d wager it’s part ego, part hidden fear of criticism from others, and probably a whole bunch of other reasons.
Yet I believe this kind of attitude about programming can lead down some very negative consequences.
I personally like to make sure I’m part of a team where there are lots of other developers with more experience and expertise than myself.
It’s the only way I’m ever going to learn new and more innovative ways about software architecture and development.
I ALWAYS assume there is someone smarter and more knowledgeable about a particular topic than myself. And I feel completely comfortable with that.
The lone wolf developer likes to think of themselves as the smartest person in the room. That they’ve learned everything that is possible to know about a topic, and it would be a waste of time to try to learn from others.
That usually translates into software code that lacks the benefit of having other developers offering their own insight and input into its design.
I witnessed firsthand the consequences of a software application that was 100% completely owned by a single software programmer who refused to share their code with others.
It was a nightmare of tangled spaghetti code that broke practically every good software design philosophy in the book, especially one of the GOLDEN RULES of development, which is DRY (short for Don’t Repeat Yourself).
Duplicated code that was repeated multiple times in the application. Violating the DRY principle is one of the worst offenders of bad software design. When you have duplicated code, it literally becomes a nightmare to change, because instead of only changing code in one place, you have to worry about hunting down all the duplicated places it could exist in the application.
You never are sure what kind of negative consequences that could happen when you need to make changes in your application.
The sad consequence from this is you are forced to change as little as possible, to avoid these kind of problems.
Which only makes the problem worse, because now you are encouraging the accumulation of technical debt.
The code continues to get worse and worse, because nobody is brave enough to refactor it into any possible and more manageable state.
It soon becomes this toxic mountain of code that becomes unmanageable.
I learned firsthand what can happen when you don’t expose software code to other developers.
Additionally, you risk the danger of what I like to refer to as the “hit by a bus syndrome”.
When the lone wolf developer, for whatever reason, no longer works at the organization or company, you end up in a scramble to find other developers to take their place.
And it’s usually not a pretty sight to behold.
Because the lone wolf developer never bothered to document what they did or shared their code with others, it’s basically throwing the poor sod of a developer who has to take it over, into the deep end of the pool and praying they’re able to make any sort of rhyme or reason to the gob of source code they inherited.
If I can time it just right, maybe there’s a chance I could schedule my next vacation the next time I hear the next lone wolf developer decides to move on to greener pastures. 🙂