In an ironic twist of educational fate, our proficiency in teaching programming has led us to a peculiar crossroads where excellence in instruction breeds mediocrity in practice. We've become so adept at teaching programming that we're actually churning out subpar programmers.
Here's where I'm coming from: I am a bad coder. My journey into coding was purely self-taught, initially sparked by the need to build and manage our company's first website. I had taken coding classes in the past, but it wasn’t until there was a specific need—e.g., a startup with no money to hire a web developer—that I was truly motivated to learn how to build something substantial.
Beyond my own coding escapades, my role has expanded to collaborating closely with some truly stellar programmers. These individuals come from all walks of the coding world—self-taught wiz kids, university degree holders, and BootCamp graduates alike.
Working alongside such a spectrum of coders has been nothing short of enlightening. At Mission.io we're crafting an advanced collaborative game framework designed to teach complex skills through immersive gaming—a project unprecedented in its ambition and scope. This journey has shattered a preconception I held tightly: the belief that the quantity of code one knows, or the breadth of their experience, is the ultimate measure of their worth as a developer.
What has become glaringly apparent, especially in the context of pioneering work, is that the depth of one's coding vocabulary plays second fiddle to a far more critical skill—learning agility. The most invaluable trait a team member can possess, beyond aligning with our vision and being dependably solid in their collaboration, is the capacity to learn swiftly and resourcefully. The ability to navigate the vast seas of the unknown, and fish out the right answers, is what truly sets apart the good from the great in the coding world.
In the early days of introducing coding into the educational landscape, it carried an aura of mystique, typically associated with the quietly brilliant kids in hoodies, typing away in corners. It was a new frontier, one we instinctively knew held importance for the future, despite not fully understanding its depths. With this recognition came the initial attempts to weave coding into the curriculum, a task that often fell to the most tech-savvy—or rather, the least tech-averse—among the teaching staff. The criteria were simple: Can you successfully connect a projector? Congratulations, you're now our resident coding instructor.
This makeshift approach to teaching coding birthed a fascinating and, in hindsight, vital dynamic within the classroom. Teachers, often learning alongside their students, couldn't possibly hold all the answers. Their role evolved into one of facilitation rather than dictation, pushing students towards goals and holding them accountable. Students quickly grasped that their teacher wasn't the oracle of coding wisdom they might have expected. Instead, they learned a foundational skill of coding (and arguably of modern work)—the ability to independently find answers and solutions. This environment fostered not just a familiarity with coding but a profound understanding of learning as an active, self-directed process, a skill that would serve them far beyond the computer lab.
Fast forward to today, and here's where my concern lies: our proficiency might just be breeding mediocrity. The landscape has shifted dramatically. Now, teachers coming into the classroom often boast years of practical coding experience or at least several years of teaching it. This expertise, while invaluable, brings with it an unintended consequence. When students are faced with challenges, the immediate response is to provide them with answers, neatly wrapped and ready to use. This efficiency in teaching, as commendable as it appears, might actually be doing a disservice to our students.
By handing answers to them on a silver platter, we're inadvertently robbing them of the most critical skill a coder can possess: the ability to find solutions independently. The truth that often goes unspoken is that a significant portion of a programmer's time isn't spent writing code; it's spent scouring Google, Github, and StackOverflow for answers to problems. This act of searching, of piecing together information from various sources, is where the real learning and understanding of coding happens.
The term 'programming languages' naturally invites comparisons to traditional language learning, which invites us to apply old, less effective habits. These are habits I wish we could move beyond.
When we teach kids to write, the process is methodical and linear: learn each letter, construct words, learn to use those words in sentences, and start combining sentences to create paragraphs. Yet, as their writing matures, our feedback often transforms too, becoming a sea of red pen marks focusing on every misplaced comma and misspelled word, rather than the richness of the ideas inked on the page.
This ritual of dissecting their writing for technical flaws, while neglecting the heart and substance of their message, is what I believe distances students from the true essence of writing. It's a stark reminder that the ability to convey meaningful, valuable ideas holds the key to their future success—not the relentless pursuit of grammatical perfection. If we're not careful, this same approach could alienate students from coding, too.
Consider how a child learns to speak. It begins with experimentation: making sounds, forming words, and eventually stringing those words into sentences. Despite grammatical inaccuracies or invented vocabulary, every attempt is celebrated. This environment of encouragement fosters rapid learning and exploration. Imagine, for a moment, if we taught children to speak in the same way we teach them to write—focusing on grammatical perfection from the outset. It's likely they wouldn't speak fluently until well into their teens.
This brings us to a crucial realization: coding cannot—and should not—be taught purely as a language. The essence of coding lies in the act of creating, in the engineering behind the code. It's about building, experimenting, and learning from the process rather than memorizing syntax and rules. Those focused on teaching the 'language' of coding need to rethink their approach. We should aim to teach coding more like how children learn to speak—encouraging exploration, celebrating attempts, and focusing on the construction of ideas rather than the adherence to linguistic perfection.
In an amusing twist, the path to enhancing our coding instruction might just involve embracing our inner "bad coder." Fortunately, I've maintained my status as a quintessential bad coder, which, in this context, makes me somewhat of an expert.
By following these strategies, we can steer coding education in a direction that values creativity, critical thinking, and independence over rote learning and memorization. Let's embrace our "bad coder" instincts to foster a new generation of coders who are not only proficient in the technicalities of programming but are also adaptive, innovative problem solvers ready to tackle the challenges of tomorrow.