Programming Education: Selling People a Lie? (blogspot.com)
An anonymous reader writes: It's hard to exist in the tech world today without hearing the constant refrain about learning to code: "it's easy, we desperately need programmers, and everyone should learn how!" UK software developer Mike Hadlow disagrees, strongly. He says, "Formal education for programmers seems not to work very well and yet the majority of those who are successful programmers are mostly self taught. On the one hand we seem to have people who don't need any guided education to give them a successful career; they are perfectly capable of learning their trade from the vast sea of online resources available to anyone who wants to use it. On the other hand we have people who seem unable to learn to code even with years of formal training.
This rather puts the lie to the barriers to entry argument. If the majority of current professional software developers are self taught, how can there be barriers to entry? Anyone with access to the internet can learn to code if they have the aptitude for it. The evidence points to a very obvious conclusion: there are two populations: one that finds programming a relatively painless and indeed enjoyable thing to learn and another that can't learn no matter how good the teaching. The elephant in the room, the thing that Yvette Cooper, the 'year of code' or 'hour of code' people seem unwilling to admit is that programming is a very high aptitude task. It is not one that 'anyone can learn', and it is not easy, or rather it is easy, but only if you have the aptitude for it. The harsh fact is that most people will find it impossible to get to any significant standard."
This rather puts the lie to the barriers to entry argument. If the majority of current professional software developers are self taught, how can there be barriers to entry? Anyone with access to the internet can learn to code if they have the aptitude for it. The evidence points to a very obvious conclusion: there are two populations: one that finds programming a relatively painless and indeed enjoyable thing to learn and another that can't learn no matter how good the teaching. The elephant in the room, the thing that Yvette Cooper, the 'year of code' or 'hour of code' people seem unwilling to admit is that programming is a very high aptitude task. It is not one that 'anyone can learn', and it is not easy, or rather it is easy, but only if you have the aptitude for it. The harsh fact is that most people will find it impossible to get to any significant standard."
Programming education should try to find people who have the aptitude to be good programmers and quickly weed out those who never will.
Even if you *can* program it doesn't mean you'll actually want to do it.
Many aspects of programming are boring and tedious. You need someone who can handle the abstract thinking, memorize the various components involved, understand how they fit and how to change them, and then sort through the various administrative steps(version control, bugtracking, communicating with devs/qa/mgmt, etc). Also, many programming jobs are very un-social. I've had times at work where I did't speak to another human for several weeks.
http://www.masturbateforpeace.com/
We should get rid of history classes while we're at it... how many kids become historians?
In fact, let's go back to apprenticeships and work-training. Imagine how quickly we could get working-class children into their lifetime careers of burger-flipping and form-filling and ditch-digging if we remove all the distraction of a 'well-rounded education'...
How can I believe you when you tell me what I don't want to hear?
In my experience, from numerous Agile/Scrum/Kanban meetings, the concept was sound -- get people together, find out where everyone is at, find what is slowing stuff down, go on.
However, that works in Japan where there is a level of respect from employers to employees.
Here in the US, what was, "what did you do, what are you planning to do, and what is in your way" becomes "explain the pathetic amount of stuff you did", "make promises for next meeting", and "point the finger at someone else." The concept of a blocker, for example is used as a way to blamestorm, and ultimately, a way to find who gets shitcanned first.
As for development in general, find a niche. Mainstream development stuff is offshored, and if by chance it isn't, it is handled by H-1Bs that rotate out after 90 days so they can't get a chance at a green card. Even if you find a dev job, you have to program at least 1000 lines of code a day, or else you will get replaced by someone who will. Bugs? If it builds, ship the damn thing. Security problems? Security has no ROI, worry about it when the lawsuits happen.
I personally recommend people go law, accounting, or a trade. You cannot offshore a plumber, electrician, or lawyer, and there is no such thing as an unemployed attorney. No, one may not wind up as a senior partner at Ben Dover & C. Howlett Fields... but one can eke out a living.
The problem with teaching someone to program is that they tend to miss the part where you have to think about the problem abstractly and structure the problem properly. If you can communicate the problem effectively to other people, then you can find a programmer to code up your idea relatively easily. The aptitude problem comes from the fact that many people think learning to program is the point. Good programmers are able to communicate abstract concepts at a high level, which can't really be taught through just learning to program. Honestly, I think you learn how to program better simply by explaining what you are trying to do in plain English. The actual programming task has almost little educational value.
Students should come up with a problem they are trying to solve, conceptualize it and then explain it to their coding buddy and if their coding buddy can code it then the student probably understands how to program well.