[dropcaps round=”no”]P[/dropcaps]art 2 of a 4-part series about the attributes of great software developers/architects.  See Part 1 for the overview.

hu·mil·i·ty

noun \hyü-ˈmi-lə-tē, yü-\

: the quality or state of not thinking you are better than other people : the quality or state of being humble ⁽¹⁾
A great software developer is someone who is not only intelligent, but also has humility.  Intelligence is a relatively understood attribute and requires little description.  Very few people would disagree that a great software developer has above average intelligence. Humility is probably more controversial; many of us have worked with or met the stereotypical self-anointed ‘king of software development.’  While those without humility can be successful, I have met many more successful developers with humility than successful developers without humility.

• A person with humility puts the success of the team/business/project above his/her own success
• A person with humility understands that no matter how much he/she knows, there is much more that he/she does not know, and embraces that knowledge
• A person with humility is not only willing to fail, but recognizes that failure is a part of learning.  He/she can recognize and admit failure early and seek ways to turn it into success. Many times, one can learn more from failure, than from success.
• A person with humility understands that perfection is generally unattainable, nor is there ‘one way’ to do anything.  Certainly, ‘my way’ is not the only way.
• A person with humility can walk the line between educating and doing.  The see successes and failures as teaching points, and understand that something different can be just as good, if not better.
• A person with humility understands that using obscure/cool/shortcut code, or the latest design pattern (that probably doesn’t fit the current need) may show their knowledge/expertise, but many times it does not help the team/project.  Writing clear, maintainable, concise, and performant code is much more important than proving you know more than everybody else.

The fact is that you will almost never come across somebody that does not have a different skill, perspective, set of knowledge, or experiences than you.  To have humility means that you understand that, embrace it, and use it to your advantage.  It means that you can work together with others to produce better and faster results than you could alone.  This is not to say that great software developers are not more skilled than others, but simply to state that very few feats can be accomplished alone.

Those without humility are closed to new ideas, different perspectives, to true collaboration, and to working towards the greater good.  I remember a colleague, very intelligent, but also a little too self-confident.  We assigned him a relatively minor development project piece.  He was managed by someone else, and he went off to do his work, rarely asking questions or collaborating.  In a great tradition of software development, the status kept coming back as ‘almost done.’  What happened is that the developer decided to use the project as a test to try a new design pattern he read about.  Instead of 3-4 weeks, it took about 2-3 months, to make it worse, the code was an absolute beast to maintain and about 3x more complex than it needed to be.  On multiple occasions various team members, myself included, asked if he needed any assistance, he never took us up on it.  Humility would have allowed him to see that the project was not a good fit for the design pattern, ask for help, or collaborate with others on the project to meet the true goal.  Any of which would have almost certainly resulted in better code and a better result.

What to look for?

Look for someone who begrudgingly admits to being very good, not someone who tries hard to let everyone know how good they are.  The old adage of ‘if you have to tell everyone how good you are, you probably are not that good’ holds very true.  Someone with humility is still confident in their skills, but generally does not need external admiration or validation.  They are also confident that they can learn what they need to know to be successful, and is open to accepting teaching/mentoring/help to learn.  They probably have a history of learning from others and have proven they can learn simple or complex concepts from others.  My first major job out of college was working for Microsoft, in their consulting arm.  While not as humble as I should have been, I appreciated that fact that every day I got to work with industry veterans with significant experience building enterprise software.  I learned more in the first year than many learn in 2-5 years, and appreciated it.  While my mentors were all confident, they were also all humble and willing to mentor/teach.  If either party had lacked humility, then neither of us would have benefited, and client projects would have failed.

A great software developer will like to collaborate and see it as an opportunity to both teach and learn.  He/she will educate herself on various software development principles, rules, architectures and design patterns, but still understands that there is no silver bullet, it is up to them to select and apply as appropriate.  If she says something like ‘I always use ____ pattern/architecture,’ or ‘I follow the ____ rules so I know my code is as good as it can be,’ then they lack humility (and probably experience, creativity).  As it exists, software development is still an art form, to say that one rule/pattern/arch can encompass everything and is optimal or will even work in all situations is naïve.  I would posit that for most businesses (i.e. not nuclear reactors, space shuttles, power grids, fighter jets..), a software development rulebook that is comprehensive enough to cover most situations is more detrimental than no rulebook at all.  A short set of guidelines, such as the clean code principles, agile principles, etc are great, and can be helpful even to experienced developers.