I’ve been a developer for over a decade now. Those years were filled with valuable experiences that were essential in making me a better developer today than I was. There was one experience in particular that was key in improving my thinking about software development.
I once took a job a small company as the only back end developer other than the CTO. Like many small companies, I also doubled up as a sysadmin… only I had very minimal sysadmin experience.
At some point in my first few months there, the primary MySQL server went down. The CTO was in a business meeting which meant that I was the only person available to fix it.
There was no one else.
We were a consumer product so we were losing money every minute the server was down and I knew it.
Ignoring the hilarity of me searching for “MySQL server went down” on Google to fix the issue, this was one of the pivotal times for me in my career. No one was going to come and save the day. I had to do it and I had the authority to do whatever I needed to do. It didn’t matter that I had never experienced an issue like that before and didn’t have all the knowledge of a real sysadmin. At that point in time, I was the most capable person that was available.
I tell this story because before this moment, I always had an out. There was always someone else I could rely on to help me with a hard problem. I just had to wait long enough for them to be available. Or I could just stare at a problem until something else came up and I had an excuse to avoid it. This was the first time where that wasn’t possible. It was the first time that I had no choice but to work through a problem that tested the limits of what I could do. This was a test of self reliance.
I’ve met many developers who depend on having an out. They are still great developers and I enjoyed working with them. But when tested by something outside their comfort zone, they wait for someone else to take over.
While software development is a team effort, this particular attitude reduces the entire team’s efficiencies. Take a situation where a team of 5 developers have 3 really high priority tasks and 10 lower priority tasks. It sounds like all 3 of the high priority tasks can be worked on right? But what if only 2 of the developers on the team are actually comfortable doing them?
1 high priority task remains idle because 3 of the 5 developers have chosen to work on less important work. There are many ways to justify it. Yet, none of those reasons would change the fact that the team is not working in a way that produces the most value.
Unfortunately, it is prohibitively expensive for companies to provide every developer with the experience I was provided. I’ve thought about possible ways to solve this, such as making less experienced developers 100% responsible for low priority services. The idea being the service can go down without the whole company getting hurt, but the incentive to do well for those developers is still quite high.
I haven’t actually tried this however. Would love to hear any thoughts you may have!
This post was originally published on blog.professorbeekums.com
Top comments (2)
One thing to consider is that often times there is no one who has enough knowledge on an issue. It ends up being the deep end of the pool for everyone. Proper engineering practices require experience to put into place properly. Without experience with a given situation or type of task, it is hard if not impossible to put the right practices into place.
I can definitely see how a small co would have these situations more frequently. As a junior dev I was thrown into the deep end of the pool (at a larger co) when our senior dev left. It was really scary, but it taught me some valuable things. 1) I knew a lot more than I thought I did. 2) I can handle it & even like being pushed.
I think the way to solve this is to have a collaborative team where everyone works on various things. Share the knowledge. This opens up the dialog between the senior devs and junior devs in non-critical moments. Stealing David's terminology here: The social status game is just that. A game.