Idiots and Experts

In 1932, the Australian army, under the command of Major G.P.W. Meredith, engaged in a month long operation that would be called the “Emu War”.  He and two additional soldiers were deployed to disperse of an emu threat to farmers in western Australia.  They brought with them a couple of machine guns and imagined a rather easy victory.  The emu, however, had other plans.  Australian ornithologist Dominic Serventy commented on the event and its difficulties with the following words:

“The machine-gunners’ dreams of point blank fire into serried masses of Emus were soon dissipated. The Emu command had evidently ordered guerrilla tactics, and its unwieldy army soon split up into innumerable small units that made use of the military equipment uneconomic. A crestfallen field force therefore withdrew from the combat area after about a month.”

The Emu WarAside from being a rather humorous story, the Emu War of 1932 teaches a lesson that a great many of us would do well to remember.  It is a lesson on pride, preparedness, and the capacity of humans to make fools of themselves.

When Major Meredith trekked westward to face the emu threat, he was no doubt confident that the mission would be an automatic and tremendous success.  After all, he had two machine guns and fighting experience in World War I.  The emu, on the other hand, were just large birds with no real intelligence and only beaks for weapons.  So what happened?

What happened is that Major Meredith made the mistake of thinking that because he was expert in war he would also be expert in culling a troublesome animal population.  What’s more, he assumed the same instruments and tactics could be used for both missions.  After all, killing is killing, right?  Wrong.  The major and his men were experts in their field, but because of this expertise and the assumption that it would carry over into other fields, they walked out of the Emu War as idiots.

How often do we see similar (though hopefully less embarrassing) events occur in our own lives?  The most common example is the cocky, energetic student right out of college and new in the workforce.  He earned straight A’s at school and was commended for his projects and productivity by professors and fellow students.  Naturally, the student is confident when entering the workforce, and as a result often makes the mistake of thinking himself already an expert at what goes on in the office and how to get things done in the “real world”.  No time is taken to listen, learn, and adapt.  Instead, the poor fool takes bold action — wrong bold action — and makes an idiot of himself.  Hopefully the action is minor and unimportant enough for everyone to have a laugh about it later, but in all cases it is an embarrassing and avoidable mistake.  Events like these are so common that they are almost universally accepted as “part of the learning process”.

What’s worse is the “expert” in another, related field who feels that their own capabilities and experiences outrank a true expert in the field of current action.  Unfortunately, examples of this type of activity also abound.  A particularly embarrassing story is that of the school lunch the government of North Carolina forced upon a little girl who’s mother had packed something that the government did not approve ( story here: http://www.theblaze.com/stories/n-c-food-inspector-sends-girls-lunch-home-after-determining-its-not-healthy-enough/ ). 

I love working as a developer, but one of the worst things about the occupation is that many developers think they are expert in, well, everything code-related.  I cannot count the number of times I’ve started exploring another coder’s work and wondered why in the world they chose to architect something one way or another only to later find out through more code exploration that they had a pretty good reason to do what they were doing.  One of the classic mistakes of a junior developer is to see only that first piece of questionable code and instead of asking questions or delving further, change it to something “more perfect” which invariably breaks the software and angers the lead developer (who likely coded the original piece, had good reason for why they did it that way, and does not appreciate being “fixed” by the new guy).

It is worth noting that after the end of the disastrous Emu War, the government of Australia re-instituted a “bounty” program that resulted in a successful culling of the troublesome emu through employing hunters and actual experts at wildlife containment.

The lesson here is to enter any sort of new situation — even if it seems strongly related to your field of expertise — with open eyes and an open mind.  Speak with the people currently involved and with those who have been experiencing and/or tackling the problem before you got there.  Lean on their expertise instead of your own so that you can become an actual expert in the project rather than just an idiot who thinks he’s an expert.