The Never-Ending Debate of Specialist v. Generalist

Another DZone newsletter crosses my Inbox, and again I feel compelled to comment.
Not so much in the uber-aggressive style of my previous attempt, since I find myself
more on the fence on this one, but because I think it's a worthwhile debate and worth
calling out.

The article in question is "5 Reasons Why You Don't Want A Jack-of-all-Trades Developer",
by Rebecca Murphey. In it, she talks about the all-too-common want-ad description
that appears on job sites and mailing lists:

I've spent the last couple of weeks trolling Craigslist and have been shocked at the
number of ads I've found that seem to be looking for an entire engineering team rolled
up into a single person. Descriptions like this aren't at all uncommon:

Candidates must have 5 years experience defining and developing data driven web sites
and have solid experience with ASP.NET, HTML, XML, JavaScript, CSS, Flash, SQL, and
optimizing graphics for web use. The candidate must also have project management skills
and be able to balance multiple, dynamic, and sometimes conflicting priorities. This
position is an integral part of executing our web strategy and must have excellent
interpersonal and communication skills.

Her disdain for this practice is the focus of the rest of the article:

Now I don't know about you, but if I were building a house, I wouldn't want an architect
doing the work of a carpenter, or the foundation guy doing the work of an electrician.
But ads like the one above are suggesting that a single person can actually do all
of these things, and the simple fact is that these are fundamentally different skills.
The foundation guy may build a solid base, but put him in charge of wiring the house
and the whole thing could, well, burn down. When it comes to staffing a web project
or product, the principle isn't all that different -- nor is the consequence.

I'll admit, when I got to this point in the article, I was fully ready to start the
argument right here and now--developers have to have a well-rounded collection
of skills, since anecdotal evidence suggests that trying to go the route of programming
specialization (along the lines of medical specialization) isn't going to work out,
particularly given the shortage of programmers in the industry right now to begin
with. But she goes on to make an interesting point:

The thing is, the more you know, the more you find out you don't know. A year ago
I'd have told you I could write PHP/MySQL applications, and do the front-end too;
now that I've seen what it means to be truly skilled at the back-end side of things,
I realize the most accurate thing I can say is that I understand PHP applications
and how they relate to my front-end development efforts. To say that I can write them
myself is to diminish the good work that truly skilled PHP/MySQL developers are doing,
just as I get a little bent when a back-end developer thinks they can do my job.

She really caught me eye (and interest) with that first statement, because it echoes
something Bjarne Stroustrup told me almost 15 years ago, in an email reply sent back
to me (in response to my rather audacious cold-contact email inquiry about the costs
and benefits of writing a book): "The more you know, the more you know you don't know".
What I think also caught my eye--and, I admit it, earned respect--was her admission
that she maybe isn't as good at something as she thought she was before. This kind
of reflective admission is a good thing (and missing far too much from our industry,
IMHO), because it leads not only to better job placements for us as well as the companies
that want to hire us, but also because the more honest we can be about our own skills,
the more we can focus efforts on learning what needs to be learned in order to grow.

She then turns to her list of 5 reasons, phrased more as a list of suggestions to
companies seeking to hire programming talent; my comments are in italics:

So to all of those companies who are writing ads seeking one magical person to fill
all of their needs, I offer a few caveats before you post your next Craigslist ad:

1. If you're seeking a single person with all of these skills, make sure you have
the technical expertise to determine whether a person's skills match their resume.
Outsource a tech interview if you need to. Any developer can tell horror stories about
inept predecessors, but when a front-end developer like myself can read PHP and think
it's appalling, that tells me someone didn't do a very good job of vetting and got
stuck with a programmer who couldn't deliver on his stated skills.

(T: I cannot stress this enough--the technical interview process practiced at
most companies is a complete sham and travesty, and usually only succeeds in making
sure the company doesn't hire a serial killer, would-be terrorist, or financially
destitute freeway-underpass resident. I seriously think most companies should outsource
the technical interview process entirely.)

