Skip to content

Arrogance and humility

Arrogance and humility are two qualities that are essential to programmers (perhaps, to everyone?). It’s hard to maintain a balance between these two opposite behaviors, so practice is essential.

Humility is important to prevent wasting your own and other people’s time. The simple manifestation of this is in troubleshooting. If something breaks in a system that you just perturbed, it’s your fault. You did it. Maybe you’ll find that the author of Foo clobbered the libraries used by Bar, but you broke it by installing Foo. Maybe Foo was installed by some installation script.  You broke it by allowing the script to be run. Maybe an intern ran the script.  You broke it by letting the intern have root.

This isn’t about blame: it’s about failure analysis. Because so much of computer systems is design (thoughts expressed as code, as config files, as permissions etc. are design in this sense), the most likely source of failure is in our actions, or worse, our assumptions.

This stands in contrast to traditional engineering fields where hardware failure is a more normal source of problems.  Software doesn’t wear out; it doesn’t need to be painted or have parts replaced.  Instead, it rots when unused.

But humility, as I am defining it, is not an ultimate end.  And achieving perfection — or even any worthwhile result — through humility is impossible.  In addition to humility you need the ability to try anyway, believing you can pull it off, even though failure is guaranteed on the first attempt, the second, the twentieth.   And eventualy success when writing new software usually comes through the redefinition of success to mean whatever it was you finally made.

In short you need arrogance.