Slashdot Mirror
The Programming Talent Myth
HughPickens.com writes: Jake Edge writes at LWN.net that there is a myth that programming skill is somehow distributed on a U-shaped curve and that people either "suck at programming" or that they "rock at programming", without leaving any room for those in between. Everyone is either an amazing programmer or "a worthless use of a seat" which doesn't make much sense. If you could measure programming ability somehow, its curve would look like the normal distribution. According to Edge this belief that programming ability fits into a bi-modal distribution is both "dangerous and a myth". "This myth sets up a world where you can only program if you are a rock star or a ninja. It is actively harmful in that is keeping people from learning programming, driving people out of programming, and it is preventing most of the growth and the improvement we'd like to see." If the only options are to be amazing or terrible, it leads people to believe they must be passionate about their career, that they must think about programming every waking moment of their life. If they take their eye off the ball even for a minute, they will slide right from amazing to terrible again leading people to be working crazy hours at work, to be constantly studying programming topics on their own time, and so on.
The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned. Programming isn't even one thing, though people talk about it as if it were; it requires all sorts of skills and coding is just a small part of that. Things like design, communication, writing, and debugging are needed. If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make programming less intimidating for newcomers. If the bar for success is set "at okay, rather than exceptional", the bar seems a lot easier to clear for those new to the community. According to Edge the tech industry is rife with sexism, racism, homophobia, and discrimination and although it is a multi-faceted problem, the talent myth is part of the problem. "In our industry, we recast the talent myth as "the myth of the brilliant asshole", says Jacob Kaplan-Moss. "This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic. In reality, given the normal distribution, it's likely that these people aren't actually exceptional, but even if you grant that they are, how many developers does a 10x programmer have to drive away before it is a wash?"
The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned. Programming isn't even one thing, though people talk about it as if it were; it requires all sorts of skills and coding is just a small part of that. Things like design, communication, writing, and debugging are needed. If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make programming less intimidating for newcomers. If the bar for success is set "at okay, rather than exceptional", the bar seems a lot easier to clear for those new to the community. According to Edge the tech industry is rife with sexism, racism, homophobia, and discrimination and although it is a multi-faceted problem, the talent myth is part of the problem. "In our industry, we recast the talent myth as "the myth of the brilliant asshole", says Jacob Kaplan-Moss. "This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic. In reality, given the normal distribution, it's likely that these people aren't actually exceptional, but even if you grant that they are, how many developers does a 10x programmer have to drive away before it is a wash?"
Outside SF, I can't imagine that this surprises anyone.
If you're looking for people who generate a profit from their time, the curve is almost certainly U-shaped based on my now not-so-light 30+ years in the trenches.
Why is this any different than the population of other skilled professionals? You will see the same curve for musicians, for example; it's not necessarily about being able to eventually get the skill, but it's about doing so in a reasonable efficient amount of time proportional to the effort expended.
In terms of actually learning, the guy probably has a point - eventually, I could learn to play the violin - but having tried, I'm never going to do it professionally.
Ask me to develop OMAP firmware or drivers, otoh..
..don't panic
On academic programming courses - of which I've taught on many - the grade distribution is definitely bimodal and there is a clear gap between those who can and those who can't. Of course, there is variance among those who can but the difference is largely that those who can largely get better whilst those who can't never get even get it.
free time and level of interest.
That's pretty much all it takes to get ahead.
Choose your bytes carefully.
If you could measure programming ability somehow, its curve would look like the normal distribution.
This guy doesn't know how to measure programming ability, but somehow manages to spend 3000 words writing about it.
So he doesn't know......programmer ability might actually be a bi-modal distribution. If he had collected data to support his hypothesis, then that would have been an interesting article.
"First they came for the slanderers and i said nothing."
I've worked in many places, but this description also aptly describes clinical/ adjunct faculty vs. tenure-track/ tenured professors. It's pretty nasty in higher ed when the perception is a liberal bastion of socialist shangri-la.
I can't wait to get out of higher ed. Bunch of insecure assholes.
Lost me here. Programming can definitely be a passion, and it can also be a talent. One might have a natural aptitude at programming. That doesn't mean one cannot learn the skill of programming, or that someone who finds it difficult in the beginning will not become an expert.
In my career I've noticed that there are developers who are brilliant, and developers who struggle. The ones who struggle can succeed through mentoring and training.
There are also developers who are kind and have great social skills, as well as those who do not. This is true of any employee at a company, including managers. Social skills can also be a passion, a talent, and a skill. That is also something that can be improved through mentoring and training.
The primary reasons we don't see this happen for social skills are office politics and the false view that personalities and behaviors are fixed.
If you are reading this and your programming skills or social skills are lacking - invest in yourself and work on them. It will pay off handsomely.
"In our industry, we recast the talent myth as "the myth of the brilliant asshole", says Jacob Kaplan-Moss. "This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic.
This is swinging at a strawman. A person can be a 'brilliant' "10x programmer' without being an asshole. A person can also be a -10x programmer while being an asshole.
Also, if a programmer can't work well with other programmers, she's not a 10x programmer, she's just a fast typist. Any software that is unmaintainable by others isn't good code.
"First they came for the slanderers and i said nothing."
The moment he or she drives someone away, fire them.
I am very small, utmostly microscopic.
Assuming his designation is accurate...nine?
Take it to the limit, everybody to the limit, come on, everybody fhqwhgads.
The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned.
Why people forget the creative side of programming?
The programming is indeed bunch of skills. But if you do not have right mind set - inquisitive and creative - your career in programming would be full of frustration.
The only software where one doesn't really need any creativity - is already written and there is literally no work there.
P.S. Of course there is the "flip side" to the creative side of the programming - "monkey" coding and testing. But for most of this work you do not even need to have any deep programming skills. Reading and comprehending documentation fully (an ability which is again easily forgotten by the sensational headline writers) is more useful and also much under-appreciated. And then there is also the writing of tech documentation...
All hope abandon ye who enter here.
What's that supposed to do for me? For the business it'll lead to a crop of cheap new hires, but surely you don't expect working programmers to encourage that
I can't speak to the validity of the articles claims. But I do know that even though I suck at programming, I still keep trying. Luckily some people are patient enough to help me out and they are awesome for doing so.
and will-power mean a lot.
Now, I don't have stats to back this up ... but many moons ago I was told by numerous profs that programming/CS had pretty much always been the bi-modal distribution, and one of them even showed me the graphs of previous years of first year programming courses to back it up.
I have seen an academic paper discussing the bi-modal distribution.
So, is he saying "among people who are programmers there isn't a bi-modal distribution", or is he saying "among people learning to program there isn't a bi-modal distribution"?
Essentially he has no statistics to back his claims, and seems to be saying that "among people who are already programmers there's all kinds" -- which is FAR different from refuting the observation in academia that people learning programming are most definitely showing a bi-modal distribution.
This sounds like he's talking from his 'feels' instead of from his 'facts'.
Lost at C:>. Found at C.
This is perpetuated by a small percentage of vocal but talented programmers who, in fact, lack the skill to work with people whom them don't think are as brilliant as they are. This probably works fine in a startup. However, if you don't ever learn to work with people of varying skill-sets, you severely limit the types of jobs you can get later in your career.
1. Programming skill is more likely to have a power law distribution rather than a normal distribution. That is, lots of very unskilled people, a chunk of decently-skilled people, and a handful of "rock stars." This would more closely match the distributions (and success rates) of other skills. This also matches my experience working with programmers of varying skill levels for more than twenty years.
2. You can teach a lot of the concepts but there is an inherent knack for logical thinking that is very hard to teach. If one has this knack, new concepts are easily grasped, solutions to problems using currently-known tools are more easily found, and troubleshooting is simpler. If one DOESN'T have the knack, they can still be successful, but it is harder, requires substantially more effort, and more of their time will be taken at each step.
It's not always pobox where someone sits on the talent distribution. This is also not a perfect predictor of their ability to produce; some people are very bright but unmotivated and unmotivatable. I would rather have someone with Leeds talent who was willing to work and produce. It's also important for a team to code to roughly the same competence level; if you have one rock star who writes code that no one else understand, you create a bottleneck for yourself on that one person being able to work with that code.
People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
When you work in a manufacturing plant making cars (for example), a productive worker if allowed to produce is about twice that of a poor producer.... When it comes to programmers/coders the quality and productivity of your upper end programmer can easily be 12 or more times as productive as your weak programmers. In worst case examples some programmers are actually a net negative when it comes to defects etc. The wages however tend to vary between 2 and 3 times your junior programmer (who could be a star or not himself). Some programmers are overpaid at the bottom pay scale, and some are underpaid at the top end. I have worked at some of the top companies, and some that are far far from it so I have been able to see both ends of it.
Programming is a natural skill which can be enhanced greatly when you work in an environment that values talent and you have people that are better than you or at least near the top of their game if you are one of the gifted. I have seen University graduates that are at best average, and I have seen self taught programmers that are among the best......
In short it is not a myth.
The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned.
I disagree with this statement. I enjoy programming and I am very good at it because I enjoy it. Enjoying it means that I am interested, stay up to date and learn new things all the time. It means I do alot of programming in my spare time, which further increases my skills.
Many developers I know do it as a job and forget programming when they leave the office. This makes a huge difference.
But no, programming talent is not distributed along a U curve. However, I firmly believe that an average developer is 10 times more effective than a poor developer. A good developer is 10 times more effective than an average developer, and an excellent developer is 10 times more effective than a good developer.
Maybe not exactly 10 times, but certainly by an order of magnitude.
Well gee whiz. The myth of the brilliant asshole is obviously false because there's no such thing as brilliance. But even if, just to be stupidly ridiculous, we grant that there is brilliance, then who could stand the asshole?
I guess you're not above propagating the next myth if it might make your point.
That being said... I'm sure to most young folks these days this is prefered to believing that actually working hard at something will eventually pay off.
It is very likely that programming skill (if such a thing actually exists in a measurable sense) is normally distributed. What looks like a bimodal distribution is really just an effect of current employment practices by Google/Facebook/etc. There are people who are "good enough" (measured very poorly by a job interview) to work at one of these "top" firms that pay really well, and everyone else simply isn't good enough. The difference in actual skill between a person who is "good enough" and one who is "not good enough" is very small.
You can be just a run-of-the-mill average regular prime minister and still hack out c++ code that solves sudoku. Yeah, it is not c++ but simple c masquerading as c++, but thats what you would expect from the average regular prime minister, right?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
The toxic part of the myth is not that how much of a rock star or a ninja the professional programmers are. It's about how people who can code are viewed by their peers who can't code. I am not a programmer, but I have written some programs in bashscript, and I show the code to anyone, most will think that I have the "gift", the "neck", or that my ability has something to do with the fact that I have been accept into Mensa.
Linux is for people who don't mind RTFM.
This guy doesn't know how to measure programming ability, but somehow manages to spend 3000 words writing about it.
To be fair, you can spend a great deal of time talking about something and make progress on the issue without solving it.
... it was absolute dopamine bliss to me while he felt like our production was being put in reverse. KLOC is a terrible metric. But yet we still need to waste a lot of breath explaining why it's a terrible metric.
For example the current metrics are abysmal so it's worth explaining why they're abysmal. I just was able to delete several thousand lines of JavaScript from one of my projects after a data model change (through code reuse and generalization) -- yet I increased functionality. My manager was confused and thought it was a bad thing to get rid of code like that
Another reason to waste a lot of time talking about a problem without reaching an answer is to elaborate on what the known unknowns are and speculate about the unknown unknowns. Indeed, the point of this article seemed to be to advertise the existence of unknown unknowns to "recruiters, venture capitalists, and others who are actually determining who gets brought into the community."
So he doesn't know......programmer ability might actually be a bi-modal distribution.
Perhaps ... but that would imply that one does not transition over time from one hump to the next or if they do, it's like flipping a light switch. When I read this I assumed that he was talking only about people who know how to program and not "the average person mixed in with programmers."
If he had collected data to support his hypothesis, then that would have been an interesting article.
But you just said there's no way to measure this ... how could he have collected data? What data set could have satiated us? The answer is quite obvious and such collection would have been a larger fool's errand than the original article's content.
My work here is dung.
Competent, basic programming may be, but there is also an aspect of art and talent to it that can't be taught no matter how much the "we don't fail kids here" people might wish it weren't the case. Companies aren't looking for competent programmers -- they offshore those jobs. They're looking for the exceptional talent that can drive the whole process from top to bottom, including issuing the designs and models those "competent" programmers are expected to work from.
I may not believe in the "10x programmer", but I most certainly do not believe that just "anybody" can be taught to be good programmer. I don't believe that of anything except the most basic of manual labour jobs.
I do not fail; I succeed at finding out what does not work.
And the reason it's bullshit is that it starts from the premise that if you could measure programming ability somehow, its curve would look like the normal distribution.
Programming ability is exactly the kind of thing that does not fall in a normal distribution. It's not even close to a normal distribution. It's more like wealth distribution, there is no meaningful average.
http://rareformnewmedia.com/
in my 39 yrs in the industry, working for the largest multinationals to boutique consulting groups to 25 people software firms on a shoe string, I've seen plenty of "rock stars" and "zeros" and everything in between (typical normal distribution) and programming ability is not strongly correlated with toxicity to the team. Everybody have their own quirks, this myth that high productivity has to come with unacceptable social behavior is more likely sour grapes. Although it is true that low productivity programmers may have to be more restrained (but not necessarily so if the reason they are still in place is because of political cover). On the other hand, low productivity is just as toxic.
Very few things in nature is bi-modal. This U shape distribution is probably the result of people living in Lake Wobegon, "where all the women are strong, all the men are good-looking, and all the children are above average" and think they are on the right side of the U while other folks are on the left side of the U when the truth is that most people live in the big lump in the middle of a normal distribution (on just about any human endeavor).
Yes and no. I'd argue it depends on how you define "programming". If you're talking about "can code up basic solutions to relatively straightforward problems" then yes, with enough time, most people can probably learn to do that. Considerably fewer ever reach the point where the code they produce is (usually) elegant. Where they're capable of troubleshooting the most elusive bugs. Where they fairly quickly identify solutions that are orders of magnitude more efficient than the naive approach to a given problem.
I tend to think the folks who reach that level are able to do so by a combination of experience and some inherent traits that you can't just pick up in a programming class. An example from my current job:
My employer makes apps. Our app downloads some images over the network when it launches. It caches them so unless something changes there's not much going over the wire, but the initial download can take a while. Up to 30 seconds where the user is stuck watching a progress indicator on the splash screen. At least two different developers had worked on this app. Then the company hired a new guy (not me). One of the first things he did was refactor the image download code to use multiple threads and transfer the images concurrently instead of in serial. With 8 threads the speedup was approximately 5x. His key insight was that most of the images were very small, so much of the total time was latency and not lack of bandwidth. Especially since latency is so high on mobile networks.
Now the previous developers were not right out of school. They had years of experience. They could "program". But they didn't recognize an enhancement with significant implications for users when it was right there in front of their faces. It's possible that if they had been specifically instructed to optimize the image loading logic they would have come up with a similar solution. Maybe, maybe not. But why did the third guy immediately recognize the problem (and put in place a very effective solution) without being prompted? Was that a "skill" he learned in a programming class?
On multiple occasions this same guy has identified long-standing bugs in our app that I'm almost positive no other member of our team would have ever been able to figure out even with infinite time.
Talent helps out a lot in the formative years, because it keeps you coming back again and again even though you suck.
The rest is mostly hard work. Becoming good requires years of practice. You have to unit test your stuff. You have to mercilessly rewrite your own code (I always consider my first effort at anything a first draft). You have to be eager to learn how to improve your skills and constantly devote time to it. You have to be willing to admit you suck before you can improve.
There's a big tendency in junior programmers to think they are rock stars and want to show off to the world how clever they are. You can see it in overly clever, halfassed threading models jammed into half finished programs You can see it in gratuitous use of inheritance and polymorphism and in the reinvention of wheels in regards to algorithms and data structures. It's only later in your career that you get comfortable enough as a programmer to put that stuff aside and focus on doing good work that will be of use to others.
By definition, 10. Perhaps being able to figure things like that out is what separates 10x programmers.
This is my signature. There are many like it, but this one is mine.
in a paid professional environment, terms like 'rock star' and 'ninja' sound like giggly things our children might say about what they were learning in school today.
Our team members have a skill level where they started at hire time, and then they learn and grow from there, both in the general languages and in our platform they work with. Nobody comes in as a 'ninja'. The longer they have been here working and learning this environment, the more we can trust them to lead projects. Everyone either improves with time or eventually moves on to other things.
Is this myth thing about school then?
If anyone needs proof that people who write about tech don't have the first fucking clue about working in tech, there you have it ladies and gentlemen. Edge is a pile of complete horse shit.
it [programming ability] is just a bunch of skills that can be learned
That is partly true. However to be a great programmer you need the right mindset, experience and maturity. A great programmer isn't one who knocks out the most lines of "code" in a day - any fool can do that or someone who writes mind-bogglingly complicated structures (all fools do that on a daily basis - and seem to take pride in it). No a great programmer is the one who can get to the nub of a programming problem and solve it in a robust and clear way and then describe succinctly why that is the best approach.
Sadly most of industry today subscribes to the "rock star" mentality - not just in code hackers, but in most walks.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
If programming is like math (and I think it is in some ways) then the distribution of talent may very well be U shaped. There seems to be a few extremely talented mathematicians like Gauss, Euler, Cantor, Godel, Ramanujan, etc. and then everyone else. That doesn't mean that those like me near the bottom of the U can't appreciate and follow what those at the top accomplish but I think the nervous systems of those who can think so clearly about math are wired in a different way. Maybe so with programmers too.
Professions that are self-eliminating can produce a 'U' shaped curve, measured in employment hours...
Take Bomb disposal as an example...
In my experience the so called "10x Programmers" are excellent examples of the Dunning Kruger effect at work.
Their work is usually hacked together rubbish that is neither well tested and intractable.
Fuck you. I'm the best. I write all my own libraries and never use anyone else's code.
What's for sure is that some of the most celebrated programmers (by management) leave a wake of defects and sloppy work and convince management to adopt horrible platforms.
Ageism (as usual) is not mentioned, though it is just as big a problem.
Support Right To Repair Legislation.
Then you're a fool, because someone out there likely has written it already, and given the length of time algorithms have been around, has likely written it far better than you could ever do on your own thanks to countless rounds of revision.
Is a person under 40 who you can get cheap. After the age limit and salary bar have been passed, the same person finds himself on the other side of the U.
Maybe it's less about the skill distribution curve and more about the "damage" distribution curve -- the idea that those at the low end of the skill curve cause the majority of the headaches.
Sarcasm, motherfucker. Do you know it?!
This one sticks out the most:
Bullshit, in the picture he's wearing a tie.
What is this sarc.asm you speak of?
Would it? I think that's probably true, but I haven't seen any real evidence of that claim.
Higher Logics: where programming meets science.
I've worked with idiots and been told I am toxic to the 'team'. It's common for incompetent programmers to try to drag everyone down to their level, and I view a programmer by the product he delivers not by how some of the others in the team say about him. See, you call it "Toxic" behavior when I have pitched battles with some programmers in a team, but to me its "culling" the idiots from team. They get pushed down and marginalized and that leaves the better programmers to deliver.
Man we've delivered some serious quality software when that happens.
The danger is that an incompetent manager then tries to push these morons back into the middle of the team, and that really just destroys the real team doing the actual work. The good ones leave, the bad ones cry "its too complicated I can't maintain it" and the features get hacked down to their level.
Man I've seen a few projects die a death that way. Crap end products nobody wants to buy.
If the top 10% can maintain it, its good code, its just not written down to incompetent programmer levels, but then again, the customers doesn't give a f*** about the inabilities of a companies coders, they want the best product. It company X gets the top 10% and company Y can only recruit from the bottom 50%, then the customer buys product X. Company Y on the other hand can't make anything nice, doesn't get the sales, even if the code is maintainable by shaved monkeys.
need to learn a new language? no problem, just read the first couple chapters of the textbook (and parts of the glossary) & off i go.
Now im 40... brain no worky right... new languages break thinky stuff.
the key skill needed for programming is to be *able to pay attention to detail*. if you are unable, by any means, to focus on one thing for any length of time (because, for example, you have the attention span of a spider on cocaine or worse caffeine, because, for example, you have been brought up on txting and IMing and twittah) then it should come as absolutely no surprise that you are utterly useless at programming.
another person mentions that creativity is needed in programming. well, yes, this is true. if you have a bug that you don't know how it got there, you need to be extraordinarily patient [attention to detail] with yourself and your work, going over it *creatively* in different ways until such time as you have found, understood and then fixed the bug.
if you do not have the patience because you are, once again, brought up on a diet of twitter, instant gratitfication and refined sugar products, *no amount* of creativity is going to help if you cannot apply it.
i call myself a programmer: what i actually have is obsessive compulsion to be able to pay attention to one task for spans of time that exceed healthy limits. i can be freezing cold and not even notice... because i'm debugging something. only sheer complete exhaustion can get through under those circumstances. this is where it helps to be working in part of a team, as it sets some structure for social interaction. it's no accident, then, that there are entrepreneurs [this goes back a few years on slashdot - there's an article somewhere] who *only* take on *english language* majors [US i presume], and train them to be programmers. why? because people who can *communicate* turn out to make better programmers than people who have been through a university-driven programming course.
There are also some careers where nobody wants a mediocre practitioner. When one's freedom is on the line, nobody wants a mediocre lawyer; when one's life is on the line, nobody wants a mediocre doctor. Therefore, why should it necessarily be the case that companies would want mediocre programmers? Some programming does have life on the line: software in cars, planes, nuclear reactors, or Therac-25 radiation machines; or people's or company's finances: software in banking or stock trading.
There are also some careers where you simply can't succeed at being mediocre, for example any kind of research scientist: if you don't publish good work (and have the kind of innate ability to enable you to do good work so you can publish), you simply won't succeed. How do you we know whether programming is the kind of job where one can be mediocre and succeed?
I've interviewed lots of candidates, many of whom claim N years experience in language X. I'm often stunned at how much many don't know -- stuff that anybody who completes a CSX101 or algorithms or data structures course should know. Is that mediocre?
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
...there is a myth that programming skill is somehow distributed on a U-shaped curve and that people either "suck at programming" or that they "rock at programming", without leaving any room for those in between...
30 years full-time in the industry, NEVER heard that before. There's a lot of companies doing mediocre work who believe their mediocre developers are rock stars. That's because to marketing and management types, successfully getting a computer to do anything at all is magic, and they cannot readily distinguish between ho-hum "accomplishments" and serious ones.
The truth is that programming isn't a passion or a talent...
Bull. Fucking. Shit. This is not a truth nor a new insight, it's just wishful thinking, and this author is far from the first management prick to delude himself this way.
...it is just a bunch of skills that can be learned.
Of course it is. But excelling at it takes certain aptitudes and talent. Confusing "it is a just a bunch of skills" with "pretty much anybody could potentially be as good as anybody else" is just stupid.
If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make programming less intimidating for newcomers.
Well now, that's actually true. But it's equally true that all those jobs ads for "junior" or "intermediate" developers are looking for okay developers, not rock stars. There's jobs for them, and I've never met anybody who expected newbies to excel. So it's kind of an implicit straw man argument--but still, we should all be careful not to drive away newcomers, and keep in mind not creating this (possible) problem.
...the tech industry is rife with sexism, racism, homophobia, and discrimination...
Maybe where this asshole worked ;-) And certainly there are companies where this is true, but how common is it? Where I've worked, I really believe the women and minorities were treated well. Granted I've never actually asked them that question, but then again, exactly how would that make them feel like they fit in?
This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic.
No way. We all know (I hope) that although the 10x (or 25x, or 50x, or infinity-x) must have certain personality traits related to sustained concentration and so on, that when it comes to pleasant vs asshole, they actually exist in a pretty normal distribution. The problem of course is that because they are somewhat rare, it's harder to screw up the nerve to fire one if you think you have one.
And, BTW, there are infinity-x programmers. There are plenty of problems that average programmers would simply not even be able to solve at all--not the majority of work of course. Relative to the amount of work available, problems that require unusual skill to even solve are rare. But given the huge amount of work, there are plenty of problems beyond the grasp of the average...
First linking to a story which says don't read me without a subscription is bad form.
Second, it is true that some folks are less than a pleasure to be around and some are better than others at some skill.
The interesting figure of merit is the smarts to pita ratio.
Many rock stars, especially the ones in their own minds, don't fair well on this rating.
Programming, like other forms of engineering, requires experience, smarts, cearivity, curiosity, enthusiam, and yes arrogance.
Experience gives one a big bag of tricks to choose from when deciding how to do something.
Smarts helps one choose wisely andgives one the ability to think through to eliminate bad paths.
Creativity is needed to make new paths.
Curiosity is needed to imagine new paths.
Enthusiasm is needed to see you through a whole project.
A measured bit of arrogance is also needed to keep one on the path he feels is right when others try to make him stray.
Perhaps the most important skill is works and plays well with others unless you wish to be limited to one person projects.
Each person brings a different set if skills.
To say that this can be put in a single curve may speak of someone who needs a bigger bag of tricks.
The curve shape is more likely a gaussian distribution for each skill on a separate curve and long tails.
The different skills reinforce each other, so there must be some cross correlation.
It is certainly possible to have negative help, so the curves do go negative.
One might try to condense this to a single graph for a specific type of programming.
I'm not sure what the shape would be.
Combining un-correlated gaussians gives more gaussian.
We need a math wiz to answer how the cross correlation would affect the result.
My guess is you still get a similar curve with slightly different tails.
It doesn't feel like this model matches reality, but I think it has to. (The nesessary arrogance thing.)
Meeting folks that are score well on a bunch of these areas seems rare. (Hence the rock star syndrome.)
Meeting folks that score poorly on many of these seems common. (Because most folks are focused on other things outside the model.)
I think this says that to get good programmers, you need to start with folks that score well on enough of these attributes to let reinforcement take them the rest of the way. A rare, good programmer should be able to stay that way if he continually works on his skills.
I have never worked with a "Rock Star" programmer but I come from the camp of actually getting boring things done so ymmv. I found the skills to do my job can be learned.
I have been able to distill what took me perhaps 20 years to learn on my own and have been able to mentor one person starting out as a "waste of seat" into someone that will be able to function at least at my level. It took about two years. To begin with my productivity was at least 10x his, maybe more. A year ago it was still about 5x, now the factor is not significant and dependent only on been there done that, basically the difference is time served.
I am now working with someone without any of the advantages of education or personal enriched environment the other fellow had so we will see. I have already seen great strides from this new person - it might take a bit longer but the only roadblocks I anticipate are will, motivation, and opportunity.
I have tried to help two other people that started out between these individuals in ability. The first thought he was a Rock Star (NOT) and is now doing an excellent job in management after years of non-improvement. I could have moved his game up immensely since he actually does have more raw talent than I do but he was better than me in every way so ... he wouldn't let me and finished his programming career with maybe half my productivity instead of 2x better... The other fellow - time will tell - but he has more talent again. I suspect this is just a job and job hopping will lure him away - so why bother learning anything to be better?
The reason you see the U curve is because, in general, there is no value attached to passing on skill. Where we are the pickings are a little thinner so you have to make due with the talent you have and my employers have figured this out.
Without effective training you will get a U-curve because programming becomes a medieval guild system. Those in the guild with all the secrets building cathedrals and those outside bashing two pieces of wood together. Most professions have figured this out and function more effectively on a more normalized productivity curve.
What axes are you using? Claiming to know anything about a distribution without defining your population or even your axes seems like a lesson in futility and just adding to the confusion.
Ok, I'll bite: It's not what you manage to program, but what you manage TO DO with it: The End Result. The bottom line. The optimal goal. Your reason for doing what you love, etc.
This is the reason there's so few Bill Gates and Steve Jobs' (two opposite ends of the spectrum) of people who really succeed in the IT software world.
What about the programmer you ask? Yeah, how far do you think that person can come if not for the ability to utilize or monetize it in some practical and valuable form?
You can have a rockstar programmer at your fingertips, but that rockstar will usually not provide anything useful (End Result, remember, not "perfect code"!) without the bright idea, stamina and resources to follow it through. If you have the latter, you don't REALLY need a rockstar, you just need reasonable people willing to put up the work and effort to make it happen, usually for the right incentives. Maybe a rockstar helps at critical junctures, but will very quickly become a liability if left to micromanage everything and everyone for too long. There is the fact too though that most people don't have the logical reasoning and stamina required to program much beyond infinite for-loops and "hello world"s.
There's also a reason why sequal to movies and books more often than not sucks. It's really tough to "manufacture success". People who think success is manufactured are the same who belittle those who lead the way at the time without anyone noticing it. Sometimes these "little people" get ahead enough to make their success. Most often, they, like unrecognized artists, are left to rot in obscurity with their bright, unrealized ideas and ideals (not a bad thing, just too hard to follow-through sometimes).
Programming is bimodal in the following way: People who think logically and people who don't. Among those who think logically there is a variation of skill from average to great. Among those who don't think logically there a a variation of skill from ineffective to destructive.
I once finished a product in one afternoon, that another programmer (well sort of) didn't manage to get working in 3 months. But then, the other programmer was a total incompetent, who did not listen, and refused to learn anything new.
So he tried to do in C, what I did in Tcl in a few hours. Epic fail.
So I've once hit the factor 1000, but generally the difference is not so big.
I see, I wish /. let me edit my comments, so I could correct "poeple" and "accept".
Linux is for people who don't mind RTFM.
Then, we must rebuild a new and proper programming community, and will adhere to strict guidelines according to gender, race, and sexual orientation.
The programming part - as the evidence plainly indicates, can be done by anyone, so that isn't a hiring criteria any more. Hire them for the correct social aspects, and they will be churning out better code in a day or two.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Says who? It would in fact look like a Pareto distribution, with some sort of long tail. Such distributions are common and to be expected in human affairs and human mental capabilities, which are not subject to the central limit theorem (which is what typically leads to a normal distribution in physical measurements).
Rubbish. If they have to revise their code they obviously suck at programming. I never revise my code, because I am the best.
Potential programming skill is very much bi-modal, just like any other skill that requires abstract thinking. You have it, then learning makes sense, or you do not. Same with most engineering fields, mathematics or physics. Of course, the rockstar vs. cretin comparison is utter nonsense, and just dishonest propaganda language. You just get two Gaussian distributions with not much in-between. "Rockstars" are still rare (and generally not very useful). I have seen this time and again in fellow students, as a teacher, as reviewer etc.
The article is another transparent attempt to make people believe coding is like manual labor and hence should be in the cheapest salary class possible.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Jake Edge writes at LWN.net that there is a myth that programming skill is somehow distributed on a U-shaped curve
Been doing this shit for 20 years, 10 (very) different companies, using different languages and technologies, for app and system level development, working shoulder to shoulder with a very diverse bunch of people. I've never heard of this myth till today.
If I were to be forced to pull guestimations out of my rear, my impression has always been the following:
1. that programming talent distribution with the X axis representing some quantifiable function of both talent and experience (two different things) closely resembles a normal distribution with near zero kurtosis and a slight, but measurable skeweness to the left. The skewness to the left results because, in my experience, lots of people leave the field or stop being active in development before getting to the next level of experience, engineering and craftsmanship. They leave because they suck or don't like what they do, or because they do a perceived beneficial lateral move into management or sales/sales engineering. Less and less people remain in the field honing their skills and making the transition into technical lead/more senior positions responsible for more complex problems.
2. The probability of introduce massive numbers of WTFs per code change sets (or introduce a single massive WTF in a single code change set) as a function of talent and experience resembles an exponential distribution. No matter how experienced you are, you can still fuck it up badly, but the probability of doing so is inversely proportional to your talent (or at least, it should be inversely proportional to your advertised talent.)
I suck brilliantly at programming. Arduino is my enabler.
Seems to me that there are two ways of looking at this. Are you basing the evaluation on the finished application or on the quality of the source code/architecture? I've seen really dreadful source code that doesn't follow good standards an practices common in the industry yet has impressive results. I've also seen coding requirements be so complex as to hinder the development process.
Hugh Pickens, the British wannabe-programmer forum troll, posts more BS fresh from the island of marmite.
This time he is channeling Jake Edge, a person much like himself, i.e., a wannabe-programmer from Merry Old England who spews 100 lines of opinion for every 1 line of code he has ever written.
Why do the Slashdot editors think this stuff is interesting? I think there must be some British Slashdot editor who keeps pushing this garbage.
I have known people who were passionate for programming... but they were terrible at it. And people who were passionate at something else but managed to write some damn good code... when they were required to as a tool to solve a problem in some other domain. I was a total computer nerd as a kid, but now I don't code for its own sake most of the time. (Actually, I do sometimes, but not anywhere near what I used to.) Now, I mostly code because I have to. I enjoy it, but it's just a part of bigger things I'm working on, and those problems (a lot of them in circuits) are what I'm passionate about.
I have another thought to put programming into perspective: I know CS professors who are _fine_ at coding, but some are way better than others. That varying coding skill has nothing to do with their effectiveness at the job, because they're scientists doing research, most of which doesn't relate to coding per se.
having grown up with computers certainly helps, but this is a profession, a job. And it can be learned.
They seem to be all over the map, in good ways and bad. Geniuses who can't ever seem to finish a project. Good, solid, mediocre developers who churn out working, but unspectacular code year after year. Quite frankly, I prefer the latter. They can make you profitable. Eccentric geniuses? Not so much, and quite frankly, not worth the effort. If you feel it necessary to write a compiler in assembler, more power to you, but do it on your own time. It has no impact on our mundane, memory-inefficient, but maintainable C# apps.
Please do not read this sig. Thank you.
It's probably less about sour grapes than it is about the image of a certain kind of coder which makes for a good story.
People like their assholes. They don't like being too close to them, but they like assholes who cut through the "bullshit" and make things happen.
News outlets tend to pick up on those stories and people who are assholes tend to encourage that, because some star coders are just assholes and like the idea that their particular dysfunction makes them seem hip and employable, as opposed to being relegated to a closet somewhere.
The reality is that there are excellent coders of both the nice and the asshole variety. It's just that you don't hear about the nice ones because they're not grandstanders. The assholes tend to be.
If given a limited budget and resources, I'd probably pick the star coder, even if an asshole. I think the real issue with a 10x coder, as opposed to a team of average coders is the overhead of managing a team of coders. If you have one guy, he has one vision and it doesn't have to be transmitted to and adopted by the team. This is useful for certain projects.
For other projects, where you are not going to be able to get any one person to be able to finish it, then team dynamics become much more important, and it becomes much more important to not have assholes on your team. If you're forced to have an asshole star developer, then you need to find people who will execute that vision without complaint. At that point, you're going to tend toward worker bees instead of highly skilled individuals because you don't want a religious war between the the two assholes writing your code.
However, if you lose the assholes, you're much more likely to find a team of above average coders because they can actually work together without trying to backstab or snipe at each other constantly. You don't need to limit yourself to coders who are just puppets of the asshole senior coder.
Don't get me wrong, puppet coding can certainly work, but is probably something you only really want in a short term startup where you can have that vision, without having to deal with larger teams.
I think the multi-modal nature of distribution is due to pulling a bunch of programmer levels together.
Programmers have certain levels of thinking, some programmers are able to reach the last level, many people never even reach the first. I forgot the full list, but here is my attempt:
- Variable substitution
- Sequential statements and memory model
- Multithreaded programming
- Temporal programming
If you remember high school, you may remember that lots of kids couldn't even wrap their heads around that symbols/variables in expressions are a substitution of numbers.
The next step, which teachers have noticed in university, even if students are easy able to understand expressions with variables, many will never be able to understand how variables can change through sequential statements.
Multithreading programming, most professional programmers will reach this level. Being able to lock data that is modified in two different threads.
Most programmers will never reach temporal programming. These programmers are able to create mutex primitives themselves, or make data structures that can be accessed/modified by two threads without locking.
These levels quantises programmers and therefor you get a multimodal graph.
Just another attempt to make the unexceptional feel good about themselves even though they neither deserve nor earned it.
Hammer down the (exceptional) nail that stands out, because he makes everybody else uncomfortable and insecure.
Coming to an industry near you, public education's "You are special!" travelling circus. Hurry! Sign up for your group therapy sessions today before it's too late! Wait, that's inconsistent. We'll still take you if you're 30 min late. Because you are special!
Wrong. I often end up writing things on my own because of either a) issues with the library or b) it doesn't have the feature I want.
Ive been hiring and evaluation software developers for 20 years, and my anecdotal experience shows that he is completely wrong.
There are top programmers for average 10 times as much work, and never write the kind of bugs that make a team work through a weekend, and there is everyone else who plod along, and tend to do the minimum to get by, and no matter how long they chew on a problem will never quite achieve the same level of excellence.
The main difference seems to be how much they enjoy writing software. Those who love it learn constantly, care about the result more, and simply keep themselves sharper.
I will say its not a U shaped distribution, more of an L shape really. There are 50+ average developers out there for every ubergeek. There is certainly a demand for average coders as well, some are quite brilliant in their own way, having a speciality or else just being great maintainers or troubleshooters.
Most of the classes I've taught - math, chemistry, physics - have a bimodal distribution. It's a reflection of the two kinds of students. Those that are committed to school and those that have other things going on and are on their way out the door. The distribution for the top end is more or less normal.
46 & 2
Wrong. I often end up writing things on my own because of either a) I can't figure out how to use the library or b) it doesn't allow the bad coding practice I want.
The top distribution are the students who are committed to school - and that is more or less normally distributed. The bottom end are the folks who have other stuff going on and are on their way out. My experience, and that of my colleagues anyway.
46 & 2
Companies I have worked for outright think in binary:
It has unfortunately become simiar in other trades; if it is highly custom specialized woodwork for a mansion, hire the top-talent carpenter; otherwise might as well hire illegal immigrants to bang nails.
It has not always been this way.
is that programming is just like any other skill. You can learn it if you work at it. Sure, some people are born with a natural aptitude for it. I'm pretty sure that the first time Linus Torvalds tried computer programming he could probably tell that he was going to be really good at it. I'm sure that after Michael Jordan's first game of pickup basketball he probably knew that he was a lot better than the other kids he played against.
Those are the rock stars and every profession has them. But that doesn't mean that you can't be a good programmer by simply working at it and learning your craft. Some people are late bloomers. Effort and dedication can take you a long way. It's a mistake to discourage people simply because they are not rock stars.
I think I'm a pretty good programmer but I'm not in the top 1%. I'm OK with that. I enjoy it and I make a good living at it. I'll never be as good as Linus but I'm happy to be doing it for a living.
Sports
Music
Art
Music
Math
They all have the same lines.
-Suck
-Amateur
-Champion.
Why is there this reoccurring programing is special. It is like walking, Most people can do it , and do it well.
It might be because there are a lot of Amateurs that think they are Champions.
With programming it is harder to tell.
Amm... anyway, most of the programmers I've known over my career have been average. They don't seem to particularly enjoy programming but they can generally make the computer do what they want it to do. Then they're quite happy to go home to their families and do other things. I've run across (and had to clean up for) five or six truly inept ones. And I mean people with no ability with computers whatsoever, who were essentially defrauding the company they were working for. Usually those people had left the company by the time I'd gotten there.
I've never met a true rockstar programmer at any company, although I have met a couple in Linux channels on IRC. I got to audit the source of the AT&T C standard library on a contract in the '90's and a lot of that stuff was brilliant. I wish I could have worked with the programmers who wrote it.
Me? I'm not going to try to appraise my own skill at it. I enjoy programming and do it at home. I've retrofitted several projects with data structures and will fix crashes that other programmers tend to ignore. I've also been told code I've worked on is easy to understand and maintain (By people in other countries who it was outsourced to.) I prefer not to subscribe to institutionalized learned helplessness that dictates that the software works that way because the software works that way and nothing can be done to fix it. I have several github repos where I work on things that interest me at the moment, mostly licensed under the Apache license. That may make me different from a lot of programmers, but I won't argue that it makes me any better or worse.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Most myths contain an element of truth. The truth is that computers are very unforgiving to software code which is not exactly, precisely correct. Few human beings are capable of operating near that level precision in any intellectual activity, let alone coding. Fewer still are capable of self-checking their results to catch the errors.
So until we develop a DWIM interface (do what I mean) there is and will be a sharp line between the folks who are good enough and the folks who aren't. There's a limited amount of difference in work product between the folks who "aren't quite" and the folks who "aren't at all."
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
A good designer rolls his own, a great designer fixes what exists and spends his time on something new.
Wait, did I just invert that U?
If there was only a 'preview' button...
Required reading for internet skeptics
I've been around a while, and I agree there are what can be called "elite programmers", but with a caveat. Such people are "masters of code", but generally they are not very good communicators, and work on projects and niches that require a high degree accuracy, fastidiousness, and debugging skills. They often work on systems software, such as OS's, database engines, network control software, weapons control systems, etc., and are usually paid quite well.
But they don't do so well when the requirements are fuzzy or change often. They don't handle ambiguity well.
Of course, this is probably an oversimplification, and possibly a feedback loop where one that is highly "code oriented" will tend to be given yet more code-centric projects away from fuzzy office politics and fickle customers such that they don't develop their "fuzzy" analytical skills. Thus, they are not necessarily inherently "bad" at dealing with Dilbertian chaos, it's just that they lack experience with it because they went into a field or niche that is more technology focused, which helps keep them away from office politics and goofy users.
It's hard to master both human nature AND machines in one lifetime. Those who focus on a mix of both are probably in-between skill-wise between people and machines, and this is where the majority of developers and developer/analysts are.
And of course there are exceptions to the rule: some master both, but those are rare in my experience. (Those who believe they have mastered both are common, but egos tend not to be accurate to their owners.)
Table-ized A.I.
How many people are really willing and able to sit at the desk for hours on end, without any human interaction, all to figure out an abstract problem? How many will enjoy such a career for a decade it takes to get really good at it?
The patience, intelligence and introverted personality required may all be on the bell curve, but one has to be on the vanishing end of it to be a key contributor to the project. Others can certainly learn how to complete a 3 page class assignment, but will be miserable if they have to code most of their wakings lives.
I would argue that quantities required are so unusual that a great programmer is always going to have difficulties in social relationships with people in the middle of bell curve, even if not to the degree that can be considered autism spectrum diagnoses or any other disability.
Correct.
/. article(s) and/or their submitters.
The only thing I know of on a U shaped curve of Awesome and SUCK are
Actually it looks more like an L shape, with the high point being suck.
But I keep coming for the commentary.
Look around you. 10% are really bamboozled by [Insert skill here] and 10% are streets ahead of those that get by. Maths, Foreign language, social skills, drawing. (Skydiving may be an exception.)
Have you heard of BAD-GOOD-BEST clinical governance? 10% of clinicians lead and make big efforts to study and improve. 80% 'keep up more or less'. 10% are drunk and/or good at covering up their lack of competence. (See http://vulpeculox.net/ob/index... and follow the bad-good-best link)
Let me also draw your attention to the '10% rule' in gene-controlled attributes. Left-handedness, Harder tooth enamel and so on. IMHO this is an evolutionary insurance mechanism (nothing whatsoever to do with the subject) so that if there's a mass-wipeout type event then there may be odd-balls who are far enough different to survive.
From TFS:
Since you can't measure programming ability "somehow" or otherwise, you don't know what the curve would look like. Which reveals the entire set of claims here as utter garbage. If you don't know what the distribution is, you don't know what the distribution is. How difficult is that to understand?
I've fallen off your lawn, and I can't get up.
This just in, unicorns aren't real either... programming like damn near everything else is a bell curve.
Most people are okay at it if they put some time into it. A minority are hopeless and will never be useful and a minority will be rockstars.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Some of us just have different metrics for drawing a line between "programming" and "stumbling around in a programming language doing dangerous, stupid, and occasionally functional things."
But, hey. If you can set your digital alarm clock, or interact with your microwave in such a way as to involve more than one button push (even if you're going to destroy the comestible), you're a programmer, right?
It's like kids with crayons. They're all artists! Special butterflies! Call the Louvre!
Now get off my nursing home's lawn
I've fallen off your lawn, and I can't get up.
Rock-stars aren't toxic: they are disruptive.
What you do with the disruption they create is up to you: embrace it and elevate everyone else, or reject it, and continue with mediocrity (and maybe keep him as an ace-in-the-hole for skunkworks and one-off solutions where time is a key factor, and unleash the disruption when the time is right).
The companies that have a "stable" development pattern in which the feature development pace, bug rate, architecture, and organizational tools are "good enough" should not hire rock-star coders. They will be frustrated with everything you *aren't* doing, and all the other developers will wonder why he wants to push for more: after all, this has been good enough, right? Inertia will kill any ideas he has for improvement.
The companies that have highly-locked down roles and restricted responsibilities shouldn't hire rock-stars: you will underutilize them, and they will be frustrated with a lack of ability to "just get it done on my own".
Rock stars work well only when they are surrounded by true peers, and everyone is operating on their level, or they are in charge (at least technically) and can fill in a mentor role with not-quite-peers (and are given reduced responsibilities in other areas to compensate time-wise). This almost never happens: rock-stars are seen as too good to not be coding.
The existence of programmers who are dramatically faster/more-skilled than others is not all that controversial, really. The question is whether they have to be assholes, or you should put up with them if they are.
My experience is, the majority of the really brilliant programmers I know are not assholes. They might be a little light on tact, but they are generally pretty good at cooperating and listening. If they weren't, they wouldn't be nearly as good.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
When James Gosling was determining what language to use for his VM, he originally looked at C++. But he found that most programmers had a hard time with the non-C parts of C++. So he pointedly created something which avoided those advanced parts. Originally called Oak, we call it Java today.
In short, he created a dumbed-down language which was usable by "most" programmers. He wasn't shooting for the top of the bell curve; he wanted "most" of it. Java is a stretch for truly clueless programmers (I'm acquainted with some people who "just couldn't get Java") and annoying as hell to the truly great programmers.
So I don't know where we keep getting this myth that programmers either stink or rock. Most of the Fortune 500 is actively looking for Java devs. Most of them won't put up with people like Linus Torvalds (a self-described "opinionated git") but you need to be able to wrap your head around the basics of functional decomposition and object-oriented analysis and design. So, you need to be at least mediocre. Java has become the COBOL of the modern era. And you certainly didn't have to be a rock star to write COBOL.
... by the Dew of Mountains the thoughts acquire speed, the hands acquire shakes, the shakes become a warning
The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned.
Then why do so many "programmers" not have these skills?
Programming isn't even one thing, though people talk about it as if it were; it requires all sorts of skills and coding is just a small part of that. Things like design, communication, writing, and debugging are needed.
The problem is that too many programmers don't realize that they don't have these skills and pretend that they do. They you get stuck with poor design or buggy code. Even worse is that many of these areas have massive overlap. You can't design a good program unless you know how to program and debug. You can't program a good program unless you understand the design. etc etc.
I guess what I'm getting at the programming is a poster child of "the whole is greater than the sum of its parts", by a huge amount. Each skill is a multiplier for all of the other skills. With so many overlapping skills, someone with all of the skills is suddenly magnitudes better than someone with slightly fewer skills.
My high school calculus teacher observed that the marks for that class over decades of teaching tended towards bimodal. To some extent, either you "got it" or you didn't.
This post (https://gasstationwithoutpumps.wordpress.com/tag/bimodal-distribution/) based on USA stats for 2010 suggests that "many of the exams that require math had this sort of bimodal distribution."
How does one measure how good someone is at programming? Even once you get past a A > B, you still need to assign a numerical score to them. You can get both the U shape and a standard distribution from the same sample by simply redefining how you assign numeric values to the data points. Another thing to note is that programming is a single skill. You don't measure a person's ability based on number of lines of code they generate per week. Some programmers are better at architecture, others at understanding existing system. Some can make really efficient linear programs, others can build fault tolerant multithreaded applications.
Often I reinvent the wheel because there is no other wheel that fits. If someone else has invented then it's proprietary and I can't get to it.
Ie, right now I'm working on a new product that has only 16K of RAM when the previous product had 4M, and there's a lot of challenges. I see code that claims to be small and memory efficient doing similar things, but when actually looking at the source they tend to be bulky in practice.
In the past I've seen lots of open source code that while very good for their environment (a big fat computer with lots of horsepower) end up not so great in different environments (size or speed constraints, customer requirements, etc).
Another example: if you've got multiple open libraries doing the same thing, don't just pick the first one. The GNU gettext library was rather largish and more difficult to read than the BSD gettext library. And besides the GNU code is forbidden to be used anyway if you can't use dynamic libraries.
I have sadly seen many cases where the code ends up being crap because some programmer insists on only using preexisting libraries, relying on marketing of the library as to their quality, and it seems no actual code of their own except to slap things together. Ridiculous stuff like using STL maps when a simple look up table would be smaller and faster, or using a boost library when the project already had code that did the same thing in a better way.
It's not bimodal but 10x rule still applies.
There's no point in trying to assign a ratio to it, because the worst developers have zero or negative productivity, on account of the damage that they do to projects by checking in inordinately complicated code that fails mysteriously, or simply by messing up everyone else's schedule by failing to deliver their part. This is not a hypothetical argument; I have several specific people from my personal experience of corporate development in mind (all in the past, fortunately.)
The summary and comments often focus on what Jake Edge said where in fact, Edge is summarising what Jacob Kaplan-Moss said at a conference. The merits of the points made during the presentation can be discussed on their own but there seems to be a lot of vitriol aimed at Edge that has no basis in either fact or logic. Aside from an inaccurate summary, it's also sad to note that slashdot used a "subscriber link" feature which was meant to be used by a paid subscriber to share an article with a small number of people until it was free a week later. The feature was not intended for sharing with the entire audience of slashdot. That is just poor form.
There was a book years ago called "Drawing On The Left Side of the Brain". Now, I was always able to draw. In grade school I was the kid the teacher would get to draw posters and stuff. But my brother couldn't draw. I gave him this book, and, a couple of days later, he could draw. I think what the book taught was not to put too much into the image. One of the tricks was to try drawing from a picture of a person that was upside down. That way the student concentrated on the lines that create the nose instead of the nose itself for instance.
I wonder if people who have trouble programming aren't, in a way, trying to put too much into it, making something that should be simple, hard, because for instance, they don't break a problem down in to simple enough steps.
Maybe it's all just about those who 'get it' and those who don't, and nobody has figured out what to tell the ones don't.
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
Maybe it's because rockstar ninja is the only tier anyone wants to pay, hire, circulate. I could hire Alice and get 40 hours of standard results, or I could pay Bob slightly more. He's not "addicted" to coding but he gets workaholic sometimes. He can be obsessive and thorough if something flips the wrong switch in him. He can easily be manipulated into overtime, side projects, etc.
Why hire a moderate-effective, moderate-paid, moderate-jobsatisfaction Meh drone when you can hire a sucker?
Over nearly 2 decades I work in IT, in most teams I worked with SOME of the guys could do more than 3-5 others together.
Also it had little to do with experience, some guys were just damn good, right out of the university.
I've also seen plenty of very experienced, yet very poor coders.
So no, not just skills you can just learn.
If I like the work environment and the work.... the money is not as important (though I do like to be paid well).... but if I am not happy with either, I demand much more in compensation.... (I have been in both environments). If that makes me a sucker, I want to be a happy sucker.... Most people in this world are not happy at their work.... which is pretty sad....
That wasn't on the Mensa exam.
Only SEEMs bimodal. The vast middle never talked about; only the extremes are commented on.
sigs are for losers (except to point out that sigs are for losers)
Reading the comments to this article, hey guys, no real life programmers commenting on this? Programming is not about programming. Neither is it about design, communication, writing or 'debugging code' - or fast typing. Programming is primarily about solving problems effectively - big and small ones. Programming is something that should bring you from a defined state A, over unknown and hostile territory to a defined state B. The rest is just a toolbox you gain over time. On this point I fully agree, the toolbox can be acquired by almost everyone. However, problem solving skills is a complete different matter altogether. Everyone has a certain mental ability about this, but my personal and professional experience tells me that this is not something you can improve indefinitely just be 'practicing'. There is a limit set out for everyone. Once someone hits his personal limit, that's it, that will be all he will achieve, sorry. Of course, management will always ask if someone can be pushed a bit further, 'it must be possible, he has been here since 5 years, he should be a senior!' (but only in age). But its like tuning a car engine: there is a limit no matter what. And the last 10% cost you 10x more than the first 90%.
BTW, WTF is debugging?
Programming is a lot like music. The best composers know which songs are worthy of having phrases stolen.
also, remember that high pay != skill. There are plenty of musicians that aren't particularly skilled at playing music that make a lot of money because they are good at entertaining.
HA! I just wasted some of your bandwidth with a frivolous sig!
Yeah, but actually no. Each skill set is different. I could write you a PCB router in under an hour, or whip up an image processing mechanism, layered image editing, signal processing, write an FFT from scratch. I can do assembly coding as fast as I can type while higher up, I favor c and Python for their various and highly disjoint abilities. I'm good at documentation, and I can manage effectively -- without getting the team to hate me. But fizzbuzz? Sort of boggles me. I solve it very slowly. Perhaps because there's no point to it and I don't really give a flying crap. :) But perhaps also because it's just not my thing. I despise puzzles-for-the-sake-of-puzzles, and avoid them like the plague.
Bottom line, any type of interview question or test will sit poorly with some high quality programmer. Some don't know a language, some have an unusual process, some aren't great communicators, some don't function well with someone staring at them or under immediate pressure... there is no perfect interview method, and surely no way to determine programmer competence outside of their actual accomplishments -- which, even when you can pull it off, is not the same thing as measuring their skills against others, placing them in an objective relationship to the skills of others, either.
Personally -- and this is strictly anecdotal, but reflects many decades of experience -- I've had a lot better luck asking many-possible-answer questions about techniques and areas of knowledge in a friendly, low-pressure atmosphere where the interviewee is made to feel they are welcome and respected the moment they walk in the door.
I've fallen off your lawn, and I can't get up.
The LWN article is not an essay by Jake Edge. It is in fact a report on a talk given by Jacob Kaplan-Moss.
I am so jealous of Jake Edge, because over the past few years of trying to re-enter the programming field with no response from employers, I have come to exactly the same conclusion -- but he has nailed the problem. The companies are all either looking for a programming god to whom they will offer six-figure salary+benefit packages, but will "reluctantly" accept H1-B greenies who will work for approximately minimum wage, when you factor in the typical 55-hour per week software development project death-march. Now we need someone who can nail the solution.
with most open source libraries the first issue is usually the biggest problem. Documentation and APIs are terribad then you try to look at the source to figure it out then you get to experience the second issue.
" how many developers does a 10x programmer have to drive away before it is a wash?" 10 ?
The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned.
Programming involves a strong understanding of logic, which most people have absolutely no grasp of. Logic is a skill that cannot just be learned. If a kid's parents don't teach it at a very young age, then it won't be learned, and that is not recoverable, and that kid's future children will also not learn logic. Today's zero-danger and zero-consequences everybody-wins learning environment for young children in the U.S. is irreparably harming our future.
Briggs-Meyer is another theory that seems to assume U-shaped curves. For that reason (ok, other reasons too...) I'm skeptical of it. Why shouldn't most people score in the middle of the various personality scales B-M uses?
Programming skill and talent (separate - skill comes from learning and practice, talent describes innate efficiency of developing skills) distributed in the population are likely approximated by a normal distribution, simply by the law of large numbers. The mean may be painfully low, and there may be an extra bump in the distribution at the high end, due to financial incentives to develop skills.
The culture likely wants to view programming as the U-curve, just as it tends to view medicine, teachers, police - any special career.
Financial incentives try to reinforce this. You are a programming genius and you can be hired to do cool, hard stuff, because you have done it before - and the market will force me to pay you lots, and you will gain more experience and be able to turn the crank again for similar rewards. You are not a genius, therefore you are a complete idiot, because I want to pay as little as possible for what the market tells me is a very fungible, widely available lowly resource. In actuality, you are somewhere in-between, but that is much harder to deal with to negotiate for your services. So, I want to think you are a waste of a chair or Grady Booch (pick a software programming rock star of your choice), because those two cases are easy to understand.
experience = expertize
Anything can be a passion, depending on who the hell is passionate.
Anything that is a profession has a concept of talent. There are people who do better and worse at any given thing. There are many people who probably could never program. It's not their thing. Maybe they'll be a musician, or maybe they'll be a construction worker.
Ultimately SJW/10.