How not to run a Learn-to-Code Bootcamp
The story you are about to see is true; the names have been changed to protect the innocent.
Before the course begins
Don’t identify your target audience
Send the sign-up page to every subscriber under the sun who has ever given you their email address. Don’t have any information about their background or interests? Who cares, your course is SUPER IMPORTANT. It would be utterly remiss of you not to inform the hundreds of people who have ever entered their email address into your website.
Don’t mention the course content
Who doesn’t love a mystery?
Give no hint about pre-requisite skills
Let the mystery continue with providing only vague suggestions about how much prior programming people should have, and vague suggestions about prior languages that might be helpful.
Don’t cover anything about the sorts of programming people should have done.
Should they be familiar with writing functions? If so, how complicated? Who cares?
Provide no information about the time commitment
Again, don’t spoil the mystery! Everyone who signs up to a bootcamp has loads of time to spare. Therefore, this information is completely irrelevant.
Once the course starts
Printing to the console
It is compulsory for the initial code on the first day to print a message to the console. Be novel! Make them print something other than “Hello world”.
It is extremely important for programmers to know how to only print text they have supplied in the print command.
Don’t, whatever you do, emphasize how to incorporate results from their code into that print command on day 1. Bury this information.
Bury key syntax information
There are multiple pieces of information that can be buried!
Students must learn to read every sentence in your lesson carefully. Therefore, don’t put the key syntax points up the very top, at the start of lesson 1.
Instead, bury this information partway through lesson 1. Syntax is much less important than learning how to print “Hello world” to the console. It is also much less important than learning that + is the addition operator.
Put your lessons and your exercises on two separate screens
Learning how to use two screens is a skill that programmers must learn eventually. How better to teach them than by splitting the lessons and exercises? I mean, books have tended to have exercises at the end of each chapter. The book model is super important to use in online courses.
Headings, shmeadings
When teaching people how to code, don’t use headings for each subsection in a lesson. The learning experience is enhanced by making students scroll backwards and forwards. The longer the lessons page, the better! There’s always the “Find” option in their browser!
Bonus points: sometimes use headings, and sometimes not.
Hints and solutions
Hints and solutions that are commented out are useful to students. We sometimes get a bit stuck on why our code isn’t working. If we get really stuck, we can see how our code differs from the solution.
This experience is enhanced by ensuring that the hints and solutions return errors when run by students. Ignore the student comments that mention that the hints and solutions aren’t working.
This is particularly important in a bootcamp, where students have a different lesson each day, and the hints and solutions aren’t fixed ahead of the following day’s lesson.
Penalize students for creativity
There is only one way to write code. Use examples that encourage thinking about user-supplied input. Do not tell your students how to get the user-supplied input. Bury the code on how to generate random numbers (which can be used for debugging) in exercises marked as difficult.
Do not anticipate that user is good with Googlefoo. Obviously, because they have some prior programming experience, they have never used Google to locate code examples.
But assume they have Googlefoo for working out how to create random numbers to test their code. Or that they read the entirety of exercises marked as particularly challenging.
Allow their code to run perfectly on their lessons page. Then, after the student commits the code and the code is public, put up huge errors.
It’s their own fault, they should have looked at the hint. They could have just used the solution if they were really stuck.
Get course feedback on the first day
Everyone knows that the first lesson is the perfect time to get student feedback. The first lesson is the most difficult. How many students can correctly spell “Hello world”? Also, basic algebra is very complicated for programmers coming to a new language.
The mystery twist
I gave up after the second day.
