Citation missing, but I've read a paper that claimed rather convincingly that you need a certain mindset both to be good at programming and to enjoy programming (unsurprisingly, this comes hand in hand).
It's not really problem solving, it's rather a specific kind of structured thinking. It's the attention to detail and the will to think through every aspect of an issue, to find a complete solution. That's also a useful skill outside of software or even engineering (I'd imagine law isn't all that different in that regard), but apparently it's really critical for software engineering. At the same time it's not necessarily linked to general intelligence or problem solving ability or creative thinking, it's just a particular way of approaching problems.
Said lost article had tests showing that only a small fraction of the population thinks this way, something below 10%.
Of course this isn't proven, but it matches with my personal experience. This always makes me very skeptical of things like end user programming, or programming as a mass profession. People without the skill can create programs, in particular in environments, but the results are usually quite fragile and expensive to maintain. "Real" programmers can usually create much greater value at lower cost, so there really isn't much of a point in employing lots of "not really" programmers.
I agree with you: what we think of as 'pro' programming -- writing large programs in formal languages and running it past an interpreter/compiler -- is probably only something the few will really get into.
However, there's a couple of exceptions to this idea I'm not sure how to handle.
MS EXCEL : It's a programming experience, of a sort, and is incredibly popular. I think it uses similar skills to writing code, but is just much more 'gentle' on the brain. There's a programming nature in excel formulae;
=SUM(A3:A14) / COUNT(A3:A14)
if you see what I mean...
BASIC : Back in the 80's, everyone and his dog had a go at BASIC programming. Most of my friends and their dads got their hands dirty typing in programs from magazines. It suggests that getting lots of people involved in simple languages might be feasible.
Yes exactly! There have been times in history (pre-printing-press) where most people couldn't even read. I'm sure there where many scribes who would look down their noses and say that the common man would never take the time to read for himself.
Our society has grown to be incredibly complex. Imagine taking your great-great-great-great-great-grandfather and dropping him in modern times today and asking him to fill out the forms to get a drivers license, prepare his own taxes, set the clock on your dvd player, or send an email on an iPhone.
I guess my point is that the "common" man is pretty capable of feats that would be considered extremely technical from a historic vantage point.
I was also about the use writing and reading as an example of knowledge that used to be limited to just specialized roles. While there are still professions that deal exclusively with writing exceptionally well, it's now part of our basic education. I think in a similar way, computer literacy could be just a matter of education.
I believe we could really start teaching code at a relatively young age too, or at least start teaching them the ability to have the mindset for programming.
Having long ago been a copy editor, and now being a member of a book club, I'd just point out that not all who write write well, and that many who read do so with limited understanding.
I actually think the excel example demonstrates that we are unlikely to see that many more programmers in the future. As much as people use excel in their offices there is still the idea of the 'excel wizard' who really understands the functions and features of excel. It's actually quite surprising how many people I've encountered who use excel pretty frequently and still don't know many of it's basic features. The fact that there is the idea of 'excel wizard' means that for most people even the programmatic aspect of excel is elusive and uninviting.
I think there's a pyramid of automation. Something like
1. Set an alarm on a phone
...
4. Basic Excel formulae
5. Excel Wizard
...
7. JavaScript copy-paste coder
...
10. Professional programmer
The original post suggested that there are more and more incentives for people to push themselves up the ladder. I don't think it'll necessarily mean a whole segment of people people jump from 2 to 10; rather, I think peopel trying to get an edge in the job market could shift up a bit, taking the distribution higher. So Excel users will become Excel wizards, word processor users become HTML coders, etc
However in the 80s I remember if you understood Wordperfect thoroughly (i.e. could do reveal codes and manipulate them) you were called a "secretary." Some form of dumbing down seemed to happen when the GUI came in.
You should see the command line interface my travel agent has (maybe all of them, I don't know), they seem to memorize 100s of airport short codes and use an odd syntax surprisingly quickly for 'non-computer' people.
Very true. Anyone who could confidently boot up a computer had a that geek cache/tarnish.
Is there an example of expectations changing around programming or automation, specifically? Programming, as opposed to computer literacy.
I suppose what I'm wondering is, why is there such a barrier to programming? People are more and more comfortable with complex apps, but not really more liable to fire up some kind of text editor... It's quite a jump to make on your own, I think -- say, going from Excel formulae to VBA macros, or using a WYSIWYG HTML editor to coding JavaScript.
I was called a 'computer wizard' as early as 3 years ago for knowing how to change the wallpaper in Windows, and also for knowing how to use Alt-Tab to switch between windows.
I agree, it's both. I remember a donald knuth quote that about 2% of undergraduates have the mental quirks that make them good at programming. He didn't say "intelligence" or "talent", he said "quirks".
That wasn't just false modesty, there are a lot of factors that have to come together for someone to want to be a programmer, and some of them really do seem more like quirks than talents at times.
Well, that may be true to an extent. The other day I was working with some code that was adequate for most purposes, but didn't meet my rigorous standards (hence: attention to detail and thinking through every aspect of the issue).
So I put on my "old age and treachery" hat, aka my puzzle solving hat, and came up with a better solution one that was:
shorter
simpler
more robust
The experienced programmers I know call this cheating, hence the "old age and treachery" (from "old age and treachery beat youth and beauty every time").
Smarts, puzzle solving and intelligence are all a critical part of that. And that's the thing that is the 10x multiplier that makes all your 'average' (median) programmers look distinctly below 'average' (mean).
I was talking to a (print) design friend the other day who's trying to learn to code. It's interesting to explain to a non-programmer what kind of person will/can become a programmer. If you don't love solving problems by digging and automating, then you will never be a programmer. As you say, not because of intelligence but rather desire and enjoyment.
Did your friend have any incentive to try it for themselves? For example, automating Photoshop using ActionScript? Maybe pro programmers like solving general problems, but professionals in other fields would be interested in solving things in just their domain.
Great idea. I'll mention that. He was coming at it from a somewhat arbitrary expanding-skillset approach, wanting to get his feet wet on the web side of things. I was explaining to him the difference between a creation that "looks" a certain way vs a creation that that "does" something.
The analogy here to law is spot on. My dad and two brothers were lawyers; I grew up in an environment where getting pancakes for breakfast on Sunday required parsing statements made days earlier and finding contradictions between them and the statements being made now. Learning to think that way, however, is not just another skill in an infinite toolbox of possible skills, all of which are equal and each of which you can be proud of in a touchy-feely way. Learning to think, and talk, and conceive in advance what you'll do next that way is akin to learning the art of war. The adaptation to programming is pretty minor. Programming is mickey mouse lawyering. The beauty of law is that someone's actually right; there's a logic at work, and teasing out the convoluted threads is your job. I can dig it. If I liked people more, I'd do it. But to say it's a preference or a happenstance aptitude, rather than a learned, honed, bludgeoned and beaten-in skill, is to seriously underestimate the people who are good at it.
Having formally studied law, mathematics, and programming, I find it odd that you could say "the beauty of law is that someone is actually right" especially in comparison to any formal system like programming or mathematics.
The law is not written in a formal language (in the mathematical/philosophical sense), and interpretation/semantics is not derivable from its representation in text; meanings derive from squishy brains responding to the text.
Having said that, I find it to be a very apt analogy; the idea behind "rule of law" is an aspiration that the law should be more like mathematics or programming rather than an ad hoc collection of rulers' decisions.
I don't remember and wasn't able to find it either, but I know which study you're talking about. There was a professor who gave his intro CS students an exam where they were supposed to interpret code. Of course, most of them had no idea what they were reading. The statement "X = X + 1" is (as a mathematical equation) garbage, even though it's legitimate in a conventional CS context (whereby '=' represents assignment). So almost all of the students interpreted the code incorrectly.
What separated the (future) successes from the failures was not how accurate their interpretations were, but whether they were consistent. The students who came up with consistent interpretations of these (a priori) meaningless symbols and could rigorously apply them were able to grok programming-- through trial and error, they picked up the actual meanings over time. The ones who weren't consistent, who just didn't "get" that these symbols had rigorous and inflexible meanings, were the ones who failed.
I actually think this style of rigor in thinking can be learned, even for average people, but it takes time. You can't go from zero to fluency in one semester. The problem (of American mediocrity in mathematical thinking, at least over the bottom 90 percentiles) is similar to what comes up in affirmative action debates: we're addressing it 18 years too late. In the US, many students never encounter mathematical proof or computer programming, except among the elite (e.g. USAMO, IMO). These aren't impossibly hard. Bulgarian and Japanese secondary students tackle proofs. Unfortunately, in the U.S., proofs are extremely rare in the secondary curriculum and computer programming is, if offered, an elective.
The study you are thinking of is "The Camel Has Two Humps" by Dehnadi and Bornat, which was never officially published (and having read it, has several control issues that are cause for concern with respect to internal validity). However, most people continue to quote this study without realizing that the authors have retracted their original claims. In a larger, later follow-up replication study (Mental models, Consistency and Programming Aptitude by Bornat, Dehnadi, Simon), the authors state:
"We now report that after six experiments, involving more than 500 students at six institutions in three countries, the predictive effect of our test has failed to live up to that early promise. We discuss the strength of the e ffects that have been observed and the reasons for some apparent failures
of prediction."
It's not really problem solving, it's rather a specific kind of structured thinking. It's the attention to detail and the will to think through every aspect of an issue, to find a complete solution. That's also a useful skill outside of software or even engineering (I'd imagine law isn't all that different in that regard), but apparently it's really critical for software engineering. At the same time it's not necessarily linked to general intelligence or problem solving ability or creative thinking, it's just a particular way of approaching problems.
Said lost article had tests showing that only a small fraction of the population thinks this way, something below 10%.
Of course this isn't proven, but it matches with my personal experience. This always makes me very skeptical of things like end user programming, or programming as a mass profession. People without the skill can create programs, in particular in environments, but the results are usually quite fragile and expensive to maintain. "Real" programmers can usually create much greater value at lower cost, so there really isn't much of a point in employing lots of "not really" programmers.