EPISODE 1704

[INTRO]

[0:00:00] ANNOUNCER: Codecademy is an online platform that offers classes on languages including Python, Go, JavaScript, C++, and many others. Zoe Bachman is the Senior Curriculum Director at Codeacademy and designs courses for the platform. She joins the podcast to talk about her work there. This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, the tooling that enables ESLint and Prettier to run on TypeScript code.

Josh is also the author of the O'Reilly learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube and dot com as Joshua K. Goldberg.

[EPISODE]

[0:01:03] JG: Hey, everyone. With me today is Zoe Bachman, from Codeacademy. Zoe, you have a very interesting career journey. Could you tell us about how you got started even before you were at Codeacademy?

[0:01:13] ZB: Yes. Absolutely. Thanks, Josh, for having me here. So, I'm definitely not your typical CS educator, although, a lot of us have had a variety of careers. For me, my interest in tech started when I was I was young. My dad worked in it and we were lucky enough at my middle school to have a computer class. So, I got to dabble in HTML back in the early 2000s, make some fun websites. But I kind of set that aside for a while because my - and still continues to be passion is art. So, my degrees were in art and anthropology, was doing a lot of like media studies stuff.

I became interested in tech as well. I got to study abroad in West Africa and did like a whole project on cell phone adoption. Around like 2008 wrote papers about like, Twitter, and how it was using protests back in the day. But most of my career up until I actually started working at Codeacademy was in the arts. I was an art teacher. I worked in art museums. It was kind of through that experience doing a lot of stuff around media literacy, that I thought about technical literacy. I was teaching middle school students, and I thought about how awesome it was that I got to learn how to code when I was in middle school and thought it would be a great experience for them, as well.

So, fast forward. I ended up doing a really cool program at NYU called the Interactive Telecommunications Program. Its nickname is The Center for the Recently Possible and the curriculum changes every year, because technology changes every year. So, when I was there, I graduate in 2017, we were doing some VR stuff. We're doing some machine learning and AI stuff, and I really went to that program to understand how I could translate my experience as an educator, as a community organizer, from the world of art, into the world of technology, and was fortunate enough to get some good employment opportunities to help with that transition.

I worked with Girls Who Code and their summer immersion program for two summers. Then, I was actually recruited by Codeacademy right out the gate. The day I presented my thesis, I got a recruitment email and was like, "Oh, this is convenient. I am looking for a job after graduation." So, yes, been there. We'll be seven years in June. Started off as a curriculum developer, and now I get to run the team that makes our courses.

[0:03:38] JG: Well, that's very exciting. What is a curriculum developer?

[0:03:41] ZB: That's an excellent question. I often think about curriculum developers as a kind of unicorn, at least from a hiring standpoint. Because as a curriculum developer, especially at Codeacademy, you don't have one area of specialty. You need to have kind of at least three. So, we look for people who obviously have technical backgrounds. They need to have some experience with coding, because they are writing courses on new programming languages, new frameworks, and because of the way our platform is set up, it's very interactive, and we do all of that through testing your actual code, you are writing, in our curriculum developers, that test code. That's one part of it.

Another part of it is creative writing. So, curriculum developers need to write our engaging narratives and think through how to make a compelling experience. If you've taken a course with us, we like to have a lot of puns and creative ideas for lessons and projects. Having that kind of writing talent is important. Then, the last part, understandably, is teaching experience. We are all educators. We all have some kind of teaching background. Many people like me started off as teachers, and then went to a coding boot camp, or a graduate program. So, being a curriculum developer is an awesome opportunity to combine all of those interests together.

[0:05:03] JG: Zoe, why would one need creative writing when teaching developers? Why would that be useful?

[0:05:09] ZB: Yes. I mean, for me, it's because teaching technical topics has historically been a really dry practice. I mean, I think there are some really awesome historical examples of people who did it in different ways. I know a lot of folks at Codeacademy were inspired by the person who wrote - I wish I could remember this off the top of my head, but it was like, it was a curriculum about Ruby, back in the day, I think, like comics or things in it. But point being that prior to Codeacademy, a lot of what learning to code was, especially if you're doing in your own, you weren't in a CS classroom, was reading from books. Maybe you're watching videos. But for us, we really believe that learning by doing is the most important thing. Design and write curriculum that gets you into the mindset of being an actual developer. But we don't want it to be totally dry, like, here's your JIRA ticket. We want to come up with different scenarios that we think will resonate with learners, so either we're pulling sometimes from popular culture, or we just make up kind of silly backstories for you, like, "You're someone who works in a furniture shop. You need to count your inventory." That type of thing. It's that kind of imagination that we try to employ in our courses to really make it come alive as you're going through the material.

[0:06:27] JG: That makes sense. There's a word that I remember from my time at Codeacademy that gets run up a lot. Could you help me pronounce and then define it? Is it pedagogy? Pedagogy?

[0:06:37] ZB: Pedagogy. Yes. You got it right the first time. So, pedagogy is kind of the art of teaching, and I guess to get really technical about it, it's specifically about teaching children, right? You think about pediatrician. It's that same root word. You can also have, I guess, you pronounce it andragogy, which is about focusing on adults. I just learned about this and I'm really not going to be able to pronounce this myself. Heutagogy is the management of learning for self-managed learners, which is definitely the types of learners that we typically see on our platform. But yes. I hope that covers that part of it. It's a word that curriculum developers love to throw around.

