Slashdot Mirror
Hiring Good Programmers Matters
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."
Are you trying to build a good application or a cheap application?
Life in Orange County
I hired a bunch of monkeys and I can't wait for them to write Shakespearian works!
Is it really that hard to find out that if someone who is good at what they do will do a better job than someone who is not as good? That seems to be common sense.
I guess it is just me... move along now, nothing to see.
... sucking up to the egos of your readers.
Yes, you're all great programmers, much better than all the others out there. Especially because you read my posts. We need more people just like you.
A good, very intelligent and experienced programmer can develop scores of times faster than the average one, because:
- 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.
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.)
Lacking <sarcasm> tags,
Have yee ever seen the programming of some websites? Ergo cheapo programmers.
Go to the w3.org and put Slashdot.org through the validator.
Joel's pretty sure of himself isn't he? Anybody else annoyed with these elitist experts?
With a sufficient number of bad programmers, and an infinite number of monkeys, you can create any program... perfectly. Just have the infinite monkeys get to work on fixing the bugs. You'll have a few copies of the program that are absolute crap, but eventually a winner will pop up.
I am scientifically inaccurate.
I'm not buying. Well, if it is true then it really it speaks to the failure of software engineering as a whole. I hire any other sort of engineer, I expect a certain level of competence and a job done to agreed standards. Not all engineers are created equal of course but the point still standards. This strikes me as revelling in a a form of failure quite frankly, there simply shouldn't be such a wide variation of outcome within the application of an engineering discipline.
Plays violent online games as: Nerfherder76
Isn't this fairly obvious? The thing is, in the code sweatshops that many "software" companies operate, high quality code is no longer the point. It's very much the same attitude that tangible goods manufacturers have taken, making a marginally acceptable product that is more or less disposable in the long run is the point. Get it out there, sell a few million units, and move on to the next version. If the product is too good, no one will buy the next version, and so good enough is the target. Companies that make a product you will never need another of go out of business.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
The problem is defining what makes a good programmer. While some firms hire based on price. But still a lot of others actually try to find good programmers. Thus the problem what makes a good programmer. Is it certifications which I think are Crap, is it years of experience which is just as bad judge, or is it formal education which is just like certification.
I like to consider myself a good programmer and most of my customers think so too. But am I really a top notch programmer there are a lot of programs out there which I see and marvel at and have great respect of the developers and I am not sure if I was placed on job with that request I would have came up with such an elegant solution. But on the flip side I see many programs so poorly done I am wondering how these people keep jobs.
So it brings up the question what makes a good programmer while it is the persons ability to use a computer to solve problems. It is harder to be able to judge.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Can the good programmer create code that compiles with a message, "Error: Too many errors." like I did in college? Now THAT is hard to do.
But those 'good' programmers will expect to be paid 3-5 times what 'cheap' programmers expect for neat little things only other 'good' programmers would really appreciate. For businesses, who only see the exterior of your program, if it works good enough for what they are paying they could care less about your neat and efficient algorithms, intelligent naming conventions, and proper use of OOP. When money is the sole reason why you are in business, shoddy workmanship or crappy programming is something you don't really care about as long as it gets the job done for the lowest price possible.
Unless this Joel fellow has some sort of long-forgotten historical notability in software engineering, I fail to see why his articles continually show up here. His company, which he repeatedly plugs in his articles, has put out two pieces of software -- a bugtracker and a content management system -- which nobody I've talked to has ever heard of. Does Joel have some insight into programming that everyone reading Slashdot does not?
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.
I used to read Caltizzle. I was a lot cooler than you.
ask yourself what will happen when people die on your bridge, job site, in your hospital because the code went wonky or prescribed 999 mg of something instead of 4.5 mg ...
...
And it does it with text that reads "Object reference not unlike paste error synk mast rtry input now (0,9):"
But, hey, it's you who will be on TV that night
-- Tigger warning: This post may contain tiggers! --
1. You can have it done fast.
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
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.
It is not enough to have 'star' engineers, you MUST have dedicated and motivated individuals. Being a good programmer does not imply willingness to work towards a common goal or play well with others. In some ways I would rather have a team of mediocre programmers who were reliable and worked well together than a couple of 'stars' who had thier own agenda.
Boehm and Yourdon have been talking about this since at least the 70's. Steve Mcconnell mentioned it in Code Complete. The data suggest the difference between the best and the average is at least 10 times.
Hiring Good Programmers Matters
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.
And if you hire any other sort of engineer, the standard you can demand depends on the engineer too. You're not going to be able to hire just any bloke who happens to have a BSEE and hand him the PCI-Express specification and then expect a low-BER implementation in a useful time frame.
Experience counts. Quality work requires skilled craftsmen.
Much more to the point, engineers are not cattle: you don't know everything you need just by counting heads in the herd.
Lacking <sarcasm> tags,
Best working conditions --> Best Programmers --> Best Software --> Profit!
WTF happened to the ??? step!
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.
bad programming saves money now. Good managers save money now, and use this success when moving on to a better job. In this day and age of lateral movement and massive layoffs, where odds are you're not gonna be at that job long enough for hiring good programmers to pay off, why bother?
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
What if you need to produce, say, a huge operating system, or a system requiring a million lines of code? (Open source is theoretically an answer, assuming the system is interesting enough to potential contributors.) You can't always use only good developers for a project. You need to go for the "long tail" effect.
XML UI Browser/Platform
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.
The point is that if your problem doesn't have the headroom to make a good programmer shine, then you don't need a good programmer. Any old joe will do. If, however, your problem is somehow "hard", then having the best pays off.
His point, I think, is that a lot of the good software out there *does* have the headroom to make a good programmer shine, but in fact it's still "joe's" who are being hired (see the AOL argument).
Personally I think it's because programming is a junction point between art and science - there's a lot of science and rigour in programming, but there's also elegance (in the mathematical sense) in most good solutions. Appreciation and production of elegance is a good definition of art.
Simon
Physicists get Hadrons!
I have always seen software "engineering" as a craft, done by craftsmen. There are too many unfixed aspects to be able to really call it engineering or a science. Of course it has elements of those, but it also has elements of art, and that's what makes it a craft. And just as there are wonderful craftsmen who can create a masterpiece of a beautiful chair from wood, there are factories turning out cheap Ikea furniture by the ton. Both might be perfectly functional in terms of parking one's botttom, but in a hundred years time no-one will be seeking out Ikea chairs in antique shops.
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.
Talented, capable, motivated people able to out perform people just in it for the money! Slashdot post available at your local terminal!!
Seriously, though, this has been said before by Paul Graham. This article talks about talent, as do some of his other essays
I simply must raise a point at the seemingly obvious statement that a 'good' programmer is so much better than an average programmer.
Lord knows that applies to artists, look at the paintings that Botticelli did of me back when I was still alive compared to the ones done all of those other greasy creeps.
But programming is supposed to be a science and a process. If you prepare a precision algorythm and carefully test it before coding with all manner of valid and absurd inputs, then it shouldn't matter what level of so called skill a programmer has when the coding proceeds.
Oh, you mean a 'good programmer' is one who by lucky accident gets working code without using developing a complete algorythm first? What do you guys do, design microwave ovens for a living?
There's no such thing as a good vs average programmer. There's only those who follow the algorythm and the lucky artists.
Thank you,
Simonetta Vespucci 1454-1476 Florence, EU
Sheesh.
Singing the praises of his beliefs based on reasonable logic and the apparent success of his small company.
I don't think his vision would really work if he had to appease public shareholders and had thousands or even hundreds of people working for him.
The guy definitely has insightful things to say sometimes. The self-congratulatory way he's done it this time is a little over the top.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
You can have your application built cheaply, quickly, or well. Pick two.
I don't respond to AC's.
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).
That guy is a blasphemer (or someone with a very low IQ, you decide). This sort of crap should never be posted on Slashdot.
I work in a large group of programmers of varying ages and backgrounds. I believe you can categorize programmers into 2 main groups.
The first, and the majority at our company, are school trained programmers. These are people whose main experience with coding has been either class related (where the emphasis is usually on theoretical applications) or employement related (where the emphasis is usually along the lines of "just get it done").
The second group of programmers, which I'm in, is the hobbyist turned professional. We are people that began programming for fun, and often program on weekends on side-projects. Data structures and interface definitions become part of our regular vocabulary, and it's often hard to talk to programmers in the first group regarding projects.
Also, from my own experiences at work, I can say that it's the smaller second group of programmers that end up carrying most of a software project, both in code output and internal design. Although the first group of programmers tend to do a better job at testing.
Given the fact that consumers are very well-trained to accept crap software and pay through the nose for it, what's the business case for the care & feeding of good programmers when mediocre programmers are so cheap and readily available? Unlike most physical goods it's difficult to judge the inherent quality of software merely from interacting with it as a user (especially when you're used to computers crashing once in a while anyhow). So why should a corporation pay megabucks for a Joel Spolsky (who no doubt is an excellent programmer) when Indians, East Europeans, or amateur Americans are available for a fraction of the cost? The code may be suboptimal but in market terms it's simply irrelevant.
'Groups' and 'Teams' may have their place, but they are not the fundamental unit of accomplishment. When allowed to proliferate unchecked, they tend to expand to the limit of available resources and then tend to stagnate. - HackNeed
Groupthinkers are great for implementation, if that is what you need, but if you want to do somthing that needs a bit of that which has not been done before, shoot for a Star! -IMNSHO
I just came back from the Santa Clara career fair. When you are looking for job, you can sorta guess what is going on in the market in general, but unless you meet your fellow job seekers and the corporate recruiters, you don't realize how much you are underestimating.
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.
Lots of tasks are complicated and complex. Electrical engineering (for example) could hardly be said to be straightforward. Indeed, thats why its called "Engineering"; it as about process as much as doing things with electricity. There is a reason why architects and structural/civil engineers don't put up buildings that fall back down again immediately after. Not every architect/struct./civ. engineer is made incredibly experienced either, but somehow they don't construct tottering powers of shit and then shrug. I think CE has to ask itself why it isn't delivering consistent levels of quality. Its a fundamental question and shouldn't be ducked through handwaving.
Plays violent online games as: Nerfherder76
Good engineers are ones who can come up with the best product possible, given those constraints.
Joel is saying that only the best products really matter, and so only the best engineers really matter.
All good points, but the data in Joel's aritcle shows that great programmers aren't necessarily faster than bad programmers (or vice versa). Joel was unable to find a meaningful correlation between completion times and grades.
That said, imho the main point is that good programmers produce better software. Given infinite time and/or money, Derek Smart could still *never* produce software as good as John Romero.
My first reaction was....well duh, then I read the article and it's pretty decent.
One recent concern at least in Banking is the use of cheap programmers.
The consensus after analysis was as follows;
1) Cheap Indian programmers are more likely have access to over 65% of the corporations entire on-line source code.
2) They Usually come to the US for training / assimilation and return to India with a few CD's of the complete source library.
3) CD's have no access or audit controls, no expiration date are not signed, dated or checked out.
4) A small suitcase of 5,000-10,000 cash can buy all the CD's from a collection of Indian programmers no questions asked with ZERO hesitation or reporting on the part of the programmers tested.
You get what you pay for.
Some one recently said, "Their will be no Digital Pearl Harbor",
I say you got another thing coming suxxor.
Recommendations:
Suggest your local news paper reporter take several small suitcases of cash to India and Buy most of the financial sectors source code.
Wikileaks, no DNS
Say what you like about this being dribble, but this is exactly what Google is doing, betting the farm on the long-term value of the cream of the crop.
Ummm, that ancient platitude is simple enough that it doesn't require elaborate explanation of all three combinations. That's why it's an ancient platitude.
Mr. Joel may write well, but in order to preach one must have a well-recognized professional experience.
I don't see this experience, therefore I don't give a flying f*ck about his insights. A mere ability to preach does not mean anyone will listen.
The unstated assumption here is that good programmers cost substantially more then average programmers. Salary TENDS to coincide with experience and business skills (negotiating raises, etc.). While skill no doubt plays a role, he is assuming a 1:1 correlation between salary and skill. While I have no doubt that the correlation exceeds 0, it sure as hell ain't 1.
You want the best programmers, no question. A great programmer is EASILY 4 times as efficient as a mediocre one (as his numbers suggest), and isn't 4 times as expensive (the unstated part).
However, you can EASILY spend more money on mediocre programmers. Talented programmers seem to want fun environments (which is the premise he started with, then dropped) and a chance to do cool things.
A friend was working at a company building tools for IBM DB2... he HATED it because it was boring. Most of the programmers were older, had families, and were there from 9-5 working on properly documented and tested code.
They didn't need flashy brilliance, it wasn't a consumer app, they needed correctness, which requires different skills.
Interestingly, his own article contradicts a core claim: software is winner-take-all and you need the best. In reality, most markets are dominated by one player (network effects plus marginal cost = 0 implies a single major player), there are MANY viable niche companies, LIKE HIS, that earn livings and reasonable returns to investors WITHOUT dominating the overall industry.
Fun read, no useful advice, total crap.
Alex
Damnit, I meant John Carmack. (why do I always get those two reversed?) I think this error sends me to geek hell.
must drill into memory...
Carmack==talent
Romero==hotty ex-girlfriend
1. You can have it done fast.
2. You can have it done cheap.
3. You can have it fully functional
And:
4. You can have done slowly.
5. You can have it buggy.
4 and 5 = MICRO$OFT WINDOWS
1 thru 3 and 5 = MICRO$OFT stuff again!
I can't believe that I was the first to comment about Micro$oft. Come on people!
Fallout 3 will suck.
...it's practically impossible to economically justify fleshing out the staff of a really large project exclusively with Lance Armstrongs. On the large (>1M SLOC) project for which I work, we use them in pivotal roles, laying out software organization, building templates for others to use, writing the really hard parts and such.
Not only that, but diffusing the leadership of a project amongst a large number of superstars may bog down the project more completely than trying to coax productivity out of motivated but less-capable minions.
YMMV, of course...
Based on the experiences I've had with totally shitty programming from various vendors the past few years, I think the problem is that the wrong people are coding. This is the result of various efforts to make programming "easy". By simplifying the process of coding, they've removed the dilligence of code inspection. In essence coders have been gelded (yes, had their balls removed) by these "easy to code" languages and IDEs. Show me a coder who can whip up C code in vi or with cat, and I'll show you a coder who is likely to have a handle on what their code is really doing. All this drag-and-drop shit is only doing one thing: it's dragging and dropping the quality of software into the latrine. People who "code" in Flash drive me up the wall. Flash sucks. VB sucks. Give me good old fashioned C or hell, even assembler. I don't buy into the notion that coding should be easy. It is a process of utilizing logic to get things done. That is never easy. Hide all of the logic behind cutesy GUI based IDEs and all we'll continue to get is shit code.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
... editors couldn't hurt either
Regardless of what software he has put out or what other projects he has worked on, his blog (JoelOnSoftware) has been read by many developers I've come across - at least the good ones...
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?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
So, you can make stuff of much higher quality than is possible with run-of-the-mill people. So what? If your customers/clients are focused on price and feature bullet points, it's a waste of time and resources to make it high quality. In fact, it's counterproductive - a high-quality system raises expectations and creates as much (or more) maintenance work as the normally crappy app the clients expected anyway.
You should never overdo anything. If you're constructing a walk bridge, making it strong enough to handle a freight train isn't good workmanship, it's just foolish. If you're making buttons and handles used in industrial automation panels, it's a waste to make them in a gold-plated titanium alloy. If you're making a drill that's expected to be run for 50 hours over the lifetime of the tool (fairly typical for home use), you would just be pissing away resources by making it last for 500 hours.
Same thing goes for software design and quality. You should not write _too_ crappy software, of course (where "too crappy" is situation-dependent) - but spending a lot of manpower, money and time on quality levels, features or extendability that will never be appreciated or used is just as foolish as the examples above.
Trust the Computer. The Computer is your friend.
It seems sort of pointless. If I'm a "good" programmer, I'm stuck that way. I can never be a "Mozart". Maybe people hiring will find it useful - look for the "great" programmers, don't go for a "good" programmer hoping he'll improve or that having lots of "good" programmers will make up for lack of "great" programmers. But as far as an individual goes, if you're good, you're good, if you're great, you're greatness is >> good. Seems rather obvious and similar to many skills.
That said, I think it is possible to improve vastly with practice and training. A "good" programmer might not be "great" but he can get close, in the same way practice and training can vastly improve anyone's ability in a sport. Just seems like he doesn't address this aspect at all.
So how often do you replace your fridge or your stove, or your house for that matter? Durable goods do have a market and some people are willing to pay a premium for it.
Think of a big hydro dam: It is constructed to last forever, since failure is simply unacceptable and repairs almost impossible.
Companies that build durable goods seem to be doing just fine...
Oh well, what the hell...
Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years.
Replace Saliery with Joel and Mozart with Paul Graham and the statement will still be very much true.
3.243F6A8885A308D313
If this article had been about offshoring programming jobs to non-1st world countries the majority of the posts would be about how you can't just replace "good" American programmers with "bad" programmers. It's not a cost savings!
But since this article is about how you only need the best programmers, most of the posts are about how elitist this post is and what an idiot this guy is for even suggesting such a thing.
Sounds like there are a lot of very insecure folks around here (*gasp* someone repeats something everyone else has known for years!)
Here is a bit of a dumbed down example. Build a program to build a prime number seive (boolean array) of one billion elements.
Novice approach:
Go to each position in the seive and check by modulus if it is divisible by a lower number.
Standard Coder approach:
Go to each position in the seive and check for modulus up to sqrt(currentIndex), because anything higher is silly.
Rock-Star approach:
Mark everything as prime, then foreach prime 2..sqrt(one billion)) multiply prime*each other remaining prime up to (one billion/prime) and mark it as composite.
The Rock star method is fast furious and brilliant. And if you payed really close attention it's ALMOST perfect. The problem is that you mismark a few items if you go from the remaining primes up to (one billion/prime) but it would take another Rock Star QA person to catch the logic flaw.
Storm
Math Nerd Note:
The Rock Star method works if you mark_composite(mult prime*(each remaining prime starting at (one billion/prime).DOWNTO.prime)).
You can do things cheap, good, or fast. Pick any two.
"Talent matters".
It's kind of taboo in our supposedly non-elitist society to say such things, but that doesn't make them untrue.
A person can go to harvard, spend a hundred thousand dollars on his education, and still be a talentless hack. I know; I've met that guy (No, N---, I'm not talking about you, don't freak out).
On the other hand, another person can go to a cheap, never-heard-of-it public school, and write good software effortlessly and quickly, on a level hacks can't even approach. It comes natural to a person like this.
Talent can't be taught. It can't be bought. It either is or it isn't present.
Again, I know this is a huge taboo these days.
But it's still true.
Farewell! It's been a fine buncha years!
While I agree with the point of the article, I don't believe hiring great people is possible everytime, however badly you may want to do it.
At any given time in the economy, there are only a handful of companies that have seemingly large monetary resources as well as time, to shuffle through a million recommendations and resumes, and funnel them down with hard questions.
When you are starting out (startup) rarely do you have enough time to wait for great people to come by and take advantage of.
On top of that, it is not always possible to get rid of mediocre people easily without taking a big hit in your plans.
While I respect all opinions, what is needed far more is not the advice on hiring great people, but on how to salvage sub-standard projects, lead mediocre people, manage a chaotic environment with limited resources and still come out succesful.
Anyone?
I don't know what you are bragging about, but your comments are pretty lame and no more. Yes you need smart people to make smart comments, but that doesn't matter on slashdot. Any Joe can do it.
Then we started noticing that his code was SIGNIFICANTLY larger than it really needed to be. Once more experienced people started checking his code, it became glaringly obvious that he didn't know what a loop was. He just duplicated code for as many iterations as was necessary.
Now of course, this was an extreme example of the difference between a good programmer and a barely adequate one, but you see the point...
Or 10 bad ones against an expert.
What's the result.
I used to be a top-notch programmer. I'm down to medium now. Sliding into management since I don't want to be a contractor and management pays more otherwise. Top-notch programmers don't get the respect they deserve.
That being said- hordes of drones + core of top notch is a lot better than "all top-notch" or "all drones".
All top notch can't agree on squat. They irritate each other about fine differences in equally perfect but different code.
All drones are much worse. They sometimes could not solve basic problems given almost infinate time. They need an expert to show them what they need to do- then they implement it.
Lots of drones are very good for huge projects- because top-notch programmers should be resolved for the risky, hard stuff- not the "grind it out" stuff.
My opinion- based on hmm... 31 years of experience. --- Former assembly language, cobol, fortran, pascal, lisp, oracle forms, rpg, c, c++, lately java, j2ee programmer- sliding into project management, status reports and meetings.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Another point to keep in mind that not all your programmers have to the above average, or even average. For example, we have a student helping out over summer. She just doesn't have the breadth of experience for us to trust her with architecture design or the most complex programming tasks, but there are lots of simpler, straight forward jobs that she can do. And working at around half my salary (per hour), she's a hell of a lot cheaper than hiring a graduate programmer with several years experience.
The article is right that there are programs that great programmers can write, that good programmers will never write, and the critics here are also right, that most programms can be written by good programmers. Simple. I would add that great programs are not only those which do something new and exciting, but also those that do something well known, but complex (like an OS, or a Word Processor, or an Air Traffic Control system), and do it efficiently, and without fault.
I'm a software visionary. I don't code.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Anyone out there who has used FogBugz can tell you that Joel should follow his own advice and hire better programmers.
The point is that you are better off gaining insights from somebody who is more recognized by the developer community. Joel's not one of them.
No matter which industry you're in, no matter what you do/make/whatever - hiring good employees matters.
If you're a car dealership - hiring good salesmen matters. If you're a home builder - hiring good architects matters. Things are not somehow 'different' just because we're talking about IT.
"Kelly" Johnson of U2/TR1 and A12/SR-71 fame felt the same way about aircraft design. His general rule was that you could get more done well in a shorter period of time with about 10-20% of the number of people in a "similarly sized and scoped" project. The key was finding the best talent and having management acting as a facilitator and generally staying out of the way.
He HAD to have a passion for his work.
No if, ands, or butts. Just that one thing has been the ONLY thing that I have seen that made a difference.
And its a HUGE difference.
This paradigm works in ANY field. Not just programmers.
If you are not passionate about your work, you are in the wrong line of work.
That is why I consider it SOOOOO important to find something to do that you LOVE doing it, even if you don't get paid... as its not long before others find out you do this, and want you to do it for them, and they will pay handsomely for it.
You think IT guys have it tricky? Try Auto Mechanics. That stuff has gotten so complicated lately that few people can get it to work if anything goes amiss thats not a drop-in/out replacement item, often leading to thousands of dollars worth of needless replacements billed to the hapless car owner.
Thats one of the things I am getting into. I don't need to actually fix the thing, I hook up a lot of homemade test equipment and find out why the car is not behaving the way it should, then let them make the decision of who lifts the wrench.
I don't have tools, facilities, or the mechanical inclination to get into engines, but I can hook up to OBD-II ports, coil ( timing ), and watch realtime engine vacuum, exhaust pressure, crankcase pressure, fuel rail pressure, exhaust spectra ( HC, CO, CO2, NOx, O2 ), engine radial acceleration, and engine temperatures with a thermal camera... and get a damned good idea of whats not right in the engine without ever cracking it open.
Right now, I am playing. The local community college just about lets me have run of the auto lab as my playground. For me, this is fun.
Right now, I don't get paid. I am just seeing if what I wanna do is doable.
When I get good at this, money will follow... but if I am gonna do it, its gotta be fun.
Here's another one I'd love to clone myself off to go play around with... Bodine/Lynx/Kinetic Art and Technology are just releasing a really neat motor design called a Segmented Electromagnetic Array motor. It works just like the voice coil positioner in our disk drives, but this one is laid out to work full circle. I wanna play around with one of these sooooo bad! Try driving a refrigeration scroll compressor just to see how efficient I can make a refrigeration process run if I can get full control of motor RPM and expansion valve using AVR microprocessors as controllers. Play around with R410/water heat exchangers to interlink irrigation water to dissipate heat. The way this thing is made, once I assemble such a thing, it should run damn near indefinitely, as well as maxing out its efficiency for all ambient and load conditions.
Or use it as a replacement for the flywheel, starter, alternator, and much of the brake in a car, leaving the mechanical brakes intact only for emergency backup. Brake shoes and belts wear out... magnetic fields don't. These are a flat pancake motor design...oughta make way for a really elegant engine design.
Yeh, maybe I consider myself to be pretty good. But I LIKE what I do.
I only have a BSEE. I don't have near the "documented" qualifications most "big company" types are looking for. But by golly, nothing in the electronic design arena scares me... I am in hog heaven with my test equipment and CAD systems, however "obsolete" the corporate types consider it to be. I know my tools like the back of my hand, even to things like knowing how much current my Triplett 630 sources when I take ohm measurements, or how my older Tektronix scopes are gonna load or distort the signals.
I find out I can "mentor" someone forever, but if he can't wait for quitting time so he can go play videogames, there is nothing I can do to pour any insight into the guy.
How does one find these kind o
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
I think it is sad because it is driven by money.. but there is a lot of examples where this is the case.
Cheers, A.
Blockquoth the AC:
Why? What's wrong with reading someone's opinion, evaluating it critically in light of your own experience and your other reading, and drawing what insights and ideas you can from it? It's like no-one's got a degree any more. :-(
Personally, I find a lot of the most thought-provoking articles I read aren't by big names. Big names can rely on having a big name, and the kind of sheep you're talking about when you say "developer community" will believe anything they say. It's the guys behind the big names who have to convince people using old-fashioned techniques like presenting facts and making logical arguments.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Somehow articles like this only serve to stroke egos. Any objections?
I can't believe I'm getting sucked into this. Sigh... Slashdot -- Junkfood for the techie mind.
OK, I read Joel's comments from time to time and sometimes he makes sense. This time he has revealed his naivety.
There are stages of enlightenment that a programmer goes through to one degree or another. Some will go through many stages; others not very many at all.
The first stage of enlightenment: I'm a good developer, but there are lots of good developers that I can learn from. I can't wait to learn from them.
Second stage: I'm a good developer, but most of the other developers around me suck. If only we got rid of all the sucky developers, we'd be going somewhere.
Third stage: I'm a good developer, but all the other developers around me suck. If I started a company with only good developers, I could make a fortune.
Fourth stage: I'm a good developer and I *thought* all these people around me were good, but they actually suck. Since all developers suck, I need to put an iron clad process in place to make sure they don't screw up.
[Note: sometimes stages 3 and 4 are reversed]
Fifth stage (the first stage with actual "enlightenment"): I suck. Everybody around me sucks. What the hell am I supposed to do? I guess I just need to improve myself (or become Wine grower in Oregon using the millions I made from stages 1 through 4 -- potentially Northern California if you managed to sell your processes from stage 4, or your "management" expertise from stage 3).
Sixth stage: Wait! Not everybody sucks (although I still do). There are a few (very, very few) people who have a handle on stuff. I'll try to learn from them.
Seventh stage: I still suck pretty bad, but I'm improving. Also, I've realized that many of those other sucky people were just mismanaged (i.e. abandonded and ordered to "produce") and misinformed (i.e. not actually taught anything by anyone who knew anything at all or worse taught by those people from stages 1 through 6). Most reasonably talented people can do amazing things if they are coached and developed properly.
That's as far as I go. However, I'm pretty sure stage 8 is "I'm totally sick of making fat cat asshole investors millions of dollars by producing completely irelevant toys that virtually everyone would do better without. I'm sick of watching people with great potential get ground down into stumps by greedy ladder climbing scumbags that fancy themselves as "managers" (or "directors" or "operating" "officers"). I think I'll become a waiter and write free software on the side.
Oh well...
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
I read somewhere (wish I could remember where) that really good programmers can be on the order of a magnitude better in programming than average programmers (in lines of code, time needed to write working code) and over the span of years, that ratio of better performance remains constant. Based on my experience this is probably close to the truth.
I want to agree with him, that the best coders are nessecary, but I don't quite trust the data. I can't seem to find the data he used. But I'm willing to chalk that up to my being lazy and his inside connections.
But even if the data is true, what does that prove? What you're looking for is people who can do things correctly, and do them correctly quickly. Time to market matters, folks. He esablishes that there isn't a great correlation, but if anything, we should recognize that the highest concentration of students in his plot are exactly in that low time / high score area. The lack of correlation isn't a proof of anything; maybe it's just random, and if they tried another experiment you'd all get the same patterns with totally different grades. For his theory to hold true, the statistics should show that there are people who can code quickly and correctly.
Finally, it's not like the iPod was awesome, and perfect in every way since the day it was made. They've been through several revisions, since the first one that made its own click noises without a speaker. More importantly, the original iPod was practically complete by the time Jonathon Ives got around to dicking with it. The GBASP is nearly as seemless, and you can still replace the rechargable battery with a little knowledge and a screwdriver. What propelled the 3rd gen iPod
was a huge advertising campaign and a bigger drive.
In this case, we're simply listening to Joel preach on about how important Egos and Personalities are to the computers business. I might suggest that he's got some investment in that opinion that clouds his judgement.
I Browse at +4 Flamebait
Open Source Sysadmin
TFA: Longest introduction to an iPod ad ever.
True. However, no matter how many times you explain that to your customers, they will want all three, and threaten to go somewhere else if you wont give it to them.
What eventually happens is that you (or someone other software house if you don't cave) will end up paying for item 2, or item 1 (in terms of contract penalties).
That's just the way it goes. If I could find out why it goes that way all the fscking time then I would start my own software house.
“Our opponent is an alien starship packed with nuclear bombs. We have a protractor.” — Neal Stepnenso
Yeah... and he used "safe search" for pictures of Angelina Jolie! What does this guy know?
it's about the requirements.
;)
Good requirements + average developers = working solution
Bad requirements + average developers = good luck
Good requirements + great developers = awesome solution
( this one is extremely hard to come by)
Bad requirements + great developers = project past deadline, eventually delivered through heroics
In The Programmers' Stone Alan Carter and Colston Sanger describe mapping, a cognitive strategy they believe explains the difference between average and excellent programmers. It was part of a course about gave at one time about improving one's skill at programming.
Is it not true that most of the cost of software comes from it's maintenance? If the code is created well from the beginning, it will be much easier to maintain in the end. Therefore: Good Code = Easy Maintenance = Less Expense
That not all engineers are created equal. You may think they are because they all have the same letters by their name, and similar resumes... but you would be wrong.
A good engineer will be more productive than 10 run-of-the-mill engineers. This applies to software, hardware, EE, ME, etc...
Often an entire product or company is held up by a core team of awesome engineers with a fleet of helper engineers to do the grunt work.
Is it really worth paying extra for better talent,i.e. ability to produce good quality software? In this job market the answer is probably yes since you can get talent fairly cheaply. During the dot com boom probably no since talent was really expensive and you could make tons of money producing crap or even nothing at all.
Some of the design and implementation of Fogbugz is a little... lacking.
We're currently trialling it and so far:
The interface is pretty.
Why were there no indices on any of the tables?
Parts of the code (asp) have frighteningly stupid design. Some of the comments comment on it (good and bad).
Perhaps the issues that count against it rose out of having coders who hadn't done database work/theory before? Don't know.
I still haven't made my mind up as to whether I prefer fogbugz or bugzilla.
GENERAL PUBLIC SIGNATURE (GPS) Any replies (derivatives) of this post must also use the GPS
Personally, I discovered I can't run with the tall dogs because my dinky little I.Q. of 135 just doesn't cut it in the world of high-volume shrinkwrapped code. The first quality of the best programmers I've met is an ability to deliver product on schedule, despite Dilbert-esque management that I swear to God thinks they understand "coders" and "coding." Most of these guys burn out fast, too. Some of 'em, like me, flame out, and never go back. The second quality of the best programmers I've met is the ability to think large -- to grok the point of the application being developed and to write structure that doesn't hide the meaning of the implementation. The best code reads like the Book of Revelations, and the best coders are very odd ducks indeed. Pay for them. They exist, and you're slitting your own throat not to.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
Its the problems we make for ourselves on the way to solving out original 1 that usually spell doom for a project/code/solution.
Mostly because of the (human) language we use to describe the original problem in 1.
And if you're unilingual, you've got a problem.
If you're unicultural, you've got a problem.
Really good programmers 'listen' before trying to apply a bunch of solutions which may turn out to be entirely inappropriate. (I once solved a programming problem by designing a desk for the data entry clerks. [It worked hand-in-hand with the dual-station manual cheque entry code I wrote. The code was easy but they couldn't figure out how to set up the work so that it could be used.])
Really good programmers see the objects AND see the relationships between them.
Really fortunate good programmers get to write to code to handle the relationships as well as the objects.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
"Plans could only be as good as the people who implement them"
No process could possible replace good programmers.
Don't believe in RUP.
Anyway good mentoring, focus, a good environment and common sense can improve productivity, indeed.
I took CS 323a...in fact, I took it in Fall 2001, making my times part of the COMPRESS01, (which we called encode-decode, and we had to learn how to do hard and soft links, as they called the same executeable), SHELL01, et cetera. The best part of TFA is where Joel discusses the assignments in 323a.....I still have my time.log files, and am shocked at some of the time figures -- although they were posted when I was an undergraduate, I never really paid much attention to the statistics...
/encode/foo/ directory and then calling it. His method of teaching things (YAGNI) was simply amazing....and it is sad that he isn't more well known. I still cherish my class notes.
As a side note, Stan Eisenstat puts CS kids through some crazy hoops. In the compress program, you have to detect how you have been called (Argv[0]) -- except you cant just look for "encode" or "decode" -- as one of Stan's favorites was putting the file in an
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
His points seem to be:
1) good programmers write better code than less-good programmers...
2) Always get the best...
Point 1 is obvious but Point 2 is a very bad way to approach a project. Should you need or expect the best garbage man to pick up your garbage? What about the best auto tech to fix your car? Okay, you say, these are non-creative tasks so they are not good examples. Well, then, do you need the best writer to write the docs for your software? In most cases, no. It's just a manual, and doesn't have to win a prize for literature.
Spolsky might like the 'best,' just as he might prefer fine wines or concours automobiles but for most things 'good enough' is the 'best' use of your resources. Besides, just try getting an Ernest Hemingway to write your manual...
As engineers, we are liable to our products. ...but not software engineers. Bridges, cars, etc., do not come with big huge no-liability stickers on them and limits of warrantability and merchantability ("replacement of the media").
Until states start licensing software engineers like they do real Engineers (those licenses do imply liability for design...), then you'll have a point.
Oh, and bridges DO collapse, but it's usually the fault of mother nature or other external forces (government entities who will not provide maintenance funds, asshats who drive log trucks across covered bridges exceeding the weight limit by 2-5x...).
Slashdot's new mantra:
Common Sense for Nerds, Obviousness that matters!
-David
You can become talented by practicing skills enough - the will to practice is all on you, though. I wasn't born understanding pointers or virtual functions, but man, when I discovered them it was so damn interesting I had to understand everything about them.
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
Particularly in a multi-user app (such as a web application) there has to be some engineering involved.
It is possible to write functional, tight code, that may be beautiful to look at, but that also does not scale well when it's slammed with 10,000 users at once.
Not only do you have to be smart in your coding, but you also have to know how to interpret load test results, use profiling tools, and other more engineer-ish things.
Often these load and performance metrics are part of the requirements, or at least they should be. To use the carpenter analogy, let's say the carpenter gets asked to build a custom piece of furniture that must be able to support the weight of a 100 gallon saltwater aquarium, while minimizing the weight of the furniture itself. He will be required to think like an engineer.
So, a true craftsman will also be smart in the engineering.
-CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
He's a homosexual communist jew.
"We have to be faster... better... cheeper... and REUSABLE..."
All the engineers I was with worked VERY hard to not laugh.
There is one way to deliver software fast, cheap, and fully functional -- don't write it from scratch. Instead, start with an existing mature project as your basis and customize it. (Assuming such a project is available, of course... but freshmeat and sourceforge have a lot of stuff in them, so it may well be)
I don't care if it's 90,000 hectares. That lake was not my doing.
his blog (JoelOnSoftware) has been read by many developers I've come across - at least the good ones...
"Good" can mean many things. Joel largely represents mainstream views of Windows and Macintosh programmers--the kind of views you might find among Microsoft Office, Microsoft Windows XP kernel, Safari, or even Mozilla developers. If you want to be like one of those developers, then follow his advice. If you think that there is something seriously wrong with that kind of software (as I do), then you would do well to read Joel's writings more critically and assume that some of it is bad advice. Thinking about those issues will still make you a better programmer.
Ah, but did you develop talent because you found them so interesting and worked so hard? Or did you find them interesting and work so hard because you managed to discover a talent you didn't know you possessed?
Farewell! It's been a fine buncha years!
I know your probably busy being stylish designers, 'good' programmers, writing your blog and what-not - but why don't you have a hyperlink to a products page on your companie's website? I remember a time not to long ago when there were lots of Great Companies with websites talking about how Great they were and how Great their talent was - but never saying what it was they made, what services they provided or what they sold. You wouldn't won't people to think your company was one of those.
Cheap and fully functional = means it will take a long, long, long, long time for the average and inexpensive programmers to build it
Unfortunately, cheap and fully functional just isn't an option--as your own example suggests, it'll take average programmers a long time to get to fully functional, which will not only require you to pay their salaries for a long time, it'll get you to market long after the competition has released their product.
Nothing is cheaper than senior developers. A good senior developer can produce much more code (covering more function points or whatever measure of external utility you care to name) that will be lower maintenance in much less time than a junior developer. But even the best senior developers only cost a few times what a junior developer costs.
Economically, it makes sense to hire as many senior people as possible, because they'll be ten times more productive at twice the price.
Blasphemy is a human right. Blasphemophobia kills.
Easily the funniest thing I've seen on Slashdot in
quite a while!
By the taping of my glasses, something geeky this way passes
sorry, can't find it now, but i remember reading an interview with steve jobs
a couple years ago, and he said something to the effect of what this guy is
saying -- that certain people are able to produce not just an equivalent amount
of labour of another programmer, but really good talented individuals can
replace 20:1 or 40:1 in what they can accomplish.
then when he built the programming team at NeXT (the parent of OSX), he
leveraged this fact to get a small group of the best able minds to produce
what a much larger group of less talented people could not accomplish.
if anyone has a reference to that interview, it'd be greatly appreciated...
regards,
j
Fire is HOT!
I'm not saying I agree totally with him, but generally I find myself really agreeing with what he is saying. And he is also on the forefront of saying software needs to consider social aspects of interfaces going forward, which I totally agree with. Some mundane details of his interview process or so forth I don't care about so much as long as I think his Big Picture views agree with reality more often than not.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
How about skillful programmers for more diffult or important tasks and less skillful ones for less difficult or important tasks. Do you hire a Queens Counsel to defend you on a parking ticket charge? Attention pompous self-important leet types, wake up to yourselves and stop spitting on your subordinates.
I lost interest in the article when he started going on about the iPod. He and I differ on the perception that choosing style over functionality is a GOOD thing. But then, that is not the point of the article.
It seems to me that he isn't really talking about good vs. bad programmers. The differences he brought up (Zen vs iPod, Winamp vs. Media Player, etc) have more to do with opinion and company culture than it does with technical superiority.
If you separate the wheat from the chaff, I think what he is trying to say is: "Surround yourself with competent and hard-working people, and you will succeed". And with that I couldn't agree more.
-R
Interestingly enough, this may be the reason why outsourcing projects fail often http://www.isteve.com/IQ_Table.htm
According to this study India has a mean IQ of 81. Although to be fair, this may be explained by poverty or nutrition.
The problem, in my case, is that I'm a wizard programmer (ha ha, and modest too), but I don't care to write code for other people. So I don't.
That's what they said about 50s furniture and the Bauhaus.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Lately, I've come to realize that management has a profound influence on code quality. Simply saying "let's just throw a bunch of great programmers at it" won't do. First of all, you're fighting the bell curve. On average, the programmer you hire will be... average. Well, not quite. They will likely "fit in" to your culture, and will perform about as good as everyone else on the team. Since management is responsible for the culture, it's essential that they do everything they can to make the team as productive as possible, otherwise, even the best programmers probably won't help, and if they do help, they'll probably last six months and then quit in frustration, having been made horribly unproductive.
In fact, I'd argue that a team can be made far more productive just by changing the manager. (Like that'll ever happen.)
2. You can have it done cheap.
3. You can have it fully functional
Now pick 2.
Madam, you are an optimist. I daresay most engineering projects are lucky to get one. ;)
The best way to predict the future is to create it. - Peter Drucker.
planning makes a great product. - your sig is my sig's bitch
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.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
And the voice did thunder from on high, and spake, "Yea verily, a handful of trained, competent workers can produce better code than 100 Elbonian crack monkeys chained to keyboards, though the latter be content to recieve bananas as payment." And the Pointy Hairs of the Bosses did turn white with the fear of wisdom, and they were blinded by the enlightenment.
How can Joel hire good programmers if he insists on using Hungarian Notation instead of a choosing a decent language?
thanks for deleting my last comment
planning planning planning.
-your sig is STILL my sig's bitch
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
Nice article about nothing. Made me rewatch "Dead Poets Society" - the chart method of defining a good poet.
By definition (Joel hasn't given any btw), a good programmer better than a pile of bad programmers. What is the price of a good programmer?
Obviously, a show-me-the-money cynic is a bad programmer no matter how awesomely he/she codes. It would be damn difficult to fit them into "best working conditions" and recieve profit.
The Boss needs some good programmers who would readily exchange some of their profit for the "Best Working Conditions". A couple drinks on a ferry with the boss praising their virtues (see article's photo) - that would do the trick. And the blog - PR is important for business. Also tell them the bad example of smb who pissed off programmers. The famous "corporate spirit technique".
"My technique is the best. My style is much better, Don't you know who I am."
Yes, yes, Joel, your stock is rising. And then comes M$ and includes its free version of the smart project management software with the stupid name. Amen.
Gotta justify your tuition to MIT? Anyone can take the professional engineer exams, just like you can take the Bar exam w/o having a JD first (like Frank Abagnale). (I worked with a state traffic engineer [yes, he passed the Professional Engineer exam... Hi, Ed) who's BS was in geography, not civil engineering).
From the National Society of Professional Engineers:
Licensure laws vary from state to state and are exclusively under the control of the individual state legislatures. But generally, the licensure laws for professional engineers require graduation from an accredited engineering curriculum followed by approximately four years of responsible engineering experience, and finally the successful completion of a written exam. Some states may waive the written exam on the basis of education and experience, but the trend is toward an examination requirement.
Though many states allow non-engineering graduates to take the exam on the basis of a long term of work experience in engineering.
#include <my_proprietary.h>
int main (int argc, char* argv[]) {
my_printf("%c%c%c%c%c%c%c%c%c%c%c%c%c\n",
0x48, 0x65, 0x6c, 0x6c,
0x6f, 0x2c, 0x20, 0x77,
0x6f, 0x72, 0x6c, 0x64,
0x21 );
}
After forty years of programming, was it worth it? Often I wonder. I've tried very hard to do good work, whether anyone cared or not. Sometimes it paid off. Sometimes it didn't. But always good work.
But I haven't had much of a life. I spent the Summer of Love in a mainframe computer installation. I've never married. Had a few girlfriends, but wasn't really into it. I'm not into nerd culture, either; I hate Star Trek, and haven't seen the new Star Wars. Nor am I a gamer, although I get royalties from technology in games you've probably played.
And not because I'm the sterotypical overweight geek. I work out, and took jazz dance for years. That's not it. It's just my destiny to program. Whether I want to or not.
Open source projects? Or commercial projects heavily rely on open source components? Software development model on FOSS is surely slow - lots of varying programmers working in their spare time that can sometimes take ages to achieve that holy grail of one point oh. However, once they reached it, it is usually very functional.
see topic.
I think Joel is arguing that, by having your average cheap programmers, you will *never* accomplish that "fully functional" stage, no matter how long it takes.
He is a good writer. He's been an avid ASP user. Since he worked for Microsoft he knows something of their older culture.
I've found over the years that CS grads tend to make things much too complicated.
Generalization is great, but it always seems that CS-degreed programmers always want to over-generalize and over-engineer their stuff.
What does this mean?
Let's say I need a function that adds two numbers. Pretty simple. Instead of just writing a function, CS grads tend to write a big function, body of functions, or a library that does addition, subtraction, multiplication, division, etc.
Then they'll forget to check the arguments, and it'll barf.
As an aside, I don't think I've ever on a project that didn't need to refactor code, even if that code was written with the intent that it didn't need refactoring. So why bother writing generalized, reusable functions that do more than you want when you have to rewrite them anyway next time they're used?
Good programmers ALWAYS WRITE UNIT TESTS so that they don't wast time weeding and pruning comments. Comments fall out of sync with code. Tests can't. If you can't figure out what between good test coverage and the code itself, it's time to rip it out and start over.
*** Sigs are a stupid waste of bandwidth.
A very good programmer in China, India or Australia will cost less to hire than a crap programmer in Silicon Valley.
Engineering is the art of compromise.
What is the definition of a good programmer? Someone who can write flawless code? Someone who can think up a solution fast? Someone who can look at the big picture and design the code and solutions to fit the big picture?
While the article is undoubtedly right in everything it says, the conundrum comes in finding 'only the best programmers' which of course presumes there are good programmers to which the 'best' are better. Sadly, finding a good programmer is something almost impossible, at least in Australia, and therefore the 'best' of a very mediocre lot, is still pretty damn mediocre. Oh sure, there are many programmers who _say_ they are good. But any code you would care to inspect has one or more major failings. It is either a) a hack of someone else's working code with the comments removed, and can not be supported by the programmer b) buggy and inefficient as hell c) the coding is so obtuse the writer can't even understand it all any more, and all to often d) all of the above. And yet, this does not prevent the so called 'best' programmer for holding out their hand for a six figure salary, working a 2 day week (sure, we all know what 'working from home' really means', and through their care-less attitude contributing to the demise of every company they work for. My tip on Australian tech IPO's is look at how many programmers are on the payroll, then divide their salaries into the start-up capital, and that will tell you how many month the company will last before another capital injection is needed. It is a very sad state of affairs if you ask me.
So have you used FogzBugz, or other products he makes?
I ask because it could well be the software is fantastic. I don't know myself never having used it. I do know from the travesty that was the ICO release that having great software does not make you a dominant player. Just look at Microsoft (cheap shot).
I would offer as evidence the continued success of the company that in fact, the software he produces is pretty good. Selling bug control software and making money at it? Let me rephrase that; He is a genius. Would YOU like to try selling bug tracking software when you are not Rational of some other mammoth company?
I know from personal experience that good programmers really can be 10x (or more) productive. In fact not having bad programmers around gives you a boost by default as you are not cleaning up messes. So it's easy for be to believe what he's saying, I guess you just need more proof.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Cheap and fully functional = means it will take a long, long, long, long time for the average and inexpensive programmers to build it
Even the average programmers would require at least an arm and a leg, when hired over a "long, long, long" period of time.
First of all, a good dev is not necessarily faster than a bad one. The bad one will do just enough to get by, badly. The good one will make a fucking work of art out of the features he owns and it will be a pleasure to maintain and extend his code. This usually takes more time than "just enough to get by" approach, but this pays off time and time again over the years.
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.
(2) The logic of this essay is amazingly confused... the tangent discussing the ipod essentially disproves his main thesis. He points out a very serious technical failing in a product which is evidentally successful for non-rational reasons...
All of that said, spreading the word that "we only hire the best programmers might turn out to be pretty good marketing.
Wow. I don't know what's more disturbing - that Romero was your ex-girlfriend, or that you thought he was hot.
"Ladies and gentlemen, the captain has turned on the 'Don't go there' sign..."
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
It's all very well to say that you should only hire the best programmers. But the fact is that these would be maybe ten percent of the available pool.
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?
True colors are revealed when one reads TFA:
I quoteth:
"When I'm not writing about software, I'm working on FogBugz: the smart project management software with the stupid name. Check it out now -- there's a free online trial. We just shipped FogBugz 4.0, a huge upgrade! Enter your email address to receive a (very occasional) email whenever I write a major new article. You can unsubscribe at any time, of course."
In post Patriot Act America, the library books scan you.
I think Joel is counting "speed" as well as quality as greatness. But actualy his data dosn't support that. He says bad programmers will never be able to do what great programmers can, yet those taking 77 hours on an assignment do just as well as those taking 8 or so.
autopr0n is like, down and stuff.
"His point is that a good programmer will simply create code of a quality that average programmers never can create"
Captain Obvious strikes again!
Is that if you don't know the name of a function, but know that it must exist it's very hard to get google to tell you what that name is. For example, use google to come up with a function that gets you the name of the user running a program on windows based on that programs PID (actualy, there are three functions you need to call to do this)
autopr0n is like, down and stuff.
You were Doomed...
Joel was the lead developer of Excel at microsoft for a long time, and he also had a hand in the development of VBScript.
Anyway, his articles are the main reason for his fame these days. His company also has a third product, CoPilot, that lets people fix software problems remotely.
autopr0n is like, down and stuff.
Cheap and fully functional = means it will take a long, long, long, long time for the average and inexpensive programmers to build it
It could also mean having a single, or small group of, exceptional programmers do it. For a complicated project you'll get relatively cheap (compared to having a large team of exceptional programmers), fully functional, and a long timeline.
Flying is easy, just throw yourself at the ground and miss. -Douglas Adams
She can write better code (amongst other things). It (almost) lies in the definition. So man, what's the point?
Ah, that's the point! What a great insight.
Sometimes fancy schmancy modular access routers and self-defending networks just can't defend against an idiot at the helm... see here for details. -m
I can't remember the last time I forgot anything.
(Think of Smart showing you the quarter-inch.)
Look at the graph on COMPRESS01. He says
There's just nothing to see here, and that's the point.
I look at it and I see a number of things:
The median time spent ranges from the bottom scores to the top.
The nearly top scores range from close to the least time spent all the way up to the most time spent.
The median scores nearly reproduce the full range on time.
Only the lowest scores seem to group closely relative to time, and they group at the median.
And that doesn't surprise me one bit.
What I would like to know is whether the guys with the high scores on COMPRESS01 tended to show reduced time on COMPRESS99. My guess would be that they would show somewhat reduced time, but there would still be a large range from quickest finish to slowest, some who finished COMPRESS01 quickly taking a long time on COMPRESS99 and vice versa.
There is so much covered in those overview-of-applied-algorithms courses that it's impossible for any student to understand all the examples well unless the student comes in with ten+ years of wide ranging experience under his or her belt. Although, for example, the concepts of parsing might help with compression, the libraries the student might have built wouldn't.
The high scores should all be considered the result of one of three things, gaming the system, luck, or spending too much time on the project.
And that is very much how things work out in the real world. Spolsky can have his iPod.
I think talent is usually correlated with motivation and desire to succeed, more than anything else.
You can become talented by practicing skills enough - the will to practice is all on you, though. I wasn't born understanding pointers or virtual functions, but man, when I discovered them it was so damn interesting I had to understand everything about them.
No, a talent isn't somethign you can aquire. You can have a lot, or very little but talents are intrinsic. You can have a underdevloped talent, you can lack a talent, but you cannot simply aquire one if you didn't have it to start with. I can sing poorly, I sang well before but my talent was underused and is not under developed. My sister can't sing at all, no matter how much she tried, it wasn't her talent. Motives and desires don't help if the natural ability is lacking. Some people think, eat, and breath algorithms, some people struggle with recursion. It's about the different make up of our brains.
"There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy."
I can't really agree with Joel. That cartoon cat was really funny sometimes.
First of all, Joel's metric of what is a "great" programmer seems to be how fast they can crank out code.
So is programmer Mike really a great programmer if he's cranking out a thousand lines of code a day, but its unmaintainable spaghetti code, and he has a personality disorder so when his girlfriend dumps him he goes AWOL for a few weeks, and he doesn't get along with others, and his domain knowledge is limited to being a "great" programmer for certain types of projects....?
I call bullshit on his drivel.
... he is a total moron in regard with the movies and iPod :)
When working in a group it's the productivity of the group that counts - not the amount of code that a single member can dish out. And to a large degree I find the group productivity to be unrelated to the individual coding skills of its members.
A good programmer helps develop an atmosphere where:
- It's encouraged to ask for and give help.
- It's encouraged to ask and give design advices.
- It's encouraged to be proud of something clever you made, demonstrate it at the whiteboard and expect your fellow developers to listen.
- It's encouraged to criticize the work of others in a positive way.
A bad programmer then? The guy sitting in the corner who thinks he's a genius(and accordingly don't need no help from anyone) and don't want to admit he's been stuck with the same problem for days. I have zero patience for such wizkids.Of cause I'm just your average XP hippie...
...it depends on the size of your company or budget. If you are a small organisation, you need experienced, honest, reliable and hard working programmers - because you cannot afford to wait for them to become good, assuming they have the potential in the first place of course. However, a large company can afford to assign less experienced engineers to less critical tasks (and even send them off to college), while allocating the top programmers to mission critical projects.
O'WONDERWe're working on it.
Aren't the good programmers supposed to write easy to reuse code which can be used by less experienced coders to implement?
Some superguru perl coder writes an snmp application from the ground up in 2 weeks. The less experienced perl coder uses the modules available on cpan and fixes the job in a day.
Just a thought.
especially the ones who read /. regularly :)
but garfield is funnier than sienfeld, and the ipod is not that great.
But your simpul and logick code is linear in both space and time.
I spent some time as course assistant correcting assignments from an introductional course in functional programming. All students attending the course has programming experiance from java before, and to pass the course four programming assignments had to be completed before deadline and validated (by me). Now the time students reported they used for each assignment ranged from 6h to 60h and then a fair amount of the students had corrections to make before they passed (usually not the ones reporting 6h of work)
Where an "average coder" might write the original code:A "good coder" might write:but a "good coder" is not neccesarily a good "software designer" or whatever title one might have, who would step out of the loop, see what the code means, and swap out the iterative solution for an algebraic solution if appropriate.
Someone "fixed" the algebraic solution, but it appears to me it is correct, and it's the iterative solution that must be fixed by replacing with
Tag lost or not installed.
I've seen plenty of mediocre developers with quite inflated egos, and enough of great programmers doing their job without much fuss.
The article has focused on the aspect of technical skills. Personal qualities and motivation are important, but they don't correlate that much with technical excellence, or lack thereof.
Lisp is the Tengwar of programming languages.
Actually this, like many other Slashdot posts, tends to look at the matter from a very enclosed US/Western European point of view.
In fact, there are many huge companies making billions and billions of dollars that will go to India or a struggling Eastern European country, and hire GREAT programmers/gurus for something like 10 times less money than their peers working in the headquarters.
I find this insulting for both programmers: one is forced to work cheaper or even loses his/her job, while the other is paid way less even though they may be working for the same company, and producing the same quality/ammount of code.
Just my 2 cents.
If you don't believe it, take a look at Siemens.
They have like 45k of developers (more then Microsoft or Oracle, if I'm not mistaken) and I don't think that many of you can name some good software product that came from Siemens.
Being a Siemens employee I can tell you that things are quite the opposite of what Joel believes software development should look like.
On the other hand Siemens is so mind bogglingly big that perhaps there are departments for which the above does not hold. It also means that they can sell crappy software.
I dropped a bunch of controls onto a WinForm, gave them some properties and VisualStudio wrote me a 4000 line method in microseconds...
Without precision, my life would be imprecise....
I wish more employers thought this way.
It is such a beneficial relationship. You hire a less experienced/qualified person to do the sort of simple non-critical tasks which are nonetheless important to allowing your project to progress and you pay them an awful lot less.
The employee gets to gain valuable experience within the industry and will be grateful for the opportunity.
The employer doesn't waste money on employing expensive staff for simple tasks and frees up their really "good" programmers from doing drudgework.
I don't think the King David metaphor from the article holds true but matching your employees skills level to the job they are doing is just common sense.
In other news,
1) Good Carpenters build good furniture
2) Good Architects architect good structures
3) Good Authors write good books
He seems to make a unspoken assumption throughout the whole article, and that is that whoever does it quickest does it best. I find this strange a pretty strange assumption. Especially when he goes on with all the product examples where obviously not the speed of the development was essential, but the quality of the end product. Good quality needs a lot of creative thinking and that just costs a lot of time. Any ole programmer can hack together a script that does a certain task; taking a step back and actually thinking about the bigger picture takes time but in the end yields much better results.
---
"The chances of a demonic possession spreading are remote -- relax."
Is it just me or is Joel on Software reeeeeeeeeeeeeaaaalllly annoying? The man seems like a bit of an egomaniac, and a Windows apologist to boot.
Spolsky's writing from the perspective of a small development house, so he's not separating "design" from "implementation" - since they're often done by the same person/people it's all included under his catch-all "programmer".
I personally would be more likely to use the word "developer", but that's just his phraseology.
You can self-evidently get away with having a few "just average" programmers around. In fact, it's possibly a good idea since truly talented hackers tend to get demotivated when given shitty, trivial or uninteresting jobs to do.
However, to suggest that developer-skill doesn't matter at all is insane - who designs and develops the "processes" you're talking about - non programmers? Then (empirically) they're unrealistic, buggy and prone to security holes. People with any experience of programming? Then they're part of what Spolsky calls his "programmers".
You might also notice that:
Which are all symptoms of poor programmers working in large groups, rather than one (or a few) talented individuals implementing a clear but extensible vision.
"Software should not be made by programmers, but processes. It's like talking about how you can build a better building with quality bricks."
Not really. It's more like saying you want your walls to be made out of brick rather than paper. Paper walls might be easier to work with and cheaper, but there's a reason we use bricks to build houses.
And yes, you can build a monstrosity out of bricks, but you can also do it out of paper - at least the brock version will be stable, hardwearing and not prone to collapsing in the first a slight wind.
Everything in moderation, including moderation itself
I heard this great analogy somewhere else, I don't remember where:
How many eight foot pole vaulters do you need to scale a ten foot wall?
He's had some good articles. This one starts nicely, but ends up being full of metaphors and the EXCELLENCE OF HIS IPOD. Also... He does not seem to take learning into account. Was he really born with his l337 sk1llz built-in?
everyone knows a million monkeys are better than one programmer!
embedded linux
These are the same exact boundary conditions my boyfriend delineates when I ask for a good ball-licking.
Keep in mind... "good" doesn't necessarily mean the same thing as "experienced". She may still be very bright even though she's new to programming, in which case she's still "good", she just has a lot to learn.
After all, none of us were born with C compilers embedded in our skulls...
Being good and experienced at programming doesn't just involve getting the code done and compiling. It also involves having some clue about stuff like security, good design, and generally knowing a lot more than just how to printf("hello world.")
The corporation I work for had at some point decided to replace an existing, working system with a monstrosity that had more buzzwords. So a team from a BIG corporation contracted the work, and took a couple of years at it, until finally the project was scrapped.
By the time it was scrapped, the code they had produced, although it did compile, had major problems, including fatal security issues. (And it also needed a cluster of two dozen servers to serve the same number of users as the old system did on 1 server. And took several hours to even start or stop. Literally.) Among other problems:
- they consistently assumed that the _only_ way to reach a page was to click on a link, so they didn't have to check rights again when rendering it. The user wouldn't have gotten the link to it, if he didn't already have the rights, right?
Wrong. By such trivial means as just editing the user id in the URL to 0, you could become super-user or change anyone else's password. (E.g., the super-user's.) And basically gain full admin rights to a corporate site.
- they failed _repeatedly_ to quote text displayed on the site. So you could simply type some JavaScript code in a text box, and have it execute (e.g., on mouse-over) in the browser of whoever views that post or offer. Again, one possible and demonstrated use was to steal or change someone's data, including an admin's.
- they failed _repeatedly_ to quote text used in SQL queries. So basically you just needed to input something like '" OR "1"="1' in the search field, and you'd get all the records on the system.
- they failed to even conside "non-repudiation". If a user cancelled their account, a cascaded delete would ensue, deleting _all_ the data about that user or from that user, including contracts. It was suddenly as if that user had never even existed, ordered or paid anything.
Etc.
We're talking about a B2B e-commerce site, with contracts worth millions, not about someone's blog about their cats. And it had gapping holes bigger than the goatse guy, for f**k's sake. As they wanted to ship it, it _literally_ allowed anyone to access any data and escalate their privileges to the max, in just a few kestrokes.
_That_ is a problem with making software with a team of incompetent monkeys. It's not just that they take longer to produce the code, or that it might need more debugging. It's that they just don't have the skill or knowledge to judge (or even consider) the implications of the choices they're doing at each step.
A polar bear is a cartesian bear after a coordinate transform.
The reason is as someone who has friends in both worlds rarely does the "software house" ever care about your outside life.
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).
whats your test for blocking idiot managers and marketoids from sneaking in?
The evidence of the article is based on student assignements and a love of iPods. Some students know more about computing to begin with, some students have a better aptitude for programming, some students finish their assignments and others don't. iPods are beautiful. But this does not support the argument that good products need a team of really good engineers and good having good engineers means having good products.
The software products produced (for the last 15 years) are often too large for a single person to produce. Let's face it, every software development team has a mix of experienced and inexperienced developers. The tasks are usually broken up in such a way that coordination is required to pull them together to make a working system. Ad-hoc ideas need to be accomodated, but these play merry hell with project timescales and costs. Clarifications of boundary conditions need to be addressed from time to time, usually from an external team or company. Support teams have their own ways of working. They may have their own tools and methods. Invariably, the product is supported or used in a different way than the designers/builders envisaged. Finally, you need to educate the junior members of the team thru experience and good practice (and time and money).
The above all point to management. It's management that can make the engineers life easy (by resolving issues before or when they arrise) or hell (thru incompetence). You tend not to notice a good manager until he's away on holiday, then all hell breaks loose.
You simply cannot built a team of experts. They'll always keep clashing intellectually. You have to head the areas with gurus, but need more subordiate people around them to make their ideas work. This applies to development, test and support.
A brilliant programmer straight out of university tends to have no idea about building reliable systems or making the product more supportable. That comes with experience. Anyone can learn it, but yes some people are natually better and some are more willing to learn, all leading to better engineers. The knowledge has to be passed on from senior to junior, or learned the hard way.
BeOS and Coherent are examples of good products at the right time build by talented engineers that in the end, failed commercially. I'm sure readers can think of other examples too. It simply is not true that systems built by good engineers are commercially more successful. (VHS vs. BetaMax)
Microsoft's success is not based on brilliant engineering talent. Microsoft may have some excellent programmers, but you just need to try to interface with some of its subsystems, and you'll soon see that all that glitters is not gold. The operating system gained traction with version 3, which crashed regularly. And when it's not the OS, it's the apps. It is marketing brilliance that has let to their success, despite the products.
I do have a point, we are liscenced.
Our school, with IEEE boards and other universities (i think U Of Texas started the thing) made the curriculum expressedly for the purpose liability and warrantability. A body of knowledge was made (www.swebok.org) and everything is in place.
We should have been
So much more by now
Too dead inside
To even know the guilt
For a couple of reasons:
1) At the beginning of some new programming project desired by somebody on the business side, the programmer will frequently not have sufficient domain knowledge to assist in coming up with complete specifications. For example, I used to work for a company that maintained demographic and and circulation fullfillment databases for B2B pubs (everything from Information Week to Concrete Construction.) With the more complicated reports that business side people asked for, I couldn't foresee the ambiguities in the specifications until I began implementing them, since I had no particular prior experience in the domain. And the business side people didn't necessarily understand the notion of "precise specification."
2) Speed matters. Even a couple of weeks can make the difference between a rousing success and so-so release in some instances. This is certainly true in the trading industry, where I work now.
If you've ever attempted to come to grips with others' spaghetti code, you'd see why bugs remain obscure. Good programmers solve bugs partly by refactoring, and partly by simply being less likely to code errors, so that their efforts are simply less likely to give rise to bugs whilst solving them.
Wikileaks, no DNS
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
... why this guy gets soooooooooo much love on Slashdot? Sure, he's clearly smarter and more insightful than the average bear, but c'mon!
The Mythical Man-Month: Essays on Software Engineering is the best book on this subject. It says that 10 very good progammers will be faster/cheaper/produce a better product than the same 10 leading a group of 200. Even though its an old book, its one that still has alot of good info. http://www.amazon.com/exec/obidos/tg/detail/-/0201 835959/002-7964039-5475214?v=glance
Fine. Don't listen to a well-intentioned observation, continue to be the only "engineering" discipline that routinely fails to implement solutions to time and on budget. I must say its interesting, on Slashdot programmers are geniuses and artistes. In real life they are people who make make a hell of a lot of excuses. Funny huh. I'll let you get back to your Joel-sponsored circle-jerk.
Plays violent online games as: Nerfherder76
" He seems to make a unspoken assumption throughout the whole article, and that is that whoever does it quickest does it best."
Apparently you did not read the article. He states, in no uncertain terms, that this is not the case. You can find the following quote just below the graphs in the article. He even emphasizes the text to stress it.
"The quality of the work and the amount of time spent are simply uncorrelated."
He is making the point that a good coder is not necessarily fast and a fast coder is not necessarily good. I think it is more the case that most programmers out there do not fall into the category of 'excellent' or even 'good' and are threatened by such facts as this gentleman present, very thoroughly and quite well I might add.
One company that exemplifies your approach is Microsoft. There are some superb people working at MS, but a lot of the basic code is cranked out by drones, and this has resulted in notoriously bloated, slow, inefficient, and buggy software that's riddled with security holes. While some of these problems can be laid firmly at the door of designers, many, many others are obviously caused by sloppy coding.
I really liked his attempt at analysis, and particularly liked his attempt to split out the higher quality coders.
I used to run the mechanical engineering section for a small project. We used a lot of contract CAD guys. A good CAD guy was about 4 times more productive than an average one, and would cost 0-30% more, per hour.
With engineers my experience is that the best engineers are roughly 4-10 times faster and more accurate than the average guy, and the bad ones have a negative effect on productivity.
War story: two of us redesigned a system and saved 200 bucks per unit. We make 100 000 units per year. So that's $20 million a year.
Somebody redesigned one of my parts, saving $0.30 per unit. We had to recall several tens of thousands of units because the new design was unsafe. Total cost in excess of 10 million dollars.
I have seen parts with identical functionality. One was designed by an idiot and cost twenty bucks. The other was designed by a competent engineer. $3
"In computing, the rapid advancement of cpu/system design yields faster machines every year"
In electronic engineering, the rapid advancement of cpu/system design yields faster machines every year
Computer science is a subset of electronic engineering
Flame on!
if nobody knows the difference.
Face it most employers couldn't tell the difference between a good programmer and a bad one, even if they adminisister some cookie cutter test during the interview process.
Furthermore even if they thought they were getting a great programmer most wouldn't know what to do with them. In the end 9 times out of 10 there's a time crunch and all the advise the programmer gives (part of what make him/her great) goes out the window anyway. e.g. Programmer: "I really think we should <b>create</b> a specification for this application". Employer: "We don't have time, we have a new deadline and there is no money in the budget to develop a spec." Besides as long as it does something no one cares whats behind the scenes at the code level right?
So in the end unless you have a great programmer running the company just hire the mediocre peeps.
>The elicist seem to forget that a company is not for making money. Its purpose is making money so that the society benefits from it!
HAHAHAHAHA! What planet have you been living on? Xena? The only interest companies have in social enrichment is that a 90% unemployed population won't be buying their products. Beyond that they don't give a damn.
>Lets say, theoretically, every company would only employ the best 10% of the people. Ignoring that some people may have multiple skills, that leaves 90% of the population unemployed! What a great thing to do!
Well firstly, the logical thing to do is to ignore the "top X%" nonsense, and look at it another way. Employ from the top down until you get to a point where adding the increasingly less skilled starts becoming a hinderance instead of a benefit.
Besides, there's no reason why the bottom 20% of developers can't get a job elsewhere. They can crunch numbers, pick up a broom, stack shelves, or whatever.
If you are completely crap at your attempted porofession, either be unemployed, improve yourself, or try another profession.
Oh, and if you're talking social responsibility - what is socially responsible about allowing and encouraging incompetent people into the workplace to hold everyone else back?
Joel Spolsky's article first bings up some findings from hard data:
- programming seems to take almost arbitrarily long; there appears to be next to no limit on maximum time and deviation (except hard deadlines)
- there is no correlation at all between the time used and the quality of the result
The question is whether quality correlates with other variables than time, more specifically, with the programmer.
So the next step should be: when looking at the scores of individual programmers, do we see consistency? Is there such a thing as a "good" programmer, who scores consistently better quality than the average programmer?
Joel's report becomes a little ambiguous at this point. He selects "the top 25% programmers" without saying how. I'm confident he selected the programmers who took the first 25% of overall (averaged) quality scores. I do not believe he selected the first 25% of results for every exercise, but the wording doesn't completely exclude it.
He reports that, collectively, these top 25% of programmers take almost exactly as much time as the rest (both in maximum and in deviation).
He then leaves the data and starts about the difference between good and average programmers. This is a total non sequitur. Nothing he says about that difference is supported by his analysis.
It might seem at first glance that the analysis supports the notion that there is such a thing as "the good programmer". But it doesn't. Joel doesn't give us any information on whether some programmers perform better than others. He looks at the ones that came out in the top 25% and *calls* them the "best programmers". For all we know, the quality scores were completely random and the programmers that came out on top just got lucky this time. To see if quality of code is correlated with the programmer writing it, we should see if there is any consistency in the difference between individual programmers' scores across exercises. Joel didn't do this. He committed the classical logical error of assuming what he wanted to demonstrate, namely, that there is a difference between "good" and "average" programmers.
For now, let's gloss over this fatal weakness and go along with Joel's (plausible) hypothesis that there is such a thing as a difference between "good" and "average" programmers. We now come to the strong point of the article. Joel was, of course, hoping to find that the programmers who produced (on average) the best quality code were also the faster ones. But they aren't: they are just as slow as the average programmer.
It's to Joel's credit that he doesn't hesitate to report these findings, since in my eyes they are fatal to the hypothesis he started out with.
What these figures prove is that the good programmers (those with good results on average) are just as slow as the average ones. The difference in productivity solely consisted of the fact that the top 25% got better results - but that is not exactly surprising, since it is how they were selected.
Amazingly, Joel draws the opposite conclusion: these same figures are supposed to demonstrate a 5-10 times speed difference between programmers! But that is only when measuring on individual exercises. It is completely unwarranted to draw any conclusions on the speed difference across exercises.
OK, so we don't really see any difference in productivity. "But wait, there is more! (...) No matter how long (mediocre programmers) work, they never produce something as good as what the great programmers can produce."
Um, where exactly did we see this? Did the data provide any evidence that some programmers never find good solutions? Nope. Do some programmers arrive at good solutions all the time? No idea. if they did, I would think they would also work faster than the average programmer, and they don't. SO again, Joel is pulling his statement out of thin air, and the relationship with the data is no more than suggestion.
On the whole, an interesting, but flawed article.
If one had a ferrari needing a tune up would he let the jiffy lube guys do it?
If one needed brain surgery would he let the ear-nose-and-throat MD do it?
Software development is no different. Anyone can create a static web page. It is quite another thing to create a multi-threaded, web-enabled, windows application.
Cogito Ergo Sum
At least in my domain, SAP. If you don't understand the fundamental model of how business data flows through the system, you'll produce garbage, and you certainly won't know that the person writing the requirements doesn't have a clue what he's talking about.
Joel makes a statement not entirely untrue, does a fair amount of comparison between software and the iPod (he must have an iPod fetish) and its a "good read?"
This article seems to be stating the obvious. If thats how one gets ahead in IT, I could have been doing that years ago!
Say what you want about Joel and his articles, but once again I think he's hit the bullseye. Most of the things he says just seem like common sense to me.
:-)
I can tell you that one place it really pays to have the best coders you can get is the games industry. At the studio I work at, our lead programmers are brilliant. They have experience and knowledge that I don't and I'll admit that I look up to them. These guys are the coders that can sit down for a few days without any distractions and come up with an awesome and flexible new system.
Being a great coder isn't just about being able to meet the spec in the shortest time, it's about having experience, knowledge and insight to come up with great ideas and ways of going about things.
I work daily with the code of a mediocre programmer, and it frustrates me to no end as it's full of bugs and isn't robust/flexible enough to do the things that we want to do these days. The difference between that code and the code that the leads put out is like chalk and cheese. Currently, about 75% of my job is keeping the old code patched up whilst I write a more robust and flexible replacement for it. It shits me to tears.
Posting anon because I don't know if the former coder is reading this or not, and as anyone in the industry knows, it's a rather incestuous little cesspool
If they balk and tell you you're not getting any additional money, then tell them they're asking you to buy a $.60 Snickers bar, a $.75 M&Ms bag, and a $1.25 bottle of coke, but they only gave you $2.00.
If they say you're not getting any additional time, then tell them they're giving you a (newly) pregnant mom and saying, "You can have as many additional moms as you need, just deliver the baby in 4 months."
Yeah, right.
This helps, because it adds frustration to people looking through the code. The goal of a bad programmer, like me, is to make sure the project fails, so that other people don't see how bad I am. Bugs are good. They take time to fix. Time is money. The more bugs you code, the more you get paid. It's also good to present missing features as bugs:
- Sure it's finished, but there's a small bug in the startup routine. I'll fix it on monday.
A bad programmer has to read a lot of tech books and articles to bullshit your employer with the complex tech language. Confusion creates opportunities for missing the deadline. By 6 months or so.
Oh... I thought you meant "Hello World"... I have to rewrite the whole thing!
A bad programmer is always busy and always has a list of unfinished tasks before him.
Can't do that, I'm still working on the network code.. You know, we had a bug there.
A bad programmer always knows that the project sucks and nobody will give a ratt's ass if it's out or not.
Bad programmers always dream of working in a nuclear facility or shuttle control lab or something. The more damage you can create the better you feel aftewards.
The absolutely worst bad programmer knows he's brilliant, he just doesn't give a shit.
Bad programmers eventually open their software companies and end up creating Windows or something.
However, when you're talking about somebody who is maybe 2-3 years out of college versus somebody who is 15 years out, it becomes a much different question. Would you rather have an average coder with major experience, or a junior kid that shows flashes of brilliance?
Personally I like having a couple of young, bright people on the team who want to be mentored. You just can't fill a team with nothing but that. It's the balance between the two that is most important, to me. I don't want a team of 20yr industry grumpy guys any more than I want a team of 2yr know-nothings.
www.HearMySoulSpeak.com
From my experience, the lack of quality in programing comes from unreasonable deadlines. It is very rare in my professional experience that I have time to sit down, create a design, test the interface, build and document the software, test the software, make revisions, and then do some more final documentation.
In most cases, someone says "we need something NOW", and it is a scramble to just barely come up with something working by the deadline. Documentation or testing are certainly out the window.
And clients don't care about anything they can't see (meaning, they will have a 6 hour meeting on the color scheme of a web app, but don't care if the code is so convoluted that no-one else will be able to work on it without reverse engineering it). The sad thing is in the long run it costs them more time and money.
My experience with all too many developers is, "we can do it slow and expensive; hey, we'll throw in badly for free." :-/
The future supply of "good programmers" depends on today's supply of cheap programmers getting work experience (and mentoring from today's "good programmers").
I once saw a survey that indicated close to 90% of licensed drivers thought they were above average. I've remembered that ever since, because it's a psychological phenomena that you can see everywhere.
Such as this thread. Remarkable coincidence that _everybody_ who posted happens to be an above average programmer.
I'm in the second group. I spent most of some summers coding for fun in my early teens. I knew I was in a minority, but who can argue with intrinsic motivation?
;)
At college I didn't do too well at engineering calculus (memorizing taylor series and maclaurin series?? WTF is up with that??) and that was a requirement for both physics and CS majors (my first two choices) so I ended up a Psych major with a CS minor.
In the end I enjoyed that decision as I not only loved the "wiring" aspects of the brain but I became much more "well-rounded" than the engineering school grads I knew (hey, I can document with correct grammar!), yet I kept my intrinsic interest in coding. Perhaps I cannot bang out a compiler or a compression algorithm... but I can talk to other objects that do that grunt work
I constantly run into people at work in the first group. They came to coding in college, or even later. They are the "get it done" types, and when they go home, the last thing they want to do is sit at a computer. Perhaps they tend to "get it done" faster than I do, but they do not appreciate what "beautiful code" means, and I often have to clean up their messes. The other day I had to explain to someone why the output of one MD5 implementation cannot possibly be different from the output of another MD5 implementation... I didn't even bother to bring up about how MD5 is considered less safe these days, as these people do not read technical blogs in their spare time like I do. I have to butt heads even over such simple decisions as grouping related preferences in the UI together, just because it will take 5 more minutes. I care about users as much as architecture. "Getting it done" is important, but not to the exclusion of all else. I would rather communicate to the client "look, i'm almost done, but I am really into this and I would like to put some extra polish on."
Not so, the first group...
I find that people in the first group are also heavier sticklers about timeliness. I would prefer to arrive late and work late, like your proverbial hacker. These folks are more concerned about keeping up appearances and catching the 8:15 train every day.
I'm still casually looking for a job (or creating my own job...) where I work with some people in the second group, but I keep finding myself surrounded with first-groupers in the corporate world.
You want it done yesterday? No problem...fork over extra cash and we can expedite everything. You want it on budget? Then it will take as long as we told you it would take.
You can't have it both ways.
I always try to use a "building a house" analogy when dealing with managers. Assuming that it takes 3-6 months to build the average house and costs the purchaser $250K. If you want the house in 30 days, add $50-100K and it can be done. Cut the budget and you get a smaller house that will take longer to build.
That is not correct. Good Carpenters CAN build good furniture, while bad carpenters cannot. However that does not mean a good carpenter will build good furniture.
I have quit buying books by several authors because they no long write good books. They can write good books, and I have worn out copies of some of their early works where they did. Today they are just putting words, on a page, and the publishers go along with it because they know people like me think "She wrote that one great book, I'll try this one".
Frank Loyd Wright was well known for leaky roofs.
Why does Joel's argument pertain only to the software world. In every field, having those that excel at what they choose to do in life, will always give exponential return. I always hear that the top programmers are 10 times more productive than their average peers. Does this not also apply to other professions (Except burger flipping). What makes programmers the exception.
Ah yes! Quite like taking tactical and strategical advice on a battlefield from Tom Clancy because I tend to judge him by what he has said and written more than any experience with battles he may have commanded or fought in.
No, more like taking advice from General Patton because I was also a general in active duty and could see the sense of what he said from practical experience.
I have been a software developer for over a decade now, thus I feel I am pretty well qualified to judge the reality of what others are saying on the topic. I've been through many successful and a few failed projects, in both large and small teams, and what he says about the abilities of above-average programmers is spot-on.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Sorry about setting you up for the merciless pummeling you have endured in replies. it was just so easy...
My counterpoint will thus be gentle. The marketplace has in fact determined his softwrae is good by continuing existance and indeed expansion of that company.
What companies do you own that are greater successes?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The idea with software engineering is that the quality of your programmers shouldn't matter a great deal. If you have good processes in place, the quality of your programmers should not be a major factor.
That is only true for custom internal IT projects.
That form of software should in fact be the most limited, since custom internal IT software should (if you want to get the most bang for your buck) rely on many modules of higher level functionality - weither open source or commercial.
It is these modules which need to be written by better programmers in order to really be a powerful tool for the corperate IT developer. The argument he puts forth as to quality of code applies equally to quality of API - a really good developer can put together an API that is a joy to use, that a bad programmer would not arrive at in a million years.
Joel even says in his article that the argument he is making does not apply so much to corperate development. It just so happens that very little work should really be corperate in-house stuff and should be using well-crafter higher level modules where possible. Many times in-house developers are working on projects they could have just adopted an open source solution to address, which is really unfortunate for the companies involved. But that's another reason why hiring good developers is of use even for IT, because they will realize when and when not to code more often than others - if nothing else just due to extreme laziness!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The primary mantra of Lockheed's Skunk Works. It always works.
antipaucity
If most programmers had a more realistic understanding of how crappy they really are at it, they would not be busy congratulating themselves right now.
Only three choices? My old boss said that software engineering was like a small blanket on a big bed. Whose feet do you want to get cold? It depends on which corner you tug on.
1) Time
2) Cost
3) Functionality
4) Quality
Tug on any one corner and the other three get shorted.
Don't blame me, I didn't vote for either of them!
What Joel doesnt examine the breadth of software development projects to know all the different types of programmers that might be right for different types of projects.
In many cases a hoard of mindless minions is just what the doctor ordered. In other cases you might need a top-shelf computer scientist. In others, you might need 4 fresh Indian IIT grads and a soda machine.
I have found hiring on skill problematic because this requires a resume of past successes - many turn into the developer equivilent of the BOFH once they have the 'high note' to back up their negative attitudes and lack of contructive productivity.
Youth, attitude, and productivity are much more interesting to me in most cases, although I will also subscribe to the King David philosophy in the general case.
I like Joel's writings. I like this article. However, the first thing I noticed that's truly missing for his point to be made is a mapping of times to individuals across multiple projects. This article displays some info, but misses proving the assertion.
The question he doesn't answer: are the same people always at the bottom of the time scale, or are all represented equally? IOW, are there truly great programmers, or do individuals just have flashes of brilliance occassionally?
The cesspool just got a check and balance.
Are you trying to build a good application or a cheap application?
Neither one. You're trying to build an application that people will buy!Marketing sells software. It doesn't matter how good a product is; it doesn't even matter if they like it! It only matters if they buy it! Everything else is secondary.
With something as complex as software, "quality" isn't obvious to the end consumer. It's not like they can kick the tires, or check for rust: the average consumer is like a six year old trying to choose which car to buy. They're going to be swayed by the best salesman; not by the best engine or the finest engineering techniques.
A good salesman can spin just about anything to make it sound good. They can probably even convince their customers that better quality is a bad thing.
Imagine a salesman trying to sell a safe made out of cardboard:
Is our new cardboard safe really more secure than those old-school, clunky metal ones? Of course it is! It's made of an all new, state of the art material: cardboard! Don't be saddled with those old, clunky, cast-offs safes people in the Dark Ages used! Get modern! Go cardboard!
Cardboard safes are more secure! There are several known techniques for drilling into metal safes, but no one drills into cardboard! And consider fire hazards! Unlike those cheap metal models, the cardboard safe will catch fire before your documents do! Get your cardboard safe today!
You see, it's all about marketing! Paying for "great programmers" probably isn't worth it for most companies; because paying for "great software" isn't going to profit them as much as a great salesman will. It's sad, but true.
Now, if you'll excuse me, I'm off to buy one of those newfangled cardboard safes....
1) Good Managment
2) A good mix of motivated programmers with a mix of experience
-- entry level coders to do the "easy" stuff
-- mid-level coders to do the hard stuff
-- super programmers to do the impossible
3) Other people
-- business analysts with BOTH programming and business experience (CRITICAL!)
-- tech writers to create the documentation
-- system architect/team leader to keep everyone on goal
Anyway, the most successful projects I was on were rolled out in phases. First a new back-end was created (in phases itself) to feed data into the old system. Then, after the backend (main processing, reports, interfaces, etc) was completed, the UI stuff started. First, the least mission critical items were done. With a team of 10 programmers, we were rolling something out every 2-4 weeks for a year. If something failed, we just rolled back to the old system for a couple weeks until the fix could be fully tested. With each rollout, we discovered more and more about what worked for the organization.
BTW, at the end of the project, we were on time, below budget, provided more functionality then was initially requested, and the END USERS threw us a party (actually, there were several throughout the year!) Management was happy, users were happy and programmers were happy. Oh, and we were all allowed to take our vacations throughout the year!
It takes a good team and short rollout cycles.
Don't make business decisions based on rumor when accurate information is easily obtainable. I agree that it's wise to choose the proper venue for any conversation, but that's an entirely separate issue. That isn't to say I don't have similar stories of my own, but I consider such behavior far more appropriate in a highschool hallway than in a boardroom. Talk is talk but business is busines.
Or look at the iPod. You can't change the battery. So when the battery dies, too bad. Get a new iPod. Actually, Apple will replace it if you send it back to the factory, but that costs $65.95. Wowza.
and then
Apple made a decision based on style, in fact, iPod is full of decisions that are based on style. And style is not something that 100 programmers at Microsoft or 200 industrial designers at the inaptly-named Creative are going to be able to achieve, because they don't have Jonathan Ive, and there aren't a heck of a lot of Jonathan Ives floating around.
If he considers the inability of easily replacing a battery inplace of style a good feature of the ipod product, then I will never ever want to buy his software.
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
She's getting half your salary per hour, and you think she's cheap?? :P
Was Joel trying to hard in this article?
I don't disagree with what he says but this article sounds like a tryout for ESPN the Magazine.
I can't recall if it was Pike, Kernighan, Ritchie or Raymond that said function length is a better indicator of quality than indentation. I have just recently re-read 'The C Programming Language', 'The Art of Unix Programming', and 'The Practice of Programming' all in the same month, and it starts to blurrrrrr.
my $0.02
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
Thank you. I sit edified.
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1