2. A single source for all of these skills is a single point of failure on multiple
fronts. Think long and hard about what it will mean to your project if the person
you hire falls short in some aspect(s), and about the mistakes that will have to be
cleaned up when you get around to hiring specialized people. I have spent countless
days cleaning up after back-end developers who didn't understand the nuances and power
of CSS, or the difference between a div, a paragraph, a list item, and a span. Really.

(T: I'm not as much concerned about the single point of failure argument here,
to be honest. Developers will always have "edges" to what they know, and companies
will constantly push developers to that edge for various reasons, most of which seem
to be financial--"Why pay two people to do what one person can do?" is a really compelling
argument to the CFO, particularly when measured against an unquantifiable, namely
the quality of the project.)

3. Writing efficient SQL is different from efficiently producing web-optimized graphics.
Administering a server is different from troubleshooting cross-browser issues. Trust
me. All are integral to the performance and growth of your site, and so you're right
to want them all -- just not from the same person. Expecting quality results in every
area from the same person goes back to the foundation guy doing the wiring. You're
playing with fire.

(T: True, but let's be honest about something here. It's not so much that the
company wants to play with fire, or that the company has a manual entitled "Running
a Dilbert Company" that says somewhere inside it, "Thou shouldst never hire more than
one person to run the IT department", but that the company is dealing with limited
budgets and headcount. If you only have room for one head under the budget, you want
the maximum for that one head. And please don't tell me how wrong that practice of
headcount really is--you're preaching to the choir on that one. The people you want
to preach to are the Jack Welches of the world, who apparently aren't listening to
us very much.)

4. Asking for a laundry list of skills may end up deterring the candidates who will
be best able to fill your actual need. Be precise in your ad: about the position's
title and description, about the level of skill you're expecting in the various areas,
about what's nice to have and what's imperative. If you're looking to fill more than
one position, write more than one ad; if you don't know exactly what you want, try
harder to figure it out before you click the publish button.

(T: Asking people to think before publishing? Heresy! Truthfully, I don't think
it's a question of not knowing what they want, it's more trying to find what they
want. I've seen how some of these same job ads get generated, and it's usually because
a programmer on the team has left, and they had some degree of skill in all of those
areas. What the company wants, then, is somebody who can step into exactly what that
individual was doing before they handed in their resignation, but ads like, "Candidate
should look at Joe Smith's resume on Dice.com (http://...) and have exactly that same
skill set. Being named Joe Smith a desirable 'plus', since then we won't have to have
the sysadmins create a new login handle for you." won't attract much attention. Frankly,
what I've found most companies want is to just not lose the programmer in the first
place.)

5. If you really do think you want one person to do the task of an entire engineering
team, prepare yourself to get someone who is OK at a bunch of things and not particularly
good at any of them. Again: the more you know, the more you find out you don't know.
I regularly team with a talented back-end developer who knows better than to try to
do my job, and I know better than to try to do his. Anyone who represents themselves
as being a master of front-to-back web development may very well have no idea just
how much they don't know, and could end up imperiling your product or project -- front
to back -- as a result.

