The Humble Developer
There are many traits sought after in good developers. Curiosity, intelligence, ownership, hunger, and dedication are a few of the common ones you’ll hear. The one I’ve seen in the really good developers I’ve worked with, though, is humility. The best developers I’ve worked with were also humble developers. They were the ones everyone wanted to work with, they knew when to reach out for help, never considered themselves above helping others, or being helped by others, and in general leveled the team up that they worked with.
Let’s be clear… I’m not advocating humility solely for virtue’s sake. There are tangible results that come from being a humble developer, and I’ll go through some of the top ones in making this point. I’m also going to contrast this behavior with what I’ve seen from proud developers and the impact it will have on the people you work with.
The humble developer…
…Will always be open to learning new things
I worked with a CTO who was a tremendous developer. We were a small company, so he still contributed massively to our codebase. He was (and still is) an amazing architect, developer, and collaborator when working on a code base. The best thing about him, though, was no matter how many awesome features he put together, he was always looking for new ways to do things, and he pushed his entire team to look for those ways as well. He didn’t assume that because he was the top dog developer he knew everything. Instead, because of his experience, he knew how much he still had to learn.
This didn’t just result in him learning new things himself. He would take suggestions from junior developers on our team who encouraged him to look into new tech, and it wasn’t abnormal for him to dive into a discussion about better ways of solving a problem with the newest developers on the team.
Contrast that with some of the developers we’ve all worked with that were sure they knew all the things that were worth knowing. Not only are they a pain to work with, but they’re toxic for an entire team. Learning plummets and you end up recycling the same solution over and over again.
…Knows that bugs are written by people
How do you react to finding a bug in your code? Is your response to ask “why isn’t this thing working?” or is it something closer to “how did I break it?” The first statement carries the mindset that the problem I need to track down isn’t my fault, while the second statement shows an understanding that developers are human and really good at writing bugs! I can’t tell you how many times I’ve worked with younger developers who are overconfident in the code they wrote, and it results in taking a really long time to find the source of a bug because they won’t start by looking at the changes they’ve made.
The humble developers understand that they probably made a mistake somewhere, so they’ll only start looking elsewhere when they’ve exhausted all possibilities in their own code. This includes writing a bunch of tests to give themselves confidence that they’ve covered their own bases.
An example of this just happened to me recently. We were troubleshooting a bug in production, and were tracking some batch jobs through AWS. The console was showing that no jobs were being processed, and one of the developers on the call ventured to suggest there was a bug with it. Another (correctly) pointed out having a much higher confidence level in AWS than in our own configuration, and was correct. I can count on my hands the number of times in 10+ years of development that troubleshooting bugs has led me to framework issues. It happens… but you’re better off assuming the problem is with what you wrote.
…Will ask for help when they need it
Struggling through problems can lead to growth in any career. Development is no exception, and there comes a time when you’ve struggled enough and it’s time to reach out for help. A humble developer will recognize when this time comes and reach out gladly. They will know they have support from their team and will want to focus on progressing the task at hand as opposed to thinking they have to prove they can do it solo. Make no mistake, while autonomy is a highly valued trait, knowing when it’s time to get help is a better one. Knowing when you need to get help is a part of being autonomous, as it will let your leads know that they can leave you alone and trust you to do your job without being silently blocked for days or weeks. If you need help, they trust you’ll reach out for it.
A prideful developer won’t reach out for help, and further, they’ll deny it when offered proactively. This can lead to no progress being made on items and could end up impacting an entire team. They’ll think that every story is an opportunity to prove that they are a capable developer and that this means it must be done without assistance from others. While every task you take is an opportunity to prove yourself, getting the job done is more important than doing it yourself. In fact, rarely is it important to be the sole developer on any project. Most of the time it’s more important to have multiple people involved, so you can spread knowledge, awareness, and have additional support when getting it across the finish line.
…Will welcome the opportunity to collaborate
While this one is similar to reaching out for help and learning new things, there’s a subtle difference that’s important to note. Collaboration is about working together to achieve better things than you would individually. It’s not an opportunity to show off how good you are at something. A humble developer will work with a team member to achieve the best result, a prideful one will want to show how impressive they are.
Some developers prefer working alone and that’s OK. That doesn’t mean they’re a terrible person or that they’re full of themselves. These developers will be at a disadvantage in their career growth if they don’t take opportunities to work with those around them. Collaborating with developers more experienced than you will teach you a ton about how to improve your skills. Collaborating with those younger than you will be a great way to share your knowledge and level another team member up. Either way the benefits can’t be overstated and having the right attitude when collaborating with your teammates goes a long way.
…Knows they can be replaced
Remember that code you wrote and were sure no one else would ever need to understand because you’d be around? You won’t always be around, so write it in a way that everyone will understand or document it well. There will always be someone else who can figure out what you’ve written, replace what you’ve written, re-write what you’ve written, or take the responsibilities you currently hold, and the sooner you realize that the better off you and the people around you will be.
The humble developer doesn’t have any illusions about their skillset. Even if they are one of the best at what they do, they realize that someone else can always be found to do their job, so they don’t act with complacency and always put their best effort forward.
Summary
Be a developer that elevates the people around you. Seek to learn new things, be helpful, assume you do and will continue to make mistakes so that you can make the most out of every opportunity to learn more. I can say, without a doubt, that if you learn to be a humble developer, you’ll be more pleasant to work with and go farther in your career.
