The quality of having a modest or low view of one’s importance.
Humility is the single character trait above all others, that will ensure you evolve as a programmer (or developer, engineer, title du jour). It is this trait that separates the lifers, the entrenched and the Dunning-Krugers from the evolving, craft honing programmer you should be.
To admit you have a lot to learn, to admit mistakes, to admit you design sub-par systems sometimes, to admit that your way, the "best practice" way, the evangelists way is just one way, and sometimes may well be the wrong way, is not a weakness. It is not the sign of an amateur. It is a measure of professionalism. Humility is a strength, and it is this strength that will drive your evolution as a programmer to greater things.
Review your previous work. You’re (almost) guaranteed to be your harshest critic.
A cathartic exercise for any programmer is to revisit old code. Do it regularly. Doesn’t matter the language or project, just choose some old code and start reading it. Get the flow and follow the execution path. Understand it. Sometimes you find a rare gem of elegant code and think to yourself “that’s a bloody great bit of code I wrote there”, however, these occurrences are the exception to the rule. If you aren’t cringing, scratching or shaking your head, if you aren’t thinking to yourself “I could’ve done so much better” or “I can’t believe I did it that way”, then you can retire now. You’re complete as a programmer.
Revel in your bug reports, complaints and criticisms. You aren’t your code.
You should actively encourage everyone to do their best to break your software. Colleagues, testers, users, peers, everyone. Ask them to do insane and unpredictable things with it, deliberately abuse it, break it. Invite criticism of your works. Today, we live in a society where people don’t like hurting others feelings, and at the same time, some programmers take criticism of their work as a personal attack. Don’t be one of these amateurs. Don’t take it personally. Revel in bug reports and harsh critique and thank the individuals who find flaws in your software as it is these people driving the quality of your work higher and making your software better.
There is no one language, design pattern or methodology to rule them all. This isn’t Lord of the Rings.
The language(s), design pattern and methodologies you are using to solve your problems today are probably not the right tools for your next problem, and if you are not reading up on, or playing around with other languages, design patterns and methodologies, then you are stagnating. Studying different languages, applying different design patterns and following different methodologies along the way will allow you to view things from multiple angles at once and allow you to be critical of others solutions and of past and present solutions in your own repertoire. Your go to language and patterns today are just a confirmation of the blub paradox1. Beware the programmer who already knows the solution to everything. Monoculture is bad.
Humility.
Go ahead, form opinions, debate, design, theorise, hypothesise, test yours, and others ideas with conviction, but always be ready to be wrong and try a different approach. And by all means, break the rules and try something against advice, but whatever you do, don’t become a zealot. Zealotry is the ruination of your evolution as a programmer and will prevent you honing your craft. Don’t be a zealot.
Master craftsmanship is rarely ever reached by even the most seasoned programmer. The title “expert”, should be considered a moving target that, even though we do our best to attain it, always stays just out of our reach. Be a life long student. Invite criticism. Be humble.
“The people who are best at programming are the people who realize how small their brains are. They are humble.” – Edsger W. Dijkstra - ACM Turing Lecture 1972.
Notes
-
Originally coined by Paul Graham in his Beating the Averages essay. ↩