brandon@
2022-12-20
twitter
This essay is edited from a piece I wrote while crowdfunding the development of Little Hackers––an augmented reality powered workbook that teaches kids ages six and up Python fundamentals through readability. Little Hackers version 1 was funded successfully and shipped to 1,000 backers globally. If you're interested in purchasing it, you can find it here.
What is the difference between learning to code and having a path to a successful career in technology?
I believe the key differentiator is leadership. In many cases, kids already have some form of natural leadership ability. When my son comes to me and says “I’d like to build Fortnite but with some stuff from Minecraft”, the engineer in me says “do you have any idea how difficult it will be for you to reverse engineer and then recombine those two games at six years old”? But, I stop myself and remember: he has identified an immensely technically challenging goal. My job is to support that goal. Coding is a tool to accomplish the goal. A large part of technical leadership is about self-identifying goals.
Learning to code is not a quantifiable goal. It took years of being a professional engineer to be able to express this. This is why engineers may get (quietly) frustrated when people ask how quickly they can learn to code by going to a boot camp. It’s very difficult to answer. Yes, one can learn a new language in a short amount of time, but what does that mean without context?
Around the world senior engineers spend their days continuing to learn how to code—better. Coding is only a means to a larger end. Setting “learning to code” as a target puts the learner at a disadvantage because it diminishes the fact that the actual goal is not simply learning to code, but rather solving problems.
The divide between learning to code and joining the conversation with regard to designing systems which address real world problems is not a gap, it is a chasm. When the goal is scoped with purpose, developing the passion to learn the technologies is a natural outcome.
I learned to code as a teen through self-study using books like Sam’s Teach Yourself C in 24 hours and hacker tutorials like Smashing The Stack For Fun and Profit. Inspired by movies like The Matrix, my goal was to become respected by the underground hacker community. I now recognize that this was the launchpad for who I would become as an engineer. Since hacking requires reverse engineering, before you write a single line of code, you need to read and understand someone else’s program so well that you can modify it. A quote I read as a teenager stood out to me then, and still resonates with me today: “Think before you code”.
The specific syntax of a coding language becomes less and less relevant as a career progresses. I often hear the question “which language should my child learn?”, or candidates will list fluency in certain languages on their resume. The reality is that in most fast-paced big tech companies, if you don’t know the language used for a project, you’re expected to learn it on the fly. Coding is not about choosing a language, it’s about expressing your designs and thoughts in a way that can be understood by computers and collaborators. In large part, top-tier technical interviews that land people large salaries are conducted using a whiteboard and no computer at all.
Here’s an analogy from the world of music. When a kid begins to take music lessons, is the goal writing music or is the goal reading music?
Learning to read music is a quantifiable goal. Once you know the notes, the sounds, and the rhythms, you can take any piece of music and understand what it’s trying to communicate. One could argue that some of history’s most legendary players never learned to read music. But the important thing to realize is that reading music has less to do with one’s eyes, and more to do with one’s ears. Leaders in music train their ear to hear first. Leaders in music can deconstruct songs simply by listening. In this way, reading great code is similar to hearing great music. It’s how a person learns and develops a style.
If you think about it, there’s really no end to what it means to write music. Knowing the symbols and how to play some songs doesn’t mean that someone “knows how to write music”. It’s a lifelong objective. The key is that the ability to interpret and understand other people’s work will deeply influence how you compose your own pieces on the journey. You never truly know how to write music, what you learn is how to add to the conversation by reading what others have done.
This is what it means to code. We can accelerate learning efforts by teaching even younger groups of kids how to read simple code. Once kids understand the meaning behind code structures, they can bridge the gap and begin to create new ideas on their own. They can understand increasingly complex examples and ask meaningful questions. They can build a vocabulary to share ideas.
Technical leadership can separate the good from the great. A technical leader is someone who has such a deep understanding of the goals and technologies involved, that they’re able to take ownership of a project’s success and influence others around them to maximize their potential. Technical leadership has less to do with writing code and much more to do with understanding.
The theme is that leaders self-identify goals, work backwards to understand the technology requirements, and are able to translate requirements across groups of people to accomplish the goal. Readability enables kids to become leaders in technology because it offers one of the most important early tools: the ability to recognize and comprehend systems that they can use to accomplish their technical goals both at an early age and throughout their lives.