How to be an Indispensable Programmer
Avoid indispensable programmers. It’s bad having them in your team. That’s what we’ve learned and that’s the way we think.
It’s fairly obvious. Having no indispensable programmer means everyone is easily replaceable. In case of illness, holiday or even job-quitting no harm is done. Replace the programmer with another one and everything is fine.
The relevance of a programmer becomes critical when he’s the only one who understands certain pieces of code or when there’s no one else who knows how to use some important tool. This isn’t the kind of indispensability I mentioned in the title. These issues are easily avoided by methods like code reviews and pair programming.
There’s a significant difference between a programmer you can’t lose and a programmer you don’t want to lose.
Those You Can’t Lose
This is the kind of team member I already wrote about. You rely on them because they own unshared knowledge. Lose them and you lose the project.
Identify these weak points and eliminate them by sharing their knowledge between multiple programmers.
Those You Don’t Want to Lose
There are several reasons why you don’t want to lose a certain team member. One might be that you’re friends. More generally speaking: you enjoy working together.
You want to have these in your team. A group of remarkable people who enjoy working together. Each one becomes indispensable by the value he contributes to the project.
How to Become Indispensable
- Be a problem solver
You have in-depth knowledge of commonly used tools and your colleagues know when they come to ask you they’ll get answers. This is possible because you don’t just use these tools but you spend additional time on improving your knowledge constantly. You never stop learning and you love to find out those little tricks and details. - Be a motivator
When your fellows look in your face they see a smile. Even the stress of a near milestone can’t force out that expression of confidence. When you talk to your team you emphasize on progress and opportunities rather than worries. - Be creative
Since software development is a creative job this should be obvious. To find bugs, to improve designs and to refactor you need to be creative. Know yourself and how to facilitate your creativity. Share your thoughts and let others be part of creative processes. - Be open minded
When others tell you about their ideas and possible solutions, don’t always be critical. Think of how their thoughts might affect your project positively first. Emphasize on the best parts and mention your worries about small details later. That way, you automatically encourage them to speak up again. - Be a friend
Work is most enjoyable when you respect each other. When you wake in the morning then you should smile simply by thinking of the nice guys you’ll meet at work today. In a team where everybody just minds their own business there’s hardly any fun involved.
And most important of all: love your job. If you don’t, then the only way to become indispensable is by becoming an employee your team can’t lose. Make a commitment and let the job become a valuable part of your life.
What makes you indispensable?
Comments
Hi Eric, nice and pleasant article… while reading your post i thought myself the author must be a someone who has considerable numbers of professional IT experience.. surprised to see your profile (..student!!)
All of the above 5 mentioned things make me indispensable, and I might add being able to cut through debates and get things done when the debates turn into debates about debating. Being the guy who makes sure there’s beer at the end of friday afternoon is usually a great way to boost morale as well.
Hi Michael. Cutting debates is definitely an invaluable skill. Especially when it comes to debates about debates. And I can imagine the faces of your stressed colleagues brighten up when you enter the room with some bottles of beer at the end of a hard day :)
This is… the single most on-point blog entry I’ve read in a while. The person you describe is who I always wanted to be for the past 10 years.
And now for the scoop: it works. It definitely does.
Thank you!
“Since software development is a creative job this should be obvious.”
Your assumption is wrong. Most managers and most people in general think software development is a not a creative task. Instead they think that a specification directly drives the program to write.
So “being creative” is considered bad behavior by many (bad?) managers because they don’t know how to manage creative guys.
Hi Olivier,
interesting point. I think there’s the need for both software developers and their superiors to see their jobs as creative tasks. I’m much more productive when I’m creative and enjoy what I do.
Another point comes to my mind reading your comment. You’re speaking of “manage creative guys”. I think “creative guys” must be lead, not managed. There’s some subtle but significant difference between managing and leading. Managing limits creativity, leading leverages it.
I go a step further and bring the beers in AT THE BEGINNING OF THE DAY. The boss loves it, even if he doesn’t feel like saying so. I know what he means.
That really helps with number “2: When your fellows look in your face they see a smile”. After a couple of beers, you can’t get that smile OFF MY FACE.
You forgot one way that will make other employees and future employees alike like you: Comment your code! Commenting helps other people working on the project, yourself and future people who may work on it after you. A detailed commenter is a good employee to have.
Other than that, great entry!
I think you don’t need to comment a lot of things if you write good self-documenting code. Sure there are very complex parts where good naming and many small functions don’t cut it. But I agree: Commenting or writing good self-documenting code is an important attribute.
The need for comments is mainly dependent on the used programming language. Developing in Java and not writing comments is unthinkable. Whereas in Ruby there’s much less need to document at method level.
But you’re both right: When there’s the need to comment then it’s important to write sophisticated code documentation.
Great article, short and precise. I think every good employee is indispensible in one sense or another. If he is replaceable without any effort, I would assume that he produces much less value to the company than the indispensible one – not that kind of people I would like to hire.
That’s why I’m a little bit surprised: I was never taught to avoid having indispensible employees. Of course, the ones I can’t loose are really indispensible – but it’s my fault in the first place. So it has nothing to do with hiring, but with the workflow.
I really liked “Open minded”, it’s a catch phrase like many others, but your advice is simple and to the point.
The paragraph explaining open mindedness is significant to me. It’s so easy to point out the not-so-thought-out aspects of an idea. But doing so doesn’t help anyone.
It’s very easy to spot the weak points because you don’t have to think so much about what the other one says. Tracing the good parts of an idea requires much more effort. But it’s worth it.
In a team where everybody just minds their own business there’s hardly any fun involved.
+1 for this!