Lord Palmerston Right or Wrong? Yes.
After sleeping on Joel’s article ( http://www.joelonsoftware.com/articles/LordPalmerston.html ), I’m left with mixed feelings. Here's the question that bothers me: why do I resist the notion that platform and API knowledge is important?
I can't speak for others, but I believe that ‘any monkey’ will eventually learn the 20% of any API or programming language that is needed 80% of the time.
Of course, a ‘guru’ knows the remaining 80%, and this is extremely valuable. But when a company is looking for a programmer with “five years of Java experience,” are they looking for the Guru? Probably not. They are probably satisfied with someone who has, essentially, one year of professional experience in Java repeated five years in a row.
So my resistance is based on the belief that there’s ‘nothing special’ about what most companies are looking for. But am I wrong?
Good programmers need a whole bunch of abilities. I’m going to bifurcate them along two orthogonal axes.
The first axis bifurcates abilities into qualities that drive the success of a project and qualities that are hygienic to the success of a project.
Drivers are abilities where the effect on the project is continuous: the better the programmer is, the more successful the project is. Hygienic abilities are clipped: provided the programmer has a modicum of the ability, the project sails along. But if the programmer lacks the ability, the project is adversely affected.
Hygienic abilities include showing up at the office when required, getting along with the team, buying into the project’s objective, and an ability to use a text editor.
But what about the drivers? Drivers include problem solving ability, case generation (a/k/a edge or corner case detection) and throughput (volume of Intellectual Property processed over time). There are others, of course.
So, given the driver/hygienic axis, where does API and Programming Language knowledge fit?
I believe that APIs, platforms, frameworks, and programming languages impose a model and a set of idioms on the programmer. Alan Perlis wrote: “A language that doesn't affect the way you think about programming, is not worth knowing.” ( http://www.cs.yale.edu/homes/perlis-alan/quotes.html ).
But is this a driver? Does it continuously drive the success of the project? I believe it does. If you don’t intuit the model, and if you don’t use and understand the idioms, you are at a tremendous productivity disadvantage. Furthermore, your code is usually terrible: you work around your platform and framework to impose your own model instead of smoothly writing for its model.
I mentioned another axis. Let’s bifurcate programmer abilities into those that can be learned on the job and those that can’t. This axis varies with the environment: some company cultures emphasize mentoring and teaching, and they would have many more abilities in the “can be learned on the job” pile.
The interesting thing I’ve experienced is that API knowledge is much more learnable than problem solving ability. Companies that use Microsoft-style interviews seem to agree. That’s certainly my preference when hiring: Given a choice between two people that have everything else, I want the person with the API experience, and I’ll pay them as much as double the salary in their first year. But I won’t compromise on the other driver abilities, especially those I don’t think I can teach or train.
So here we are with an important ability that is a driver and is also learnable. Given time and inclination, a smart programmer will learn the API. But (s)he will be drawing a paycheque and learning on the job. And perhaps companies don’t care to pay programmers while they’re learning.
So where’s my resistance to Joel’s article? While I respect Joel’s choices as a company manager, my experience with companies that are looking for “five years of java experience” is that they don’t appreciate the fact that API experience is necessary but not sufficient. Joel has written many times that he insists on hiring smart people and giving them a productive place to work.
So when he says he’s not interested in hiring people who don’t have strong experience in his platform, I don’t believe he’s saying he’ll take low powered programmers just because of alleged experience. I also don’t believe he’s saying he’ll take someone with a very shallow knowledge that has been reused time and time again. I suspect he wants smart people who are also deeply immersed in his platforms and APIs.
The typical HR person asking about “five years of Java experience” isn’t, as Joel pointed out, qualified to judge the difference between someone with a scanty knowledge and someone with deep understanding. And most of these companies are not even trying to judge whether a prospective hire can solve problems or is a proficient case analyst.
So why do hiring companies emphasize API experience measured in years? I conjecture because it’s easy to test for it. No complicated problems, no long and involved investigative interviews, no written tests, no programming auditions. Just fill in the box and make a background check to verify it.
Thus, in summary, I agree with Joel’s assessment of the importance of API knowledge. I agree that companies are looking for it. And I agree that I look for it myself when I’m hiring. But not at the expense of other abilities I’ve identified as drivers to a project’s success.
Thursday, December 12, 2002
Thanks for including your web site link. Impressive body of work.
It difficult to generally discuss "what makes a good developer", since there is no universal set of things that a developer does. Are they translating well thought out specs into code? Writing the specs? Talking to the customer about what they want vs. what they need? Do they need to be a leader? A follower? Are they primarily a buyer of ideas or a seller? New code or maintenance? Innovate or comply?
Beyond these questions is the "speed" of the hiring company. Do they want the product quickly, don't care what they spend or whether it works? Or, do they want to grow slowly, evolving the product over 10 years and several versions while retaining key people that work well together? Both approaches have business validity.
I agree with you that choosing a developer based on answers to the preceeding questions is more productive than basing on API knowledge. The quirks in an API can often be garnered through newsgroups, asking coworkers, etc. I wouldn't hire someone to do technical architecture or standards without having "best practices" knowledge of the baseline platform or technology, though. In a way, it's a waste for multiple team members to be packing around the same "use it once or twice" nuggets of API wisdom.
So, given the "real" questions you want to ask about a developer, how do answer these questions?
On your site, you mention personality testing. This has a certain appeal, although as a very undeveloper like INFP, I would tend to use the information in a supporting capacity only. My company (about 40 people) has started using DiSC assessments during interviews. We'll see how that works out.
I believe that fundamentally, there is no quantitative way to determine which developer will work out best. "5 years Java" doesn't mean someone isn't a jerk who writes code that reads like a plate of Thai noodles. You can only base maybe 25% of the hiring process on these stated factors. I find it amazing that it's unacceptable or "feely" to put honest information about your personality and work style on a resume.
In your experience, is there any reliable hiring method beyond gut feeling? How can those who aren't naturally intuitive approach this process? Given the staggering amount of cost/revenue difference between a "good hire" and a "bad hire", is there any way to hire a consultant who specializes in evaluating developers?
Thursday, December 12, 2002
Short answer (client visit in an hour or so):
References, references, references.
“The only security is your talent and people’s belief in your talent” ~--Garth Drabinsky
Friday, December 13, 2002
I think it's certainly true that the complexity of APIs and frameworks has grown vastly over the years. Though we shouldn't forget that older languages tended to have a lot of functionality built into the language, which often included some of the features now found in libraries and frameworks.
Last year, during a period of 'increased leisure time', I spent a couple of months learning Java. Because of my existing knowledge of C++, it took hardly any time to learn the differences, so the language was no issue. But the class libraries took months, and I know there's lots of stuff I never touched.
The same is true of .NET. There are some 1400 classes in the current version (likely to increase when version 1.1 comes out soon).
However, in the case of MCF, which is an abstraction of the Windows API, it often falls short of the mark, requiring knowledge of the underlying technologies it is built on. This is the problem with abstractions. When they fail, you have to get your hands dirty...
Friday, December 13, 2002
Fog Creek Home