Recent craigslist internet engineering jobs, exclamation point:** Rock Star (Affordable) Flash Developer Needed ASAP!
** Seeking a rock star DBA for our production environment!
** Great Opportunity for a Rock Star Intern!
Before interviewing for these positions, be sure to comb your mullet and put a cucumber down the front of your spandex pantsuit.
On any given day, about 30 craigslist job postings in my area are looking for "Rock Stars". They are all really looking for "programmers", so, as I am about to enter the job market, I happen across them with increasing frequency.
I have to ask myself: How the heck did "Rock Star" eclipse "productive"?...and why haven't other industries caught on? Where did this trend come from?
No, Captain Klaa(pictured) has not been going around writing corporate dress codes, and yes, perhaps these HR departments are a bit too exuberant(see below). But that's not why I'm looking into this.
I don't have a problem with the use of the term "Rock Star" per se. I don't want to make fun of anyone. I enjoyed Spinal Tap as much as the next guy.
No, I'm looking into this because the trend really got on my nerves. I couldn't put my finger on why that was; so I explored it, and learned something.
I think these employers are trying to do two things:
1) Find programmers that are very productive (top 1% preferrably).
2) Imply that they will treat them well.
What I think they really want is to:
1) Attract programmers who know they are very productive and easy to work with.
2) Imply that they their team is productive and easy to work with.
If you have recently read Joel Spolsky, you may feel the need to replace "productive" with "gets things done" - I won't feel bad.
Thinking about how these employers can get what they want, I found what I really want: a productive, easy-going team. The heart of my problem with a team of Rock Star's is that it's so far from that ideal.
I asked roughly the same questions that employers ask. It was so informative to me that I would recommend it to anyone looking for a job. Here's what I came up with:
1) How do I know I am productive?:
Well, I can measure it.
The employers who are looking for rock stars have probably read that timely tome - The Mythical Man Month, in which the productivity of programmers is said to vary by an order of magnitude by skill alone. Well, this is one of the things that is still true in that book, but not in the way most people probably think.
Most people know how to measure their own productivity. They can describe what they have produced, and discuss it at length. "I developed X in Y weeks and I here it is", etc.
To most employers, your past productivity in the domain of the job in question is the primary measure of your likely future productivity.
Most people are o.k. with that. It's just common sense that you improve at a task with experience. This is hard to measure, but anyone who plays chess might assume that from competent to expert there may be 100 or 1000X improvement in most fields to be gained by experience. As it turns out, this is a highly contentious assertion. No one knows how much experience really has to do with it.
In absence of a candidate that is productive in the required domain and easy to work with, an argument can be made that a candidate that is trainable and easy to work with will do.
Trainable is usually a secondary requirement, and you can measure it the same way you measure productivity, based on past performance. In the case of a programmer out of school, trainable may be the only applicable requirement.
The more experience and intelligence the better. That's nice, but...
2) How do I become more productive?
Most people have a decent understanding of the factors upon which their productivity depends. It may vary from person to person and purpose to purpose. For me, right now, it consists of four things that I seek to improve upon daily.
Domain experience:
Produce more. Focus on one job for a while, and you will become an expert. I may be an order of magnitude more productive at writing support scripts or IVR applications than I am at writing web applications. At some point in the near future, however, I expect this situation to reverse. This just makes sense. I am working on web apps every day. If I want to get good understanding the core concepts of a framework and writing large programs in that framework, then there is no substitute for doing that.
Tool expertise:
Programming tools are made from software and improve productivity. New and better tools come out every day. If I spend time every day learning tools, I will improve my productivity. Commit to this, and you will improve.
Mental and physical health:
Stay healthy. My levels of pain, discipline, and energy vary based on my lifestyle. I get up every morning and excercise, clean up, hug my wife, drink coffee, and solve a puzzle. If I don't get a healthy start to the day, or if I don't take care of myself in other ways, I am sure my productivity will suffer.
Environment:
As a programmer, I work best either in a quiet office or pairing with one or more team members at about the same skill level. I can rank environments for productivity as well. The library is fine, a coffee shop is not so good, and home is right out - too many non-work distractions. Nothing compares to a serious, conflict-free, office work environment.
All I can do here is be aware of the quality of my environment, which varies from job to job. Experimenting with environmental improvements can help, as do these helpful techniques for tough environmental situations.
Kaizen.
3) How do we know when someone is easy to work with?
Probably the most important and tricky part of the hiring process, for both the employer and the candidate, is measuring soft skills.
If a candidates tech skills are not up to par, you have to train them. Fine.
Employees with very poor soft skills can destroy an entire company. Experienced employers and employees know this. So what we are looking out for here, are the bottom few percent of the employee pool in soft skills. No one wants a report or a manager like that.
My soft skills can be measured, and so can those of any company. We just ask each other how we handle situations that matter, and check references.
For my part, I have to ask myself tough questions: How many co-workers have I helped, how many have I hindered, what tough problems have I solved with them, what have I learned, and how can I improve?
So how can I improve? Aside from discussing this with past co-workers, knowledge will help: PeopleWare.
It can't hurt to improve, but I think most people are probably o.k. on soft skills. Still, the better adjusted the team, the better for everyone.
And now, a word to folks advertising for Rock Stars:
If you would like to project an image of your programming team, a gathering of Rock Stars is probably not what you want. Rock Stars are people who produce hit songs and are worshipped only as long as they keep pumping them out. A collection of rock stars are not likely to work together long.
Sounds like solo-superman programming while surrounded by dysfunctional sycophants and confrontational peers. Probably not what you meant. If that is really what you meant, then I suggest a different perspective.
I could suggest a different analogy...A construction crew is a closer match than a Rock band. It could be that your construction crew wants to design and build the next Guggenheim and drink beers after work, but it's a construction crew all the same.
Better yet, drop the analogies. Mention your team, your management style, your process and your product. Mention that you would like applicants to discuss what they have actually produced, providing examples where possible. Maybe lead with something like: "Highly productive team seeks C programmer" - or whatever actually describes your team and what you are looking for.
Mention that soft skills are important up front. This is a very good sign.
And...Rock on.
1 comment:
One important note on GrandMasterProgrammers (see c2.com wiki mentioned above), aka "Rock Stars?"
Before you hire one, you had better be able to track quality and functional output, and reward it properly.
You want that happy 10X programmer. You don't want 10X lines of undocumented, buggy code that doesn't meet your needs added to your code base for 6 months by a disenchanted programmer who subsequently jumps ship. It's hard to watch and has crushed more than one business.
Post a Comment