>Aaaand the rest of the article is pay walled by medium...
AFAIK Medium doesn't paywall content (at least like this?). That modal you get has a button to close it in the top right corner. I understand the aversion to paying for things but please make sure your attack is valid before throwing it out there.
Medium doesn't paywall content...yet. They have been raising walls for months now, with all the elements in place - "you have read X articles, register for more"; all they need is to flip the metaphorical paymentRequired bit.
They do paywall member-only content with a real-life paymentRequired bit[1], which writers are encouraged to use. You can (for now) create content that doesn’t require a membership to read.
When you publish a story, they ask if you'd like them to curate it for distribution—then include that opting for distribution automatically paywalls your story. It's less than ideal.
Thanks for the differentiation! I was pretty sure there was some paywalled content out there but I know this article is not in that category. I appreciate you sharing.
In my experience it depends on the blog/article. You aren't always able to see the full article without logging in and you get a limited number of free articles when signed in.
I have yet to run into an article limit without being signed in. I hit the limit on the reg as many tech articles that turn up while troubleshooting are on Medium these days. Maybe the problem is signing in?
Yes the problem definitely is related to signing in. Ironically you can view more if you do not! However, I have run into a few blogs/articles that require sign in to read.
This is an active area of CS research into what is called “tracing” - looking at a program and reasoning what it’s output would be. In a research study I was involved in 2 years ago, the efficacy of various teaching methods for introductory computer science were measured by student’s ability to trace program execution rather than by the ability to write code.
I was interested in research on this as well, just googling I found http://www.it.uu.se/research/group/cetuss/Events/2005-12/pro... which studies how students go about tracing a piece of code. It doesn't go into learning techniques, but categorizes the techniques first year students use to trace code (which they say is often poorly done). It seems interesting base level research to start with. It was kind of interesting to monitor my own mind when I traced the example code to see how I went about it also.
The paper linked adjacent to this comment looks interesting as well. What I gathered from the experience was that if you can capture student activity while they are tracing (e.g. eye tracking, recording incremental changes to a doodling interface and doing some pattern recognition on it, etc) you can fairly accurately and repeatably figure out their structural thinking ability.
We've started doing this in pair-programming too, without knowing a term for it. Make a change, then before running it, verbally state what we expect to happen. It seems to help a lot. It's turned into a regular habit for me when programming solo as well.
This is really great. It's really important to minimize the number of things students have to understand so they can focus on the things that they need to decode, at least in my experience. A good example is worth so much.
This guy clearly hasn't taught at a coding bootcamp. While he means well, you absolutely MUST go through the basics - the key is not staying there for long because, yes, it's boring.
It's important to give context and ground your proposed problems in reality. Relatable content is the single most important part, so skip the "foo/bar" stuff and go for real-life examples. That's it! No need to write clickbait!
If you believe people with no coding experience will magically figure it out, you'll have a bad time and your students will hate you.
I have to agree. My wife is going through a bootcamp and I am stuck helping her with the fundamentals after the instructor tries to breeze past them. She's not a "figure it out later" kind of person and wants to know details upfront. Simply throwing a problem at her that she has no tools yet to solve creates a lot of frustration.
I co-founded Dev Bootcamp where I was responsible for training our teachers and designing our curriculum. I 1000% endorse the article.
The author isn't suggesting students will "magically figure it out". He's helping them develop the muscles they need to articulate, build, and refine their own mental models.
You can get students making CS-relevant predictions without them having ever seen a single line of code in their lives within the first hour. Students will enter the world of programming with an orientation that enables them to learn 10x faster, which is even more critical in the coding bootcamp context.
I'd say the author is helping students develop their capacity for abductive reasoning (https://en.wikipedia.org/wiki/Abductive_reasoning). The goal is to get students to build accurate models for what the computer/code is doing, not just form rules that happen to match what they've observed.
For example, here's a 100% true story. I once showed a student code like this (in Ruby)
my_name = "Jesse"
my_age = 32
puts("My name is #{my_name} and I am #{my_age} years old.")
They asked a great question: "Are the names my_age and my_name special? Do we have to use those names?"
I explained that, no, so long as you use the same name everywhere, it will always refer to the same value. The names of the variable aren't special. I changed the code:
my_giraffe = "Jesse"
my_waffles = 32
puts("My name is #{my_giraffe} and I am #{my_waffles} years old.")
I use names like "giraffe" and "waffle" so students still recognize them as nouns but are less likely to bring some prior, inappropriate context into their reasoning.
"Oh, I see!" they said. "You can use any variable names so long as they start with my_."
The fact that they articulated their rule clearly to both themselves and me right at that moment puts them in the like 95th percentile of beginning students. Induction is natural but dangerous for beginners, who are so desperate to make sense of what they see that they'll adopt the first model that accounts for what they see without any consideration of the alternatives.
If they were thinking in terms of _predictions_, though, they'd naturally test their model by removing my_ and seeing what happened.
it's interesting that for non-english populations, this part of programming does not really require explanation if the course uses local language words for names, and english vs local language is clearly keywords vs chosen names.
“Hey, I have a good idea for a game,” I said. “It’s called the function machine game. I will think of a function machine. You tell me things to put into the function machine, and I will tell you what comes out. Then you have to guess what the function machine does.”
I'd also like to see this approach for teaching more advanced coding concepts.
Does anyone know if there are any books/lectures that are something like "advanced readings in programming" where you are given real-world code samples that are high-quality? That paired with some questions to direct learning (along with some helpful context around the problem domain) would be really interesting.
Reads like socratic method 101, but holds weight from experience.
I used a similar method to teach pretty complex manual artillery firing to 17-20 y/o's with spotty high school education coverage. If a professor can explain (or get them to explain) in simple English a relatively math-free, logic-based solution to a problem, and then add the necessary terminology, it's majorly successful.
Interesting idea, will try this approach on my son.
I remember when I was a kid, I took an after school programming course and the teacher had a very cool approach to start us with:
All attendees were "computer nerd kids" with some programming knowledge, usually in BASIC (it was the late 80s), and the course was taught in Pascal. So instead of building from very basic principles, the first lesson was something like: "This is the editor, this is how you compile. Now, let's write an algorithm to find the largest integer in an array, and that way you'll pick up all the basic building blocks".
This was mind blowing to me, I was ready for an hour of "hello world" and demonstration of basic language constructs, like it was taught at school. But instead, in the first lesson he had covered compiler invocation, variables, static types (a totally new concept coming from LOGO or BASIC), functions, conditionals, loops, arrays and console output - and probably the very idea of algorithms. It was really great.
The original version of LOGO provided an emulated turtle that I'm pretty sure was shown on a display if one was present. It was on a PDP-something, though, so later cut-down versions might not have had it. (I think the Apple ][ one had one, too.)
Not only coding, but much else in my (Electrical Engineering) college education, was taught as if I was a computer:
- my God you cannot use a term without defining it first
- you define the term once, then never again
- always start from a very small, apparently useless example, then build up, only getting to something useful at the very end
This is a great way to program a computer. It is a lousy way to teach a human. Humans are more like machine learning algorithms; give them examples, then later explain the general definitions and syntax.
If machine learning ever becomes a mainstream method of programming, I wonder if it would cause programming instruction to improve? Probably not. The "define first, useful applications last" style of teaching is probably actually based on math and philosophy logic, so there's centuries of inertia there.
Interesting. In Mathematics classes, you usually have what are called 'motivating examples'. For instance, you might take an object and then see that you can't tell something about it, but if you restrict it in a certain way then it starts having certain interesting properties. The difference between a good lecturer and a poor lecturer is often whether they can give you good motivating examples.
The textbooks though are frequently as you describe. They execute like a computer program. Hartshorne's Algebraic Geometry is the classic example for me: it takes so much work just to go through each page. Even chapter 1 you have to skip forward to see that you can get the Nullstellensatz before you can come back to see why you're restricting your object in a certain way. This is no way to learn.
Ha! My last name is "Hartshorn", I was kind of thrown by your example at first. You are right, though, textbooks may be this way even more often than lecturers.
I had the same problem in high school math - symbols would be defined once, then the teacher would use them constantly but never explain what they meant again. And the only way to find it again is to thumb through the textbook page by page because the index lists names of concepts, not the arcane runes that correspond to them.
Learning to code helped my math ability greatly, now I see sigma and think "for each, add to total".
This is great! It's also very similar to the approach we use to teach deep learning at fast.ai, based on research into teaching methods done by David Perkins at Harvard. A couple of our principals are:
- Teaching “the whole game”–starting off by showing how to use a complete, working, very usable, state of the art deep learning network to solve real world problems, by using simple, expressive tools. And then gradually digging deeper and deeper into understanding how those tools are made, and how the tools that make those tools are made, and so on…
- Always teaching through examples: ensuring that there is a context and a purpose that you can understand intuitively, rather than starting with algebraic symbol manipulation
Thanks for fast.ai. I think to some degree this maybe personality driven. Whenever I'm taught like that, I constantly feel anxious about "holes" in my knowledge. I believe it gets hard to plug those holes when you learn from a top down approach. The bottom up approach is harder for a reason, the knowledge gained is more thorough.
I know the feeling. Years later when you realize there definitely is a hole, but it might be in the second chapter of some pretty basic book, that you have skimmed several times without finding it, because it is so basic.
Spot on advice. Teach concepts by way of a goal/example first, then after the learner achieves the desired outcome, introduce the formal concept; it'll get etched in their memory.
For some people (e.g. me) it works to let them fail first by trying to achieve a goal without the requisite knowledge. This motivates them to learn. Unfortunately you can't really do this in a traditional educational setting or in the workplace (in both cases failure stains your "reputation"), so I can only do it on my own.
58 comments
[ 3.2 ms ] story [ 119 ms ] threadI’m serious — stop it with the gatekeeper introductions to content.
Aaaand the rest of the article is pay walled by medium...
AFAIK Medium doesn't paywall content (at least like this?). That modal you get has a button to close it in the top right corner. I understand the aversion to paying for things but please make sure your attack is valid before throwing it out there.
They do paywall member-only content with a real-life paymentRequired bit[1], which writers are encouraged to use. You can (for now) create content that doesn’t require a membership to read.
[1] https://link.medium.com/ptFLm9KZV1
The paper linked adjacent to this comment looks interesting as well. What I gathered from the experience was that if you can capture student activity while they are tracing (e.g. eye tracking, recording incremental changes to a doodling interface and doing some pattern recognition on it, etc) you can fairly accurately and repeatably figure out their structural thinking ability.
It's important to give context and ground your proposed problems in reality. Relatable content is the single most important part, so skip the "foo/bar" stuff and go for real-life examples. That's it! No need to write clickbait!
If you believe people with no coding experience will magically figure it out, you'll have a bad time and your students will hate you.
The author isn't suggesting students will "magically figure it out". He's helping them develop the muscles they need to articulate, build, and refine their own mental models.
You can get students making CS-relevant predictions without them having ever seen a single line of code in their lives within the first hour. Students will enter the world of programming with an orientation that enables them to learn 10x faster, which is even more critical in the coding bootcamp context.
That learning style thing has horrible consequences for about 40% of students in the American one size fits all public education model.
https://blogs.kcl.ac.uk/cser/2017/09/01/primm-a-structured-a...
For example, here's a 100% true story. I once showed a student code like this (in Ruby)
They asked a great question: "Are the names my_age and my_name special? Do we have to use those names?"I explained that, no, so long as you use the same name everywhere, it will always refer to the same value. The names of the variable aren't special. I changed the code:
I use names like "giraffe" and "waffle" so students still recognize them as nouns but are less likely to bring some prior, inappropriate context into their reasoning."Oh, I see!" they said. "You can use any variable names so long as they start with my_."
The fact that they articulated their rule clearly to both themselves and me right at that moment puts them in the like 95th percentile of beginning students. Induction is natural but dangerous for beginners, who are so desperate to make sense of what they see that they'll adopt the first model that accounts for what they see without any consideration of the alternatives.
If they were thinking in terms of _predictions_, though, they'd naturally test their model by removing my_ and seeing what happened.
Amusingly, your comment is a fun example of short abductive reasoning just like the student in the other guy's story.
https://byorgey.wordpress.com/2018/05/06/conversations-with-...
“Hey, I have a good idea for a game,” I said. “It’s called the function machine game. I will think of a function machine. You tell me things to put into the function machine, and I will tell you what comes out. Then you have to guess what the function machine does.”
https://www.looneylabs.com/games/zendo#howtoplay
Does anyone know if there are any books/lectures that are something like "advanced readings in programming" where you are given real-world code samples that are high-quality? That paired with some questions to direct learning (along with some helpful context around the problem domain) would be really interesting.
http://shop.oreilly.com/product/9780596510046.do
“The Architecture of Open-Source Applications”
http://aosabook.org
You also might be interested in “Coders at Work”.
https://www.goodreads.com/book/show/6713575-coders-at-work
I used a similar method to teach pretty complex manual artillery firing to 17-20 y/o's with spotty high school education coverage. If a professor can explain (or get them to explain) in simple English a relatively math-free, logic-based solution to a problem, and then add the necessary terminology, it's majorly successful.
I remember when I was a kid, I took an after school programming course and the teacher had a very cool approach to start us with:
All attendees were "computer nerd kids" with some programming knowledge, usually in BASIC (it was the late 80s), and the course was taught in Pascal. So instead of building from very basic principles, the first lesson was something like: "This is the editor, this is how you compile. Now, let's write an algorithm to find the largest integer in an array, and that way you'll pick up all the basic building blocks".
This was mind blowing to me, I was ready for an hour of "hello world" and demonstration of basic language constructs, like it was taught at school. But instead, in the first lesson he had covered compiler invocation, variables, static types (a totally new concept coming from LOGO or BASIC), functions, conditionals, loops, arrays and console output - and probably the very idea of algorithms. It was really great.
This is a great way to program a computer. It is a lousy way to teach a human. Humans are more like machine learning algorithms; give them examples, then later explain the general definitions and syntax.
If machine learning ever becomes a mainstream method of programming, I wonder if it would cause programming instruction to improve? Probably not. The "define first, useful applications last" style of teaching is probably actually based on math and philosophy logic, so there's centuries of inertia there.
The textbooks though are frequently as you describe. They execute like a computer program. Hartshorne's Algebraic Geometry is the classic example for me: it takes so much work just to go through each page. Even chapter 1 you have to skip forward to see that you can get the Nullstellensatz before you can come back to see why you're restricting your object in a certain way. This is no way to learn.
Learning to code helped my math ability greatly, now I see sigma and think "for each, add to total".
I think it's worth nothing that there are different learning styles, and some people actually enjoy bottom up approaches more.
- Teaching “the whole game”–starting off by showing how to use a complete, working, very usable, state of the art deep learning network to solve real world problems, by using simple, expressive tools. And then gradually digging deeper and deeper into understanding how those tools are made, and how the tools that make those tools are made, and so on…
- Always teaching through examples: ensuring that there is a context and a purpose that you can understand intuitively, rather than starting with algebraic symbol manipulation
If you're interested, there's more info here: https://www.fast.ai/2016/10/08/teaching-philosophy/
Thanks for fast.ai. I think to some degree this maybe personality driven. Whenever I'm taught like that, I constantly feel anxious about "holes" in my knowledge. I believe it gets hard to plug those holes when you learn from a top down approach. The bottom up approach is harder for a reason, the knowledge gained is more thorough.
I'm not sure you can just make that statement. Interest and motivation will be the deciding factors in the depth of your knowledge in the long run.
Imagine having to read the full manual of a video game before you can play it vs just fooling around and looking something up when you need it.
I touched upon this before in another comment: https://news.ycombinator.com/item?id=19010428
There are some great practical examples here of that 'better' that apply beyond just programming to general language learning as well.