[0:07:20] JG: Why do curriculum developers love to throw around the word pedagogy?

[0:07:23] ZB: Yes, because it's hard to often distill the work that we do into a particular phrase, but pedagogy is one of them. Kind of mentioned before, curriculum developers have all these different skill sets that they employ to make engaging, learning material. At the end of the day, the object isn't to entertain you as you're learning, it's to teach you something. In order to do that, you need to know a lot about learning science, and the art of learning, as in pedagogy, and what are actually effective techniques for teaching people, especially in an environment where you're not in a classroom, face to face with your students.

I have a lot of experience with classroom teaching. I currently teach in a university setting. As a teacher, you pick up on so many things when you're in those environments, right? You can tell who's struggling, maybe someone who's getting a little listless and bored, because maybe they're not being challenged enough. But when we're in this type of online asynchronous learning platform, like Codeacademy is, we need to really think deeply about what's the kind of research that's out there to think about how do you craft a pedagogically strong learning experience. It's not just the content and stuff, too. It's also the features that we develop in order to make sure that you're coming to us with certain objectives in mind and we want to help you reach them.

[0:08:50] JG: So, let's say that I'm someone who's working at a company and I've been tasked with training up my fellow developers on a particular new technology. What can I learn from the pedagogical experience of curriculum developers, such as yourself, about how I should structure or even find resources for my fellow developers?

[0:09:08] ZB: Yes, absolutely. There are so many different types of what we call instructional design frameworks out there that one can choose from. For example, Codeacademy, we typically employ one called the five-step system. Fun fact, a lot of early curriculum developers at Codeacademy were Teach for America employees or graduates. I don't know the technical phrases. So, they brought a lot of, again, learning science and frameworks to our program and taught a lot of us about it.

In the five-step system, you, as the name suggests, have five different parts of teaching that you would design for a holistic teaching experience. It starts with a hook. Typically, a hook means something that's going to grab the learner's attention, and help them understand why learning this content is meaningful to them, and why they should continue with it. So, it could be a compelling story, or an interesting puzzle, or even like part of what they're learning and just getting them to kind of start exploring and playing around with it.

After that, you get introduction to new material. So, that's when we teach you, "Okay, this is the concept you're learning." Or in programming, maybe, "This is like the syntax that you're learning." It was to map these things to the Codeacademy content types that you would see while taking a course, this is all in the lesson, and what we call the narrative, that written part I was talking about before. After that you have guided practice. So, guided practice is, in a classroom setting the idea that you are applying what you learn along with the teacher. If you do have questions, you need support, there's someone there to assist you, and you can confirm, "Okay, yes. I do understand that." In our situation, that's the checkpoints, where you write code, you run it, and we tell you, "Did you get it correct or incorrect?" We give you some feedback. If you didn't pass, and so you can fix it. Even through that process, you're learning.

After that, comes independent practice. At that point, you are kind of meant to be off on your own. The training wheels are off, and you're again, working on applying. You're starting to really refine this mental model that you've been building. How you understand this concept, how it works together with previous concepts that you've learned, and you're starting to feel more confident in your abilities. That maps to the projects that we have. Then, the last stage is evaluation. Very commonly, this is some kind of quiz, something that's like, "Okay, you know your stuff. We've validated that for you. You can move on to the next piece of content." For us, that's quizzes.

[0:11:44] JG: Not all of those features existed at Codeacademy, when it got it started over a decade ago. Is there some priority to them that one might need to choose between if you had a limited budget? 

[0:11:55] ZB: Yes. If you didn't limit yourself, I would say, focus on the lesson. That's the core learning experience. Even for us, typically, lessons are the free offering that we have, that we want to make sure everyone has access to, and then projects and quizzes are ways that you're going to feel more confident in what you're learning.

[0:12:14] JG: Yes. I've heard this said for many people that there's no way to truly know a technical subject until you have to actually do it yourself. You can go through as many limited-scope lessons as you want. But until you've made that bigger, less handhold-y project, it's not quite the same in the brain. 

[0:12:30] ZB: Yes, absolutely. It reminds me of something that we say ourselves in teaching, which is you don't really know something until you have to teach it to someone else, too. Even the idea of like, if you want to teach some of your peers about a new technology you're using, like, I love the concept of brown bags at companies. Because I think it's a really great way for one, knowledge share, and then two, to have an opportunity to kind of test yourself, assess yourself. How well do I really know this subject that I'm interested in teaching to other people? What parts are missing for me that I should really, brush up on? Even for myself, I've been teaching now for so many years. I've been teaching this one class. Now, I'm on my third semester, and every single time as I prepare my notes, and I kind of get ready for a lecture in the next day, I'm like, "Oh, there's one little part that I feel like I could strengthen my understanding of."

[0:13:24] JG: Absolutely. Out of many great quotes from Richard Feynman on teaching. One of my favorites is, "The more you teach, the better you learn. Teaching is a powerful tool to learning." And that's absolutely true.

