This comes up pretty often. Here's a sentiment that is often present:
I heard that to get excellent results I should do X,
but I don't see a really painless and trivial way to
do X. X doesn't seem practical.
When I work with non-coders to help them with their scripts or whatever, I commonly see all kinds of things that should be done better: simplify this, refactor that, etc. I have learned the payoffs for doing things the right way, and I try to pass some of these things on. Usually the response is "I understand. That would be a better approach." but then they go back to their old ways. They just want to get the immediate thing working and move on.
It's not at all surprising that advice from smart people with a lot of experience seems like a lot of work to those of us just trying to get today's problem solved. But take a step back and look at anyone working at the top of their field and you'll find them doing lots of things that are hard, involving doing things right rather than just getting a task crossed off the list.
"Wow, that chef keeps everything spotless and sharpens his knife a lot, and only uses the best ingredients."
"That master carpenter sure spends a lot of time caring for tools and doing a lot of other things that aren't cutting wood."
Why should hiring coders be any different, unless you believe that coders are a commodity?
A good engineer isn't one who designs a building with the thickest walls possible but with walls having appropriate thickness.
And generally, I don't think everyone at the top of their field necessarily gives the advise to use the absolute best tools and materials. A lot would instead give the advise to use appropriate tools and materials. A lot of good programmers can recognize that a quick but inefficient VB script can do better.
A lot of good programmers can recognize that a quick but inefficient VB script can do better.
Quite so. Some "best practices" only earn their keep once they become ingrained and automatic. Prior to that there's additional cost that only makes sense when amortized over a long enough time. If there's no real reason to expect that payoff then there's no good reason to make that extra effort.
In general, quite sound advice. But, to follow this analogy, you don't always need a top chef. You may just be working a hot dog stand, a McDonalds or a college Chinese joint. Not every chef is headed to a 5-star restaurant.
The terms of this debate often seem wildly 'provincial' for want of a better word. 99% of the people yammering on about 'hiring the best' don't operate companies that could hire the actual 'best' under _any_ circumstances.
Unless you can offer some combination of industry-leading salaries, major prestige, the opportunity to publish and/or work on their own stuff (if that's what people want), etc. you're not getting the best. Maybe very, very good. But not 'the best'. If you're not hiring for a Tier 1 research university or Google or Microsoft Research (in a different era), or paying massive salaries in the financials, ... think about it.
This isn't simply snark. As long as people aren't getting to hire Thompson or Knuth or Lampson or whoever, they are in fact making compromises of sorts and should be thinking hard about what those compromises mean, rather than just proclaiming that they only hire the 'best of the best'.
The main takeaway I got from Joel's essay was that companies whose focus is software need to hire better programmers. Maybe the 99th percentile is extreme and it should have been 9th. But it isn't difficult for me to imagine that the vast majority of programmers work at companies whose focus isn't software, and whose work is mostly things like connecting to legacy telcom systems. That vast majority of programming work doesn't need to be done by crack teams of algorithm gurus.
If your company is working in something more performance bound, such as CG animation, then you probably do need top programmers. Salary won't be the only way to get them, though. People with a true love of CS probably get bored with all the database driven CRUD apps.
In my experience, it's critical to hire a great "anchor team". Thereafter, the hires become a little less critical. The worst work situations I've seen or been involved with had a weak anchor team. There's an expression that "'A' players hire 'A' players and 'B' players hire 'C' players" and that's definitely true in small organizations. For larger organizations and the reason I think the anchor team is so crucial is that an 'A' anchor team can make 'B' players play like 'A-' players and 'C' players play like 'B' players. The infrastructure, thinking and processes put in place by 'A' players can make other less capable players much more comfortable and productive. Make sure your team is supportive of all members and everyone will be better as they play up to the high quality of the other members (when playing sports, I always play better when playing against people who're better than I am).
That said, it's certainly a matter of focusing the anchor team on putting in place excellent practices. Huge problems can still occur if you have a great anchor team but they focus only on solving their own particular problem. You wind up with the best authentication system ever and a broken payment system or with the most incredible sales pipeline ever and technology that doesn't match what was sold.
Clearly, "hire only the best" is impossible for every company and business model. Also, clearly, this discussion is mostly about capability, knowledge, etc; fit with the organization must always be superb.
I agree with this. Having A-players, recognized and respected as such may get the best of everyone. Lots of very capable people simply have had the bad luck of reaching teams without this kind of references and never were forced out of their "comfort zone". It's shocking when, having formed a great concept of yourself after years of practicing your craft, suddenly you find someone that outsmarts you in such a massive way.
These discussions often rank all hires from 1%-100% as if they all fit on one dimension. That is an unfortunate simplification.
I don't know what the right classification system is, but it's certainly more complex. For example, teams can tolerate a certain amount of new-but-promising talent, as long as they have guidance from experienced programmers. In fact that balance is important. Secondly you need people who can work together effectively. Both of these ideas indicated that you can only evaluate a hire in the context of the team they are joining. So arguments that "you can never hire the top 1%" add nothing to the conversation.
What I've found to be more valuable than the superstar programmer is the competent coder that writes clean, readable code, with comments, error checks, clear log messages, and tests. When one coder interviews another simply ask to see a sample of code they've written, any code, and then decide if they have a coding style you can work with. Once a coder is part of team of competent coders who are engaged with the project you then can use code reviews to help each other improve.
The differentiator to me is the SuperStar will figure out how to avoid writing a lot of the code Competent guy will write cleanly. A mix of both works really well when SuperStar can gently steer Competent in the less complex direction.
That's what I consider "the best", but unfortunately that kind of professionalism even rarer than the "superstar" programmer. Which is very unfortunate should you manage to hire one of those "superstars", since they need at least three of those guys to clean up after them...
A "superstar programmer" that doesn't "write clean, readable code, with comments, error checks, clear log messages, and tests" is simply not a "superstar programmer."
There are un-fun things to work on in life and if you are going to hire a "non-superstar" and have them work on a non-critical part of your company, it's not that bad.
If someone has a outside passion - say sailing and wants to just get a job to help them pursue it, more power to them if you can adequately utilize the talents in 30-40 hours versus a powerhouse 90 hr die-hard talent.
Personally, I find fulfillment in my 40-80 hr "day" job and then go pursue other fun activities; a lot of my (especially engineering - non-cs/ee) friends want a 30-40 hr job and some play power, others trade stocks, others play sports rabidly every evening - you must respect the personal motivations and find a way to align it with your organization / startup, if you cannot, then yeah, it's done.
There are a lot more factors to look into other than the level of proficiency in programming: I would hire a so-so programmer who have room to grow in addition to being able to follow directions and schedule over any super star.
There is a huge problem with the linked article. He asks the rhetorical question: "is hiring only the best practical" for every situation. The answer is of course no, you can get by with competent or very competent and don't need the absolute best in a field, which few can afford.
But the question asked is a giant red herring that has nothing to do with his stated problem!
His actual situation, as he explains, is not that he is trying to choose between the best and the merely excellent. He is trying to choose between the completely incompetent (the only applicants he has) and no one!
That is an entirely different problem from deciding whether or not to hire the very best.
I know of an investment bank that explicitly avoids hiring "overqualified" devs. They don't want someone rocking the boat. They just want drones in the back office IT dept, for whom they pay 2X the market rates. Geniuses!
There is one big problem with JS's paradigm of Smart and Gets Things Done that I never see addressed. It's right there in the title. If a programmer Gets Things Done, what does Smart add to the equation? Say you have a cat who habitually walks all over your keyboard and bangs out perfect code, every time. Do you really care?
No one would praise a program that takes 2 steps to do something that can be done in 1 step. So why does Smart and Gets Things Done get so much credit? I'd understand Gets Things Done and Gets Along much better.
If you've ever dealt with code that Gets Things Done but is not Smart, you'll know why it's in the title. There are a million ways to skin a cat with programming, and you can pick a stupid(er) way or a smart(er) way. I'd much rather work with the person(s) who pick the smart(er) way.
The "perfect code" part of your comment above implies smartness. Dumb people don't write "perfect code".
That reminds me I once came along code written like this:
function MakePrintable(nr as Int)
{
Str as string
if nr=1 then Str="1"
if nr=2 then Str="2"
if nr=3 then Str="3"
...
if nr=27 then Str="27"
if nr=28 then Str="28"
if nr=29 then Str="29"
return Str
}
This code worked in the program it was used in (it Got Things Done), but in a dumb way (lazy? ignorant?).
I admit this is a rather extreme example, but it provokes the universal feeling when you look at gravely suboptimal code: "What did the programmer think when he wrote this? Didn't he know that ...., it's so obvious!"
I guess it depends on your definition of "done". If something is sorta slapped together in a way that is hard to read/debug or non-performant, to me that's not "done". So perhaps it's a matter of semantics.
Joel addresses why he titles that in the book. People that aren't smart and get things done usually do "stupid" things, that someone else will have to come along and clean up. Here's a link to the post that discusses it: http://www.joelonsoftware.com/articles/fog0000000073.html
Oh I get that (did read the whole thing) however conversely, couldn't it then just be titled, "Smart" with an explanation further down that smart people know that they have to get things done or else it's just talk? I mean, you can redefine and contextualize anything, but I think if you promote a slogan as strongly worded as Joel's quote below, you have the responsibility to make it complete without a further explanation.
The #1 cardinal criteria for getting hired at Fog Creek:
Smart, and Gets Things Done.
That's it. That's all we're looking for. Memorize that. Recite it to yourself before you go to bed every night.
He wants us to memorize a short slogan, and that slogan, in programming speak, is buggy and wasteful (wasteful in the sense that I described above, and buggy in that a smart gets-things-done a-hole will single handedly kill your project). Gets Things Done and Gets Along on the other hand is complete in and of itself.
There are a lot of smart people who worry so much about getting things perfect, or doing things in a too-general way (i.e. "architecture astronauts") that they never actually get anything useful done, or they take far too long to get things done. These people often lack pragmatic business sense.
You can argue that it's a matter of semantics whether "getting things done" implies "smart" if you start defining "done" to mean more than what most people assume from the word, but it's definitely not true that "smart" implies "getting things done" even if you start to stretch meanings. There are plenty of people who are really smart, but who do not get anything practical done.
Smart people solve difficult problems that less smart people either (a) couldn't solve or (b) would take a relatively long time to solve. This is what smart people "get done". If you're lucky they'll even write the code for the majority of the system by way of proving to you that their idea works. (By definition it is easier to implement a skeleton solution than it is to explain the idea to someone who wasn't smart enough to originate the idea.)
People who merely "get things done" are conscientious in their attitude to work but do not have the spark of intellect that would help them identify quicker ways of getting a task done. This lack of spark also means that they will frequently say that problems are impossible to solve (or prohibitively time consuming to solve), whereas in fact a smart person would identify it as a problem that they could solve.
Example from my own experience within a government accountancy department:
- The person who merely "gets things done" happily spends two weeks each year calculating the cross-charging amounts between all the departments and eventually produces the correct figures.
- The smart person does the same task in 30 seconds using pivot tables and lookups in Excel.
I don't see why you always have to hire better people than you, or people at least as good as you. If you don't mind people taking some time to learn, you can just hire good problem solvers and let them learn as they work...
(1) Who will you learn from? Successively hiring only people equal to or less than the current skill level within the company inevitably leads to a gradual lessening of talent within the company.
(2) How will you stop the talented staff leaving? By hiring untalented people you shift more work onto the most talented. Since they also probably don't want to work in a place that is known for hiring people without talent they're going to be very likely to leave. This will exacerbate the brain drain within your company.
Oh, I'm not saying this a good way to aquire all your devs. Sometimes, though, if you just need to hire one extra person to write tests or do some supplemental work for the main devs, a rockstar is overkill.
It's a great thing to say, because how can anyone argue about hiring the best people?
The problem is, the statement is rhetorical, there is no "best" -- a superstar in a big bureaucratic organization might be someone who "gets" process and following through on certain things. In a startup or other type of company, there are attributes separating "best" from the rest. The process superstar from MegaCorp might destroy a startup!
At the end of the day, management adds value when they take a bunch of people with a base level of knowledge and helps them deliver whatever the product is that is being developed. The trick is finding folks with good work ethics who have the base level of knowledge that you need. There's no magic.
Clearly it's not practical advice. It's simply a reminder that just because the person can code does not mean they are worth hiring. For a lot of founders, they are under such pressure to produce output, the mere indication that a person wants to help them do that makes them not want to pass up the opportunity.
Startups have a hard time hiring because the benefits are not as solid as a large company, there is almost always not enough bandwidth to weed out the ridiculous number of bad candidates, and there are rarely hiring processes in place. However, for a smallish startup, hiring a bad person can literally ruin the company.
There are a lot more variables when hiring a person for a startup. For example, is there a strong cultural fit, is the person financially stable enough, is the person technically competent in the areas that need competence and able to learn new things, is he/she willing to spend what many regard to be extreme hours working and sacrifice normal aspects of their life, can he/she work quickly and also not cause friction, etc. Nobody is perfect and a lot of people simply don't prioritize their job or life this way, which is totally fine, but it's much harder for a startup to absorb those differences in the same way that a large company can. Therefore, there needs to be an emphasis on hiring the absolute best candidate you can find.
To translate this into practical advice: take a long time to hire a person (don't rush), only do so if you are absolutely sure that you want to hire a person, and even then hire them on a contract-to-hire basis, and be quick to let them go if things are not going smoothly.
Hire the absolute best you can find. Your goal should be to find people who are better than you at what you do. You need to hit every source of talent and try your damn best to get the best. Failing that, settle for someone who is only as good as you are. This is monumentally important with your first 4-5 hires as it sets the bar and sets the culture.
For job seekers:
They are interviewing you, but YOU are also interviewing THEM. If you are not passionate about what they are doing, it's probably not a good fit. If they are unwilling to listen to you give a better solution than the one they thought of, there's probably something wrong with their culture. If they are offended that you found a bug in their code or test, that's a huge red flag already.
Now, in big companies you can get away with coasting along, working as a simple code monkey. If that's what you want (not saying it's a bad thing), then you need neither passion nor aptitude to get a decent wage working an easy job.
If, however, you crave something bigger and more rewarding, you need to seek out companies that are passionate about the same things you are. In a market as hot as this one, there are a LOT of passionate companies looking for talented people (especially startups!).
I think this is inherited from the mathematical side of computer science. In mathematics, there's a strong sense -- and it's even true to some degree -- that all progress across the history of mathematics rests on the shoulders of a few great mathematicians, prodigies.
But you are not a computer scientist. You are a software engineer.
The accomplishments of engineering are not built on the inspired work of a handful of geniuses. They are built on the careful toil of tens -- hundreds -- of thousands of good enough engineers. Every day you use dozens of pieces of software and hundreds of real world objects designed by an endless army of good enough engineers. Engineering is not like mathematics. You don't create timeless works which will be a monument to your greatness for all time. You create something which will be serviceable for a few years, and then replaced. Even if you are perfect, the best, and create the best possible program or device, the world changes around you and your device is no longer needed or new computers change the constraints and let you write an even better program than was previously possible.
"Superstar" programming is a function of the talent as well as the environment. The standards set by the team during one's formative years has a lot of bearing on his/her eventual superstardom. I tend to look for motivation and willingness to learn, in addition to smartness and ability to get things done.
I think that as an 'interviewee' things are not on your side to begin with. You are the underdog, no matter what the interviewer or the company which is interviewing claims. Esp. the new graduates are nervous. I think @Developer Art at least gave an alternate solution in his interview, most folks will find it easier to accept what interviewer said.
Are your people better than the competition? If your competitors have great engineers, you may top talent to compete. If it is some forgotten nitch, you may be able to get away with less.
These types of articles seem absurdly generic, given the wide range of software complexity.
Like with everything else in life, get the best value for money. Sometimes the Porsche is exactly what you need. Other times, the Honda Civic is better for your requirements.
It's not at all surprising that advice from smart people with a lot of experience seems like a lot of work to those of us just trying to get today's problem solved. But take a step back and look at anyone working at the top of their field and you'll find them doing lots of things that are hard, involving doing things right rather than just getting a task crossed off the list.
"Wow, that chef keeps everything spotless and sharpens his knife a lot, and only uses the best ingredients."
"That master carpenter sure spends a lot of time caring for tools and doing a lot of other things that aren't cutting wood."
Why should hiring coders be any different, unless you believe that coders are a commodity?