While the irony of trying to present myself like an expert on humility isn’t lost on me, I feel that humility is an important enough skill for all software engineers and leaders that I’m going to try anyway. I’ll preface this with: humility, like communication, is one of those skills that requires constant attention and balance. For communication, if you talk too much you can be perceived as a rambler, too little and you’re uncooperative or cold. Humility is similar – too much and you lose trust for being too self-deprecating, too little and you come across as rude and arrogant.

So! First things first – how do we get to the perfect balance?

The humility balancing act

Where you currently are on the humility scale will depend a lot on your background, personality, and other factors (shout out to my fellow neurodiverse friends with RSD!). That said, my advice for everyone is generally the same regardless of your current humility level. Acknowledge, internalize, and accept that on the bell curves of intelligence and capability you are probably somewhere in the middle.

A person with a stick pointing near the middle of a bell chart, demonstrating the vast majority of people fall within a range.
You Are Here-ish. (Photo by SimpLine)

If you take a step back and think about this logically, it makes sense, right? While most of us like to believe we’re top-of-the-class awesome, realistically and statistically we probably fall somewhere in the majority. I find this perspective especially useful around performance review time. If I get a low evaluation, that’s okay. Probably like 40% of people were evaluated lower! If I get a great evaluation? Awesome, but it’s likely at least 20% of people got even higher, so don’t get too big a head about it!

The “I’m probably average” mindset also helps me with imposter syndrome. Maybe I’m awful and don’t know what I’m doing, but it’s wildly unlikely I’m the lowest performer in the room. I’m also probably not the smartest person in the room which is great! Lots of people to answer my questions and help me out!

So, how does this mindset help you as a software developer?

Not the worst idea

Approaching software development with a good balance of humility can feel like a cheat code. Embracing my averageness, I offer up basically any idea I have in planning sessions or PR discussions on how to do things. Knowing I’m not the worst means that I can assume other people might have that idea, or that there are other options that are definitely worse than whatever I’m suggesting. Knowing I’m not the best means that if my idea isn’t accepted it’s probably because there’s a better option. After all, if I’m not the absolute best person in the world, my ideas certainly won’t be.

This balance of humility is also great when it comes to PRs or demos. I’m generally unafraid to ask questions because I can pretty safely assume that around half the group present needs them asked. If something seems too complicated to me, I’ll ask for comments or simplification because it’s probably too complicated for other people who need to look at it. I also can accept comments more easily knowing that there are definitely people smarter than me on my team. Sometimes I’ll push back, sometimes I’ll meet them halfway, and sometimes I bang my head against a wall feeling I should have thought of the suggestion sooner. No matter what the feedback is, though, humility helps me appreciate and learn from the discussions.

When coding, the humility balance comes full force. I do my best to write boring, easy-to-read code (preferably with an ADR to give more context and get ideas from others). I avoid cleverness as much as possible and generally don’t waste time looking for the most “elegant” solution. When you perceive yourself as not the most clever, it’s not an ego hit to write code this way. Showing off is pointless when you know that around half the world could do it better. On the other side, I also want to write for the other half of the world – the ones who need more clarity and less complexity. I want to write code that is kind to the person coming next, and that person might be me with a cold or after a bad night’s sleep.

Being humble also makes me more willing to do the coding tasks many find painful or delegate to co-ops or junior engineers. If I’m not the best, there’s nothing I’m “too good” to do. My time isn’t inherently more valuable than anyone else’s, so yeah, I’ll spend a month playing test catch-up or updating documentation. If spending my time that way helps the other developers on my team it’s worth it, since at least half of them are better coders than I am. This attitude really helps with drudge work, since you can always remind yourself that you’re enabling someone better than you!

A woman in front of a laptop with a huge smile and arms raised exuding success.
I'm the best at being mediocre! (Photo by BullRun)

About that leadership thing

Maybe you’re reading this and you aren’t a developer! Maybe you’re a leader-type person, like a manager or CEO or something! Well, boss, humility is a pretty important skill for you to keep in mind too. The fact is, you likely got to your position by being really good at what you do. It’s common for top-level contributors to be the people that get those promotions, so you know you are probably not average, right?

Maybe. Who cares!

The fact is, once you get to the higher rungs of the career ladder it’s likely that your time will be far more dedicated to admin, mentoring, and big-picture thinking than keeping up with all the latest and greatest technical knowledge. While you might have been the best at one point, embracing that you probably aren’t the best now will keep you from dictating approaches (accidentally or on purpose) and help you embrace delegating the vast majority of hands-on work that needs to get done.

As a leader, trusting your team is critical. Assuming that at least half of them are smarter and more capable than you makes that trust a natural thing. Of course, they can do whatever is asked of them. You could, and you aren’t even the best! There’s no reason to doubt them at all!

Really, whether you’re a leader or a developer there’s another big benefit to practising humility.

Accepting and giving feedback

We talk a lot in engineering and leadership circles about the importance of continuous feedback. Without humility on both sides, feedback conversations are an exercise in frustration.

If you think you’re the best, how can you internalize and adjust when you get criticism? How do you approach others with compassion and understanding? How do you give advice or mentor when you think your success is just because you’re naturally better than everyone?

If you think you’re the worst, how do you stay motivated through tough conversations? How do you feel comfortable offering advice to people you think are better than you? How do you give advice or mentor when you think you have the least to offer?

Whether you’re giving or receiving feedback, practising humility during those conversations enables a greater level of honesty and openness. By accepting that you are average, you can take feedback knowing you have room to improve without being crushed by the negative. As an average leader, you can guide others with patience, knowing that you likely don’t have the right answers or perfect advice for each individual. Instead of directing, you can lean into empowering your people to find the answers themselves – an excellent growth opportunity for both you and them!

In my experience, humility breeds compassion for ourselves and the people we interact with daily. By finding the right balance, we can accept both our strengths and our flaws, as well as the strengths and flaws of others. Humility may be a difficult skill to master, the perfect balance always elusive, but it is so worth the effort.

In my humble opinion.

Pam-Marie Guzzo

Hash An icon of a hash sign Code Name
Agent 00109
Location An icon of a map marker Location
Nepean, ON