[0:13:33] ZB: Yes. I 100% agree with that.

[0:13:36] JG: So, let's talk about the design within this five-step system we've got here. Suppose I were that same person from before. You've convinced me I want to go teach my fellow developers a subject, thanks to your expertise. How would you recommend someone go around designing what goes into the whole lesson and so on?

[0:13:54] ZB: Yes. It's a really great question. So, in terms of our practice of instructional design, where we started is with a lot of research, right? You kind of judge you even for yourself, like we were just saying, how much knowledge do you have about the topic? From there, maybe you want to start looking at the documentation, understand certain intricacies. We're talking about, again, a new framework that's been developed. After that, it's always good to look at what other people have done in the past. It can be a source of inspiration to understand and also develop your knowledge and sense of what do you think is a good course? What is a course that's maybe not really hitting the mark for you? 

We'll often go and look at other platforms and see, what have people done really well here? Sometimes what I've done is even talk to people who are developers. I remember I did this when I developed or learn C# course. I actually posted on the Girls Who Code Facebook group, and I was like, "What were the kinds of things that you wish you had learned when you were first learning the language?" Or, "If you've learned C# before, what are the kind of the gotchas that you feel like are important to focus on, on a course for beginners?" It's just great to hear firsthand accounts, because it's sometimes so hard when you've been a developer for years, or developing this type of content to put yourself back in the shoes of someone who's like a complete newbie. So, getting to access those memories from people is one way that you can kind of achieve that.

Otherwise, thinking about design, it's a process. You start and you have initially a set of learning outcomes. What do you want a learner to complete by the end of the course? What should they be able to demonstrate in terms of whether it's kind of hard knowledge, hard facts about things? Or is that they can apply something? At the end of this course, I'm able to build an app using React components. Then, you work backwards from there and you figure out, "Okay, what is the very first thing that I need to teach someone? And to what depth do I need to teach it?"

I think our Learn X courses are some really good examples of this, because we've got like a kind of a tried and true formula now where we're like, "Okay. We're going to teach you about a language, but we're also going to teach you fundamental programming concepts at the same time." The way that we've structured those courses is to look and say, "Okay, for us, fundamental concepts include variables, comments, loops, conditionals, functions, and depending on the language, maybe there's some other things that people feel like are really important there." Then, you decide, "Okay, well, how do we split that up across different modules?" It makes sense maybe to do a module for each concept, right? That seems like a good amount of information for someone to digest, maybe like in one sitting. 

Then you dive even deeper and you start outlining the lessons within each module, and then it's like, "Okay, well, like how am I going to write this lesson on loops?" Well, we know there are different types of loops. Maybe we want an intro exercise where we talk about what is the purpose of loops? Why would you use them in coding? That's the hook again, right? You're getting someone interested, showing them why it's important to them. Then, you have an exercise per type of loop. We have wild loops, we have for loops, et cetera, et cetera. Maybe you have an exercise where you want learners to compare them. Can they analyze and understand in what different contexts would they use one loop versus another?

That type of output takes a lot of time. As instructional designers, you come out with outlines, you maybe feel really confident about it, and then you start writing the exercises, and you're like, "Oh, wait. No. Hold on a second." Actually, I need to put one more exercise in here. One of this exercise is getting way too long. There's too much information for one person." So, it's a very iterative process as well.

[0:17:40] JG: I can see now why you use the term unicorn to describe the ideal curriculum developer candidate, not only are you deeply technical, because you've described loops, stuff like that, but they are deeply inside the frameworks and languages, courses that need to be designed with these ideas in mind, and your psychological. You're trying to get in the mindset of someone. As you get more deeply technical, the paradox of teaching becomes harder to get into that mindset of the learner. So, you're drilling down into the basics, and really distilling what are the actual learning outcomes for each course or module, must be an incredibly difficult thing to do reliably.

[0:18:14] ZB: Yes. Especially when, we're doing this kind of one size fits all approach. We have people coming to us with absolutely no programming experience. We have some people who come to us who may know a handful of different programming languages, but they like the way that Codeacademy designs the content, they know what they're going to get from it. We've also played around with having different variations of Learn X courses. We now have learned X for programmers' courses. If you are familiar with these concepts, or you know several other languages, you can just jump into the one about Rust. You don't need to be handheld through like being taught for the umpteenth time, what is a for loop? You just want to know, what's the syntax? Give me an opportunity to practice. Let me demonstrate that knowledge and get the feedback from you.

[0:19:02] JG: Absolutely. There's another challenge I'd love to bring up with you, which is the joints difficulty of accessibility and localization. We're not talking here about the accessibility of the platform itself. That's a whole other very interesting -

[0:19:14] ZB: That's a whole another -

[0:19:16] JG: Yes, it is.

[0:19:16] ZB: Just talking about that today with a new feature.

[0:19:18] JG: Oh, great. But accessibility in the educational idea. Can you talk a little bit about why that might be difficult for you?

