Good programmers: there is no substitute

[jducoeur]

[Rant warning.]

One of the hazards of being semi-management these days is that I spend altogether too much time on the hiring process -- both writing reqs for new hires and interviewing people. And I keep being surprised by the question, "What kind of programmer do you want?"

The answer is, "A good one". All else is commentary.

If I'm hiring someone to work on the client, I keep getting questions about, "Do they need to specifically be a Flex programmer? How many years of UI programming experience do they need?" and so on, as if that's the important part. If we're looking for QA Automation Engineers, there are all these questions about, "Is it critical that they know a particular automation framework? How much time do they need to have spent on QA automation?"

These are the wrong questions. I do not, by and large, give a good goddamn about how much time someone has spent in a pigeonhole. Indeed, the more focused their career has been, the more suspicious I am of them. I have met Flex programmers who wrote the most atrocious code I've ever seen, and QA Engineers who thought they knew how to do automation because they could string lines of code together; both have been nothing but trouble.

While it is a *slight* exaggeration to say that Programming is Programming is Programming, it's not a huge one. Give me a programmer who knows what they are doing -- who is keeping up with the field and how to program *well* -- and I can confidently throw them at almost any problem. Moreover, I can be pretty confident that, after a fairly modest ramp-up time, they will probably be programming rings around the specialists who know an area well, but haven't spent the time really learning the craft of software.

Seriously: if you're in management, stop worrying about trying to hire specialists -- a good generalist programmer will, in most cases, be your best bet. If you're a programmer, don't spend as much attention learning specific libraries and such -- focus on honing your craft every day, knowing the general art of programming well, and exploring it in many forms. Good code pretty much looks like good code, whether you're writing databases, user interfaces, web servers, test harnesses, or anything else.

[/rant, brought to you by seeing the same mistakes made a few too many times]

Comments

[dsrtao]

Here's the quote from our software engineering ad:

You are driven, smart, and collegial. Most of your peers think you’re among the smartest people they know.

Obligatory bullets:

BS/BA or higher in CS or a related field
Preference to solve causes, not symptoms
0-5 years of postgraduate experience
Ability to close projects

Note that we do not mention our technology stack above. We believe the “right” people will be successful regardless of the specific technologies they have used in the past. That said, you do get bonus points for experience with: Ruby, Rails, Perl, C++, Apache, Oracle, Postgres, git. More bonus points for contributions to open source projects.

...
The closest person we have to an HR rep was a technical manager at DEC for many years.

Exceptions...

[jeremy bennett (from livejournal.com)]

Of course, the exceptions prove the rule. In my experience the higher up the software 'stack' you go the more true your statements become. However, there are certain areas where more experience and specialization become critical. Yes, a good programmer eventually learns what they need but that difference can be 1 month when you're learning RoR before you're effective on every project thrown at you and 6 months before you're effective working on things like device drivers, kernels and my favorite pit of scum and villainy - webkit.
In my experience what you find is you need a balance of generalists and specialists. The generalists learn to grasp the overall problem and can move from piece to piece and stitch the whole thing together but the specialists keep those pieces solid and give the generalists someone to rely on when they need that critical single piece of knowledge.

Re: Exceptions...

[dsrtao]

No, I think you're wrong when you say "there are certain areas where more experience and specialization become critical".

*Every area* is going to benefit from more experience and depth. And that means that it is rare to hire someone who has that experience and depth. Instead, you have to invest in them until they do. Six months is barely long enough to get a good grasp on how things fit together in a major project.

Re: Exceptions...

[jducoeur]

Yep. I actually had that in mind when I wrote the rant -- my time at Looking Glass taught me that, eg, 3D renderers are *not* a generalist function, but instead require deep math background and a fiendish devotion to optimization.

That said, specialist fields are *relatively* small. It's true that you need people with specialty knowledge for game simulators, device drivers, database implementation, and that sort of thing, but I'd be surprised if all of that amounts to more than 10% of the total programming out there.

Indeed, the number of times that I've looked at something being done at a company of mine and said, "That requires specialist background, and is out of my league" have been pretty modest. There was the physics and rendering work at Looking Glass; here, some of the high-level data processing stuff requires a *bit* of specialty knowledge about doing it efficiently. Several jobs have benefited from having some depth in security, and I've built that up gradually.

But for most projects, even ostensibly "special" ones, the necessary knowledge is mostly pretty general. You have to be comfortable at multi-threading for a *lot* of domains, but IMO that's always a good skill to have. All in all, most programming turns out to be mostly just programming...

[corwyn-ap.livejournal.com]

