Developers: Specialize
In software development, as in most things, there is value in being a generalist; a utility player. It’s nice to have that person that can be dropped into almost any situation and make progress. They can usually be counted on to do the job well enough to ship the product according to the spec.
But sometimes it’s just not good enough to know the basics, what happens when the generalist gets into something over his head. Enter the specialist; the one who eats, sleeps and breathes his language/technology of choice. The one who comes through with the elegant solutions quickly when things get really hairy, or the person who you call when you need to take your code to the next level of style or performance. Sometimes you just really really need a specialist to get you over the big hurdles.
Unfortunately, I feel like the software industry is fostering an environment where developers feel like the only way to be successful is to be an extreme generalist. If you look at the average job posting for a software developer you are bound to find a requirement of a developer with 5+ years of experience and is a master of something like five or ten different languages and technologies. Developers know that’s a load of crap, yet we still pack our resumes with buzzwords. How many of us have been at home burning the midnight oil cramming yet another “hello world” tutorial in right before an interview because god forbid we don’t know about the new language/framework that came out yesterday! I fear this silly game is only stunting the growth of some great developers out there.
Let’s imagine if this were the way that the construction industry worked. Get rid of carpenters, electricians, masons, plumbers, and painters and replace them with “constructors”. I doubt the constructors would get far in trying to handle all parts of the construction process and meet the same standards we have today. Our housing quality would plummet if every plumber had to worry about learning how to make cabinets and wire up lights as well. By having specialties it has allows us to push the limits of those fields farther and continue to innovate and improve. So why do many companies have front-end developers worrying over stored procedures?
I understand using the “wearing many hats” strategy in a small start-ups where money is short and a patch job by someone can get you by at the start, but when you grow up as a business and begin staffing multiple developers does it make sense to continue to hire ‘handymen’? I strongly urge managers to stop hiring any developer and start looking for the developer that will excel in the position and fill your need. Just because you find a css wizard doesn’t mean you should hire him if your shortcomings are in the back end.
As for developers, we need to spend less time padding our resumes out with buzzwords and spend that time improving the skill that we are looking to provide. If I hate writing C then why should I include it in my current skill set while looking for a job as a javascript developer. I feel like the quality of the software produced as well as the development community at large would greatly benefit from more of us beginning to specialize. Perhaps the medical doctor approach of general practitioners and specialists would be a good model, but I really think we need to get away from this endless stream of generalists and start harvesting some of the talent they are hiding.