[0:19:25] ZB: Yes. Again, being this asynchronous platform, we're trying to keep every type of learner in mind as we're designing, and DEI provides powerful frameworks for doing that. At the same time, especially as you were talking about localization, I think, roughly, if we look at the audience data that we have with learners at Code Academy, half is in the US, but the half is international. There's a strong contingent in India, which is where we've been exploring, doing more localization efforts recently.

So, I talked a lot in the beginning about how we really pride ourselves on our creativity and we try to make this super engaging content. But we're also inhibited from our own cultural context, right? This is the anthropology major coming out for me. It's like all of us, there is no kind of base version of culture. I mean, there's a ton of globalization now. So, a lot of US culture is exported elsewhere in the world, so people can understand things like their Disney references, right? But we also want to be pretty sensitive to understanding that we're not fully just making this for a US audience. So, we have to be careful about the certain examples that we use.

One example that came up a few years ago was someone loved basketball players. They were like, "Okay, I want to make an exercise." In the exercise, I can't remember what it was teaching. But let's say it was like, something with conditionals and had to do with like - so that was the other thing. It wasn't even about basketball players. It's just basketball player names. But then they had other professions, including being doctors. There became the unfortunate circumstance of taking Steph Curry's name and saying he was a doctor, Steph Curry. Then, we had learners who understandably were like, "Are you insinuating some kind of stereotype about Indian people in terms of curry and becoming doctors?" And we're like, "Oh, my goodness. This was like a total oversight." With a lot of DEI things, it's always about, even if it wasn't intentional on our part, it's still something that is read that way. It's still something that we should apologize for and change.

So, I think, over the years, we've gotten much better in terms of thinking sensitively about how our material is received and how we can design it in the best way for an international audience.

[0:21:54] JG: Part of the challenge there is that as you grow and scale, as you say, go from a US-based startup to a multinational target company, or go from training your one team to providing classes for the rest of your organization or company, you get more and more groups of people who have cultural backgrounds or experiences that are foreign to you, literally, and it becomes more and more important to talk to those people, as you said earlier, to understand what are the possible ways that you can insinuate something horrible, or otherwise mess up in this way?

[0:22:23] ZB: Yes. It's also interesting, because you mentioned, again, localization, and we're doing so many projects now about understanding our learner bases, and what's important to them. It's still the same platform. I think we're going to experiment, maybe with things like translation, especially given, I mean - I know, we're going to talk more about AI in a second. So, I like hesitate to even touch the word right now. But it has to come up in a conversation about teaching technology these days. But there is a lot of interest around how can we use technology in order to generate translations of all of our courses. 

Because actually, fun fact is, way back in the day, we used to have translated versions of our courses. We had much, much smaller course library, like only like five or six courses, right? Intro to HTML, or learning HTML. We used to actually have an open-source content management system. So, people could create their own lessons, and so people were creating versions of learn HTML in Spanish, in French, that they could then share with their developer communities and their countries, or wherever people are online. Unfortunately, when we deprecated our former CMS, and also from our version of our learning environment, all of those courses were deprecated as well.

There were a lot of, unfortunately, upset people. Again, talking about accessibility, someone had made a course specifically for learners who are on the spectrum to learn HTML. That's incredible, that someone could use our content as like a base and then know their audience so specifically to build off of that. But again, as you were talking about with scale, and our catalog has grown into the hundreds, it's just not feasible for us to manually translate everything, especially given how quickly technology changes. It's like, if we have to update, like, we made a massive update to our React and Redux content last year that took multiple, multiple months to get through, every single piece of content and every different course and path it existed in, and then you had to do that in multiple languages like, "Oof." But, again, maybe that's an opportunity down the line if there could be some kind of automation. 

[0:24:40] JG: But Codeacademy does offer some kind of service for businesses where they can make their own courses, right?

[0:24:45] ZB: Yes. So, we had something called Codeacademy for business and it was an opportunity both for enterprise clients to get more affordable rates for a large number of seats if they wanted to buy Codeacademy for their employees. But there were some cool experiments that we did. We did one with Lyft, where we - I can't remember if we exactly gave them access to author, which is our content/learning management system. But I know that they made onboarding content through it. But fully white listing author is still not something that we've achieved that I would love to see, because that was part of the original vision of the tool back in, it was probably roughly six years ago now.

[0:25:30] JG: When you say, do you mean white labeling as in making it so a company could use it as its own?

[0:25:36] ZB: Exactly, yes. So, there are so many different small companies out there that want to have their own curriculum, or I'm thinking about, like, people who do a lot of developer relation work. MongoDB is known for having a really awesome Mongo University platform. But there are other smaller companies that wanted to do a step beyond documentation. They'll dip their toe into doing courses. A lot of those people really like Codeacademy, and we're like, "If I could have access to the Codeacademy platform and teach my tool through that way, I feel like that would be really beneficial for our audience." That's like one use case.

Then, another one is kind of like what we talked about with Lyft, but it's all the internal training. If you start a new job, there's so much you have to learn about the codebase, and how your team works together. Onboarding is such a delicate process. Saying that, as a manager, it's like something that you're always having to constantly refine. You want new hires to be successful as soon as possible. Especially, these large corporations, they really want to see, are there ways of making it more automated? Making it more asynchronous? So, like a platform theoretically like Codeacademy could be used in that way, and have enterprise clients bring in their own data and writing to achieve that.