Should I send you a resume?

[sichling.livejournal.com]

I totally agree!

Incidentally, if you hear/know of mostly work-at-home stuff, I have a friend (lots of experience, in the grayer category) who might be interested.

[metageek.livejournal.com]

ITA, famously, uses Lisp. When I interviewed, only one of the interviewers did anything to check my claim that I had used Lisp slightly. (That one was a doozie, though—he handed me a printout of a function in Common Lisp and asked me what it did. I stared at it for about ten seconds, panicked by the DO loop—and then recognized the shape and said, "Oh, this is quicksort!" That was enough for him; he waved away further explanations and went on to more important questions. But I'd've been lost if I hadn't seen quicksort in half a dozen functional languages.)

[unicornpearlz.livejournal.com]

That's freaking awesome.

In HR support interviews, I've been asked to name 3 state laws and 3 federal laws. Same idea.

[dragonazure.livejournal.com]

THIS. Well, mostly. A good programmer should be able to adapt to any programming language you throw at them. The deciding issue for most managers is "how much time do I allow for the programmer to become proficient in the platform we use".

[jducoeur]

Yep, but I think that issue is often grossly overstated. A weak specialist will get up to speed more quickly, but will be a long-term drag on productivity; a strong generalist will need more ramp-up, but in the long haul will be much more useful.

Or to rephrase that in practical terms: hire specialists as contractors, and generalists as employees. Not always -- there are certainly exceptions, especially if your business has particular specialty needs -- but more often than not, that's the right tradeoff...

[umbran.livejournal.com]

You might be forgetting one of the purposes of such requirements - first stage weeding.

Maybe this isn't true specifically for software engineering in Boston right now, but in general, we are still working with 9%+ unemployment, so the market is still flooded with folks looking for work. While those requirements aren't technically necessary for the position, they are usually required for the person who is dong a first pass on the resumes. When you have hundreds of resumes, you need *some* criteria to cut down the list of applicants to a reasonable size.

[jducoeur]

On the one hand, I understand that -- I'm well aware of the flood of slush-pile resumes one can easily get. (My boss at Convoq listed a position on Monster exactly once, and regretted it horribly.) OTOH, my observation is that it's most often the wrong criteria.

I seriously mean that I (speaking as our UI Architect) don't *care* whether a UI programmer has Flex experience; I don't even care all that much whether they have UI programming experience, although that's mildly helpful. I care enormously whether they have a proven track record of developing good software; can work independently; have a curious mind and a passion for improving themselves in programming; understand the common underpinnings (ranging from design patterns to refactoring to threading to unit testing); *enjoy* programming as an artform; and so on. It's easy to teach such a person what they need to know for a particular problem; it's hard to teach a weak specialist how to program well.

*If* the initial weeding produces enough candidates that some will have the above criteria, then that may make sense. But I've observed that a disturbingly large fraction of people who self-identity as "QA programmers" or "UI programmers" or "Web programmers" or such are basically lousy programmers who happen to know a library. So this style of weeding may wind up throwing out most of the *best* candidates, due to incorrect focus. You can wind up with a more tractable pile, but all of them bad.

And just to underscore this: that slush pile is typically made up *heavily* of these people. The really talented generalists are the ones you have to search hard for, because everybody wants them. Crappy specialists are a dime a dozen, and often the first to get laid off when times get rough...

[unicornpearlz.livejournal.com]

In my experience, the slush-pile from Monster or Careerbuilder can generally be made smaller if the right posting is put up. What I mean is be direct, be succinct (even if that means you're not putting what programming languages you need up there). Say what you need, what qualifications the person MUST have (if any) and then put these lovely little words: "Those who do not meet these criteria need not apply."

Sounds hokey, right? Well, I can honestly say that in a place where unemployment was over 13%, we were hiring for a mid-level administrative assistant to work with 1 director and support her in 1 area. We got 13 resumes from Monster and 11 from Careerbuilder.

We found our top 5 candidates lickity split and had someone hired within 2 weeks.

It's all about the verbiage.

[umbran.livejournal.com]

On the one hand, I understand that -- I'm well aware of the flood of slush-pile resumes one can easily get. (My boss at Convoq listed a position on Monster exactly once, and regretted it horribly.) OTOH, my observation is that it's most often the wrong criteria.

Well, if you can find a way to state the right criteria in a sentence in the req, such that it's presence on the resume verified in a 30-second visual (or machine-automated) scan, and have it verifiable in a short question in an interview... well, I think that's probably HR's Holy Grail. Write a book on it, sell it for a bazillion dollars, and retire as a wealthy philanthropist.

The thing is that the qualities you actually want are simply not well-screened for on a sheet of paper, or even a single interview. They are intangibles only provable through longer-term examination. Until we have brain scans that can test for it, I expect you're pretty much out of luck.

On being semi-management ...

[rippah.livejournal.com]

I am semi-management myself, having direct yes-or-no over who works with me and under me. I am one of the principals of a small startup company, and the two founders being the CEO and the CTO have been convinced of the value of hiring what we call 95% people.

Because we are so small, and because we are solving really hard problems in our products that no one else in the world has solved, we need people that are capable of solving any problem that we throw at them.

Yes, there is room for specialization, and some of the problems that we solve are specialized. But what is needed is Programming Ability and Being Very Smart and Being Driven.

Currently, we use Python, Ruby and Clojure. I am personally fairly language agnostic, but use Python for my particular projects. The two people that I have hired directly are able to handle tasks such as writing a Windows kernel debugger from scratch, writing a userland library that can manipulate NTFS volumes directly, or do expert system analysis on classifications of data.

These are all projects that we have completed and continue work on. These are not projects that can be classified as being familiar with any language or another, but to borrow a word from Heinlein, require grokking computing at a deep level.

Fantastic

[unicornpearlz.livejournal.com]

This is a fantastic rant that I actually want to send to people I have worked with before. This is what I tried to tell them when they said they need every programming language, when really all we needed was HTML. But, would they listen to me? An HR specialist who used to be a programmer and hangs out with programmers and was taking the training for my certs in SQL/Oracle & CISCO? No. Why should they? I didn't get those certs, so obviously, I know nothing.

Actually, this rant can be used for any specified support position. Do you have marketing experience? How many years have you used Sage ABRA or PeopleSoft? Do you have customer service experience?

Anybody can answer yes to all three and be able to 'get by'.

Marketing - do you drive, look on the internet, read email, shop, read, watch tv or interact in the 21st century? Then guess what, you have marketing experience. Sage ABRA/People Soft? Just HR database programs. If you can figure out a database or have ever used Access, you're in. What about customer service? Have you ever interacted with anyone ever? There you go, you know how you like to be treated and how others like it too.

It doesn't really matter (for support positions) what your training is IN. What matters is that you're malliable, want to learn, are open to new ways of thinking, and are able to grasp ideas in a second while watching people interact with other people. Ta-Da!

But, shhh... don't tell the hiring managers that.

[zachkessin.livejournal.com]

So true.

I actually did OK in the slush pile last time around but got my current job by giving a talk at Sayeret Lambda on JavaScript as a Functional Programming language.

I am working on being more of a generalist.

[jducoeur]

Good subject for a talk. Having spent much of the past two years working in Actionscript (which is basically ECMAscript 4), I've come to respect how much functional style I can easily use in it...

[zachkessin.livejournal.com]

The talk went well and was well received. If you are interested I think there is a video somewhere online.

Actually for functional programming Coffeescript is even better. I have been using Coffeescript with underscore.js and I don't think I have needed to use a loop in ages.

I am also working on an ebook about using Monads in JavaScript.

[jducoeur]

Intriguing -- I'd definitely like to see that, once it's ready. (I'm still at that mid-point where I *kind* of get Monads, but need more practical examples to drill them into my head...)

[zachkessin.livejournal.com]

I am finding that Monads are one of those things where they are just not going to make sense until you have written a bunch of code with them. (And I think once you get to that point you will wonder how you ever lived without them.

I get the Maybe Monad and the Container Monad. The State Monad and a few others leave my head spinning.

If you would be interested in being a tech reviewer I can probably get you a some free e-books. It is being published by O'Reilly

[jducoeur]

I am finding that Monads are one of those things where they are just not going to make sense until you have written a bunch of code with them. (And I think once you get to that point you will wonder how you ever lived without them.

Yeah, that's my impression. (Much like most of functional programming. Having gotten used to lambdas and closures, languages without them drive me *crazy* nowadays.)

I get the Maybe Monad and the Container Monad. The State Monad and a few others leave my head spinning.

Maybe I find totally obvious; Container and State I *kind* of get, but not quite. More generally, I don't quite grok the abstraction of Monads yet; that's what I'm trying to get to.

If you would be interested in being a tech reviewer I can probably get you a some free e-books.

In principle, yes, but I'm sufficiently over-stretched right now that I shouldn't volunteer -- too high a likelihood of dropping the ball...

[zachkessin.livejournal.com]

I hear you on the overstretched part. I will let you know when it is going to be published (Probably Jan-Feb)