From Zero to Hero, or There and Back Again
You just landed your first software job. You’re excited, this is a great opportunity! You’ll be able to apply that expensive Computer Science degree to something useful and start paying back those students loans. (If you’re self-taught, good on ya). You know a lot of stuff and now you have the chance to use that knowledge to solve some interesting problems.
Your first day of work goes pretty well. You get set up with HR, someone gives you dev accounts to various tooling and you start poking around at the projects on GitHub. “Hey”, you think, “this is going to be easier then I thought”. A few days in, you are assigned a task to do. You check out the project and follow the README to run it locally. You start running into problems.
- You need RVM, but the README doesn’t say what version of Ruby to use.
- There’s a Vagrantfile in the project root, but you can’t tell what it’s used for.
bundle installthrows a bunch of errors. System libraries are needed, but which ones?
- There is a
Makefile, but the Rakefile is loading tasks from somewhere and the Makefile is pretty cryptic (typical).
- Running the project depends on an external API, where is the secret token?
- A Postgres database is required to run the project, how should it be configured?
- Some of the business logic is written as stored procedures. WTF are stored procedures?
- Running the integration tests locally requires a private Docker image, do I need a proxy or something?
You ask your teammates for help, but you feel bad interrupting them because they’re busy on their own tasks. It’s also hard getting answers because usually only one person on the team knows how a particular piece works. You end up on Reddit waiting for someone to get back from a meeting. You’re also starting to feel a bit like a fraud; how does everyone here know this stuff and I don’t? Maybe software development just isn’t for me.
Let’s get this out of the way. You’re not a fraud. You’re suffering from imposter syndrome and it’s common in the tech field. It’s common because our work is constantly under peer review. A pull request is a threat, an opportunity to be “found out”.
You have to conquer impostor syndrome, it will only hurt your career. Here’s the good news: there are a lot of resources to help. There are often open spaces at DevOpsDays events focused on the topic, Forbes and the American Psychological Association have written about it, lots of people have talked about it on their blogs. The resources to help you overcome imposter syndrome are there.
Now onto the more pernicious problem. From earlier:
It’s also hard getting answers because usually only one person on the team knows how a particular piece works.
This is the elephant in the room.
The amount of risk introduced to a team (and ultimately a business) by not actively sharing institutional knowledge is negligent.
Your bus factor should be at least 2. Yep, this problem is so common we have a term for it. Critical institutional knowledge does not belong in the head of a single person. The Phoenix Project features a character named Brent that is the go-to guy for fixing problems because he knows a lot of things that other characters don’t. Brent is a hero.
Here are a few characteristics of a hero in software engineering:
- They hold a large amount of institutional know-how in their head.
- When an outage happens, they are on the front line to fix it.
- They prefer to communicate through their code.
- If they leave the company, the project(s) they’re on will likely stall.
- They don’t take much time off (there’s no one to cover for them).
Management loves heroes for #2 and #5, but they’re often unaware of the downside of having a hero on their team. The net effect is negative for keeping a team happy and maintaining a sustainable pace. As engineers, we need to be able to explain this risk to management.
Heroes may see hoarding information as job security. Making management aware that heroism is hurting the team (and increasing risk) removes this incentive.
This is what a sustainable engineering process looks like:
When we encounter a new technology, we have to learn to use it. At this point we are a zero, a beginner. We do some tutorials, get comfortable and then start working on integration. By the time it’s in a production workflow, we (hopefully) know the relevant details. We are a hero. This is when a lot of engineers move onto their next task.
This is the problem. Now only we know how something works. Instead, we should focus on transitioning back to a zero. We take the time to show a teammate how something we did works and the considerations and assumptions we made along the way.
Here are a few battle-tested ways to facilitate the
hero -> zero transition:
- Do pair-programming. Often half-baked assumptions are ironed out when pairing and you end up with a better result. Learning happens in real-time.
- Treat documentation as a first-class citizen. Not just code comments, but user-facing doc as well. “This is the goal of this sub-system”, “This is how you run the tests”, etc.
- Hold a timeboxed meeting to present a new idea/tool/language/system to a group to teammates. Leave plenty of time for questions.
“That sounds nice”, you say. “But my boss would never go for it. It takes too much time.” You’re right, it does take time. But your boss will go for it, if you can align your request to his/her interests.
- Management wants your team to be efficient. Keep track of how much time teammates are spending waiting on answers or doing rework because they couldn’t get a timely answer from your local hero. Do this for a couple weeks and present the results.
- Management wants to minimize project risk. Highlight the parts of your project that only one person knows about. Explain that if they become unavailable, delays will occur.
Frame your conversation re: heroism to the needs of your audience and you’ll have a better chance of affecting the change you want.
Avoiding heroism is not a call for mediocrity. You can be excellent at your job without being a hero. Share what you know; help your teammates be excellent at their jobs too. They will respond in kind. By transitioning back to zero, you are actually providing more value to those around you and the organization you work for.
Thanks to Jennifer Davis (@sigje) for her talk “From Hero to Zero” at DevOpsDays Boston 2014. It was the inspiration for this post.