Shai AlmogI taught myself to code from scratch. I just started writing in Basic on my Sinclair when I was in kindergarten and “got it”. I later picked up the books and courses easily without that initial study period of formal training. When I got to advanced academic materials I already knew pretty much everything. As a matter of fact, I never learned much from teachers. I learned to read mostly on my own and followed through with most disciplines.
This isn’t a “brag” because the reason for that is a learning disability. It’s hard for me to understand teachers and communicate with them. This was a problem in my childhood but became a bigger problem when I started to teach programming in a local computer lab at 16. I was a terrible instructor. Typically we would mimic the skills of a good role model when performing a task, I didn’t have any good teachers. At least not good for my learning disability.
I kept teaching on and off for over a decade. It wasn’t because I was good (I wasn’t), but you couldn’t tell that from the feedback I received. Most students gave me high ratings, why did they?
The main reason was that I was knowledgeable and made an effort. The students who “didn’t get it” would end up blaming themselves or making an extreme effort to understand. This dragged on for a while until I faced a class in which I got a bad review. It stung and I initially rejected the notion that I could be the one at fault. Eventually, it sunk in.
I took that to heart and improved, I’m still not a great teacher. One of my shortcomings is my thought process isn’t visual enough so I don’t communicate as visually as most students need. I’m working on that, it’s an ongoing process.
People like me who aren’t natural teachers need to overcompensate in other departments. One of the biggest tricks up my sleeve is my approach to learning. I teach theory in short bursts while focusing on building something cool.
Why do we Have Hello World?
As a teacher, I usually taught advanced classes. Those are the “easy” classes to teach. In these classes, the students already have a decent baseline. If they don’t understand something they can check and they don’t get intimidated or ashamed because they missed something the teacher mentioned.
A beginner class is an enormous challenge. If I explain something only once, or I forget to mention something, I might lose the entire class. People might be missing basic knowledge and if I explain it too much or too thoroughly some students might get bored and lose interest.
You lose if you do and you lose if you don’t. There’s very little “winning” in this area.
That’s why we have the “hello world”. It isn’t just to show how the language looks or how the tools function. It’s a “win”. Once we compile and run a version of “hello world” we accomplish “something” and that is the most important part. It gives students the motivation to keep going and double down. Even if I missed something when teaching, they might make the extra effort to go back and learn or ask a question if they feel a sense of accomplishment.
A few years ago gamification was a “hot trend”. Thankfully it’s out of vogue, I never liked it. Stack overflow is great (that statement doesn’t condone the actions of overzealous rogue moderators), but what I liked about stack overflow wasn’t the gamification. It’s the accomplishment that rewarded that. I enjoy the points or badges not because they are points or badges. I enjoy them because I earned them by giving a great answer. This is the core of the matter and what most learning experiences miss: winning.
In it to Win
I see a syllabus like this in practically every “beginner” oriented course:
Hello world
Variables
If statements
Loops
…
We accomplish one thing. Then it’s “study”, there’s no “reward” for successful accomplishment or something measured that would trigger excitement. I get why we teach that way… People need the theory. But is that theory sinking in if we learn it sequentially?
When we build an ongoing demo and constantly improve it; we learn the theory while continuously accomplishing such goals. Better yet, we can intertwine it with a narrative story of developing an application or a game that helps memorize and form a narrative trail. There’s one downside: the tutorial sucks as a reference since the ideas are mixed within an additional narrative.
But the advantage is the “show don’t tell” approach. I love encapsulation. It’s wonderful. Don’t explain it. Show me why the code looks bad if I don’t use it. Don’t explain every type and waste my time, show me how to build stuff and then go back and refine it to explain the nuances involved in practical terms. This is the exact approach I tried to take with my Java Basics free course. The idea is that we can build a Wordle clone without knowing anything and slowly refine it into a real-world application.
Yes, we need to understand some basics before we can write something useful. But the bar is very low. Better yet, we need to make flawed and imperfect code so we can show how to improve and fix it.
Achievement Unlocked
When we say gamification this is what it really means; to achieve something meaningful and not merely satisfy a metric a company needs to further push a user through a funnel. This applies to teaching coding skills and to your SaaS.
Quite a few SaaS companies still show pointless “awards” and badges to get us engaged. Even kids don’t buy that nonsense in their iPad games. A reward matters only when you made an actual effort and should signify something with meaning. There’s harm in those nonsense awards as they reduce your credibility. When you have an important milestone that award won’t matter as much. In any product, we need to divide the steps into achievable hops where something meaningful is accomplished before moving to the next step.
An important aspect is milestone communication. A person needs to understand the goals, short and long-term. When I teach I start a lesson by discussing what they will know by the end of the lesson: why should you pay attention?
When I start the course I need to discuss the ending. What you will know and ideally show what we will build. I didn’t do this for the videos in the Java Basics course since I’m building them as I go along. That is not an ideal scenario. But I might revisit the first video in the series and redo it once I’m done. This gives us the motivation to work towards a clear goal.
