Engineering Ardor
“Science is the study of what is. Engineering builds what will be.” — Theodore von Karman

Job Listings and Past Experience

I started this blog now because I believe I’ll have more free time to devote to hobbies. I’ve just switched jobs. As I looked at my options, I read many listings for software engineers. The emphasis these listings placed on experience in a particular programming language, tool, or framework was disappointing.

Requiring that a programmer must have experience in one particular language or tool is like insisting that a waiter must have experience waiting tables at a seafood restaurant. Who cares if his experience was at a steakhouse instead? The essential skills, knowledge of how restaurants operate, and ability to deal with difficult customers are the same. If he’s thrown off because the plates have steamed crustacean on them instead of grilled cow, he’s no use to me anyway.

I’ve heard the counter-argument. “But steak and lobster have such different centers of gravity, so the plates balance differently. And it’ll cost us a lot to teach him the particular gotchas of this kind of food, like not letting the lobsters catch his fingers with their claws!” The idea here is that every language and tool has unique quirks, and that a developer must have experience with those quirks or they’ll get mired in a productivity sapping tar pit of small mistakes. There may be some truth to this argument in the first few days on the job, but not over the medium and long term.

I’m not dismissing the value of experience as a whole. The right kind of knowledge and experience are valuable. More experience working as a developer is better than less. I’m now a far better developer than I was five years ago. I’ll be better still in another decade. Domain knowledge and experience, too, are more than surface deep. Picking up a thorough understanding of a problem domain takes time, and in the meantime the less experienced programmer may do some amount of well-intentioned harm. Don’t expect someone with a background in developing UML modeling tools to produce a good design for a real-time, embedded signal processing system. Those distinctions make for better hiring criteria than years using a language or tool.

When hiring, I look for developers with strong skills in areas that contribute to delivering software. A great developer should:

  • Know how to produce good, clean code.
  • Understand requirements specification, design, and testing.
  • Have solid experience with the things that keep projects running smoothly throughout the life cycle, to include development process, configuration management, peer review, and work estimation.
  • Have superior soft skills such as drive and motivation, verbal and written communication ability, the capacity to work with a team, and leadership capability.
  • Domain knowledge applicable to the project.

See what’s missing from that list? Specific languages. Specific development tools. Specific APIs. Specific processes. It doesn’t matter whether the candidate’s experience is in C or Perl, NetBeans or Eclipse, CVS or Subversion, PSP or XP. To a good developer, those are just variations on a theme. And yet, these variations get top billing in job listings: 8 years experience in C; not C++, because we don’t understand the similarity. Ideal candidate must fog a mirror held under nostrils and supply own blank stare.

Insisting a candidate have experience with a particular language or tool set assumes that it’s a difficult to translate development knowledge from one language syntax to another. For a short time there was a fad - forgive me, trend - toward languages with very English-like syntax. Those languages never took hold, in part because they solved the wrong problem. The syntax was never the hard part; the right kind of thinking was and is.

A few old college friends of mine say they’ve solved this problem by lying shamelessly about the buzzwords they know. Once they land the job, they hit the bookstore and pick up a few reference books. By the time they walk in for their first day on the job, they know everything they need to know about the language and tools du jour. I can’t bring myself to do this. As for you, gentle reader, this is between you, the little you with the pitch fork on your left shoulder, and the little you with the halo on your right shoulder.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • Furl
  • NewsVine

Leave a Reply

Subscribe without commenting