The Burden of Knowledge

Your best software developers are not the ones you turn to for everything. Your best are constantly distributing knowledge, removing themselves from being a key-man dependency. Your best have delegated sufficiently that they have freed themselves up to learn new skills. 

It is a natural instinct for software developers to want to learn more, to consume all of the knowledge in their vicinity. Like a sponge growing heavier the more it soaks up, it feels good to become the owner of more knowledge. This applies to good software developers anyway; you can spot the bad developers a mile off as the ones who have closed their minds off and don't want to learn anything new. I know what I'd do with a sponge which refuses to soak up anything new.

"Find the most talented person in the room, and if it's not you, go stand next to him" Harold Ramis

Developers start their careers fresh-faced (not literally true of the generation of young, hipster-inspired devs of today) and ready to learn. Some think they know a lot and others more wisely know they know little. Again, the ones that think they know it all are the toxic ones to work with. The best new developers know there is plenty of whitespace on their knowledge canvas and look to mentors to help fill those voids. 

In most companies, there are people who know shit. They seem to know a lot and seem to know just about everything. They are experts in their field. The best ones don't call themselves that on their job title of course, but are expert nevertheless.

When you are inexperienced and have questions you cannot yet answer, you look around for those that can help you answer them. You'll find that people gravitate to the Solution Givers, the Experts, the Gurus. It is only natural to be impressed with these people. It is only natural to model yourself on them and want to be in that position yourself in the coming years.

Knowing stuff is addictive. You know stuff; you answer questions; you earn respect. It feels good to be revered and good to be needed. Any of that nagging doubt you have that you don't actually know what you're doing and everyone else does? Well it doesn't go away. It never goes away! But you do become adept at drowning out the internal doubt. Over time you realise that nobody actually knows it all, or anywhere near the amount they give off, but that is another talk for another day.

So you know what you want to be in 3 years; you want to be an expert in something. Maybe you want to be technical expert in Android development. Maybe you want to know every internal system in your company, far beyond the reach of any existing documentation. Let's be honest, everybody has a sneaky desire to be indispensable. Good, little grasshopper, you have noble ambitions.

Your aim, however, should not be indispensability. Being indispensable may sound attractive but it comes with a hefty price attached; a price paid by you and your employer.

So you've become indispensable; congratulations! How do you continue to be indispensable? Well first off, you should stop all attempts to knowledge share with your team. Every little piece of information you give them makes them more powerful and you more weak. Secondly, you should cease all delegation. Empowering your team will only make you more easy to replace. Finally, you should not view your team as collaborators; if these people know what you know they can take your job. Your team is now your enemy.

Does any of that sound enjoyable? Does that sound like the kind of culture you want to be a part of?

If you are the only person in your team who knows how to do something, that isn't an achievement; that is a failure

I spent the start of my career with completely the wrong attitude. I saw the expert and I wanted to be that. I wanted to know things that no one else did and took pride in every piece of unique knowledge I gained. Every new thing a medal to cherish.

Every decision made in a project is knowledge. Every non-conventional configuration, every quirk, hack and nuance. Every here be dragons.

It took a while to realise that knowledge isn't a badge of honour; knowledge is a rock that must forever be carried.

Each new rock weighs you down, slows you down. You want to get on with your development, right? Get on with your real work? Well sorry, but you are the only person that knows about this CI system, so someone needs your time. You are the only person that knows how to configure your build system, so someone needs your time.

Before you know it you're fat, bald, yellow, naked and struggling to make any progress on anything new and cool.

You're so busy doing everything that you don't get time to do anything. You tire, you burnout, you leave. The company just lost its indispensable expert.

Development should be a social experience. Failure to treat it as social results in loneliness, isolation and knowledge gaps. It is easy to change, however. Paired coding, code reviews, knowledge sharing sessions, delegation, documentation, mentoring and plain old talking all help to alleviate key-man dependencies and distribute knowledge across the team.

Let me leave you with some parting words which I believe dearly. Sharing knowledge is the mark of a professional software engineer.

If you have unique knowledge which is crucial to the company, it is your duty, as a professional, to share it