[0:27:01] JG: I think that's a great segue into what I wanted to talk about next, which is the larger scale kind of next steps for the industry. Having companies be able to provide tailored learning experiences for their developers, for their team members, and so on, is a really powerful way to level up those teams. Where do you see the industry going over the next 5, 10, 20 years in that regard?

[0:27:22] ZB: Yes. I'm going to pick out what you said in terms of that kind of intentionality around designing programs, because - and we're going to talk about it now. We're going to talk about the big elephant in the room, Generative AI. It has to come up, especially in the context of talking about Ed Tech. But there has long been a promise and AI in Ed Tech is not a new thing, right? It's been around, it's been used in many different ways. One of the big ways it's used is in content personalization. I kind of mentioned this earlier, but one of the challenges of being an online platform is we can't differentiate learning easily for our students in a classroom. You can do that through thinking about, "Okay, I'm going to have a task, and maybe I have some extra challenges that you can do if you complete the task." Then, for a student who's struggling to complete the task, you can provide supportive help for them.

But doing that level of differentiation online means you have to have like a lot of data, about how the learner is progressing, and then knowing just in time, in that moment, how you can adapt your learning platform for them. Or other classic examples of, I want a very specific learning path. Our curriculum is great. It's very fast. But it's also very opinionated. We have a full stack career journey and we say, we are teaching you a FERN stack. Sorry, if you want to learn Angular. But with Generative AI, it means one content production can theoretically move faster. That's still something a lot of people are experimenting with.

Two, as mentioned, you have the ability to get a lot more data from learners and then think about okay, with this data that I have, how can I generate something like a unique path from you? Then maybe eventually too, can you actually have a very customized learning experience? People are experimenting with how can you drive your own learning through just chatting with an AI? People do this already with ChatGPT. A lot of prompts are like, "I want to learn how to be able to do this. Can you give me a set of instructions to be able to complete X, Y, and Z task?"

[0:29:41] JG: There are some risks there though, because AI is not exactly known for precision or accuracy in its responses.

[0:29:47] ZB: Or veracity.

[0:29:49] JG: None of the above.

[0:29:50] JG: Yes. I mean, it's really tricky, and that's why I kind of hedge all of these things, because it really depends on having a strong, what they call like human in the loop. You, as a human, using AI features need to be able to judge for yourself is the content that I'm getting out of this or the support that I'm getting out of this actually accurate. We came out with a lot of experimental AI features in our learning environment recently, really cool things that I love. We have one that explains your errors that you get. Another one where if you highlight code, it will explain what that code is doing. All of them have a disclaimer that AI can sometimes be inaccurate. Because we can't see what's happening in real-time. 

Well, I'm sure maybe there's probably a way we're collecting data and able to assess it. But this push and pull of a technology like this, that it really, again, can open up so many opportunities, like personalized learning, like greater support. I mentioned just kind of like two asynchronous features, but mentioned chatbots too, mentorship is one of the biggest challenges in Ed Tech. How to solve that by, having something where you can equitably pay people to be mentors, but also have an offering that people feel like is fair, at a price that they feel like is low enough for them to pay.

So, if people are comfortable conversing with an AI mentor, it could be helpful. But again, very much underscoring you can't trust everything the AI says, and so you have to develop your critical faculties to be able to say like, "Is this information I'm getting correct or not?"

[0:31:34] JG: Just spitballing here. I would love to see some kind of content, where AI generates something that seems plausible and then the challenge is to determine whether what the AI generated is actually plausible.

[0:31:45] ZB: I love that. It reminds me of actually some classic exercises that we've had in our courses where we have bugs in it, and we have you debug as part of the exercise, which is actually doesn't work great with our testing environment. But I think it's like pedagogically really useful. 

[0:32:01] JG: That's also a relatively uncommon, but I think high potential application for interviewing developers. Instead of having them go through three different iterations of write me an app, have one of them be, "There's an app, it's got bugs, work with me to fix them."

[0:32:15] ZB: Yes, absolutely. Because that's so much more relevant. It's way more real-world oftentimes. When you're a developer, you're often working with someone else's code. You have to gain familiarity with it. You may run into issues with it, and or maybe, or obviously doing code reviews, too. If you have to go in and be able to detect bugs in someone else's code.

[0:32:38] JG: Out of curiosity, how do you interview people applying for a curriculum development role?

[0:32:42] ZB: Yes. It's a great question. So, kind of covers those three skill sets I mentioned earlier. It's been a minute since I've interviewed someone. The specific though, I get to do the hiring manager interview at the end and talk about how awesome our team is. But historically, there would be interviews where well, one, we would have you draft a lesson. So, I remember when I applied, I drafted a lesson, I think, in Python, maybe teaching list methods using Pig Latin, I think was what I did. And you get to the interview, and someone has actually reviewed your lesson, and they give you feedback on it. So, one thing we look for is actually how do you handle feedback, talking about the experience of reviews, not just reviewing someone else's material, but having your own material reviewed.

