My least favorite phrase is "those who can't do, teach". Two and a half years ago, I moved from a normal software engineering job to teaching General Assembly, a coding bootcamp. It changed my life for a lot of reasons — but one that stands out is my increased ability to program and the depth of my knowledge on the technologies I use every day.
I call myself a "mostly self-taught software engineer". I dropped out of computer science in college after two classes due to a mix of imposter syndrome and my career goals at the time. All of my web-development experience is self-taught - or ‘community-taught’, as I like to call it.
I taught myself well enough to build stuff at my job. I could read the documentation and Google my questions well enough to get where I needed to. But I didn't have the underlying concepts of web development at all. I didn't know whether `class`es were built into React or ES6. I didn't know a thing about JavaScript's event loop. I had never heard of the virtual DOM or the component lifecycle despite writing functional React code all day. Essentially, I could write code but I didn't know a lot of the *whys*. I had a lot of other skills that made me successful, like my ability to work with people and drive to learn new things.
I was terrified the first time I ever taught a lesson as a guest lecturer for General Assembly's data science program. I almost bowed out multiple times. I'm pretty sure the lesson was awful because I was shaking and could barely keep my thoughts straight. I had teaching experience, but mostly with kids instead of adults. I had taken multiple education classes in college, including doing my shadow semester at a local elementary school. But being in front of a classroom or adults teaching programming was much more intimidating. That being said, I learned so much from teaching the lesson. I taught the lesson on a Python library called Bokeh, which I'd heard of but was nowhere near an expert in. So, I had to dive deep to write the lesson. I picked up this new skill and learned a new library I loved working with, and I understood it way better than I would have otherwise.
I taught it again, and it went better that time. I was still terrified, but it was becoming more fun. I got questions from angles I would have never considered myself. And then a full-time position teaching web development opened up. I decided to interview for it, and landed the position.
I then had the challenge of teaching 18 students how to code from zero to professionals in 12 weeks. Again, it was a huge challenge. I knew the technologies we taught. I'd been working in React since just after it came out, I could hack my way through CSS and framework-less JavaScript, and I had used Ruby on Rails nearly daily as well. But I had never dived deep on clojures, prototypal inheritance, the box model, `this`, functional programming, and numerous other fundamental concepts. Sure, I could write code pretty well, but my knowledge was mostly surface-level.
In order to teach something to someone, you have to know the topic comprehensively. Bloom's Taxonomy is a fixture in teacher education - it's essentially a pyramid that displays the levels of learning something in-depth. The first step in learning is remembering it, followed by understanding, and then applying the knowledge. The next step is to analyze it in order to draw connections between ideas, then evaluate the connections which entails justifying your opinions on the topic. Finally you create, which means building on the concept with your own original work.
Teaching in a lecture-based format requires pretty much all of these steps. You need to be able to justify your opinions on the technology you're using, connect one concept to one another -- a technique referred to as ‘linking’ in teaching, and you must be able to build a curriculum to teach that technology well.
In order to teach people to code, I needed to dive deep. I needed to understand the surface level to build things, the concepts to explain them, and I needed to prepare for students' out-of-left-field questions. It was like doing an incredibly hard job interview all day, every day for my full-time job. I, in no way, could have taught if I didn't know the topic myself. My years of software engineering experience were invaluable, but I had to go so much deeper than that. I had to learn in my style and then disseminate that in as many learning styles as possible to the class.
My programming skills got better too. I understood the underlying web development fundamentals really well and could use them when I was writing new code. I also became more confident in my own skills, though impostor syndrome never goes away. Teaching also led me to start blogging, which got me more involved in the developer community, which ultimately transformed my life. Moving into a teaching role was the best thing I could have done for myself as a programmer.
Almost three years later, teaching is not only my job, it's also my passion. It's magical to see someone go from "hello world" to professional developer, and seeing programming become the adult version of LEGOs is the coolest experience. I have the best job in the whole world. But, it's so much more challenging than any software engineering position that I've held.
Coming back to the "those who cannot do, teach" phrase, if I couldn't ‘do’, there would be no way to teach what I teach. I live-code applications in every lesson, disseminate information in different ways to reach different learners, and have to anticipate questions from every angle.
Programming is difficult, but the problems repeat each other. Human problems are usually more complex than computer ones, and teaching is no exception to that rule.
