One argument for project-based learning is that it is fun and feasible. Few people have the discipline to sit down and learn for hours, but this becomes much more tolerable if you’re working towards something concrete. It also has the advantage that you might end up with something you can show to potential employers.
I agree that it is not the most efficient form to learn. It would be much better if we had a private teacher. The alternatives he lists all have some enormous disadvantages. I don’t see how “writing just the networking component of a larger system” is not a project (the same goes for the fourth alternative). Also, you first would have to understand the complete system, which would be potentially more inefficient to write something yourself. The other alternatives are all variations of “get someone to set up an ideal learning environment for you”.
You don’t need to understand the complete system to write its network component, you only need to know what it’s supposed to receive and transmit and how it’s supposed to react to it.
The problem with real life projects is that more often than not, there are simply no specs either because no one has time for it or the requirements change too quickly. For a toy project that stay the sames from one course run to another, both are non-issues.
It also has the advantage that you might end up with something you can show to potential employers.
Exactly.
In addition, no musician enters a band or orchestra by showing off how well they practiced scales. They won’t ever be prepared to play live if they didn’t practice in front of people before.
No martial artist can be realistically fight in real life or in competition without actually fighting someone before.
As always in life, balance is everything. You need a mix of specific trainings and higher level training.
The author talks about how project-based learning fails, and then suggests…more little projects?
The author complains about choice of languages for teaching and being too vocational, ignoring that this line of thinking taken to its logical conclusion would mean we only cover pure math in school (which, while tempting, seems a bit misguided given the code I’ve seen written by mathematicians learning languages on the job).
The author’s biggest argument is that projects fail to teach and they show this by constructing a strawman where somebody is excited about a project and decides to pair with somebody who takes all of the tasks they wanted to learn from. First, I don’t think most projects have this neat organization of tasks into a spreadsheet making it easy to swipe the juicy bits. Second, if the purpose was learning I’m pretty sure the person who wanted to learn networking would’ve objected when the networking tasks were all swiped. Lastly, it just seemed like more of an argument for not pairing.
Oh, and then of course, the author sells us on their new course designed to teach us (via drills, which are not totally not toy projects , because the ad just told us that projects don’t work).
Just leaves a bad taste in my mouth.
Edit: The author, ladies and gentlemen. This background does suggests a very academic bend, which might explain the approach taken–that, and their desire to sell coaching.
I agree with you. As both a trained musician and programmer, the parallels drawn in this post are in pretty bad faith. The core antagonism of the argument is “sometimes you don’t get to do the things you need to practice” which has nothing at all to do with projects.
This reminds me of a talk by Mike Acton (I think it was this one) where he said that you should practice every day. In his case it’s optimization, so pick a function and understand how it’s being used, what it compiles to and what are the bottlenecks, etc.
But what about other kinds of practice? Should you pick a random codebase and try to understand it in as little time as possible? Add tests to a random library? I found this notion so foreign when I first watched that talk, I think it’s because we don’t really have a culture around this. Sometimes I try to practice with Project Euler problems, but implementing algorithms is something I never do at work.
Pretty sure I learn better and faster through projects. Theoretical learning just doesn’t have the same “stickiness”.
I’ve actually thought about this quite a bit because some theoretical learning is needed and it’s great to have.
Here’s what seems to work for me (learning a new framework, language etc.).
1) Learn just enough to get started. (Or copy something without fully
understanding the nuances to hack on).
2) Start (This is part many theoreticians never get to.
Even less get to Finish).
3) Find the pain points. Look up the answer. Rinse and repeat for a bit.
4) In many cases (if thing is important or needed):
Finally give up and methodically read the docs or take the class.
Now the information is pertinent rather than just words and
disembodied concepts and it seems to take hold.
Doing it in the reverse order just doesn’t seem to work nearly as well.
That’s basically the same process I go through. Steps 1-2 quickly provide a mental model for understanding the subject. Once you have that model, it’s easier to do a proper reading of the documentation and incorporate that information by relating it to a project you’ve already started.
One argument for project-based learning is that it is fun and feasible. Few people have the discipline to sit down and learn for hours, but this becomes much more tolerable if you’re working towards something concrete. It also has the advantage that you might end up with something you can show to potential employers.
I agree that it is not the most efficient form to learn. It would be much better if we had a private teacher. The alternatives he lists all have some enormous disadvantages. I don’t see how “writing just the networking component of a larger system” is not a project (the same goes for the fourth alternative). Also, you first would have to understand the complete system, which would be potentially more inefficient to write something yourself. The other alternatives are all variations of “get someone to set up an ideal learning environment for you”.
You don’t need to understand the complete system to write its network component, you only need to know what it’s supposed to receive and transmit and how it’s supposed to react to it. The problem with real life projects is that more often than not, there are simply no specs either because no one has time for it or the requirements change too quickly. For a toy project that stay the sames from one course run to another, both are non-issues.
Exactly. In addition, no musician enters a band or orchestra by showing off how well they practiced scales. They won’t ever be prepared to play live if they didn’t practice in front of people before. No martial artist can be realistically fight in real life or in competition without actually fighting someone before.
As always in life, balance is everything. You need a mix of specific trainings and higher level training.
I don’t really agree with this, like, at all.
The author talks about how project-based learning fails, and then suggests…more little projects?
The author complains about choice of languages for teaching and being too vocational, ignoring that this line of thinking taken to its logical conclusion would mean we only cover pure math in school (which, while tempting, seems a bit misguided given the code I’ve seen written by mathematicians learning languages on the job).
The author’s biggest argument is that projects fail to teach and they show this by constructing a strawman where somebody is excited about a project and decides to pair with somebody who takes all of the tasks they wanted to learn from. First, I don’t think most projects have this neat organization of tasks into a spreadsheet making it easy to swipe the juicy bits. Second, if the purpose was learning I’m pretty sure the person who wanted to learn networking would’ve objected when the networking tasks were all swiped. Lastly, it just seemed like more of an argument for not pairing.
Oh, and then of course, the author sells us on their new course designed to teach us (via drills, which are not totally not toy projects , because the ad just told us that projects don’t work).
Just leaves a bad taste in my mouth.
Edit: The author, ladies and gentlemen. This background does suggests a very academic bend, which might explain the approach taken–that, and their desire to sell coaching.
I agree with you. As both a trained musician and programmer, the parallels drawn in this post are in pretty bad faith. The core antagonism of the argument is “sometimes you don’t get to do the things you need to practice” which has nothing at all to do with projects.
This reminds me of a talk by Mike Acton (I think it was this one) where he said that you should practice every day. In his case it’s optimization, so pick a function and understand how it’s being used, what it compiles to and what are the bottlenecks, etc.
But what about other kinds of practice? Should you pick a random codebase and try to understand it in as little time as possible? Add tests to a random library? I found this notion so foreign when I first watched that talk, I think it’s because we don’t really have a culture around this. Sometimes I try to practice with Project Euler problems, but implementing algorithms is something I never do at work.
Speaking only for myself:
Pretty sure I learn better and faster through projects. Theoretical learning just doesn’t have the same “stickiness”.
I’ve actually thought about this quite a bit because some theoretical learning is needed and it’s great to have.
Here’s what seems to work for me (learning a new framework, language etc.).
Doing it in the reverse order just doesn’t seem to work nearly as well.
That’s basically the same process I go through. Steps 1-2 quickly provide a mental model for understanding the subject. Once you have that model, it’s easier to do a proper reading of the documentation and incorporate that information by relating it to a project you’ve already started.