You typically find this idea of teaching abstract advanced concepts first in anyone who believes in a constructivist theory of education, which this article smacks of quite a bit. The problem with constructivism is that it really only works with beginners who stumble onto a natural talent that gave them these foundational skills, or whose parents were wealthy and educated enough to have them and teach them to their kids. Constructivism's lie is that it claims to want to teach everyone, but then is only successful with natural talent.
If instead you teach basic skills in the best way, through fairly rote learning combined with application, then later abstract concepts are possible and can be discussed. The idea that you have to do one (abstract concepts) without the other (basic skills) is simply an attempt to limit the types of people who can succeed at an activity to only those people exactly like the teacher.
In other words, attempts to teach abstract concepts first as if basic skills are pointless are simply attempts to weed out undesirable people, which is what this article's proposal would do.
I agree with you. People learn best when they can see the relationships between what they're learning and the real world. Abstract theory should be learned only after there's something for the learner to latch onto and apply it to.
Think of all the best teachers you've had in life. Did they teach by throwing you head first into the water to see if you could swim, or did they start by telling a story and then slowly peeling back the layers to reveal more complexity? Start with simple applications and concepts and then expand on them.
This article also ignores the fact that Computer Science is essentially an esoteric branch of applied mathematics with a little bit of philosophy thrown in for good measure, and any attempt to teach younger kids these concepts will mostly fall flat on its face before we radically improve the quality of our STEM education, particularly mathematics. Until we do so, Computer Science will remain the ___domain of those with a natural affinity for it.
Fundamentally I agree, but I question why we do not teach computer science/coding the same way we teach music?
For example, when I first learned how to play piano, I wasn't taught how to play Major 9th chords. Rather, I learned simple melodies and expanded into more complicated harmony as I grew older. The reason why I began learning more theory was because I knew of its potential to make me a better musician. This can be applied to computer science learning as well. You definitely don't want to start kids off on learning by trying to explain how a sorting algorithm works, that's totally meaningless. You want them to get things working, make them solve problems, give them problems that are so absurdly hard to solve with their current knowledge that they MUST find an alternative.
This is how you truly educate. By making people solve their own problems, because they have to. It's really funny how people step up their game when they believe they have to do something for their own good.
The primary reason for this is that we are currently at a phase where we are encouraging people to program who might not otherwise bother with it. As a consequence, we're making the lessons fun and appealing right off the bat. Writing an iPhone app is more entertaining than writing a command line guess-the-number program, but the latter is a more applicable teaching tool (mostly by virtue of there being far less knowledge necessary understand what's going on).
Fundamentally I agree, but I question why we do not teach computer science/coding the same way we teach music?
There are many reasons. One is that the fundamentals of classical music-- the notation, the instruments, the techniques-- have not changed substantially for hundreds of years. Compare the evolution of the keyboard from 1700-present to the evolution of computers during the same timeframe.
Another is that while programming is an activity, it is not a performance. Musical training is designed to impart specific technical skills for use in performance of music. Programming is more akin to composition.
I agree with you, but this somewhat flies in the face of what he says. He is arguing that CS is important, not just learning to code. But I think learning to code is important because it is what attracts creatives, and both creatives and engineers are needed in development.
There are two things that attracted me to programming:
1. Telling something else to do what you want, and it does it.
2. Being able to be creative within bounds in a way that allowed me to learn new cool things each day and build with those new bits of knowledge upon other bits, to great things that were entertaining.
Without some bounds, chaos and floundering reign. Electric slot racing was cool because a realistic (per ratio) speed was involved, but control was possible, and it was a simple control, variable power to the engine. Having to steer those cars without slots at that speed is beyond our abilities. This is the problem today, to me. There are so many options. There are no slots in the track. No Apple II. And, there are now so many prewritten solutions. You don't need to write a game to find what you were thinking of. There is little reason for the younger generation to develop anything on their own. My kids just play games. I know I couldn't get them to develop if I tried, though I tried once and failed. They'd rather be creative with markers and paper- and that's ok. But, it makes me miss my younger years on the first home computers; I can't give that to them; that era is gone, and I miss it.
But I think learning to code is important because it is what attracts creatives, and both creatives and engineers are needed in development.
You're guessing here (and you admit it), but I'm a very strong data point for the opposite. Anyone who knows me would tell you I'm creative (I started out, and still am a filmmaker and it's all I'd do if I could afford it).
I had thousand of hours of computer science before I wrote my first line of code, at age 20, and I didn't seriously get into coding until I was 24.
So no, I don't think coding and creativity have any link whatsoever. I find CS extremely creative and enjoyable, much more so than coding, which I consider to be "S" work in the Myers-Briggs taxonomy. When I want to be creative, I step back into CS mode.
When you're building a skyscraper, you are not going to design every brick.
The basis of teaching children how to code is making them learn how to use code as a problem-solving tool. Like this, the sorting will not be important by itself, but as means to an end. As a way to achieve greater objectives.
And besides this reasoning, we have another: in CS, something is generally built on top of others. If you write a heapsort algorithm in C, you don't need to understand it's implementation in assembly. When I write my HTTP Applications I don't need to understand all the Network Layers beneath it. As I write this, I don't really understand the intricacies of Google Chrome and MacOS that make it possible. Am I ignorant? No. There is much thinking and learning to high level coding too. It's all about how complex your problem is and how you learn to apply logic to solve it.
While it may be perfectly acceptable to ignore the lower-level details when first learning some new technology, or even when using it for personal use only, that sort of ignorance is not acceptable when working on systems that are meant to be used seriously.
At that point, you need to have at least a high-level understanding of each and every layer that you're building upon. If you don't, then it will come back to haunt you, whoever uses your software, and whoever has to maintain it after you're long gone.
We've all encountered, or at least heard of, the Java and Ruby programmers who use ORMs, but who refuse to learn SQL, and refuse to learn how relational databases actually work. They write their software while understanding only the highest levels of the abstractions that they're working with, and then the system ends up performing horribly. Then somebody more experienced and knowledgeable gets called in, and gets to see how the ORM is generating abysmal SQL queries, or indexes aren't being used.
It's better to know and understand than to not, especially in the long term.
I have built many systems that were meant to be used seriously. Never once has my lack of understanding of graphics cards, for example, come back to bite me.
Every system is built on abstractions. You can argue about the value of understanding particular systems, but we are well past the point when any one person can or should understand them all. No one is arguing that it's acceptable to learn only the highest-level abstractions. But it is acceptable to let somebody else worry about some of the lower-level ones.
People who don't focus on understanding engineering systems often focus on understanding other systems––team dynamics, for example, or business needs. I've met a lot of developers who only cared about learning the technical side, and were happy to look down on developers who didn't feel the same. Is that wiser, somehow?
No, you probably don't need to know much about how graphics cards work if you're working with databases or other software that doesn't really involve graphics in any serious way. But if you're working on graphics card drivers, high-end video games, visualization systems, or simulations, then you'd probably should have such knowledge.
The point is not to fully understand every single layer that exists, including those that your software never interacts with, or only just makes very light usage of. But you should have at least a basic understanding all the way down through the code and hardware you do use, directly or indirectly.
It's perfectly acceptable to not understand the low level details of seriously used systems. Isn't that what teams are for? You can trust the engineers developing infrastructure so that you don't have to worry about it. Sure, understanding the high level concepts can't hurt, but it isn't going to make a front-end developer any more productive.
I disagree with the last point. Understanding the low level details of a system definitely makes a developer more productive.
When I am working on an iOS app and I get stuck on a bug, I can open a disassembler and immediately figure out the cause of the bug. The same goes for a ruby developer who wonders why their queries are taking forever or a front end developer who doesn't know why their interface is dropping frames.
Any serious engineer should be able to fix these problems on the spot if tasked with it.
The engineers can't really do that for all cases [1]. Understanding abstractly what's going on at least a few layers up and down your stack will definitely make a front-end developer more productive, if by productive you mean able to complete a finished product rather than just a buggy first draft.
> It's perfectly acceptable to not understand the low level details of seriously used systems.
Yes, that's what my colleagues thought a few months ago, too, when they churned up a web UI for an embedded device. My teamwork was, apparently, insufficient to make them realize that a configuration interface that takes half the available flash space is rather large (the other half was taken by a goddamn kernel, a web server, a proxy server, a bunch of other networking tools, a logging service and all the tools that communicated with the web ui!). Lack of understanding regarding how routing works in TCP/IP networks also meant that their first attempt had a pretty fatal flaw which resulted in the configuration interface becoming inaccessible, which became apparent in the first ten minutes of testing and required a significant amount of redesign because the entire workflow of the interface depended on that.
Their Bootstrap wizardry was remarkable, but ignoring how the underlying system worked resulted in them having to start from scratch.
It works the other way 'round, too. Not understanding how web tools work would also make my systems programming entirely useless when it has to provide the infrastructure on which such tools rely.
No one likes all this complexity. I hate it, too. I sometimes truly, really wish my job was as simple as taking this thing from here and putting it over there. Ignoring this complexity doesn't make it go away though; building tools that can isolate some of it behind a comprehensive and consistent interface is ok, but relying on those tools to do it for you without understanding what they do is technical suicide. It's this kind of thinking that makes people think it's ok for a rudimentary word processor to take six fucking seconds to load, after asking you for a password, in 2014, on a quad-core system.
Edit: it's also worth pointing out that this is really beyond the scope of the article's argument. What the article insists is that this:
hardly helps anyone learn coding as a problem solving tool. This exercise taught the reader exactly nothing about how to solve the problem of sorting numbers. I could ask someone who works for me to sort me those numbers, and my understanding about algorithmic thinking would be as rudimentary as before.
Teaching children how to use calculators does not increase their problem-solving ability, not by an iota. Teaching them mathematics does that, and their ability is further advanced when they learn about theorems and structuring proofs, about induction and, yes, about using a calculator.
It's the same here. I'm not arguing that computer science should be purist to the extent that you shouldn't use anything but a Number 2 pencil to program. That's stupid. I am arguing, though, that teaching people "to code", as if programming consisted in nothing but translating from English to Codese, is pretty much as retarded as teaching mathematics as if it were a language, consisting of nothing other than translating the English "Two apples and three apples make how many apples?" into the far more cryptic "2 + 3 = ?".
Teaching kids to use calculators DOES increase their problem solving ability. They can produce the same result as someone using paper. If the problem's really advanced, they may have to use brackets correctly too. You teach the same logic whether it's on paper or not, just instead of shuffling numbers in your head, a system that's BETTER at it is doing it instead.
But the issue is, you've added the Calculator dependency to the Kid program. Whether or not that's an issue depends on whether Calculator is a well maintained and dependable project.
On the other hand, there are downsides to NOT using the easier Calculator library, and writing all the code from scratch (i.e. Memorising Mathematics systems and practicing them enough to use them at any reasonable speed) — 1) storage space and using up brainpower / focus storing micro numbers, when you could be focusing on the bigger picture algorithm, 2) speed, the Calculator library is optimised and written by experts, 3) bugs, the Calculator library is well tested, whereas it's easy for anyone to make simple arithmetic mistakes.
> While it may be perfectly acceptable to ignore the lower-level details when first learning some new technology, or even when using it for personal use only, that sort of ignorance is not acceptable when working on systems that are meant to be used seriously.
I'm a self-taught web developer. While I have probably picked up some programming fundamentals/best practices through experience I have very little interest in computer science or learning the low-level details of every technology I use.
I probably couldn't get a job at most SV/SF startups, but I run several WordPress sites that have millions of monthly visitors and that have traffic spikes of 100,000+ visits in 2-3 hours at least a few times each month. I'm paid very well and I don't need to apply rocket science to do a good job.
Meanwhile I have friends with CS degrees at hot VC backed startups using all sorts of crazy technologies and advanced programming techniques for sites that get maybe 100,000 visits a month.
If you ask me, ignorance is premature optimization, overengineering and hiring expensive people to apply skills you're nowhere close to needing.
I think you've benefited very heavily (a lot more than you may realize) from the work of people who did have more formal training, and who used that knowledge to build the systems that you in turn have built upon.
You're right, it does take much less effort and skill to run moderately high-traffic WordPress-based web site these days. That wasn't always true, though. In the 1990s and even into the early 2000s, it did take skill to get the most out of web servers with clockrates below 200 MHz, maybe 16 MB of RAM if lucky, very limited storage, and limited network connectivity. Specialists were needed in cases like that.
What you seem to consider "ignorance" is usually just considered "forethought" and "planning ahead" by those involved. It's easy to rail against so-called "premature optimization" until you've seen that kind of prudence prevent unexpected scalability disasters from happening. For a young company, like the kind your friends apparently work at, a little bit of foresight and effort at the start can significantly mitigate the harm that can come from unexpectedly large demand. In some cases this is what will determine whether or not that company survives and thrives.
> I think you've benefited very heavily (a lot more than you may realize) from the work of people who did have more formal training, and who used that knowledge to build the systems that you in turn have built upon.
And your point is? Am I supposed to create a shrine to the people who built the first microprocessor?
> You're right, it does take much less effort and skill to run moderately high-traffic WordPress-based web site these days. That wasn't always true, though. In the 1990s and even into the early 2000s, it did take skill to get the most out of web servers with clockrates below 200 MHz, maybe 16 MB of RAM if lucky, very limited storage, and limited network connectivity. Specialists were needed in cases like that.
I'm sorry but it's not 1999. I can't imagine anyone winning a potential client over today by saying "You couldn't do in 1999 what you're doing without someone like me" or "I will architect your website so that it can run smoothly on a server with 32MB of RAM."
> What you seem to consider "ignorance" is usually just considered "forethought" and "planning ahead" by those involved.
So struggling to hire (because you're looking for overqualified candidates a lot of whom don't want to work on a simple website with less than 100,000 visits per month) and increasing your burn rate by paying $140,000/year fully loaded for web developers you can call "engineers" is "forethought" and "planning ahead"?
I know enough people who have worked at typical VC backed startups to know that most of them never grow big enough to have the kind of scalability and performance challenges they'd all like to believe they're going to have. And as a practical matter, if you look at the great companies that have emerged in the past decade (think Facebook, Twitter, etc.) and how their systems have evolved as they scaled, it's pretty clear that if you become a massive success, you're going to need to substantially rewrite your code base anyway and by that time you won't have to hunt for the highly technical engineers you need. They will be knocking on your door.
The biggest risk to just about every new startup is not having a developer who is a little too friendly with an ORM and who might have to turn to StackOverflow for help with a complex SQL query. It's getting a good enough product launched before you miss your market window and/or run out of cash.
"When I write my HTTP Applications I don't need to understand all the Network Layers beneath it."
If you want your HTTP application to perform well, be secure, be scalable, work with a multitude of browsers in unusual conditions, and be able to troubleshoot weird errors, then yes, you will at some point need to know something about TLS and TCP and IP (v4 and v6) and even Ethernet and Wifi.
Similarly, architects and engineers have to understand how the materials they're planning to use are made, what their capabilities and limits are, and how they can best be used to implement their vision for a building or a bridge. They can ignore how the bricks are made and how they perform, but their structure will not last.
Did you ever consider that a lot of the work being done by developers today makes them more like plumbers and electricians than architects and engineers?
> Similarly, architects and engineers have to understand how the materials they're planning to use are made, what their capabilities and limits are, and how they can best be used to implement their vision for a building or a bridge. They can ignore how the bricks are made and how they perform, but their structure will not last.
Np, they don't. At least not to the degree that some people here think programmers and software engineers should know computer science topics and various levels of abstraction. As an electrical engineer, if I had a custom transformer I needed the spec sheet and evidence that the parts met said spec sheet. The spec sheet had basic electrical and physical parameters along with relevant composition information. I didn't care what exactly the core was made of unless it was specified; I certainly didn't care how the core was cast and milled, how the coils were wound, how the casing was added[1], or what the casing was made of[2]. I didn't care about the details of how out custom or off-the-shelf ASICs were made, only that they met the stated specs. I needed to know how they functioned in the circuit, how they interacted with each other, how the spec tolerance on different parts affected the overall operation. If I had a problem that looked like a lower-level issue, say an ASIC that may have switched manufacturing processes without the manufacturer telling us, I worked the issue at our system level and let an ASIC specialist handle the nitty-gritty details as necessary; the ASIC specialist similarly relied on me to handle the board-level issues.
I was going to give a civil engineering example with concrete, but I'll cut right to the chase. Computer science, misnomer that it is, is a very broad subject area. As it matures, it continues to get broader. At some point, we as an industry, and to some degree the academic community, need to realize that the subject area is too broad for everyone to know everything and that people need to specialize. If I want to build a radar system I need as a minimum: an RF engineer who understands the gory details of RF transmission and RF semiconductors; a power engineer who understands the gory details of DC power conversion and distribution; an electronics engineer who understands the gory details of mixed-signal board design; another electronics engineer who understands the gory details of high-speed digital board design; a firmware engineer who understands the gory details of FPGA and CPLD design; and an ASIC engineer who understands the gory details of analog and mixed-signal chip design.
Everyone I just mentioned will have one or more degrees that say "electrical engineering", and many may only have a bachelors. Each engineer certainly understands the basics of what the others are doing, but each is still a specialized engineer. They are NOT interchangeable. You cannot hire people for their generic "electrical engineering chops" the way Google and its cargo culters hire software engineers, even straight out degree programs. Every electrical engineer cannot know everything equally well, and once you start working and specializing through experience it just gets worse. The sooner this industry realizes that software engineering is not different and that complex software projects need specialist teams coordinated with proper systems engineering[3], the better. I firmly believe that most of the "talent shortage" right now is an artifact of companies looking for people like you describe, people who know everything and can move freely up and down the stack. That is increasingly impractical and not nearly as efficient as getting people to specialize and work together effectively in multidisciplinary teams.
[1] These were fully-encased transformers.
[2] Again, unless we specified something specific.
This! This is the first comment I've read in this thread that's dealt with the core issue.
We, the world, don't need millions of people who can write a good sorting algorithm. A few thousand will do. We need millions of people who can use the sorting algorithm that those thousand people wrote, to build things higher up the stack, and billions of people who can use the things those millions of people wrote to do their work.
As you go deeper in the stack, fewer people ever need to understand it, and they will be paid more and more. We don't need more computer scientists and sorting algorithms. One good solid sorting algorithm is fine. The whole idea of evolution is we build on the successful developments of previous generations. We don't need to know how a lightbulb works, we just use it to illuminate the desk while we write a paper on genetics.
I don't think we should train kids to be computer scientists — the really talented ones will do it anyway, and the number of people entering this field will continue to grow for the foreseeable future — I think we should train them to be lawyers and doctors who understand code. To a level where can throw together a solid working solution to a problem they have, without having to go to a programmer who may not have the deep subject knowledge that allows a novel solution. If the doctor can code, they can iterate on their idea in a way that just isn't possible if someone else is developing it for them.
Excel and macros etc are the beginnings of this, but it'll go further — at some point JavaScript or Python will hopefully be prevalent.
One of the startups I'm CTOing is working on exactly that problem, or rather, has worked on it and is commercializing the solution.
Logo[0] (the language for children) is actually more complex and abstract than what we've got, which isn't a language at all, but closer to a spreadsheet for code, except...people don't even know they are coding, much less using what everyone here would call a debugger. They're just doing stuff that, if you were a computer scientist, you would recognize as coding.
I'm pretty excited about it, we're beta testing with an 800 person company in Australia at the moment, and hope to go into a general release over the summer. I think it's similar in significance to the business world as the spreadsheet, which allowed non-programmers to do number crunching. Our stuff allows non-programmers to do the vast majority of business automation and back office coding being done today.
When you build a skyscraper you don't need to design ever brick, but that is the wrong analogy. You do need to understand the properties of the different bricks so you pick the right ones, and use them properly, otherwise the building will crumble under its own weight.
If you write a heap sort algorithm you don't need to understand it in assembly... Except if you need to optimize performance. If you ignore the network stack while you write an HTTP app, you might not know how to protect from a man in the middle attack, your particular app would not need it... But maybe the next one does. You might not understand how chrome and Mac OS works... But then if pop ups start to appear you will not know what to do.
While some levels of abstractions make things easier to deal with, programming is more about process building than specific tools, and I feel that the original article got right
I find sorting algorithms a bizarre and damaging introduction to computer science.
If, as suggested, you ask an interested teenager how they sort a list of numbers on paper, they can usually give a reasonable algorithmic explanation, e.g.
"Find the smallest number in the list, and write that first,..."
Then, they have to throw that thought process away, and rote learn some different and esoteric alternative - the A-level course mentioned in this article requires you to execute bubblesort step-by-step, from memory, on paper.
When in fact, the teenager's own creative method (that we threw away) is much closer to how a computer scientist/coder should be thinking.
A well-taught computer science course will not force anyone to rote-learn algorithms. Instead it ought to walk the students through the discovery process of improving from a naive but simple bubble sort, through more complicated algorithms.
Once they understand the complexities, they can appreciate the genius of quicksort. And with the sort problem well established in their minds, they're ready to appreciate the value of more complicated data structures than the list they were working with.
The difference is between understanding how to make computers do things with the tools available (knowing about built-in sort methods) and understanding how computers actually work (learning how sort algorithms have been developed).
You may be right that a programmer doesn't need to, on a daily basis, think about how sort() is implemented. But learning to work out a well understood problem with a knowledgeable instructor will teach her how to solve the next problem she comes up against on her own that no one has yet solved.
Just like any scientific pursuit, the best way to appreciate the tools and knowledge that is currently available and what methods and processes ought to be followed to improve the tools and increase the knowledge, is to walk through the process of understanding step by step, from simple to complex. If rote is involved then someone is screwing up.
>A well-taught computer science course will not force anyone to rote-learn algorithms.
Agree but with the correction that you mean well-structured computer science course. The UK national A-level syllabus for "Decision 1", that which is under discussion, largely demands rote-learning for the examination. To avoid this, for whatever reason, would be very poor teaching.
There are structural deficiencies here, which teaching cannot overcome. (Also worth noting that this is part of the HS maths course, and mathematics teachers are typically not knowledgeable enough to offer the flavour you demand)
> Instead it ought to walk the students through the discovery process of improving from a naive but simple bubble sort, through more complicated algorithms.
Bubblesort is not naive and simple. Given the opportunity to invent a sorting algorithm from scratch, as a total beginner or as an expert, nobody would spontaneously suggest bubblesort in 2013.
If you open your course with bubblesort, it's my belief that a lot of capable students are going to be thinking "why did we start here? => computer science is not for me".
Overall, I agree with your teaching method - but bubblesort to quicksort is the wrong route. If sorting algorithms are introduced (I don't think it is a good start point), insertion/selection sort to bucket sort would be more pedagogical. The start point more closely matches students' naive understanding, and the end point forces teachers to be more clear about what the key learning points are.
Decision 1 brings back memories ... As I recall, that was the 'easy' module that everyone would do well at (precisely because it was rote-learning basic algorithms, possibly without even the use of the word 'algorithm'), to compensate for the world of pain that was Pure 3.
10 years later, however, most of it spent doing literature degrees, I remember a lot more integral calculus than box-filling.
> [...] To avoid this, for whatever reason, would be very poor teaching.
Depends. You can teach for the grades, or you can teach for lifes. In general, it's mostly university entrance requirements that care about the grades. Otherwise, don't worry about the grades at all.
But that's exactly what the author is advocating - exploring the process that the teenager came up with! There was no mention of quicksort, mergesort, bubblesort, etc - just that once you start trying to understand how to do something mechanical like sorting, you start to understand how algorithms work.
Not to mention that using N different sorting algorithms as your introduction to computer science (as is often the case) has to be the most boring, un-motivating content to choose from. The only thing worse is "lets learn about recursion using the fibonacci sequence." Ugh.
Absolutely correct. Using these abstract algorithms in such a "one-size-fits-all" pattern is very disengaging to students; Constructivist educators should work hard to find suitably contextualized algorithms to explore that individual students will find cognitively engaging.
In my view a reason to teach sorting is simply that it provides a set of relatively simple cases for studying things like execution speed and storage requirements.
Ha, that sounds like bootstrapping would be necessary.
> So my feeling is that, by all means, we should be teaching anyone and everyone how to code, to lay the groundwork for teaching computer science.
Yeah, but which knowledge - coding or computer science, is more important? Both can be aimed at solving problems. It depends on the context, especially regarding the language and associated libraries etcetera being used.
I absolutely agree with this. All kids should be learning how to compile a basic program as they are learning their multiplication tables. They may not end up being computer scientists or mathematicians but everyone should at least get that. I certainly didn't. They didn't even have programming at my highschool.
While I agree that it's important to stress the differences between code and CS, I still believe that, at an High School level, it's better to teach how to code instead of CS.
Programming is a practical skill. It's easier to engage kids with it and it will probably be more useful to them in the future. It's hard enough to engage kids with practical stuff ("I'm never going to need X, I'm going to become a Y"). I just don't see most HS students interested in data structures, algorithms, and complexity analysis.
I would rather see a bad programming course where the students actually learned something instead of a good computer science course that most of them completed by memorizing exercises, cheating, etc.
If you believe that the only role of schools is to teach useful skills, then you are correct.
But I believe that the role of an educator is more than that. School should teach our kids to see the world for its beauty and to understand how it works. Practicality of subject material should not be a factor in what we teach our kids.
There's a reason why we should teach Shakespeare, proofs in math, music history, kickball and beauty in algorithms.
Teaching our kids useful skills is important, but as a Teacher, I believe it's more important to instill in them the eyes and tools to see and appreciate the world around them.
> If you believe that the only role of schools is to teach useful skills, then you are correct.
I believe the role of schools, especially before and during high school (it's another matter for college/uni) is rather to teach basic skills (read, write, count, know a bit how the world works and how to think) and to teach how to learn, and also what exists that could interest you.
Teaching only useful skills is very simplistic and even seems to me like a bad idea, and I think you demonstrate why in the rest of your post.
For starters, I'd say CS is better described as a branch of applied mathematics rather than a science like chemistry or physics, if one wants to associate it with any academic category at all.
Moreover, "coding" isn't really "applied computer science" in the way, e.g. electrical engineering is "applied physics of electromagnetism." In fact, one doesn't need to know or understand even the first thing about CS in order to be an extremely effective programmer. The same isn't true about most engineering:physics/mathematics analogues.
It's a false comparison. Algorithms, and data structures don't have a ready, real-life examples, that a new kid from middle school can already relate to. I suppose, you can point to facebook and google and try to explain the infrastructure behind them, but he still doesn't have a way for the kid to play with and see the consequences. I also think there's a false dichotomy implicit in your question.
Actually, you learn your first algorithm in elementary school, you just call it "doing an Euclidean division by hand". You're first data structure comes a bit later, in middle school, with vectors. That are just the first among those that I thought of, there are many more.
My point still stands. You don't run into Euclidean division when you're running back home. You don't see vectors when you're waiting for the school bus to take you home. You never see Binary trees, when you're out playing. But you do see buildings and some being constructed. Not to mention the legos game.
Aka, the abstractions to concreteness is harder in CS than in Civil Engineering. It still might be a good strategy to teach some subset of all students, but as general policy for the majority it'll be horribly ineffective (I think).
People see them, they just don't recognise them as that thing — and they certainly don't know what they're called.
You're right that CS has tonnes of ridiculous terminology, that gets in the way of learning. In Mathematics, most people complete high school before they ever hit the terminology. Things have simplified names, like 'divide' and 'add', which helps 95% of the population get a better handle on it.
I absolutely think those should be changed, though not to cooking.
Imagine what a country of citizens--educated in engineering and computer programming to the same degree we do literacy today--might be capable of accomplishing.
That is a completely backwards way at looking at learning to code.
Sure you can boil down trivial examples to make the process one of learning syntax, but the moment you do anything of your own design you begin learning the fundamentals of computer science.
They may not be able to explain to you how sorting works, or many other minute details, but they will probably be able to tell you how they were able to get pressing the screen to result in the character moving up.
After that they will realize the character can't move up forever, so what should happen when it reaches the top? etc. etc.
Simple but non-trivial things are exactly what is needed to get someone to dip their toe in computer science, and will certainly work as a stepping stone to more formal processes later.
Pretending that one liners aren't valuable so by extension small programs aren't valuable is asinine. If you want to point out specific examples then feel free, but this abstract focus at the start just makes you seem like you are focusing on things they shouldn't care about.
As another note, sorting numbers 9/10 is a solved and thus uninteresting problem, don't ever make someone do it until they know a ton about computers.
Don't these guys realize that even out in the real world there are large numbers of programmers who aren't computer scientists. They have code running in production as we sit here and debate the merits of teaching children what will become an essential skill in the future. I work with people who will never need to recall from memory how to write a quicksort yet they've been collecting paychecks as developers for years. I can never understand the backlash against teaching people something. Aren't we all for abstraction and encapsulation? You don't hear doctors complaining that people are learning how to eat healthy but not learning how all their internal organs work.
There are large numbers of practicing (mechanical, electrical, etc.) engineers who aren't physicists. But you have to be up on your physics in order to work as an engineer.
In my observation, engineers tend to forget their math and physics pretty quickly after getting out of school. Many are proud of it. Most of the work of an entry level engineer is CAD, troubleshooting, and bureaucracy.
It's not like we're talking about astrology vs astronomy. We're talking about science and engineering. Why can't we be teaching both? In fact, shouldn't we be teaching both? Together? In service of each other? I think so.
> Learning to code is merely teaching people to spell.
This is true, however you can't dive into the nuances of Shakespeare without knowing what words are and how to spell them.
One thing to keep in mind when arguing theoretical vs mechanical education is children can't think like adults. In fact, children aren't even capable of abstract thought until they hit the 11 to 13 year old range [1] (and only the bright ones are able to think that way that young). So starting a deep dive with Computer Science with 7th and 8th graders is a fools errand.
But it is a worth while endeavour to show them the mechanical side of coding. They will eat that up. Once they have a handle on mechanical tasks, then you can start introducing the theoretical. More kids will pick up the concepts that way.
As a musician and a scientist, I wonder if music and art are better analogies than science? And what if we had the luxury to teach some things in school just because they're interesting and fun? Isn't that why most of us learned programming?
When kids learn music, they typically start out by playing an instrument, or singing. Teachers are comfortable letting theory be taught later, if ever. Even the dilemma of what programming language to teach is analogous to what instrument a kid will choose.
> As a musician and a scientist, I wonder if music and art are better analogies than science? And what if we had the luxury to teach some things in school just because they're interesting and fun? Isn't that why most of us learned programming?
I agree that Computer Science is not a science. It does contain elements of science, but on the whole it is an inter-disciplinary subject.
Rather than compare programming to music or art, I would compare it to craft. The difference being that programming is mostly done with a practical end-use in mind. It's more like being a stone mason or a goldsmith.
I'm not sure most of gets called computer science is actually science it terms of "a systematic enterprise that builds and organizes knowledge in the form of testable explanations and predictions about the universe" as wikipedia puts it. Mostly it would be better called software engineering. I think people tend to call it science because that sounds sexier.
The stuff the writer of the article says he supports in the Apps For Good initiative is even less science like. "competitor analysis, testing, monetizing, building a team, and legal / social ramifications of releasing an app" is business studies, not science.
You have a good point. OP was trying to show how to pursue computer science by understanding the meaning behind programming. But he deviated it to the software engineering which is a different scope to chase for.
If you like to pursue computer science, you spend your time on improving algorithms, improving compilers, improving language and improving operating systems. When you like to pursue a different direction to write software applications, you focus more on the latter part OP mentioned.
There is no absolute line between the two. Understanding better in the low level will always help, especially for the new programmers. That's why we had the principle courses in colleges.
People do need to spell, and the majority of the population is even worse than illiterate by the author's standards.
A universal desire to teach people to read has the same pitfalls, but nobody argues against that. Why? Because reading opens a door to a world of information that you didn't have access to before.
Coding is similar, except that it opens the door to the world the author describes: the creative world where you get to take the ideas in your head and make them code incarnate, and appreciate the beauty of algorithms and all of that. The distinction is obvious, but so is the required progression if we want this process to start with kids.
EDIT: that the ADULTS proposing this stuff don't know the difference is troubling.
The thing is, most software jobs today don't require much knowledge of computer science. Mine certainly doesn't. I have a both a bachelors and masters in CS, but I'm no better at my job than my coworker who has no CS education but learned to code on his own. I can't think of one time I've used Machine Learning, AI, advanced Networking concepts, advanced OS concepts, Computer architecture, etc in my day to day work. Not to say those jobs don't exist in industry---they are just very overshadowed in numbers by jobs to build CRUD apps.
The world certainly needs Computer Scientists, but it needs a whole lot more software engineers.
It certainly depends on what industry you're working on. If your company is working with AI or optimization related stuff, etc..., CS knowledge is def. useful if not essential.
I should really write a blog article about this, but let me make a few meta-points on the subject of CS:
1. I don't think it should be called CS. Not everything in CS is a science. It could be called "Computing" instead.
2. CS is not a branch of mathematics. HCI is not mathematics, for example, and HCI is an important part of CS.
3. CS is as a unique and inter-disciplinary subject.
4. Programming is not a science, or an art, or a branch of mathematics. Most of the time. The best description I have come across is that programming is a craft. CS involves and supports programming. You can program without a CS degree, but knowing CS will make you a better programmer than you would have been without it.
5. The term "Software engineering" is very unfortunate, just like the term CS. I'd prefer "software development", and as indicated above I consider it not to be like traditional engineering (Safety-critical systems etc. excluded). Software is not like bridge building, as many many people have previously pointed out.
6. Making analogies with other academic subjects is not particularly helpful, as CS is quite unique. Physics, Chemistry and Biology mostly study natural systems. In CS we are usually studying systems we have created ourselves.
I think it's all very frustrating, as our young discipline continues to seek an identity. There's a false dichotomy between CS being science or engineering; we need to get past that.
It's important to capture the imagination of young people and encourage creativity. Projects like Scratch are a fantastic introduction to solving problems with computers, and young children actually enjoy using it. Kids are excited about building things and getting results. Think LEGO/KNEX, would these toys be as popular if you needed to study the composition of the plastic and physics of forces? Think how many minds have been inspired with simple toys like these.
Computer science and the intricacies of sorting algorithms are a really fucking boring thing to learn/teach. Why make coding in schools monotonous and irrelevant when it could be fun and inspiring? I agree that the fundamentals are important to study at some point but that can wait until a higher level of understanding is achieved.
I have worked with a lot of developers from different educational backgrounds I can tell you that knowing computer science and being able to code are two totally different things. Businesses are interested about getting shit done and seeing results, not how you did it. I don't think that a computer science degree properly prepares you for real life software engineering.
Make coding fun, inspiring and motivational! Teach kids what they want to know and help them to enjoy learning.
Learning to code is a prerequisite for learning computer science. You will not ever get interested in how to sort numbers in an efficient way until you've had to try to do it yourself because you needed it in some of your own projects. This practical need of yours will put everything else into a context and things will flow from there.
For example, I think I "invented" selection sort when I was maybe 10-11 years old because that was the obvious choice. Then few years later when I first read about quicksort, I kind of already had an intuition to why that just might be a heck a of a lot faster than what I had used before. And also to why selection sort might actually be really, really slow.
I also think that coding and computer science are so tightly connected that in practice you can't do one without the other even if you wanted to. I also think there's no easy path to coding: you need to start from the lowest level and build from there. Or start a bit above the lowest level but go for a dive down later, and only then continue upward.
> Learning to code is a prerequisite for learning computer science.
I know what you mean, but there's a lot of people who have CS degrees and have /absolutely no idea/ how to code - when I was a Unix admin, this described most of my colleagues.
They knew sorting algorithms well enough to pass an exam, but parse a spreadsheet with some proposed file systems and make them? That was a big deal.
I think this should be the top comment here. I taught myself to program as kid, not because I was interested in Computer Science (I'd never heard of it, and if I had, it wouldn't have been appealing to my 7 year old brain). I learnt to program because I wanted to make things, specifically games. That's what kept me typing in those lines and lines of BASIC, that's what inspired me to keep learning new languages and technologies - so that I could make better stuff! And this continues to this day. If I'd been pressured into learning Computer Science instead, I would certainly not be a programmer today. Back then, and even now, I just wanted to make stuff and experiment - Computer Science has only been something I've become interested in in the last few years, and has been completely inconsequential to my career development.
So I disagree with this article. Programming is a creative, fun thing which is much more accessible to children (and adults!) than the comparably dry, stuffy subject of Computer Science. And it's not even true to say that people with formal computer science backgrounds make better programmers, so what is the benefit here?
No, that's not even remotely an accurate analogy. Computer science is a branch of applied mathematics; not a physical science. Engineers need to have a basic understanding of core physics principles in order to do good work. That analogy doesn't hold with respect to programming and CS. A better analogy is that CS is to programming as number theory is to arithmetic: a person doesn't have to know what a "field" is in order to compute 2+2, or to be able to solve incredibly complex computing problems in general.
I'd split Computer Science in two - the basic stuff and the cutting edge. While most CS graduates have the former, they are ignorant of the latter, unless they read up research papers.
It is good to have a foundation, and coding alone doesn't give it, hence the need to learn basic CS, but probably nobody can keep up with the cutting edge of it, being so vast and dynamic.
> I'd split Computer Science in two - the basic stuff and the cutting edge. While most CS graduates have the former, they are ignorant of the latter, unless they read up research papers.
That's pretty much true of graduates in any field of science, not just computer science. A BS is a fine grounding in the basics of a field, getting a grip on -- usually some slice of -- the cutting edge is something you do by reading current research in the field.
> Computer science is a branch of applied mathematics; not a physical science
I would disagree. Whilst CS did originally branch from mathematics, nowadays it is an interdisciplinary subject and to call it a branch of applied maths would exclude huge areas of CS such as HCI.
There are good analogies and bad analogies, though. Good ones use relationships that actually have common elements that are meaningful; that's how they work to convey information.
Depends on what component of compsci you are talking about. I worked with several profs that have never worked on large software projects. They spent their lives constructing proofs and the closest thing to programming they would do with any frequency is update their webpage.
Software engineering is to programming as civil engineering is to construction. Software engineering is just a small slice of computer science.
This is simply a (somewhat inaccurate) attempt at re-interpreting semour papert's advice that learning to program should serve as a medium/conduit of ideas but doesn't have intrinsic value, in and of itself, outside of the ideas applied and diacovered. If he was aware of papert it would've helped to see an attribution.
There is infinite arm-chair teaching going on regarding coding/programming/computer science right now. If anyone is tempted to do more, fine. But please, please, read up on what people actually doing it have discovered. Reality quickly upends assumptions when you try to teach.
The one thing a lot of people really miss when talking about education is proper motivation. Believe it or not, it is not natural to want to know what the 'sort' function does. Even the most curious, smart individuals may ponder for a moment the implications of not knowing what that black-box function is doing, but very few are compelled to start digging.
And really, what's so bad about that? If the sort function solves your problem, then guess what, you just solved your problem. Now, next week when they plug in some new sets of numbers and their program breaks, they'll have to figure out what the hell the sort function actually does. Then two weeks later when they need to plug in large data sets, and the program takes days to run, they'll need to investigate better algorithms, and so on.
It's called classic problem solving, and it doesn't get nearly the credit it deserves. It provides proper motivation (not forced motivation, or misguided motivation). One is not simply compelled to ask "Are there more or less efficient ways to sort numbers?". There must always be a reason.
Lastly, what is academias obsession with berating professional coders?
>I learned the BASIC and Pascal languages at school. Who uses those now? No one. Learning to code an iPhone or Android app is great fun - but in 10 years time when those children are adults, the world will have moved on and Objective C will be yet another obsolete language.
Let's just ignore the implied purity of the former two languages mentioned, but Objective C is used to program for the most popular phone the world has ever seen. You average kid grew up with one of these things, it's very natural to want to make something for it. This attitude is really unfortunate. People that go from zero to making shippable apps are pretty awesome, it takes a lot of effort to persistently learn (by yourself!). What makes it worse is that the computer scientist and the coder who wants to solve/ship something are trying to solve two completely different problems. There is no reason for this kind patronizing.
The point of all of these campaigns is to get people building software as a trade, or skill to MAKE useful products and services for other people, be it full time or part time.
The president and others don't distinguish between CS and programming largely because they don't know the difference, but my guess is also because making the argument about which is which is largely irrelevant to their point because those knowledge requirements vary wildly depending on the intent of the software.
For some pieces of software you don't need to know CS to make a successful product, for others you do. The whole point is to get the average person - or at least a larger amount of workers - to be able to solve problems and create solutions with software.
While almost everybody agrees that pure rote memorization is not usually the right approach in (any kind of) teaching, I tend also to be very skeptical of the oppositely pure approach.
We might reason that the programming languages we usually use today are not likely to be the ones used tomorrow, but the tremendous amount of understanding one can achieve using the languages of today can still be useful tomorrow.
Notation/code are purely conventions -- the idea they can express can be expressed in any number of ways. Nevertheless, ignoring notation/code can be harmful. Paraphrasing Leibniz, notation can be the difference since the necessary labor of thought is wonderfully diminished.
Valid point, but I'm more peeved by how the campaigns incorrectly interchange CS with coding with programming, which will probably lead to student confusion.
In any event, they're calling it "learn to code" for a reason. They're focusing purely on pragmatics - operating entirely within the confines of the abstraction that a language presents you. It's a mechanical skill.
The whole thing is a sham to appear progressive, anyway. I honestly do not believe computer science and programming are fit for the outdated bureaucratic classroom/routine model of schooling. We should worry more about how efficiently it will be taught, than about nomenclature.
I think this is related to the question about which programming language to use for teaching. For me the MIT switch from Scheme along with SICP to Python is a shift from teaching CS to teaching how to code, for the better and the worse.
I utterly and completely disagree with the notion that teaching someone numbers.sort(...), and that having fun building an iphone app in a language that will be obsolete in some number of years is not as valuable as learning the "fundamentals" and the underlying reasons why something works.
teaching numbers.sort(...) is saying to someone "heres a tool, and here' how to use it. Some people will want to go on and understand how and why the tool works - and we should recognize those folks and encourage them.
this is the classic art / science / engineering conundrum -- they're all important and they all overlap.
I don't disagree that co!outer science is a more powerful perspective to learn, do a fun substitution exercise and replace computer science with building a car. We can lament that people just don't appreciate the beauty of the design process or that people who design cars really "get" cars better than everyone else and that the people who manufacture the cars really hold the power, but at the end of the day some people just need to know how to drive them. In my analogy, there are way too many people taking the "public transportation" route; teach em to drive.
I don't know where you're based, but in the UK learning to drive includes a moderately hard theory test. So, you do learn about stopping distances, why you should indicate, simple car maintenance etc.
Anyone can learn the basic mechanics of driving (right pedal go fast, left pedal for changing gears, turny thing to change direction) - but we should teach so much more than that.
That theory test is still all about operations and basic maintenance. They don't cover fundamental engineering points like crumple zones, valve timing algorithms, or the metallurgy of the engine components.
In term of teaching strategy, if you separate the hands-on, try and tinker things, from the more fundamental, you end up with only half of the learning process.
A good teaching format will help you learn the fundamental by connecting it to hands on building, to experiments, to the intrinsic reward of creating something. You can alternate or mix them. Most of the time you have to start with creative tinkering and foster going deeper and deeper.
So: yes, and yes! :-)
I'd have thought the best strategy is to teach coding/basic scripting as a requisite course earlier on and then allow more official CS education to be something a student can choose to do in a later course if they so choose.
The basic understanding of how to use a programming language will be of practical use to them, the CS course will let them understand what the programming language is actually doing under the hood.
Although I agree a broader scope is needed when teaching kids to "code", I feel there is a such a threat to digress and swing the learning pendulum in the other direction. Meaning that the kids never get filthy bugs on their hands but end up learning about Silicon Valley Entrepreneurship.
Sometimes it pays to dive right in and let them lead there own way out.
Medical software is now clawing its way out of lots of bad software written by people with good ___domain knowledge and too little programming and CS chops. Really, the point should be to make sure the larger culture knows what it doesn't know.
Imagine if many financial institutions didn't fully understand their debt instruments...that would be bad, right? (2008) Well, many companies don't understand their technical debt, act like it's some kind of magic, and tell themselves it doesn't matter.
make sure the larger culture knows what it doesn't know
A million times this. I am not sure if it is possible though.
I fear that any programming training as part of basic education will only expand the number of people who feel entitled to code, because they've been exposed to it, and then commence to build absolute shit. That is already a big enough problem, with large-scale failures like the Target breaches or healthcare.gov.
That was plain stupidity and not a direct result of an exploit in software that was written. The malware used the default passwords on the embedded XP Payment software to gain root access and scrape the database.
> healthcare.gov
Although I tend to agree, I think this points more a flaw at the Government contract bid structure versus poorly developed code.
I don't see it this way—that learning to code is in some way less elegant and less conceptual than learning computer science. That "it's not science" anymore. Rather, your idea of "learning to code" is just operating at a higher level of abstraction from your idea of "learning computer science."
When you start with primitives like array.sort(), you're implicitly bringing the organization of a program or system as a whole to the forefront, while abstracting way the mechanics of that sorting process. This is a good place to start understanding individual computer programs and systems.
When you start with primitives at the logical and mathematical level (i.e. theory), you're bringing the organization of lower-level concepts like data and control structures to the forefront. This is a good place to start when understanding the components that go into higher-level primitives like "sorting."
And you can go up and down in terms of the level of abstraction you want to view computer systems. Go higher, and you'll think more about the way multiple computer systems integrate (this is precisely what frameworks, APIs, and SDKs tackle). Go lower, and you'll think more about the way hardware interacts with machines (which, ironically, brings us back to electrical "engineering"—not science!).
To me, it's all just layers of abstraction, and the layer you choose should just be the one you find natural, interesting, and maybe useful. It's not a strict hierarchy; there are branches and perhaps cycles. But our understanding of the systems that run industry today, are only possible upon a complex system of abstractions that goes all the way down to the physics of the universe.
There are patterns and antipatterns to understand when "learning to code" (at the systems level), just like there are patterns and antipatterns to understand when "learning computer science" (at the theoretical level), but they just operate at different levels.
The term "computer science" implies that it is science, and not engineering. I think that the main reason theory is seen more as an "academic" pursuit as opposed to more abstracted understanding of computer systems is precisely because it has been so thoroughly abstracted, that trying to operate on a purely theoretical basis is just too inefficient to be particularly "useful" in an engineering setting, by some metric. It's not because of innate beauty or complexity; it's just where that arbitrary line is drawn.
CS is about algorithms, data structures, evaluation strategies - hows and whys, while coding is about memorizing stuff - <tr><td>..., getElementById(), public static void..., etc.
Logo is still the easiest to grasp programming language for young children with the possible exception of Scratch, though I still think Logo is better.
From my experience, the Logo Turtle is a neat idea - but it often got stuck and couldn't crawl around. When it did work, kids used to draw crude pictures!
If instead you teach basic skills in the best way, through fairly rote learning combined with application, then later abstract concepts are possible and can be discussed. The idea that you have to do one (abstract concepts) without the other (basic skills) is simply an attempt to limit the types of people who can succeed at an activity to only those people exactly like the teacher.
In other words, attempts to teach abstract concepts first as if basic skills are pointless are simply attempts to weed out undesirable people, which is what this article's proposal would do.