Summary
"Humility:
be generous in what you receive;
be meticulous in what you provide." --John D. Mitchell
Advertisement
Let me posit that the principle of humility is the root of all greatness. To be
clear, I make no claim as to the orginality of this
notion. Heck, I happily admit that my definition is a more or less direct
generalization of Jon Postel's famous quote (talking about network
protocols):
"In general, an implementation must be
conservative in its sending behavior,
and liberal in its receiving behavior." --Jon Postel, RFC 791
What I will claim is that my generalization is a correct, precise, and,
most importantly, useful definition of humility. Why?
Because, as helpful as the myriad general purpose dictionaries are, they
don't tend to provide definitions in a form that are useful as guiding
principles.
I contend that without useful guiding principles, we cannot efficiently and
effectively reduce to practice whichever weird and wonderful notions that
may compel us each to action.
Why do I think that this principle of humility is key to great software?
Regardless of however else software can be perceived, software is all about
relationships. Humility is a principle guiding us in how to act within the
context of relationships -- i.e., in communicating with others.
Let me go out on a limb and claim that much of the communication in the
computer world is, ahem, less than humble. Computer languages, APIs, and
protocols are brittle and filled with persnickety edges (and gaping holes).
Amongst developers, ad hominem attacks abound and incessant
opinions flow with precious little regard for simple things such as facts,
reality, and reductio ad usum.
I'll drill down into these areas (and more) in future posts.
If I can extend the limb you're climbing out on a bit further into the ether, I have had a suspicion that this conservative liberalism applies also to the incessant language wars. Are script languages safe? Are strongly typed languages passe? My answer is that strongly typed languages (e.g., java) are good for generating output (be conservative in what you generate), and scripting languages (e.g., python) are good at handling input (be liberal in what you accept). The strong typing helps limit errors, and the scripting flexibility allows for considerable bending of rules. Naturally, this issue is domain specific, but the gist is basically true: we need and should use both at the same time for diffent ends (or directions) of the communications channel.
While this is a good principle for the boundary of a system, it is a source of over-engineering when applied to the pieces within a system. Too many times I have seen sub-system code that is overly humble, such as having a sorted buffer for its input requests in case they arrive out of order. The developer feels he is "adding value" even though the upper layers of the system already guaruntee request ordering. One needs to balance the wasted effort in adding this "value" against the future probability that it will be useful. The concensus in agile programming is that these bets generally fail.
Couldn't agree more. Nicely put. This is why I dedicated my book to The Humble Programmer. Of course, every programmer should read Dijkstra's Turing Award Lecture of the same name.
> If I can extend the limb you're climbing out on a bit > further into the ether, I have had a suspicion that this > conservative liberalism applies also to the incessant > language wars. Are script languages safe? Are strongly > typed languages passe? My answer is that strongly typed > languages (e.g., java) are good for generating output (be > conservative in what you generate), and scripting > languages (e.g., python) are good at handling input (be > liberal in what you accept). The strong typing helps > limit errors, and the scripting flexibility allows for > considerable bending of rules. Naturally, this issue is > domain specific, but the gist is basically true: we need > and should use both at the same time for diffent ends (or > directions) of the communications channel. > > That's my suspicion anyhow. Thoughts? > > = Joe =
I like this idea. I'd like to work in a single language language that offers both. There doesn't have to be a strong vs. weak (or more accurately, static vs. dynamic) type schism -- they can both live in harmony, in the same language. Jython is a good start along this idea, but for some reason hasn't become very mainstream (anyway, it isn't really one language -- you have to know and write both Java and Python code to really get the best out of it).
I concur that this is fundamentally a language issue. Both in terms of human languages and computer languages. Partly this is an issue of people searching for the holy grail or the one true language. Partly it's laziness. And partly it's that, for many different reasons, most developers never really learn very many languages during their careers -- especially languages that are distinctly different from the first one or two that they learned.
Tcl with C has had this capability for 15 odd years. A number of Tcl extension/packages have been originally written ("prototyped") in pure Tcl and then key parts were rewritten in C. The original Tcl code needed no or very little changes (and the users of the Tcl package need change nothing).
This type of bi-level separation has all sorts benefits. I've found that more problems come up the more disjoint the languages are (in terms of their fundamental notions of how to get things done). I.e., look at Tcl on top of Java.
Ah, yes. This brings a couple of things to mind...
First, it's all a question of where you want to draw the line between "inside" and "outside". Well, I find that that almost always devolves into the issue of who draws the line. :-) I.e., it takes discernment to create a balanced solution given the context. This is why I like Henry Mintzberg's quote: "A technique is something that you use instead of a brain."
The eXtreministas are right on in questioning a blind adherence to centralized planning in the development world.
Another facet is that all too many people use whichever quip they think that they can get away with using as an excuse for not having to e.g., take responsibility for having to make good decisions. A Pure Evil form of this is where someone will use a quip/quote/etc. as the excuse to do exactly the opposite of what the point of the quip was, while claiming they are following that guideline/principle/whatever.
I don't know why... the best young programmers I know are quite arrogant, but the best older programmers I know are very humble. (Currently I fall into the "young and arrogant" category, unfortunately.)
Perhaps it takes a certain personality type to become a good programmer... and then, a certain level of maturity to become a great one...?
Ah, yes, well I think people lump a lot of different facets into "arrogance". For example, seriously questioning why certain decisions have been made and thinking that there are better ways of doing things. Yes, those can both be interpreted as "arrogance" and, depending on what one does from there may or may not actually be arrogant.
To be clear, when I'm talking about the principle of humility, I'm most certainly not talking about the so-called "political correctness" definition -- I am talking about the definition that I presented. I know a lot of hard-chargin' SOBs who may well be (considered as) arrogant as Larry Ellison but they follow the principle of humility with great aplomb.
All that said, I do find that there are general tendencies in less experienced people that inhibit humility. But, be clear that there are general tendencies in more experienced developers that inhibit humility, too. It's just that the specific tendencies are relatively disjoint between the two groups. More importantly to me is the fact that the great ones are great regardless of age and they just get better as they get more experience.
Previous Topic