(T: Or be prepared to pay a lot of money for somebody who is an expert at all
of those things, or be prepared to spend a lot of time and money growing somebody
into that role. Sometimes the exact right thing to do is have one person do it all,
but usually it's cheaper to have a small team work together.)

(On a side note, I find it amusing that she seems to consider PHP a back-end skill,
but I don't want to sound harsh doing so--that's just a matter of perspective, I suppose.
(I can just imagine the guffaws from the mainframe guys when I talk about EJB, message-queue
and Spring systems being "back-end", too.) To me, the whole "web" thing is front-end
stuff, whether you're the one generating the HTML from your PHP or servlet/JSP or
ASP.NET server-side engine, or you're the one generating the CSS and graphics images
that are sent back to the browser by said server-side engine. If a user sees something
I did, it's probably because something bad happened and they're looking at a stack
trace on the screen.)

The thing I find interesting is that HR hiring practices and job-writing skills haven't
gotten any better in the near-to-two-decades I've been in this industry. I can still
remember a fresh-faced wet-behind-the-ears Stroustrup-2nd-Edition-toting job candidate
named Neward looking at job placement listings and finding much the same kind of laundry
list of skills, including those with the impossible number of years of experience.
(In 1995, I saw an ad looking for somebody who had "10 years of C++ experience", and
wondering, "Gosh, I guess they're looking to hire Stroustrup or Lippmann", since those
two are the only people who could possibly have filled that requirement at the time.
This was right before reading the ad that was looking for 5 years of Java experience,
or the ad below it looking for 15 years of Delphi....)

Given that it doesn't seem likely that HR departments are going to "get a clue" any
time soon, it leaves us with an interesting question: if you're a developer, and you're
looking at these laundry lists of requirements, how do you respond?

Here's my own list of things for programmers/developers to consider over the next
five to ten years:

1. These "laundry list" ads are not going away any time soon. We can rant and
   rail about the stupidity of HR departments and hiring managers all we want, but the
   basic fact is, this is the way things are going to work for the forseeable future,
   it seems. Changing this would require a "sea change" across the industry, and sea
   change doesn't happen overnight, or even within the span of a few years. So, to me,
   the right question to ask isn't, "How do I change the industry to make it easier for
   me to find a job I can do?", but "How do I change what I do when looking for a job
   to better respond to what the industry is doing?"

2. Exclusively focusing on a single area of technology is the Kiss of Death. If
   all you know is PHP, then your days are numbered. I mean no disrespect to the PHP
   developers of the world--in fact, were it not too ambiguous to say it, I would rephrase
   that as "If all you know is X, your days are numbered." There is no one technical
   skill that will be as much in demand in ten years as it is now. Technologies age.
   Industry evolves. Innovations come along that completely change the game and leave
   our predictions of a few years ago in the dust. Bill Gates (he of the "640K comment")
   has said, and I think he's spot on with this, "We routinely overestimate where we
   will be in five years, and vastly underestimate where we will be in ten." If you put
   all your eggs in the PHP basket, then when PHP gets phased out in favor of (insert
   new "hotness" here), you're screwed. Unless, of course, you want to wait until
   you're the last man standing, which seems to have paid off well for the few COBOL
   developers still alive.... but not so much for the Algol, Simula, or RPG folks....

3. Assuming that you can stop learning is the Kiss of Death. Look, if you want
   to stop learning at some point and coast on what you know, be prepared to switch industries.
   This one, for the forseeable future, is one that's predicated on radical innovation
   and constant change. This means we have to accept that everything is in a constant
   state of flux--you can either rant and rave against it, or roll with it. This doesn't
   mean that you don't have to look back, though--anybody who's been in this industry
   for more than 10 years has seen how we keep reinventing the wheel, particularly now
   that the relationship between Ruby and Smalltalk has been put up on the big stage,
   so to speak. Do yourself a favor: learn stuff that's already "done", too, because
   it turns out there's a lot of lessons we can learn from those who came before us.
   "Those who cannot remember the past are condemned to repeat it" (George Santanyana).
   Case in point: if you're trying to get into XML services, spend some time learning
   CORBA and DCOM, and compare how they do things against WSDL and SOAP. What's similar?
   What's different? Do some Googling and see if you can find comparison articles between
   the two, and what XML services were supposed to "fix" from the previous two. You don't
   have to write a ton of CORBA or DCOM code to see those differences (though writing
   at least a little CORBA/DCOM code will probably help.)

4. Find a collection of people smarter than you. Chad Fowler calls this "Being
   the worst player in any band you're in" (My Job Went to India (and All I Got Was
   This Lousy Book), Pragmatic Press). The more you surround yourself with
   smart people, the more of these kinds of things (tools, languages, etc) you will pick
   up merely by osmosis, and find yourself more attractive to those kind of "laundry
   list" job reqs. If nothing else, it speaks well to you as an employee/consultant if
   you can say, "I don't know the answer to that question, but I know people who do,
   and I can get them to help me".

