Generalization and Specialization

I have been reading "My Job Went to India... (and all I got was this lousy book)" by Chad Fowler. I'm still in the middle of it, but a couple of sections really resonated and I wanted to jot some thoughts down while they were fresh in my mind. It is probably worth mentioning for those not familiar with the book that it is not really a criticism of India or of outsourcing in general, but rather, a pragmatic discussion of how to survive in the midst of the current trend to outsource technical work. Fowler presents his thoughts on what a person can do to keep their job domestic when so many positions are leaving the country.

A couple of his ideas are contradictory, yet complimentary. He argues that a developer should decide to be a generalist or a specialist. He compares the specialist to an assembly line worker on a mass production line. The generalist, on the other hand, is the proverbial "Jack of All Trades, Master of None". I like that Fowler tries to dispel the negative connotation surrounding this label. In Fowler's opinion, either path can lead to better protection of your job.

The generalist is able to pick up the odds and ends and minutiae left behind in the wake of layoffs or outsourcing. He argues that it is important for the generalist to understand to some level the product at both a business and technical level. At the product level, understand the customer needs and business case for the product. At the technical level, not only should you understand the code used to realize the product, but also the architecture, test strategy, and deployment process. The generalist should also be careful not to fixate on specific technologies, e.g., code versus database, Java versus C#, etc.

A specialist can make his or her self safe in a different way. This is accomplished by understanding an area of technology to a depth that qualifies this person as a guru. By doing so, the developer becomes the indispensable resource of last resort, turned to when the really hard technical issue crops up that the rest of the team can't resolve. Fowler is quick to point out that this is a difficult state to attain. One example he uses is an interview question, "How would you write a program, in pure Java, that would crash the JVM?" He argues that unless you understand the internal workings of the JVM (which would include the threading model, memory management, and instruction generation), you aren't a Java specialist.

As an aside, I don't consider myself to be a Java specialist, but my first thought was to exhaust memory, but I am sure there are faster ways to crash the JVM.

While he didn't come right out and say it, I got the feeling that Fowler sees generalization versus specialization as an either/or proposition and that he maybe leans a bit towards favoring generalization. While I concur that generalization is a better survival strategy, I think there is room in the generalist’s repertoire for some degree of specialization. In my mind, a melding of the two ideas is very compelling.

I consider myself to be a generalist. I am a degreed electrical engineer. I have experience with digital electronics. I spent the first four years of my career coding in assembly for an embedded real-time system. I also wrote real-time firmware in C and C++. I have written graphical applications for Windows and the original MacOS. I am currently developing middleware apps in Java. I also have experience with scripting languages such as PERL, TCL, and Bash. I wrote some SQL and am currently learning the Hibernate ORM utility. Next up is Groovy. The list of things to learn is very long and is growing faster than there is time in the day.

I don't mention this to toot my own horn, but to support my hypothesis that I am a generalist. But I am also a specialist, albeit what I will term an opportunistic, short term specialist. Invariably, during certain stages of a project, I wind up learning something to a detail that meets Fowler's definition of a specialist. The area of the specialty varies from project to project and because of this variability, the half-life of my "specialist" qualification is short in duration (on the order of 1-2 years). For example, in the mid-90's, while working in the test and measurement industry, I became an expert on the IEEE 488.2 and SCPI command sets for instrument command and control. I knew the vagaries of the standards and what requirements needed the most work in the code. Ten years later, the details escape me, but at the time, when a question was raised about these protocols, folks came to me. The same has occurred in other industries, including understanding drug interaction for IV compounding, VME and VXI bus protocols, ISDN signaling (LAPD and Q.921), and currently, I am immersing myself in the agile methodology, SCRUM. In the spirit of "use it or lose it", when I move on to other projects, the details get fuzzy, but I always try to adopt at least one topic to focus on and embrace in a detailed sense.

The side-benefit of this strategy is that even when the details fade, much of what I learn can still be applied in a general fashion. Which supports my initial statement that I am a generalist. In summary, as a generalist, sometime specialist, I can attest to Fowler's thesis that developers who adopt these strategies maximize their chances of staying gainfully employed. It has worked for me.