There was a technical component. I think I had to do something again, with lists. They were so patient with me. I was like, I've been coding like for one, two years, maybe, felt like I could teach. I swear, I'll learn. Then, we had a pedagogical interview. So, we would talk about what's your experience with teaching? What are the different frameworks that you're familiar with? Who was your favorite teacher? What about their process, their methodology, did you really like? So again, ensuring okay, what technical skills do you have? What are your writing skills? What are your instructional design capabilities? And then, generally, how do you work on a team? How do you communicate?

[0:34:17] JG: How would you apply that train of thought of understanding how someone can teach to interviewing for senior staff plus roles in the software industry?

[0:34:26] ZG: Yes. That's super interesting. It's not something I personally have a lot of familiarity with in terms of my experience, but we do have a lot of interview content that we've developed over time. I will say most of our interview content is aimed at the junior developer and going into it. But my understanding of senior roles is that you're meant to be a mentor. You're meant to be someone who can teach the more junior people on your team that you're supporting them in their growth and coming to understand both what the technology is that you're working on, but also just technology in general.

I think it's something that I always loved and still love about the culture of Codeacademy is that it really was a culture of learning, and that we really all saw ourselves as lifelong learners, and that people were so willing to teach people and mentor them, and make them feel comfortable about jumping into completely different parts of the codebase. Something I love is that actually, a lot of team members from the curriculum team have moved on to other departments. One of my like, if it's okay for me to say favorite team members, but he is Kenny is -

[0:35:42] JG: Kenny.

[0:35:42] ZG: Kenny, yes. After many years of demonstrated interest and working part-time, on top of being a curriculum manager, he was like, also doing engineering tickets on the side and learning about gamut and web platform stuff, and he is officially going to become a web platform engineer, which is fantastic. But he's not the only one. He's like, I don't know, maybe the fourth person who moved into engineering. We had multiple people become product managers. We had some people go into data science. I just love that because not only are these people incredible teachers, and they're going to bring their teaching expertise to their new teams, but they also saw the value in continuing to educate themselves continuing to upskill, and being able to chart a new pathway for themselves.

[0:36:31] JG: That kind of lifelong learner mentality is incredibly useful, especially on long-lived teams, where you're never going to be working in the same technology over and over again, without having to eventually teach a new person, or to learn a new concept. It's very rare that someone can learn very little, almost nothing perpetually, for years. You have to eventually onboard to something new.

[0:36:53] ZB: Yes. Absolutely. We see this a lot with our learners, that people come to us because they may have been in the industry for years. They could be this back-end engineer who was working in Java, and suddenly they're like, "Oh, my goodness. Maybe I actually want to get into DevOps and I want to learn about cloud engineering. How do I do that? How do I make sure I can find the right course, that's going to give me the skills that I need to feel confident to start applying to these new jobs?"

[0:37:24] JG: You know what, as we bring up this point, I realized my previous statement might have been viewed or viewable as somewhat misguided. There are many people who throughout their careers actually don't learn very many new things, who are settled and happy in the thing they're doing. I have a friend who's been a Java programmer for 20 years, has been writing the same stuff Java Spring, or an equivalent for quite a while. If I'm in what, the radical candor mindset to bring in a new term would call the rock star mentality.

[0:37:49] ZB: I was just thinking that.

[0:37:50] JG: Yes. There are superstars, and then they're rock stars. Superstars go and do things that are new and exciting, rock stars stay doing the same thing over and over, and both are valid, both are great. Both are incredibly valuable and important for the team. If I'm in the rock star mentality, can I still use these kinds of learning frameworks, pedagogical shenanigans to advance myself and the folks around me?

[0:38:10] ZB: Yes. Absolutely. One thing I think back to is what we were talking about how even if you feel like you're very experienced, in a certain technology, or in certain concepts, that you can always learn something new. There's always something to uncover there, and maybe it's not necessarily like a new fact. But it could be just like a new perspective on it, a new way that it's meaningful to you, or to the work that you do. I think that you get, I don't know, kind of like mushy, but like, everyone is constantly on a journey of self-discovery. We may continue to have the same habits or the same interests time after time, but I think we still continue to grow and evolve as people. Then again, I'm also a person who tends towards the superstar mentality. I have had six different titles, I think, at Codeacademy, almost as many years as I've been here. So, being a teacher, too, obviously, I think evolving oneself is a worthwhile pursuit.

[0:39:18] JG: Well, that is an excellent closer to the technical portion of this interview. I'd like to move on to the more non-technical side of things, if you'll pardon the analogy. Let's talk a little bit about your past for a bit because you've done some interesting things. Could you tell us what Aural Reef is?

[0:39:34] ZB: Sure. So, Aural Reef was a project that I did in grad school at the NYU interactive telecommunications program. It was a project where I was interested in exploring the impact of humanity on coral reefs. I don't know if folks are very familiar with this, but we've been pretty negatively impacting coral reefs the past few years. I think I was looking this up. We've lost about half of the coral reef is on the planet since the 1950s. There was actually a massive loss in 2016, due to a global bleaching event when I was doing this project.

