As a person with broad intellectual interests, I might be an anachronism. One of the problems of free market economics is that it exploits our strengths and exacerbates our weaknesses. People that seek a healthy balance don’t fit naturally in the system. Fortunately, I took up my career as a software developer during a sweet spot of sorts – enough infrastructure had been established that we don’t have to worry about the details of how a computer manages memory and peripherals or does arithmetic on different data types, but the industry had not yet become a self-sustaining economic system driven by the generation and sharing of digital data. As a generalist, then, I was valuable as a translator between the digital realm and the “normal” world.

I was struck by the magic of the digital reality. My father enjoyed sharing stories of how he could make programs break in the early days by abusing their input devices, but by the time I had come on the scene, the electrical engineers had succeeded in creating a world in which the computer never seemed to get tired, made your mess disappear without fuss, and always did exactly what you asked. Knowing men, I wasn’t surprised that many were seduced completely by that fantasy. In my case, I was seduced by the fact that if you knew a little about software, you could get any productive person to talk to you in the hopes that they could partner to parlay their expertise into dot-com fortune.

In translating those conversations into software, I was fortunate to have object-oriented development methods to exercise.  It allows me to create software abstractions that correspond well with the goals of my users. In engineering applications, concerned with the operation of actual machinery, object-oriented methods are a particularly strong fit.

That’s not so much the case in the software industry today. Companies such as Google and Facebook have managed to compile huge stores of data, and aspire to correlate that information with economic activity. There’s really no definite theory behind those explorations, so we’ve seen the rise of languages that describe efficiently algorithms that filter, transform and correlate random pieces of data.

The recruiting challenge facing engineering companies is lampooned in a GE ad in which a new hire finds himself competing for attention against the developer of a mobile app that puts fruit hats on pictures of your pet. GE is competing against nascent monopolies (Google and Facebook again the exemplars) that throw money at developers just to keep them out of the hands of their competitors. I faced the same challenge when seeking to grow my current team.

But when exploring the technologies (Haskell, Clojure, and others) used by Google and others for analysis of large data stores, what struck me most was how terribly dry they are. There’s no sense of connection to people and the choices that they make. To me that takes a lot of fun out of my practice.

This has been expressed in my working through of the examples in Troelson’s Pro C# and the .NET 4.5 Framework. Confronted with examples with names like “ExtractAppDomainHostingThread” and “MyAsyncCallbackMethod”, I found myself figuratively tearing out my hair. Yes, these names are self-documenting, in the sense that they forecast accurately what we find in the code, but they aren’t even entertaining much less actually fun.

When Troelson begins exploring how .NET supports an application that has to perform many separate tasks in parallel, he introduces a class called Printer that writes a number to the screen and then waits a short time before writing the next number. By running many Printers in parallel, we can see clearly the unpredictability of the results in the screen output.

Of course I am offended by this whole concept. No Printer in the world ever behaved like this. So, given this class that does something meaningless while wasting time, I renamed it “Useless.” Rather than invoking “PrintNumbers”, I tell my Useless class to “WasteTime.” As methods for corralling wayward tasks are advanced, I further the metaphor with methods such as “WanderIdly” and “LanguishInAQueue.”

My son and I meet most Saturdays for lunch at the Fresh Brothers in the Westlake Village Promenade. When he interrupted my exercises, I talked him through these examples, and he burst out laughing. Now that’s success.

So what’s the developer trapped in the digital world-view to do? My suggestion would be a return to assembly coding. At Los Alamos in the ’50s, my father picked up the habit of trying to read the consonant-rich listings. He would become mightily amused as he punctuated them with lip-smacks and shrill sirens, decorations evolved in the secret society of machine developers trapped on the isolated buttes of New Mexico.