SoylentNews is people
SoylentNews
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?"
(Score: 5, Interesting) by bradley13 on Tuesday May 05 2015, @11:48AM
Being able to program well requires certain abilities, for example, abstraction and logical/mathematical thinking. Given those abilities, someone can learn to program. Likely it's true that those abilities are distributed on something resembling a normal curve.
However, there is a threshold effect . Someone of average ability may be able to write toy programs, but that isn't useful. Real software systems are much larger and more complex, and require an abstraction ability pretty far on the right of the normal curves.
My feeling, from many years of teaching programming, is that you need to be in the upper 10% of the population. The other 90% may still be able to find a role in software, if they want. Testers, QA people and technical writers are all essential, and a familiarity with programming will be helpful. But they should not be developers.
Everyone is somebody else's weirdo.
(Score: 2) by VLM on Tuesday May 05 2015, @12:21PM
One interesting aspect is writers definitely follow the 10/90 rule or whatever where the best are really productive, the rest just kinda fill space. So you want to hire a tech writer based on being a good writer, not the "89th percentile washed out programmer".
On the other hand its possible to run QA where the QA dude is a hard core diagnostician where the 10/90 rule applies (probably more like 1/99 or worse) or you can run QA where you're basically torturing thinking human beings into mindless test driven development robots without the automation, and managers like that don't need or deserve more than minimum wage workers to strictly work off a procedure.
Looking at the management impact in the second paragraph its probably possible to mismanage a dev group the same way its possible to mismanage a QA group such that you get the weird result where skill has no effect on team output. Higher functioning ability doesn't matter if applying that ability is forbidden by mgmt, in QA or dev, intentionally (micromgmt) or accidentally (crappy open office, etc). So its possible the presenter dude never had a decent manager or a decent job so he logically assumes his experience means that no programmers can benefit by talent because he's never seen it or experienced it. I would imagine if your only experience with boating/sailing is being an ancient world slave chained to an oar, you wouldn't really see the romance of the sea or enjoy sail boat cruising very much and you'd have some peculiar ideas about the "right way to run a boat".
(Score: 2, Interesting) by GDX on Tuesday May 05 2015, @12:43PM
Actually there are no only one Threshold, there at least 2 Thresholds, I have observed that the distribution is actually similar to a normal distribution but with 2 valleys, on really notable that separate the people unable and the people able to program and other less prominent that separates a the normal programer (code monkey) from the good programers (developer).
(Score: 1) by Ethanol-fueled on Tuesday May 05 2015, @02:02PM
Salesforce.com has a "feature" where if you choose to edit a record, and somebody else is editing that record, it gives you NO WARNING that all the changes you are making to that huge record will be rejected and discarded because somebody else decided to edit that record before you did. All without any kind of warning until you've wasted all that time making extensive edits to a record.
You could use e-mail and shot-gun-e-mail everybody involved asking for them not to edit the record, but you might miss somebody who got up from their desk while editing the record. Either way, coordinating around it is also a messy waste of time.
Salesforce.com. You'd think that was a solved problem in computer science 10 or 20 years ago.
Maybe those 10% of people who deserve to be developers should be working on only those 10% of projects that require superhuman cognitive abilities. If those other 90% are good enough for Salesforce.com, they're good enough for anybody else.
And I'm saying this as somebody who wants to discourage people from learning about computer science because I'm gonna graduate fairly soon and want as little competition as possible.
(Score: 2) by Grishnakh on Tuesday May 05 2015, @02:26PM
That's because this kind of development (closed-source proprietary software) is feature-driven and run by managers. What you're talking about isn't something that customers ever complain about (remember, the customers are managers who buy the software, not peon employees who actually use it), so Salesforce.com's managers never bother to allocate time to actually fix the problem, since it's more than a trivial fix.
(Score: 2) by tibman on Tuesday May 05 2015, @03:32PM
Record locking or something similar doesn't seem difficult and it's probably on a very long todo list. At the top of the list are new features that companies on the fence want. At the bottom of the list are non-critical bugs and "nice to have" features that greatly improve the product but don't actually make any money. Polishing products doesn't seem to be taught in any business school.
SN won't survive on lurkers alone. Write comments.
(Score: 1) by tftp on Tuesday May 05 2015, @10:09PM
Record locking or something similar doesn't seem difficult and it's probably on a very long todo list
This requires some button to "check it out" and, after editing, to "check it in." It's a change in the workflow, and as such it has consequences.
(Score: 0) by Anonymous Coward on Tuesday May 05 2015, @03:07PM
I'm a QA lead, and disagree with that statement. Sadly many big firms have QA driven like monkeys. Follow some procedures, that's it, so when I see those on a CV I usually do a phone interview up front, weeds out a lot with minimal time wasting.
However, my interviews for QA engineers are a lot harder than for developers, not only do they need to know the stuff developers know, they need more general knowledge to and a good testing mind set on top. That's for my normal QA engineers, performance testers is another ballpark, there's no such thing as a junior performance tester.
Secondary, quality usually suffers a lot when you get only drama queens/rock stars as developer, usually for the same reason: if it installs on their box with their tools, it's installable and they're happy. The more rock star developers in a team, the easier you'll encounter these stupid shit bugs that shouldn't even have made it to my team.