So, I wanted to explore how we could positively impact coral and have a positive relationship with them, versus the negative one we currently have. So, when I was thinking about what that relationship would look like, it was kind of tricky, right? Because I'm sitting here in New York, not really near any coral reefs. I don't think I'd even been to a coral reef, actually, when I did this project. I thought about how do I maintain the relationships that I have in my own life over distances? And technology is like one way that we do that, right? We talk on the phone, we use FaceTime.

I kind of came up with this idea, like, what if we could call a coral reef? What if we could speak to it and have it speak back to us and let us know how it's doing? It's kind of cool, because I actually came across this research that shows, you can tell the health of a reef, just by listening to it. Typically, we look at reef health through its color, because when coral dies, it's actually bleached. Talk about as coral bleaching and that's a phenomenon where coral has a symbiotic relationship with something called zooxanthellae and there's something with the rising water temperatures that's driving the zooxanthellae out of the coral and out of the reefs, leaving them to die.

So, the idea there was basically to say, "Okay, we can listen to the reef. If it's a happy healthy reef, it's going to be making lots of noises. And if it's a dead reef, it's going to be very quiet." In a similar research area, they were actually showing that if you play the sounds of a healthy reef and a dead reef, you can bring back life to that dying reef and repopulate it.

To go back to kind of the telecommunications idea, I would basically, it was kind of a concept, but put a microphone and a speaker in some kind of coral reef with someone's permission, of course, and then set up an exhibition where people could come in and go into like something like a phone booth and listen to a reef and hear how it's doing, maybe do something where we would translate the coral reef sounds into natural language. But what I did do as a proof of concept was have someone speak through a phone using a Maximus P patch, and translate their speech into coral reef sounds. The idea there is like kind of like how we talk to plants, and that's supposed to help them thrive and grow, that the more you could talk to the reef, more of these healthy reef sounds would emanate from the reef, and eventually bring the zooxanthellae and the other reef creatures back.

[0:42:52] JG: That's incredible. Did you ever have any results coming out of this?

[0:42:55] ZB: Unfortunately, it was just a concept for grad school class. But I would love the opportunity if someone wanted to throw me some grant money to actually do a full-scale project. One of my good friends happens to be a researcher on coral reefs in the Caribbean. So, I did talk to her about it at the time. She thought was pretty interesting.

[0:43:15] JG: That general idea of being able to input in one language or medium and output in a tangentially related language or medium such as input English, output coral reef sounds, is really interesting. I can imagine that with the recent AI burst, you might be able to do some more applications there.

[0:43:32] ZB: Yes. I was actually having the same thought, as I was kind of thinking about this project. I did it about eight years ago now and technology has changed so much. AI has presented really interesting opportunities for auto-translating. So, I would be curious how it would take on the idea of translating, especially the part about coral reef sounds into human speech, how could it approach something like that?

[0:43:56] JG: Yes. I've seen some really interesting AI demos, both recently, and also, in fact, 5, 10 years ago, of using tech like that to translate from, let's say, a large-scale adult understanding of programming. Someone who knows programming, is teaching a concept to, as we've alluded to earlier, a more, let's say, localized, or let's say, a third-grade level explanation of a topic. Being able to do that reliably, I feel, it would be very, very powerful.

[0:44:21] ZB: Yes. I absolutely agree with that. It gets into a lot of stuff around personalization of learning, like we were talking about earlier, and also being able to quickly differentiate curriculum for a wide array of learners.

[0:44:33] JG: Absolutely. You've got a large collection of projects on the cover collective, but I'd love to ask about, unfortunately, we only have time for one more. I think the next one that pops out to me is could you explain what OwnSpace is?

[0:44:47] ZB: Oh, yes, OwnSpace. So, I was really into wearables and soft technology when I was in grad school. I think me and some other people were initially a little bit intimidated by hardware and electronics, but I was familiar with sewing and weaving, knitting, and learned that there are all of these same materials that you can use when developing hardware circuits like LEDs, batteries, wires, and they have like a version of that using what they call soft components. We actually had what was known as a Soft Lab at ITP.

This project was a little bit in a different direction, because it didn't use any particular hardware. It was kind of more engineering and structural in nature. But when I moved to New York, I quickly realized you don't have a lot of personal space. You don't have a lot of your own space, even when you're in private buildings. I missed experience of basically being in my car when I used to drive a car, when I lived in other cities, and had to really own one. But you really had that kind of intimate private experience, where if you had a really bad day, she could yell, you could cry, you could scream to your favorite songs. That particular project was an opportunity to imagine what it would be like to do that while still being within a public space.

I thought a lot about camouflage. History of how different creatures and also humans, obviously, can hide behind certain patterns that make it seem like they're part of their surroundings. At one point, I was looking at creating an actual fabric out of images from Google Search history of New York. Another thing I looked at was reflective material. So, the idea of tricking the eye or getting people to look away from it, because they would just see themselves and not seeing someone else. I actually, went to Washington Square Park wearing a prototype that I made with this like very shiny reflective fabric and just like sat there for about 15 minutes and had my friend fill me. That was basically a reason I didn't go in the reflective direction and I went in the other exploration of city imagery, because people definitely stare at you in Washington Square Park, if you're wearing a giant reflective piece of fabric, despite there being plenty of other weird things happening in Washington Square Park all the time.

