if(this.humbleDeveloper === Agile)

What is it "to be humble"?

Dictionary.com defines humble as: “not proud or arrogant; modest” and “courteously respectful”. Being humble is a mindset that people can adopt to create trust in relationships that will show others a willingness to listen and learn.

In any field, in this case, context engineering, being humble is not really a quality but rather an art form that is developed from talent and practice. We can think of humility as a form of currency to gain trust with multiple parties. To summarize Patrick Lencioni’s teachings, one exposes their own weaknesses to show others that they have nothing to fear, allowing honest conversation.

But why is humility important in engineering or when working with a team?

We could probably talk about this endlessly, but at the end of the day it boils down to being able to make others feel comfortable around you without creating defensiveness or anger.

The Three Humble Anti-Patterns

I would like to identify three examples that I have experienced that demonstrate what a lack of humility can cost:

My code is better than yours

This is the one I have unfortunately primarily suffered from and is the most ironic and iconic of them all. So what happens when your code is always better than other people’s code? In my experience, a developer that thinks this way tends to write unnecessarily complex and poorly commented code. The mindset is “I am the Man because I have just made this amazing Linq statement that spans out 20 lines.” Or, “look at my elaborate design (that uses a huge amount of poorly implemented design patterns).” Aside from the code, this attitude leads to a very toxic environment where others might feel inferior and may prevent them from showing or even writing code for your review. This fear can lead to important missed opportunities. For example, another developer has just solved a complex problem in a very unconventional way. Despite their solution working, they are afraid to approach you because you have consistently demonstrated that your way is always the right way. By not being humble, you may miss out on the fact that the solution is exactly what you were looking for and needed. This fear does not only affect people who are perceived to have little self-esteem or do poor work. This also happens when someone with less experience solves a problem that a more experienced developer could not solve. Whether or not you are “the Man,” or the “CodeFather,” in my case, you need to demonstrate humility and consider how many opportunities you might have missed from not listening to others. More importantly, how many quality deliveries and time savings you might have missed from not helping others with your “awesome skills".

Instance.getStaleDeveloper().next(); throw new NullPointerException

I can fortunately say I have not personally suffered from this one, although I have seen it. This most certainly ties in with the latter, and personally I do think that this is a side effect of prolonged pondering on why “my code always is better than yours”. This often leads to garbled code with cryptic variable declarations that mean nothing to anyone but the person who wrote it. If a company has one or more of these types of people mentoring other developers, trainees will pick up the mentor’s own “unique” way of coding that will be difficult to debug and hard to change. Great developpers and code leaders are humble enough to treat you as a peer. They try to write the simplest code possible and take every opportunity to learn with you. I have worked with developers like these. These were all excellent working experiences that I have cherished and still remember. I learned so much from working with them and I have seen others with similar experiences releasing quality software despite the hardest challenges and the steepest of deadlines. If you as a developer fall into this category, don’t think how you can teach a beginner. Think about how a beginner can teach you and how much you want to be remembered by that beginner.

Lazy initialization, exit code 1

1. This is a bit shorter to summarize, although in essence this is the that situation when you compare yourself based upon challenges that where either very easy or that you didn’t solve completely on your own, although you do claim to have. Even though the description of humble does not say it, being humble is also appreciating others and whether you have written that code that fixed that bug or not. If someone helps you, show appreciation for that person. This will build trust with that person, and they will be more forthcoming in the future because they will know how much you have appreciated the input they have given. Some people see this as a form of submission or weakness because they could have solved the problem on their own if they had more time. This is not weakness, this is a strength and a form of respect that you show others as you work with them.

2. The opposite side of the spectrum can cause problems too. This is when you solve problems on your own even if it has been days trying to solve them without asking for help in fear that others might think less of you. Asking help and collaborating on a a problem can be fun and shouldn’t be thought of as a weakness. In fact, if you ever heard of the principle of “fail fast” this is very similar. The faster you fail, the sooner you will solve the problem, the faster you make other aware you failed, the faster others can help you solving the problem. Easy problems are not fun to solve with others, hard problems are what bond people.

3. Finally, solving problems that feel too easy even if you are solving many of them in a rapid manner should not give you the right to feel special. When a problem is either too easy or too hard to solve, you need to double down. What I mean by doubling down is not to find a harder challenge so you can brag, but to find a challenge that is unsolved period so you can then learn from it and expand your horizons. This is another lesson that I learned the hard way. My thinking is that stale developers are like stale iterators, nobody likes them because they never move forward. If you only know Cobalt, C# or your own architectural designs, sooner or later the only special place you will have is on a shelf in a museum. If you truly believe you are full stack, you are on learning duty 24/7.

As a consultant, how is this important when approaching a new fresh contract with a company you have no knowledge of? Envision a new company as the ferocious lion, approaching and about to eat you for dinner, and you developer standing there with fear of getting eaten. This is just an analogy for saying you are entering a new environment involving people of different skills and levels of experience that you know nothing about, and are going to start working with while being assimilated into their team rapidly in order to get production going. But what do you think the lion will do if you fight? It will eat you for dinner and then will move on to the next prey the day after with no regrets. The latter is the most important part, “with no regrets,” which means they will forget about you and won’t really care whether you will come back or not. In most cases they will not want you to come back and they will take their business elsewhere, which for you means less work and you’ll be the one not having dinner 😉. Winner, winner chicken dinner only happens when you have a profound impact on people, especially those who have just spent big money on you want you back at all costs. Not because you just write great code, but when you convey your skills through passion, team collaboration and foster great relationships that bring everyone forward, most importantly together. The only way to achieve this is to open yourself to others, trust them so they can trust you, learn from them as much as they can learn from you, and honestly, just have fun!

How to return careerGrowth++?

In a nutshell:

Write simple code! It is not a weakness, it’s a strength. Simple, well defined code means writing self-documented code that everyone can learn from. When you are looking over your code, you should NOT think “is this readable?” as one of the self-checks, you should think “is this learnable?” If nobody can learn your code or how it works, congratulations, you have wasted a bunch of time.

You must be as humble writing your own code as you are also writing for others. This means that you should not make fun of other’s code, no matter how bad you perceive it to be. This is a lesson that is usually learned the hard way but held dearly and expressed through your passion of writing better code while teaching or showing others how to write better code.

Adapt to others while you are new. This is a big part of the previous point. At the beginning work harder not smarter, then once everyone has adapted to you do the opposite, remember you are the outsider, you must understand why the locals do what they do.

Code is currency as much as your humble state of mind is. Even if you are great at writing code, you have to remember that you are working with others and you are part of a team. Even if you are solo in some situations you are always part of a team, if you are great at what you do, that’s an excellent opportunity to use your skills to help others or solve problems that make other people’s lives easier. It’s not an opportunity to ridicule them, that’s just a big waste of your time and skills. This will break trust and alienate people in your group.

No matter what you do or whatever situation you are in, no matter who you are, you have to always remember that you attract more bees with honey than vinegar!

I would seriously like to thank everyone at Centare to have helped me understand most of this, through their repeated patience, guidance and bug hunting spirit and foster great relationships, meaningful bonds and amazing development throughout every environment we encounter ;).