5. Learn to be at least self-sufficient in related, complementary technologies. We
   see laundry list ads in "clusters". Case in point: if the company is looking for somebody
   to work on their website, they're going to rattle off a list of five or so things
   they want he/she to know--HTML, CSS, XML, JavaScript and sometimes Flash (or maybe
   now Silverlight), in addition to whatever server-side technology they're using (ASP.NET,
   servlets, PHP, whatever). This is a pretty reasonable request, depending on the depth
   of each that they want you to know. Here's the thing: the company does not want
   the guy who says he knows ASP.NET (and nothing but ASP.NET), when asked to make a
   small HTML or CSS change, to turn to them and say, "I'm sorry, that's not in my job
   description. I only know ASP.NET. You'll have to get your HTML guy to make that change."
   You should at least be comfortable with the basic syntax of all of the above (again,
   with possible exception for Flash, which is the odd man out in that job ad that started
   this piece), so that you can at least make sure the site isn't going to break when
   you push your changes live. In the case of the ad above, learn the things that "surround"
   website development: HTML, CSS, JavaScript, Flash, Java applets, HTTP (!!), TCP/IP,
   server operating systems, IIS or Apache or Tomcat or some other server engine (including
   the necessary admin skills to get them installed and up and running), XML (since it's
   so often used for configuration), and so on. These are all "complementary" skills
   to being an ASP.NET developer (or a servlet/JSP developer). If you're a C# or Java
   programmer, learn different programming languages, a la F# (.NET) or Scala (Java),
   IronRuby (.NET) or JRuby (Java), and so on. If you're a Ruby developer, learn either
   a JVM language or a CLR language, so you can "plug in" more easily to the large corporate
   enterprise when that call comes.

