Hiring Good Programmers Matters 681
Doctor O writes "Joel Spolsky (of joelonsoftware fame) has some good points and fun with numbers on the quality of programmers and whether it is more profitable to go with cheap or good programmers. His point is that a good programmer will simply create code of a quality that average programmers never can create. An interesting read."
The answer depends (Score:5, Insightful)
versus (Score:5, Insightful)
- There isn't a need to go and ask simple questions all the time around.
- Development experience gives a 'mental' outline of what the end thing will look like
- Intelligence comes handy when one is 5 level deep in a nested function (which can't be simplified) and trying to add another 2 levels at once.
Cost of Quality (Score:5, Insightful)
My experience with this is in the IC design part of the world, but the rule remains: you're better off with half the people but good ones.
If you want to add bodies, let them do review work. It actually does contribute to quality, and has the added benefit of making better engineers out of the reviewers (and, IMNSOHO, of those who know that their work is going to be reviewed, too.)
The cult of the elite programmer (Score:3, Insightful)
Re:The answer depends (Score:5, Insightful)
Yeah (Score:1, Insightful)
Who is Joel? (Score:5, Insightful)
I suppose, of course, that the same could be said for most tech journalists, most of whom would have a hard time compiling a source tarball. On the other hand, usually tech journalists are reporting on companies' press releases, not writing editorials about software design.
Software application development comes down to... (Score:5, Insightful)
2. You can have it done cheap.
3. You can have it fully functional
Now pick 2.
Fast and cheap = means using average and inexpensive programmers and is not fully functional
Fast and fully functional = exceptional programmers and will cost an arm and a leg
Cheap and fully functional = means it will take a long, long, long, long time for the average and inexpensive programmers to build it
The timeline for the application, whether you need it tomorrow or can wait a few years, in addition to the budget determines what kind of programmers you can afford and need to hire.
- tokengeekgrrl
Re:Common Sense (Score:3, Insightful)
I agree. (Score:5, Insightful)
No art, however minor, demands less than total dedication if you want to excel in it.
This means that people who aren't dedicated to their profession won't properly trap errors, will always be calling functions wrong, and won't figure out what their users want. In a word, they won't excel.
If you don't want your software to have nasty bugs, hire good programmers. If you want your software to work beautifully, hire good programmers.
Articles from another world... (Score:1, Insightful)
hahaha...
No, wait. THis is sad.
buhuhuuu...
I'm a pretty good (great) programmer myself and meanwhile I believe that about ~98% of all IT businesses here (in Germany) have business models that are solely made of _consulting_.
Here in Germany we take pride in not writing software ourselves anymore. We sell the software of other ppl from other countries while we train our social skills in never ending discussions.
Consulting might earn some money as long as there are customers. But ppl who had not already a computer at the age of ~10 (or younger) like us are getting fewer every year. What money will consulting earn in 10 years? Consultants will be reduced to what they are: "Installation Wizards"
That's it my friends. Stop your CS studies. COnsulting is just not worth it. Sit in front of your computer and write code with passion my german friends and some day there might come a feary from EA or something and take you with her to Vancouver/Canada where you'll get your own little box with computer and monitor.
But please, don't believe that someone here in Germany is really looking for a good (or great) programmer anymore. Some might have a job. But are they coding? A Portal? - Bah, RSS will kill that and even T-Mobile has portal-free handies now with google.de as first page.
I'm german and I know our IT branche has lost it's balls.
One remark I do not agree with... (Score:5, Insightful)
I agree with the first part of the statement but not necessairly the second. The reason is as someone who has friends in both worlds rarely does the "software house" ever care about your outside life. If fufilled means being challenged, constantly engaged in your work, but constantly on deadline death marches, always-on fire control, and no life outside of work I guess you can call that satisfied. Have a friend who works MS. LOVES his job, but everything in his life revolves around it and the insane hours he keeps there.
Work to Live, Don't Live to Work.
I respect the heck out of Joel but he seems to fall in that second camp. When the tale of your life is told make sure its not about the code you cranked out but the lives and people you touched.
Yeah, but (Score:5, Insightful)
This is my curiosity... (Score:5, Insightful)
Does every "good" programmer have a degree in computer science? Are there exceptions? How can a programmer who might be "average" GET to be a "good" programmer? Can mediocre programmers be MADE into good programmers? This guy seems to be suggesting that it's ok to continue the cycle by doing NOTHING to enhance the abilities of these mediocre programmers. What about hiring a couple of good ones, and then some others who can be ACTIVELY mentored? Isn't that how some other professions work? What is medical internship all about? What about the journeyman status in the building trades? It's all about mentoring and moving people to the next level of expertise.
That's because it's a craft, not engineering (Score:5, Insightful)
Software is much the same. A true craftsmen of the art will produce code that is so tight, so functional and so spare that it is nothing short of beautiful. When was the last time you made something beautiful? We all get the warm fuzzies from time to time when we think we've done good work, but how can you really tell?
My view is that software engineering courses are all very well (not exactly a waste of time), but they might perhaps be the wrong way to turn out good programmers. Perhaps something more like the traditional apprenticeship would serve better - mentoring by someone who is already a craftsman "well versed in the art". I guess the main drawback of this is that most good programmers are often terrible teachers, but that might reflect the lack of a tradition in the field.
The full saying is... (Score:5, Insightful)
Let me guess... (Score:3, Insightful)
Seriously though, it is very non-obvious to a good deal of IT Managers. When you perceive software development costs as ultimately a burn on revenue, their conclusion is that you need to minimize said costs (much in the same way that you would seek the lowest-priced landscaping or office-cleaning staff).
Re:That's because it's a craft, not engineering (Score:3, Insightful)
Hiring Anybody (Score:1, Insightful)
From a corporate recruiters point of view, you have an avalanche of resumes of people with all amounts of relevant experience. Standing in line, I checked out the resume of the guy in front of me. I realized that if he and I were to sit down to argue as to which one of is most qualified for this job, we wouldn't be able to convince ourselves.
Every job listing states "excellent this, excellent that". Every candidate claims they are bright and their degree and experience is highly relevant. One person I talked to told me that he found his last job after his 40th application.
The entire process is a huge blur. The only thing that is happening is HR spinning the wheel until the candidate's acronyms are a 1-to-1 match with the job description. And they can do that. There are a ton of candidates.
A few of the HR people I talked to thought I would be a possible match for a certain kind of job just because of an acronym I mentioned. I didn't want to tell him he was out of his mind (if he could read my resume and understand it, he'd realize that I'd rather die than take that position he mentioned). I realize that they cannot read, nor do they understand what is written, but they have to solve this problem.
Nobody (except the very few) care about how good you are. "Good" means "risky" sometimes. They'd rather take the safe bet and sleep comfortably.
The Google strategy (Score:4, Insightful)
Re:And exactly what is a 'good' programmer? (Score:5, Insightful)
1. It has nothing to do with money. You can find good quality developers at both ends of the pay spectrum. In fact, I adamantely believe that the further you get towards the high end of the pay spectrum, the worst the quality is. Too cheap is bad too, but not as bad as too expensive.
2. A good programmer isn't limited to a narrow set of tools or technologies. He will pick the best platform and language/tools based on the application's needs. A bad programmer is one who only knows a small subset of technology and ends up forcing applications to operate within the confines of resources which limit stability, flexibility, performance and productivity.
3. A good programmer spends a lot of time researching the project before ever writing a single line of code. A good programmer demands the client/employer be as detailed as possible regarding the specs of the application. A bad programmer is comfortable with ambiguity relating to product specs. A good programmer, in lieu of getting detailed specs from the client, will create his own outline of what the application will involve and make it finite before coding even starts and make sure the client signs off. Good programmers don't tolerate ambiguity in specs.
4. A good programmer/sub-contractor is more likely to charge a flat rate for the development of the project than an ambiguous time-based wage (but all sub-contractors have to have provisions to deal with project creep and problem clients).
5. Good programmers expose bugs in applications and platforms. Bad programmers create them where they didn't exist.
6. Good programmers always exceed the client's expectations in terms of flexibility and versatility. Bad programmers tend to literally interpret feature lists and make program structure more finite than modular.
and last but by no means least...
7. Good programmers ALWAYS DOCUMENT THEIR CODE WELL! Bad programmers take great pride in making sure nobody can understand what they're doing.
The other side of things (Score:5, Insightful)
I tend to judge him by what he has said more than any experience with software he has written or managed. And really his blog has very good insights on software that other people ignore at their peril - this particular story is no exception to that rule.
just because he also has a bit of the marketer in him (understandable since he owns a business) does not automatically mean he does not know what hes talking about in regards to programming.
So would you disagree with his assertion that a higher quality developer can produce code that would never come from a mediocre one?
Re:Who is Joel? (Score:5, Insightful)
1. I haven't heard of him, therefore he must not be important and
2. He can think and write, therefore I read his log.
I definitely fall into catagory 2. I am not a programmer, but I work with programmers, request changes from them, and depend on their work. Insights that I gain from his website and his books have lead to more understanding on my part, and better results. That's good enough for me.
Good programmer = terrible teacher? (Score:5, Insightful)
This was an interesting observation:
Something I've found in many aspects of life is that the people who are really good at something tend to be able to explain it, clearly and accurately, to someone less experienced. This is true of almost any field I've ever studied, from mathematics to martial arts, from driving to dancing.
It's interesting that in Japanese, there is little distinction between being very good/experienced at something, and being a teacher of it. If someone in Japan asks you whether you teach programming, and you're the 20 year veteran Senior Software Engineer at your company, the answer is yes even if you don't teach in the English sense. It's simply implicit that by being good at something, you will be teaching those around you as you do it.
I think the difference between someone who's really good at something and someone who's just OK usually comes down to a depth of understanding. One can follow a cookbook of techniques, or regurgitate information they've been fed in the past. The other writes the cookbook, because they've understood the information and worked out how it all fits together.
A corollary of this is that those who truly understand a subject tend to be better able to convey their understanding to others. Because they can see it from more than one point of view, they can adapt their explanation and examples to fit the knowledge and learning preferences of the person they're trying to teach. Those who never reach that level of understanding can repeat what they were told when they were learning themselves, perhaps even in multiple ways they learned from multiple sources, but they can't adapt it, can't see it from different perspectives and present it in different and original lights.
Thus I'm rather surprised that you think most good programmers are terrible teachers. Most programmers may be terrible teachers, but I question whether a good programmer who is unable to pass on that knowledge is really that good at all. It's unwise to generalise completely, because of course teaching requires skills all of its own, but I've met very few great practitioners in any field who weren't also outstanding teachers.
Re:Can't Go Wrong (Score:4, Insightful)
Consider Paul Graham, who could be accused of writing programmer ego-stroking articles. They are both good writers, but I like that Joel (at least here) tries to support the theory. He doesn't say "Some programmers are fundamentally better", which is a fairly wide-spread folk belief, backed only anecdotally usually. Instead, Joel says "Are some programmer's fundamentally better? Here's some data that suggests just that".
On a seperate note, a lot of other posters here are saying "Who's Joel?" and "Why should I listen to some guy I've never heard of?". Well, that's a silly argument against whatever he might be saying in your article of choice. Remember that ESR was a nobody once; he seems to be primarily noted for writing the Cathedral and the Bazaar. Similarly with Joel: he's worked on a few software projects, though you may have never heard his name, and he writes well, and his articles make sense. To me anyway: you may disagree, but at least then you're disagreeing based on content, not based on "I've never heard of him so he must be some jackass upstart know-it-all."
Re:Cost of Quality (Score:5, Insightful)
It gets worse when outsiders above the project (say, a division manager that is not paying attention to the status reports) decide to listen to hearsay and water cooler talk and use that as criteria to bring more people in:
"The guys in the break room are bitching about the project, we need to bring more php programmers."
Next thing you know, this head guy is talking to everyone except the actual team that knows what is going on.
This happened to us less than a month before delivery. For real. We found by accident that the boss was concerned and was getting ready to shop around for extra PHP people. Small problem: we were not having PHP problems. Our problem was a hosed CVS repository, which is what we were overheard bitching about while making coffee in the break room.
When we told the boss that there was nothing wrong with the code and we were less than two days behind our schedule (which is much more agressive than his) he almost shit a brick.
The lesson? Don't bitch about technical stuff unless it is a controlled environment. We now keep our bitching for our daily walk to pick up lunch. The odds of someone from the office overhearing us and getting half of the information are pretty much nil.
BTW, the boss still came up with a good idea for bringing extra people, since programmers are not needed. He thinks we can bring temps just to do grunt work like filling a bunch of web forms, etc.
Moron (Score:2, Insightful)
In the process of moving the skill to the algorythm designer you've made the whole process that much worse. Now the algorythm is being designed by someone who likely has'nt written much code with the current generation of tools, losing all sort of optimizations that CompSci (with a math view) people just can't see.
Programming is an engineering process. In engineering you always operation with incomplete information. If you pretend to have complete information you will screw yourself.
IMHO all self described 'star' programmers should start their careers working for a couple of years maintaining other 'star' programmers work (by that I mean crap code written by someone who thinks their shit don't stink). Arrogant little shits should not be ALLOWED to do design untill they learn humility. This is best accomplished by throwing them into a project that they could not possibly complete unassisted. 'hello world' is usually close to complicated enough.
Call it paying your dues, or call it completing your education.
You get what you pay for (Score:1, Insightful)
I had a client who was upset about my hourly rates because he was comparing me to offshore programmers who were working for about 1/8 of my rate. But his project was a mess. There was no separation between the View and the Model (ie, there was HTML thoroughly intermixed with code). No one understood how the system worked. Code was being stored in database tables and then executed to render requests. The project was vastly behind schedule. In short, a lot of things were going wrong. He was just looking at the $/hour, not value/$. Value/$ is the only ratio that really matters. He's a smart guy, and has learned from his mistake.
One good programmer is more than equal to ten bad programmers. A good programmer will deliver this:
- Code that's an asset, something which adds real value to the business
- Code that's a product, in the sense that it is ready to be deployed both in-house and in other businesses, instead of code that is interwoven with infrastructure
- Code that is documented and comprehensible to others who get involved
- An organization that has internalized sane design and coding practices to make all of the above routine, instead of unexpected
Anyway, that's what I did for him, as much as possible. Hiring programmers who don't know what they are doing is like building a house with bad construction. It may look good but it's not worth anything.-----------------
mobile search [mwtj.com]
Re:The answer depends (Score:2, Insightful)
Re:versus (Score:2, Insightful)
Yeah, I'm sure it does. Or maybe that good inteligence should not be wasted on 7 level deep functions that need rewriting anyway?
The Linux Kernel coding style [lwn.net] does have an insight on this issue:That's such a bunch of bullshit (Score:5, Insightful)
Second of all, if you're five levels deep in the nested function, that's a good indicator that you're not good enough at software design.
What to do with all the non-genius programmers (Score:1, Insightful)
Unless you are google you may well not be able to recruit the best.
Another problem is it's very difficult to actually determine the quality of a programmer without hiring them and watching them work.
For the rest of us who are not in the top 10 percent are we just supposed to pack up and go home?
Re:The answer depends (Score:3, Insightful)
For new software product development, you might get away with that.
Writing software for business use, not a hope of achieving that.
Deadlines of "7 weeks away, because that's when the ads go on TV", requirements of "Has to do everything!", constraints of "No, we can't afford ", changes a week out like "we just signed an agreement, you must integrate with this whole new supplier"...
The only thing you've suggested that's really viable and sensible there is hiring good people. Although you utterly bollocksed that one by trying to link pay to project deliverables - do that and you'll get exactly what you asked for. That's never what you want.
Good people will cope with changing environments and still deliver good work. For once, I'm agreeing with Joel, badly as he did justify his argument.
Re:Good programmer? (Score:3, Insightful)
Excellent qualifications.
Someone who can look at the big picture and design the code and solutions to fit the big picture?
No, this is bad. Looking at the Big Picture is the manager's job, who can't let a Mere Programmer, even a Good one, do that.
Re:And exactly what is a 'good' programmer? (Score:4, Insightful)
1. It has nothing to do with money. You can find good quality developers at both ends of the pay spectrum. In fact, I adamantely believe that the further you get towards the high end of the pay spectrum, the worst the quality is. Too cheap is bad too, but not as bad as too expensive.
Maybe you are not guaranteed good programmers by paying alot, but good programmers still cost more. I just do not see how things could be different, except if you are saying that companies are completely unable to recognize quality.
2. A good programmer isn't limited to a narrow set of tools or technologies. He will pick the best platform and language/tools based on the application's needs. A bad programmer is one who only knows a small subset of technology and ends up forcing applications to operate within the confines of resources which limit stability, flexibility, performance and productivity.
A good programmer will not only think of the needs of the application when choosing tools, but will also consider the context he is in. Chossing an unknown and complex tool might well be a very bad idea, even if it fits the job perfectly. I realize that you might intend this to go under "the application's needs".
3. A good programmer spends a lot of time researching the project before ever writing a single line of code. A good programmer demands the client/employer be as detailed as possible regarding the specs of the application. A bad programmer is comfortable with ambiguity relating to product specs. A good programmer, in lieu of getting detailed specs from the client, will create his own outline of what the application will involve and make it finite before coding even starts and make sure the client signs off. Good programmers don't tolerate ambiguity in specs.
Most projects are not of the form "implement a correct compiler for Java" or something equally well defined. In many contexts, demanding exact specifications will result in endless preparations, and as soon as the spec is "perfect", requirements will have changed. Specifications change because needs change and the knowledge of the users and developers increases as the project progresses. This is not a bad thing, it is a very good thing, even if it can be annoying to the programmer. I think eXtreme Programming gets this right: get some code out of the door as quickly as possible so people can try it out.
4. A good programmer/sub-contractor is more likely to charge a flat rate for the development of the project than an ambiguous time-based wage (but all sub-contractors have to have provisions to deal with project creep and problem clients).
Specifications change so a flat fee is a bad idea for everyone.
Good programmers expose bugs in applications and platforms. Bad programmers create them where they didn't exist.
Good programmers are human, so they make mistakes too. Of course they may do it less frequently, but they still do it.
6. Good programmers always exceed the client's expectations in terms of flexibility and versatility. Bad programmers tend to literally interpret feature lists and make program structure more finite than modular.
Unneded flexibility and versatility can increase code complexity, introduce bugs, make the program harder to use in the common case and lengthen development time. It is much better to get the program out there in use quickly, and then implement just those things people actually end up needing. Of course, in some cases things can be made more general "for free", and then the good programmer will try to spot it and do that. Sometimes the flexibility and versatility is really useful og necessary, and only in those caes will the good programmer make the program that way.
7. Good programmers ALWAYS DOCUMENT THEIR CODE WELL! Bad programmers take great pride in making sure nobody can understand what they're doing.
I might agree, depending on what yo
Software houses that care about your life (Score:3, Insightful)
We live in different worlds. I have no experience of software product companies that try to consume you. On the contrary, in my experience, software product companies that hire "good programmers" are conscious that they "good programmers" are often "high performers" in several areas that don't include work, and need to be to keep happy, and thus productive. I guess that is because the people who consequently hire "good programmers" are similar themselves (not necessarily programmers, but of the same general disposition).
Drowning under a waterfall (Score:3, Insightful)
Not stupid, but naive. Waterfall models went out with the 1980s, because they didn't work.
If there's one great truth the software industry has (mostly) successfully learned in recent years, it is that successful projects must be adaptable, because requirements change. With the possible exception of things like military and medical projects, it's almost never helpful to fix absolute requirements up-front. Any project whose plan involves the words "finished before the first line of code is written" is pretty much doomed to failure before it even starts.
Yes, get user feedback early and often. Yes, get someone who understands UI design to do the UI design, and have someone whose role is to co-ordinate the customer view and the developer view of the project. Yes, give the programmers a clear idea of what you want and letting them get on with providing it. These are all good things.
But you have to do them more than once. Whatever process you use, whether you prefer lightweight or very formal, it needs to be iterative and go in cycles. Unless you're prepared to increase your overheads by at least an order of magnitude, nothing else works.
Re:The answer depends (Score:3, Insightful)
If only they cared.
You're all so cool (Score:1, Insightful)
Such as this thread. Remarkable coincidence that _everybody_ who posted happens to be an above average programmer.
Re:Don't comment, UNIT TEST! (Score:1, Insightful)
Tests can fall out of sync just like anything else. Discipline is an important part of all programming; so is being permitted by management to do your job. Neither are guaranteed.
Pruning redundant or false tests out of the test suite is usually just as much work as pruning redundant or false comments out of the code.
If the test is for a feature that no longer exists, it needs to be deleted at the time the code is changed.
If a comment is inside a function that no longer exists, it is automatically deleted.
Tests can't replace comments; in fact, a good test suite is itself often commented.
You need comments tying the test to the actual business rules it's attempting to verify, explanations for assumptions underlying the test, and how any magic numbers listed in spot checks were generated, and a justification as to why they're the correct value.
If your test code just says that foo() returns "bar" when called with "baz", but doesn't say why that's the right behaviour, it's not a very maintainable test.
In short code needs comments. Test augment, but do not replace, the need to explain your code.
--
AC