[0:47:20] JG: I find it interesting that in New York City, like many other crowded cities, there's a general culture of not looking at people when they're doing anything, but there's some things that will trigger, "Okay, this is interesting. This might be a good interesting, not a bad interesting. I will pay attention to it." Perhaps, your reflective surface was one of the good interesting pieces. 

[0:47:38] ZB: Yes. I would like to think so, although it wasn't the aim of the project. I think it definitely got a lot of people asking questions and had people wanting to engage with me over the project.

[0:47:48] JG: Taking this project in other direction. People who are learning to code generally need their own space to be able to experiment. Do you think there any parallels between I need a car or a similar space to scream into, and I need a scratchpad to be able to play around with anyone judging me for my bad code?

[0:48:04] ZB: Yes, absolutely. I think when you're learning something new, you are super vulnerable, especially for adult learners. A lot of adult learners, we've forgotten what it's like to be a beginner at something. We're used to being an expert at this point in our lives. I see this a lot with my students at SVA, because I get older students who have been artists and designers honing their craft, really perfectionist, and then they get coding thrown at them. They're like, "Oh, my goodness. What is this?" It's a completely different way of thinking and it's really jarring. To your point, I think your question kind of reminds me, of course, of like Virginia Woolf's, it's like a room of her own. I feel like I should be able to know this off the top of my head. You know what I'm referring to. A Room of One's Own.

[0:48:56] JG: A Room of One's Own. Yes. That classic work from 1929. Yes.

[0:49:02] ZB: There we go. But that the entire idea being that women writers needed to have their own particular space in order to do their work. I think that's, again, true that people need space, to block out distractions, to be able to reflect, to also really interrogate themselves and allow themselves to again, be honest and vulnerable about what they know, what they don't know. But I think, at the same time, only half of the equation of learning. I think learning is a really social experience and I think people need to push themselves out of their comfort zone, out of that safe space, in order to really grow and challenge themselves because it's kind of hard to challenge oneself over and over again, and it's really only when you come into contact with other people who can provide you with feedback, or they can answer questions, that I think we really have the opportunity to learn and grow.

[0:50:01] JG: There's a great read called Slack by Tom DeMarco. Not the messaging service. The concept of having slack or leeway, scheduling. Some of the points that makes on this include, you can't get your organization, or your developers, or insert other human resource to be operating at 100% efficiency at all times. There are several things they need in that schedule to be effective. One of those is slack in the schedule, where the name comes from. They need to be able to have some buffer time or just some downtime. Then, they also, as part of that downtime, need to be able to dedicate time to recharging so that they may learn. Let alone time to learn. You can't just be constantly do it. That's not the entirety of the learning equation.

[0:50:41] ZB: Yes. I mean, that's a huge part of any creative practice, too. You have to have the time and space to be able to space out, like literally. You just need the opportunity to let your brain mull over things. I mean, I think about that too, with debugging. Again, when I'm teaching students and talking about debugging strategies, one of them is just walk away from it. Do something else. Or people have those stories about how they'll go to sleep and then in their dreams, solve the - yes.

[0:51:13] JG: Dream coding is fantastic. I used to keep a small, I think the Amazon product was love notes. You're supposed to write like, "I love you" or some such to a partner. But I would just write little code debugging. "Oh, I just realized on that in the shower," and it's an incredibly effective tool.

[0:51:29] ZB: Yes. You always got to have that notebook right by your bed so that you can write the idea down as soon as you remember it.

[0:51:35] JG: I have one final question for you. Tell us about your Maine Coons please.

[0:51:40] ZB: Oh, yes. I have two Maine Coons. Their names are Max and Mabel. Max is white and Mabel is apparently, I think, it's called gray smoke is the name of her coat. I've never seen a cat like this. She looks like a tuxedo cat. But then her fur kind of has guy theory, white tips on the end of it. There's like a little bit of reddish in there. Anyways, we adopted them back in November and they're almost a year, there'll be a year in May and they are ginormous. They are already twice the size of any cat that I've ever owned and there's two of them. I live in a Brooklyn apartment, so it's an experience. But they're super sweet. I didn't know this, but I guess Main Coons, kind of doglike in nature. So, they really like to follow us around. For example, when I stepped into this room to do the recording, Max was quite unhappy about it and immediately meowed. But I'm a super cuddly person. I've always loved both cats and dogs. But cats, it's sometimes hard to find a cuddly cat. Not these guys. These guys are such cuddlers. They will just come up, sit right next to you, nuzzle you, and they've got these long coats. So, they're just like really extra fuzzy too. They're a joy.

[0:53:01] JG: That's excellent. Wonderful. Well, I'd love to keep talking to you about cats and pedagogy. But this is all the time we have. Zoe, we thank you again for coming on to Software Engineering Daily. This has been a true treat. Is there anywhere you'd prefer people try to find you on the Internet?

[0:53:15] ZB: Sure. You can find me at my website, zoebachman.net. That will also put you to my email, zoey.bachman@gmail.com.

[0:53:25] JG: Wonderful. Zoe, have a great day. For Software Engineering Daily, this is Josh Goldberg. Cheers all.

[0:53:30] ZB: Cheers.

[END]