6. Learn to "read" the ad at a higher level. It's often possible to "read between
   the lines" and get an idea of what they're looking for, even before talking to anybody
   at the company about the job. For example, I read the ad that started this piece,
   and the internal dialogue that went on went something like this: Candidates
   must have 5 years experience (No entry-level developers wanted, they want somebody
   who can get stuff done without having their hand held through the process) defining
   and developing data driven (they want somebody who's comfortable with SQL and
   databases) web sites (wait for it, the "web cluster" list is coming) and
   have solid experience with ASP.NET (OK, they're at least marginally a Microsoft
   shop, that means they probably also want some Windows Server and IIS experience),
   HTML, XML, JavaScript, CSS (the "web cluster", knew that was coming), Flash (OK,
   I wonder if this is because they're building rich internet/intranet apps already,
   or just flirting with the idea?), SQL (knew that was coming), and optimizing
   graphics for web use (OK, this is another wrinkle--this smells of "we don't want
   our graphics-heavy website to suck"). The candidate must also have project management
   skills (in other words, "You're on your own, sucka!"--you're not part of a project
   team) and be able to balance multiple, dynamic, and sometimes conflicting priorities (in
   other words, "You're own your own trying to balance between the CTO's demands and
   the CEO's demands, sucka!", since you're not part of a project team; this also probably
   means you're not moving into an existing project, but doing more maintenance work
   on an existing site). This position is an integral part of executing our web
   strategy (in other words, this project has public visibility and you can't let
   stupid errors show up on the website and make us all look bad) and must have
   excellent interpersonal and communication skills (what job doesn't need
   excellent interpersonal and communication skills?).See what I mean?
   They want an ASP.NET dev. My guess is that they're thinking a lot about Silverlight,
   since Silverlight's closest competitor is Flash, and so theoretically an ASP.NET-and-Flash
   dev would know how to use Silverlight well. Thus, I'm guessing that the HTML, CSS,
   and JavaScript don't need to be "Adept" level, nor even "Master" level, but "Journeyman"
   is probably necessary, and maybe you could get away with "Apprentice" at those levels,
   if you're working as part of a team. The SQL part will probably have to be "Journeyman"
   level, the XML could probably be just "Apprentice", since I'm guessing it's only necessary
   for the web.config files to control the ASP.NET configuration, and the "optimizing
   web graphics", push-come-to-shove, could probably be forgiven if you've had some experience
   at doing some performance tuning of a website.

7. Be insightful. I know, every interview book ever written says you should
   "ask questions", but what they're really getting at is "Demonstrate that you've thought
   about this company and this position". Demonstrating insight about the position and
   the company and technology as a whole is a good way to prove that you're a neck above
   the other candidates, and will help keep the job once you've got it.

8. Be honest about what you know. Let's be honest--we've all met developers
   who claimed they were "experts" in a particular tool or technology, and then painfully
   demonstrated how far from "expert" status they really were. Be honest about yourself:
   claim your skills on a simple four-point scale. "Apprentice" means "I read a book
   on it" or "I've looked at it", but "there's no way I could do it on my own without
   some serious help, and ideally with a Master looking over my shoulder". "Journeyman"
   means "I'm competent at it, I know the tools/technology"; or, put another way, "I
   can do 80% of what anybody can ask me to do, and I know how to find the other 20%
   when those situations arise". "Master" means "I not only claim that I can do what
   you ask me to do with it, I can optimize systems built with it, I can make it do things
   others wouldn't attempt, and I can help others learn it better". Masters are routinely
   paired with Apprentices as mentors or coaches, and should expect to have this as a
   major part of their responsibilities. (Ideally, anybody claiming "architect" in their
   title should be a Master at one or two of the core tools/technologies used in their
   system; or, put another way, architects should be very dubious about architecting
   with something they can't reasonably claim at least Journeyman status in.) "Adept",
   shortly put, means you are not only fully capable of pulling off anything a Master
   can do, but you routinely take the tool/technology way beyond what anybody else thinks
   possible, or you know the depth of the system so well that you can fix bugs just by
   thinking about them. With your eyes closed. While drinking a glass of water. Seriously,
   Adept status is not something to claim lightly--not only had you better know the guys
   who created the thing personally, but you should have offered up suggestions on how
   to make it better and had one or more of them accepted.

9. Demonstrate that you have relevant skills beyond what they asked for. Look
   at the ad in question: they want an ASP.NET dev, so any familiarity with IIS, Windows
   Server, SQL Server, MSMQ, COM/DCOM/COM+, WCF/Web services, SharePoint, the CLR, IronPython,
   or IronRuby should be listed prominently on your resume, and brought up at least twice
   during your interview. These are (again) complementary technologies, and even if the
   company doesn't have a need for those things right now, it's probably because Joe
   didn't know any of those, and so they couldn't use them without sending Joe to a training
   class. If you bring it up during the interview, it can also show some insight on your
   part: "So, any questions for us?" "Yes, are you guys using Windows Server 2008, or
   2003, for your back end?" "Um, we're using 2003, why do you ask?" "Oh, well, when
   I was working as an ASP.NET dev for my previous company, we moved up to 2008 because
   it had the Froobinger Enhancement, which let us...., and I was just curious if you
   guys had a similar need." Or something like that. Again, be entirely honest about
   what you know--if you helped the server upgrade by just putting the CDs into the drive
   and punching the power button, then say as much.

10. Demonstrate that you can talk to project stakeholders and users. Communication
    is huge. The era of the one-developer team is long since over--you have to be able
    to meet with project champions, users, other developers, and so on. If you can't do
    that without somebody being offended at your lack of tact and subtlety (or your lack
    of personal hygiene), then don't expect to get hired too often.

11. Demonstrate that you understand the company, its business model, and what would
    help it move forward. Developers who actually understand business are surprisingly
    and unfortunately rare. Be one of the rare ones, and you'll find companies highly
    reluctant to let you go.

Is this an exhaustive list? Hardly. Is this list guaranteed to keep you employed forever?
Nope. But this seems to be working for a lot of the people I run into at conferences
and client consulting gigs, so I humbly submit it for your consideration.

But in no way do I consider this conversation completely over, either--feel free to
post your own suggestions, or tell me why I'm full of crap on any (or all) of these.
:-)

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.