Hi everybody. In this video we get to talk to Ronesha Dennis, someone who has done something a lot of us aspire to do: combine multiple interests into one unified body of work. In Ronesha's case, she brought together her love of teaching and her love of programming, turned that into work that helps students of all ages, and wrote what may be one of the best beginner-friendly books on Python development I've had the chance to read.

We're going to talk about how Ronesha got started, what motivates her to keep teaching, and which topics students struggle with most when they're learning programming, along with a whole lot more that comes up along the way. It's going to be a fun one. Ronesha, great to chat with you. I've been following your work for quite some time, and we chatted a little while ago, so I thought it would be fantastic to have you share more about yourself and the work you're doing with everyone who's listening and watching.

So before we get started, I always like to ask the same first question: of all the things you could be doing in the world, what made you choose technology?

Honestly, I started coding when I was about nine or ten. Everybody had dial-up back then, we had a computer, and I wanted to see if I could test some things out. My parents gave me the freedom to use the computer and clog up the phone line, so I got to experiment mostly with HTML. I definitely wasn't trying backend stuff at nine or ten. I don't even think I knew what that was yet, but I tried a lot of HTML. Then, when I was around 11 or 12, one of my favorite musicians had a contest for someone to build a fan site for him.

I decided I was going to win that contest and build the greatest fan site in the world. I tied up our internet and our phone line for a very long time building it, and I ended up winning, which was really cool. In high school I studied a lot of networking and discovered I didn't enjoy networking. So when I got to college, thinking that networking was what computer science was going to be, I decided not to major in computer science. I majored in Communications with a minor in computer science, and after graduating I spent some time working in public health.

That was really great and it opened my eyes to a lot of the issues in the world and to how companies and nonprofits try to approach those issues. But after around five years, I had to admit something to myself. I love helping people, and I come from a family of educators, so that value was deeply ingrained in me. But public health wasn't the way I was meant to do that work. I wasn't happy. So I sat with myself and asked what really made me happy and what I was actually passionate about.

To answer that, I thought about what I did as a child and what I would have done for free. I realized I had done a lot of coding for free as a kid. It wasn't very good, but I loved doing it. So I said, you know what, I think that's the path I want to take. That led to one coding boot camp, then another coding fellowship, then a job in the field, then going back for a master's degree, and some teaching along the way. Now I'm at a place where I finally feel right about where I am.

That's really fascinating. Lately I've been seeing all these quotes on LinkedIn and Twitter—Bill Gates and Warren Buffett come to mind—about how the thing you liked doing when you were young is often the thing you're most likely to be successful at later. What you described feels like exactly that: you liked coding when you were younger, you liked dabbling in technology, and after a few years away from it you found your way back to the thing that fit.

I think having that period when I did something else again was useful. There were portions of it that I did truly enjoy, but I didn't have the passion behind it. Fortunately, I was raised by people who really got to take on their passions as their jobs. It's a completely different approach in how you approach doing your work when you actually really care about it. Now I'm willing to work a little bit longer to make sure that I'm producing something—whether it's for clients or for students—that actually works and will actually be something meaningful and beneficial for them.

You've read a couple of chapters of the book, and even there, it was really important to me to share some of my experiences, or some of how I saw these things and how they clicked for me. I feel like that's something that helps to make tech more accessible. I think that people look at technology and think, “This is so hard. Only people who are super smart can get into tech.” Yes, there are super-smart people in tech, but also the concepts at their foundational level are easy to understand if you can think about how they apply in real life.

That's how I think about things, and hopefully that's what's going to be reflected in the book.

That book too. That's actually really great, because hard work and passion are often treated like this unstoppable force that can make you happy, successful, or at least personally fulfilled. You mentioned the book, and we'll come back to it in a bit, but before we do, what made you want to move from working in tech to also teaching it? Teaching technology is really fun, but it's also a really challenging thing to do.

It is challenging, but I think what I learned about myself is that I learn from teaching others and helping others. That's really where you get to test: Do I truly understand what I'm talking about? Do I truly get this concept? If you can't teach it or talk to others about it, then do you truly understand it yourself? That's always been how I think. I guess having a mother who was a teacher, that's how things were taught to me: If I can teach this to you, then that means I understand it.

Also, I really wanted to teach because I've talked to so many people who have said, “This field is really hard to get into. I don't know if I can do it,” and things such as that. I just don't believe that's true. I do believe the language that we use around technology is what makes people feel like it's inaccessible. So I wanted to get into teaching because I felt like I could relate to people. Not only do I feel like it's important to build relationships with people, but I also felt like I could talk about technology in a way that would click.

I started by working with what I call babies, but they weren't babies. They were between the ages of six and 10, which is really young to me. I started working with kids and teaching them how to code. With them, it was really fun because you have to figure out, “How does this relate to the little experience that this person has in life? How can I talk about this in a way that they can understand?” That was really fun. From there, I worked with Black Girls Code for a while, which was a lot of fun. Then this summer, I actually spent the summer in San Francisco teaching with a program, CodePath.

That was super cool because it was my first time working with college-age students and teaching them full-stack development. Even then, I found that the approach I took with the kids was the same one I needed to take with these young adults in college: Find ways to help connect it to things that they understand. I always test topics on my mother. One of the most fun times was when we were talking about React and the state in React. My mom has done no coding ever in her life.

I said, “Mom, I'm going to talk about state by talking about the different stages that a banana goes through.” I explained that to her, and she said, “I get this. Now I know what state is.” She can't code at all, but she was able to understand the concept. That's the approach that I take, and I really enjoy it.

That's a great example of how to explain state. I may have to borrow that and credit you at some point. Teaching six-to-ten-year-olds and then college-age students feels like it should be wildly different in terms of attention span and prior knowledge. How does that actually work in practice? And what programming language were you using with the younger kids?

For the six-to-ten-year-olds, we started off using Scratch—MIT's Scratch programming environment.

Then how did the move to Python go? How did their first days with Scratch go, and how did that transition from Scratch to Python work?

I think it went really well, because this is also one of the things that I'll tell you a little bit about when we talk about the book: I try to find things that they are familiar with. For example, when I talk about things like conditional statements, I often talk about gaming controllers because I love gaming. When I was five, six, or seven, I was always with my cousins, always playing Nintendo, Super Mario, or whatever. I was always playing a game, and so I figured that at that age, they should know a little bit about gaming and whatnot.

I can bring that into this conversation about how you use control structures and conditional statements. Of course, I don't know any of the newer controllers, so I say, “I'm going to show y'all this N64 from the 1990s and explain how the control structures here should work.” This is how we're going to talk about conditional statements. I found that the thing that worked with six-year-olds was also able to work with 18- and 19-year-olds. I think it's about finding those things that are so common—what I call common at an elementary level—and using that as a thread to teach the babies and also teach the adults.

That feels very close to the Richard Feynman style of teaching: reduce things to something familiar, and then the details of Python or Scratch or whatever else become much easier to understand because people first understand what the thing is trying to do. Once those kids learned some early programming, what came next for them? I always wonder about the gap between early exposure and the point where they either pick it up again in high school or college. How do you bridge that gap, or is that something you've thought about?

That's a great question. Unfortunately, in my experience, I haven't had the chance to be a person who has bridged that gap. But I think it's something we as a tech community could look into more. I know there are programs for five-, six-, seven-, eight-, nine-, and 10-year-olds, and after that, we tend to have programs for older teens. We don't truly have anything in the middle, and beyond not having anything in the middle, the things we have tend not to be accessible. When I say accessible, I mean that many of the coding boot camps I look at for kids are heavily priced.

Parents want to teach their kids how to code and make sure they continue to have access to it, but it isn't affordable for them. As a tech community, that's something we could look into: How can we ensure that we're making technology accessible for everyone? Tech isn't going anywhere. Not only is it not going anywhere, it's constantly growing. The things children learn at five, six, or seven are obviously great foundational things to have. But just as you have to keep up once you're in the workforce, we have to do better at learning how to bridge that gap. To answer your question, I don't know yet.

I don't know how we can do that now, but it's definitely a community issue we should discuss. We have to talk about it as a community.

Absolutely. When we think about boot camps, are there ways of scaling them so they don't have to be physically in person? Actually, that's a different question. There are online communities that help teach individuals. What is your take on learning in a boot camp, where you have more hands-on work, smaller groups, and probably even meet in person, versus some of the more online, distributed versions of learning?

You know, honestly, I really think it has more to do with understanding your learning style, because I think that there are people who would truly benefit from being in, you know, that kind of aggressive boot camp where every day is just code, code, code, code, and, you know, tend to be somewhere between 8 and 12 weeks- and again, I've done a boot camp, so you know, I definitely know like what that experience is, versus people who are better at that individual learning and, you know, able to sit in front of a computer all day. We've seen a lot of it with COVID.

You know, being able to sit in front of a computer and learn from you know, either videos or reading or whatever, like it really has to do with getting down to figuring out how you learn, so I don't necessarily. I think it's great that we have, you know, this wealth of resources, that we have not only coding boot camps but also online schools. You know, freeCodeCamp, that you know things are available on YouTube. I'm happy that we have all of that, but it really comes down to like the person knowing what works for them.

You've taught a lot of students, and I'm curious: what are some traits that successful students tend to have?

I think it's the same traits that successful engineers exhibit. It's all about having that tenacity, being super determined, and saying, “I'm going to figure this out.” I tell my students all the time that when you're looking to come into technology or come into coding as a field, or even if it's just something that you want to learn a little bit about, you have to be okay with being frustrated, because it's going to happen. One of the first things I say is, “If you make mistakes, it's fine. Fail really fast and be okay with failing fast.”

Be okay with running the program before you have everything in place, so that you can run into that syntax error, runtime error, or logical error that's going to come up. Be okay with that, because the more you run into those issues, the better you're going to get at the overall process. The biggest thing is being open to running into issues, letting them happen, and not letting them become a mental thing for you. Don't let it become, “I'm not good at this because I didn't get it right the first time.” At my last job, I was a lead engineer, and I've since started my own business.

At that company, growing into that role came from being willing to take those risks, start fast, mess up, own that I messed up, go back at it again, and say, “I'm going to figure out what is happening and what is causing this issue.” That's one thing. The other thing is being open to being a lifelong learner. If you aren't open to being a lifelong learner, I don't think you can work in the programming field. You have to consistently learn not only new versions of a language that you're comfortable with, but also newer technologies and frameworks.

When I reached out to you, I said, “I read your book on React because I needed to learn React in a weekend so that I could be prepared for a project.” I found a book, and it was really helpful to at least get me started. That spoke to two things. First, I know my learning style. I learn through reading, so I needed to get a book that I could sit down with. I wasn't going to be successful if I tried to do the online YouTube route. That wasn't going to work for me because I would get distracted.

I needed a book that I could sit with, handwrite notes in, figure out, go through the frustrations with, and get to the other side of it. Second, it showed a willingness to learn something new. I'm not going to be successful as a lifelong programmer if I'm not willing to learn React when new versions come out and learn whatever framework is next. I haven't touched Go yet, but at some point I need to learn Go. As much as Python is the language that I truly love, it's not the first language that I learned. But it is the language that I really enjoy teaching and enjoy working with.

I also know that if I want to be in this field and continue to be someone people want to work with, I have to be willing to learn those new things. Learning comes with accepting the frustration of that process.

I think what we're getting at is that students come in to learn programming, but what they really gain is a more fundamental skill they'll carry through the rest of their lives. In programming, things often don't work for subtle reasons, and you have to keep trying until they do. That kind of persistence applies to almost anything, technical or not. You come for the coding, but you leave with the life lessons. Quick aside: you mentioned Python wasn't the first programming language you learned. What was the first one?

If we're talking about programming languages in the backend sense—and putting aside the debate over whether HTML counts—the first language I learned was C++. Then C, then Ruby, and then Python.

Wow, that is quite the jump. When you did back-end development in C++, what was the first program you built? You mentioned and described the app for your school, but before that, as a hobby, was there a time when you first wrote “Hello, World!” or created an application and thought, “Wow, this is really cool. I can type arcane things on the screen, and then something more human-understandable comes up”? What was that first application?

For me, I would say the first back-end programming application for me was definitely in school, with C++. If I remember correctly, it was a calculator. That was the first time I felt like I really built something. I can't even tell you the first time I wrote “Hello, World!” because I felt like it can be a lot more. I thought, “This isn't enough for me. That's the basic; what's next?” The first time I really felt that excitement around building something on the back end was when I built the calculator and all its functions, and then built a front end on top so we could actually see it.

I thought, “This is how you make a desktop application.” I'd never in my life even thought about it, so that was really, really cool. Were we using Visual Studio. NET, or was it C++ 6.0? What was the IDE of choice at the time? It was Visual Studio. Was it Visual Basic? It's been a while. Yes, Visual Basic, because this was the first real programming language that I learned as well, and it was also in school. I think we were using Visual C++ 6.0 or something. The UI looks the same even today; there's only so much you can do in a C++ text-editing environment.

That's really cool. You got to work on the back end and the front end and see all of it. This is always magical. The way I describe it to people is that you see cars on the road all the time and think, “It's a car doing all these things.” Then you realize that, within a few hours, you can build your own car with just some parts. You think, “I had no idea that it doesn't take that much effort to build a very basic one.” With enough practice and effort, you can build something more complicated. That's how I describe programming in general, because we use apps all the time.

Before you learn programming, it's all a little magical: How is this working? What's going on? Even with the menus, you right-click the little file thing and a drop-down appears. How does any of this work? Then you start writing your first lines of code and think, “This is actually not that complicated.” It's a little bit of hard work, of course, and there are many concepts you need to understand. But once you put those pieces together, it all falls into place nicely. Now let's talk about Python and your decision to write a book. You mentioned earlier that I reviewed it with your checkers, and I loved every moment of it.

It was really fascinating. What was your leap from teaching in person and teaching all the students to writing a book?

I studied communications in undergrad, but I've also been writing since childhood. It's very interesting because it really does go back to childhood: the interest not only in coding—though, as I said, it was more so HTML and making really pretty web pages—but also a lot of interest in writing as a child. I started writing short stories and poetry, and I always loved it. When I took a step away from coding, I also took that step away from writing creatively too. I think part of it is just coming back to myself: the process of figuring out what I'm really passionate about.

When I realized that I was really passionate about coding, I also realized that I had that passion and interest in writing. As much as I really like the creative aspect of writing, I also enjoy teaching, obviously, and I wanted to bring all of that together. I could teach and talk about something that I really enjoyed and felt like I knew well, while also getting out that kind of creative energy of telling stories too. As you know from reading a little bit of the book, I tell stories of how these things made sense to me.

I also give a lot of examples of how you can actually see them in the real world. That's a little bit of my creativity coming out in the book, and that's how I got there. It was like putting all of the passions together, all of the things that I've really enjoyed, and saying, “I want to package this, and I'm okay with putting my name on it.”

That's really great to hear, because combining writing with technology is almost like a force multiplier. You get to bring two passions into one thing. When you started writing, what did the process actually look like for you? Writing a book takes a lot of discipline, a lot of time, and plenty of moments where you wonder what you're even doing. So walk me through how it all went.

Honestly, part of it was that I was also teaching at the time. I got to see what my students were experiencing and ask: What order do I need to present this information in so they understand it? A lot of that went into creating the initial outline for the book. I considered the order for presenting the content, the examples that were really hitting home, and the motivational discussions I like to have in my classrooms. I also asked what motivational ideas we could include in the book. After that, it was really about sitting down, and let me tell you, that was the hard part.

It was so difficult for me just to sit down, let it all come out, write, and make sure that it made sense and stayed simple. Because the book is for beginners and people who have never coded before, I needed primary readers who had never coded before. I got my mother to be one of them. I had her sit with the book and asked, “Hey, Mom, do you feel like you can code from this? Do you feel like you can learn from this?” By the way, she's 72, at a point in her life where learning something new can be a little scary. She felt like those concepts were connecting for her.

The process was really a lot of sitting, outlining, trying to simplify things, rereading, going back, and editing. There were things I read and thought, “Okay, this makes sense to me, but it makes sense with the knowledge I currently have. Is this going to make sense to a beginner?” I cannot say that this book is for beginners and then include things written so technically that they scare people away. That would be the opposite of what I want to do. I truly feel there is enough space in the technical world for all of us, because not everybody who learns how to code wants to be a developer.

Not every person learning to code is saying, “I want to go in and take people's jobs.” Sometimes people are afraid of making it more accessible because they do not want someone to come in and eventually take something from them. But it is so important for people to be able to talk about tech, even at a basic level, whether they want to be a product owner or build their own thing without personally building it. They may just want to own it while being able to talk about the process that goes into it.

For me, it was super important to make sure that people who did not have the technical upbringing I was fortunate to have could read it and say, “We get this.” Even at the most basic level, they should be able to get it.

That's a great way of framing why learning programming is beneficial, even if people never write code professionally. Having that fundamental understanding of how things work carries forward in so many ways. It is like the argument you often hear about biology or physics: “I am never going to build a pendulum and measure how fast it goes. Why am I learning this?” In some ways, it is like exercising. Do you really need to? Yes, because the benefits accrue over time. Your brain also needs to be expanded and pushed into various corners. I love reading articles about what motivates people to learn because I greatly enjoy teaching.

I always wonder: Why do people learn, and what is the benefit of teaching people hard things? One fascinating thing is what happens when you learn something genuinely difficult and get through the other side. Psychologically, it gives you confidence and shows you there is value in the grind. There is value in learning something hard and getting through it, because that builds your confidence to ask, “If I can learn this and be successful at it, what other things could I succeed at if I put in effort and time?” That gave me a different perspective on why teaching hard things sometimes makes sense.

As I mentioned the last time we talked, I decided out of the blue to write a book on data structures and algorithms. It is not because I am passionate about the topic; it is completely unrelated to what I normally think about. I enjoy teaching programming through things that move and display on the screen, so this is very different. My motivation came after reading a quote and a study about this. Most developers never need to use algorithms day to day, outside of notoriously difficult interviews at various companies.

Often, you only need to know the concept at a high level so you can go to Google, type in what you need, copy and paste the code, and be good to go. But learning the details and why something works may unlock new pathways in your brain and help simplify things you thought were complicated. I will eventually find out whether that was a good idea, but I think it is fun to teach people hard things and see them succeed at learning. Once you do that, difficulty becomes relative: what used to be hard now becomes easy. That matters because opportunities in technology are finite, and continued learning can set you apart.

Becoming genuinely skilled and curious gives you an advantage in whatever you do. It is not only about working professionally; the habits and confidence from learning difficult material carry into other kinds of work too. I recognize the practical frustration: programming is hard, and you first have to help people understand it before they can use it as a path toward future opportunities. That connects to the mindset you discussed earlier: constantly learning, trying new things, and pushing yourself outside your comfort zone. It makes you more effective. At the end of the day, there is always a finite number of opportunities in technology.

Setting yourself apart by becoming very good at what you do, because you genuinely want to learn more, gives you an advantage whether you work professionally or not. In your boot camps and training, many students are ultimately learning so they can do more programming or use it to get a job in technology. Something that sometimes frustrates me, though I understand the reality, is that first you need to get people into programming and teach them a difficult concept. They need to learn it first. Often, what people learn and enjoy learning is not what the job market is actively seeking. How do you bridge that gap?

How do you help people understand that what they learned is not irrelevant, but a stepping stone toward what they ultimately need to learn? Learning how to learn is the real skill in programming, not necessarily the syntax of Python, Go, C++, or C.

That's exactly what I was going to say: you have to teach people the value of learning how to learn. I have close friends in different fields, and one thing they always say is, “I have to learn how to learn.” I think any path you use to learn how to learn is beneficial. Being in the programming world now makes me feel—I hate to use the word, but I will—unstoppable. I am so confident in my ability to learn new things. One thing I try to instill when working with students is that they may decide they do not like coding.

They may decide this is not the right field for them and that they want to do medicine, law, or something else. Whatever they want to do, if they can accept the challenge while they are here—the challenge of learning and building—I guarantee that they will gain something. Even if they only learn, “I hate coding,” they will also learn, “I am capable of building. I am capable of doing whatever I want to do.” If that is all I achieve with a student or someone reading my books, then I have done my job.

It's such a fine line. How do you encourage kids to learn something they might not be interested in without pushing them so hard that they get completely frustrated and turned off from the field forever? How do you balance those two extremes?

That's difficult. I think adults—as teachers, parents, or anybody who works with or has kids—need to teach them the value of understanding that not everything is for them, and that is okay. But they have to be present in this moment and accept where they are now. It may be frustrating to learn a little programming, just as it may have been frustrating when they were three years old and their mother read them a book they did not like. Sometimes that is simply what you have to deal with. You go through the process, and at some point you reach the other side of that frustrating process and realize there was beauty in it.

It may take a long time. I can look at things that happened seven, eight, or nine years ago in my life that were really frustrating moments. I look back at where I am today and think, “Oh my God, if I had not gone through that frustrating moment eight or nine years ago, I do not think I would be prepared to write a book, build programs for people, or be prepared for anything else happening in my life.” To answer the question, I think it is important to have real conversations, even with a four-, five-, or three-year-old.

Say, “I need you to be patient now, because five years from now, ten years from now, or maybe even 20 years from now, this is going to make sense to you.”

Yes, and the best part of what you mentioned is that there is no age limit. We all need that reminder. Whether you are young or fully an adult, you will do things you may not want to do without immediately realizing their value. If you see them through, you may eventually realize their full benefits. There are things I worked on as a child that now, 13 or 14 years into my career, make me think, “Wow, those things I learned at 10 or 11 apply now.” I never thought those things would come up as something I could relate to, use as an example, or use to make something else make sense.

We may not realize the value while we are doing something, and we may only understand its benefits much later. That reminder remains useful at every stage of life. I think everything has meaning and purpose. We have to remind both children and adults that sometimes they will run into frustrations, but those frustrations are there for a reason. I love jumping between topics. It is almost like watching a movie that jumps among different timelines in a multiverse. Getting back to your book, you mentioned writing, and there are different kinds of writers.

Some are notorious for following a strict schedule and routine; if anything is off, their brain says, “Nope, I can't write right now.” What was your routine like? Did you block off a fixed period every day and say, “I am going to write during this time”? Did you use a particular tool to keep your writing consistent? What were the exact details?

My writing process was very much about making sure I was in the right energy to do things. If I felt productive that day, I wrote. This was difficult because that energy would often arrive on a random Saturday when I had plans with friends and had looked forward to those plans all week. Saturday morning would come, I would wake up, and think, “Oh my gosh, I am in the energy to write right now.” Because that was the energy I was in, that was where I stayed. I disappointed many people that way, but I think it worked out well for me.

I learned to recognize the right time and when I felt most productive. It was the same with work. I was very fortunate to work with companies that gave me flexibility in when I worked. If I did not want to work a nine-to-five schedule, I could work from maybe three until sometime in the evening. That meant I was working at my optimal productivity level. I took the same approach with the book. There were days when I sat down and really wanted to write, but simply could not. Instead of forcing myself, as I sometimes might with programming, I said, “I want this writing to be a natural and authentic experience.

I am going to step back and wait until I am actually in that productive energy.” Because that was the path I took, I also had to tell myself that I still needed deadlines. If I was only going to work when I was in that productive energy, I also had to say, “On August 5th, I am going to be done. On August 5th, we are switching into full edit mode.” If that meant sometimes tapping into productive energy when I was not ready, I had to figure it out. I still had to meet the deadline, even though it was self-imposed because the book was self-published.

I had to have that conversation with myself. It was about finding a balance while making sure I presented the information in a way I could be proud of. I was not going to put my name on something if, at the end of the day, I was not proud of how it was presented.

Yes, that is the discipline you need to write a book. I think only people who have written books fully appreciate it. At the end of the day, you look at 300 or 400 pages of content and think, “There is no way I am writing 240 pages.” But then you establish a routine. Whenever you have the energy and mental space, you write five pages, 10 pages, and so on. Over time, that accumulates into a large book. That brings me to my next question.

Did you create a table of contents first and follow it from the beginning, or did you write about whatever inspired you at that moment and then collate everything into an order based on what you had seen from your students? What's interesting is that I started with an outline, knew I was going to follow it, and then did not follow it. I began with the basic concepts and topics. I knew what they were and how they should be covered.

But some days I would have an experience and think, “This could fit into that section, so I am going to jump to writing it,” even though that was not the order I intended. I wanted to take a sequential approach, but that did not happen, and I think that is okay. I tell people all the time that coding is also creative. People do not often think of software developers as creatives, but we are. In the same way people tap into creative energy to build art or music, software developers, software engineers, and programmers—whatever term people want to use—also tap into that energy.

Sometimes I tapped into a section I was not ready to write yet, but I said, “You know what? I am just going to go with it.” It was fun. The unexpected order did not prevent the ideas from eventually fitting the book. Following that creative energy sometimes mattered more than preserving the sequence I had originally imagined. Do you have a process for taking notes? For example, I keep notes on my iPhone all the time. At random moments, such as sitting in traffic at a stoplight, I think, “That's an interesting idea,” quickly bring up my phone, and write the note down for later.

Many writers I have talked to use a similar approach. Depending on what they are doing, inspiration strikes and they do not have time to write everything immediately, so they take notes to remember it later. Do you ever have those moments? Do you have a process for making sure those ideas never get lost forever?

I had to develop a process because I like to think I have the greatest memory in the world, but I do not. When I had what I thought were good ideas, I would tell myself, “I am going to remember this.” Then I would get home, sit for 20 minutes, and realize, “Oh my God, I do not remember that at all.” Eventually, I decided to keep a cloud copy of the book that I could pull up anywhere. I would jump to the relevant section, add a comment saying, “I want to add this note here related to this thing,” and write perhaps a sentence.

Sometimes that sentence was not enough to remind me what I wanted to get out of it, but many times it helped. It was interesting because I am usually very structured and organized, and I think that is especially important when coding. In this process, I stripped that structure away completely, and I am okay with it. Structure is important and can lead to a great product, but there is also value in stripping it away and saying, “I am going to approach this the way it flows in my mind and comes to me authentically.”

Friends who knew I was working on a book would say, “Ronesha, we are so accustomed to you having deadlines and all these other things.” I took that away, and I think it was very beneficial for me. Letting the ideas arrive authentically did not mean abandoning organization forever; it meant choosing when that organization would enter the process. It may sound absolutely crazy to someone else, but as a person who is structured in every other aspect of my life, I decided this was the place where I would eventually apply structure but let the work flow freely first.

Yep, and there are a few things I've been reading from like. I love reading other content creators explain their process and things like that- a lot of like scientific studies also on just writing. How does writing really work? And one of the best explanations I heard is that our brain, you know, when we're writing it almost like three distinct phases, that your brain probably more phases, but three ones that you know relevant to what we're talking about here, is that there's the ideation phase, there's a creation phase and it's the editing phase.

And the more you can isolate your brain to be focused in one of those areas, the more successful you'll be, because if you're jumping between ideation, creation and editing and all these things, there's a there's a large amount of energy just being within context switching in general. Even our brain has its own smaller ways of context switching. We just goes back to your point about like, when you have an idea in your brain of like you know I'm not gonna forget this, I'm not gonna forget this brain. Remember this.

10 Minutes later, you already forgot it because your brain went from, like, the ideation phase to some other part of it, where now it's not just a case of remembering, it's like how to travel mentally to one, whatever you know space I was in earlier. Remember that. Which is why, even if you take notes and you aren't detailed enough in the context, it still gets lost. And I always find it very interesting because some writers say, like you know, when it comes to writing, I don't do any editing, I just write all the words that I can that seem relevant at that point.

Even if it doesn't make any sense, I don't stop, I just basically just put all the words down and then, when I'm the editing phase of my brain, I then go back and rewrite it for clarity and conciseness and all those various things, but never mixing them both together, because if I do that, the end result is I wrote less and what I wrote isn't actually as good as it would have been otherwise foreign. Yeah, so next step: you know, like you mentioned, your students and your mother.

As for feedback in terms of like what resonates and what doesn't resonate, and things like that, when you're teaching programming to students, most most difficult concept for them, where it just took them a lot of effort to wrap their heads around.

That's a great question. In most languages, the hardest part is often not the foundational or conceptual material, but the syntax. Students struggle with things like indentation in Python or curly braces in JavaScript because those conventions do not feel like a natural way of writing. We learn to write in blocks and put a tab at the beginning of a paragraph, though I do not even know if they do that anymore. We learn MLA and APA, and then, when you start learning a programming language, those conventions do not help all the time. You are learning another language and everything that comes with it.

What I have found most difficult for students is learning how to sit down and truly apply it, which again goes back to syntax. They understand the concepts and can talk about them, but the actual application, along with the frustration of syntax, is where issues appear. They eventually overcome that and realize that even professional programmers have this issue, especially with context switching. If someone uses Python on the back end and React on the front end—it happens to me all the time—they switch from one way of doing something in Python to another way in JavaScript.

They think, “This isn't working,” and then realize they used something that is not even applicable in that language. The problem is not that students cannot understand programming. Often, they understand it well, but translating that understanding into the exact form a language requires creates the frustration. Overall. That is where I have seen many struggles. I try my hardest to create environments where students feel comfortable asking, “What am I doing wrong here?” Sometimes the answer is simply, “You need a colon,” and that is it.

I love hearing other creators talk about process, and one of the best descriptions I've heard is that writing has at least three distinct phases: ideation, creation, and editing. The more you can isolate those modes, the better, because context-switching between them burns a lot of energy. That also explains why a quick note isn't always enough. If you don't capture enough context, your brain has to somehow travel back to the exact mental state you were in when the idea first showed up. That leads to another question. When you're teaching programming, what concepts are usually the hardest for students to grasp?

That's a difficult question, and I have discussed it with many other engineers. From my perspective, students should learn the basics of the language, become familiar and comfortable with them, and then step into using AI. I think AI is beautiful and will be used to build and grow great things, though I have some fears that it is growing a little too quickly. I am not going to lie about those fears. Everything is about foundation, and once you are comfortable with the foundation of something, you can switch to anything. If we introduce children or students to AI too early, I fear they will skip the foundational steps.

If they later decide they want to enter the workforce, they will not be prepared. Without those basics, students may be able to produce something with help, but they may not understand what the tool skipped or know how to continue when the foundation matters. I hope the focus remains on the foundation. Then, as a level up from that foundation, we can talk about artificial intelligence and everything else that can help people create something more polished.

It is tough because I struggle with this all the time. When I am explaining a concept, I wonder, “Do I even need to explain this anymore? People can just go to an AI assistant and make it work.” The example I use when arguing with myself is that I do not know machine code. I have no concept of writing in such a low-level language. I enjoy higher-level languages like Python and JavaScript. You could argue that because I do not know machine code or assembly, yet work in higher-level languages, prompt engineering may become a programming language of its own.

Describing to an AI what you want to build could abstract away another level of detail: the actual language and syntax. That transition will take a while because many people work with hardware and low-level languages. They need to know languages such as C, which in my mind is very low-level and difficult. You can easily put an application or computer into a state where you think, “This is wrong in so many ways.” I always struggle with this concept because it may be a moment-in-time issue. I am old enough to remember when Java first became popular and people asked, “You are not worried about memory management? What is going on?

You have to understand pointers and how all these things work.” Java developers said, “No, the virtual machine takes care of all those things.” Now replace Java with artificial intelligence, and replace memory management and pointers with syntax and debugging in your coding environment. I see the same pattern playing out in its own way. Even then, Java's automatic memory management was not always as efficient as manually allocating and deallocating memory. That is similar to where we are now. AI sometimes hallucinates and makes up random things. If you do not know the subtle details, you could ship production-quality code with major security, memory, and other flaws.

The comparison does not settle the question for me, because abstraction has helped programming before while still leaving important lower-level work and knowledge in place. It is tough to rationalize where I stand. Have I reached the point in my technical understanding where everything new seems wrong simply because it is new? It is like musical taste: “The best music is what I grew up listening to. Everything after that is bland.” I genuinely struggle with where AI fits into this.

It could be a personal preference rooted in my fear of how quickly AI is growing. I recently saw AI being used to create music that sounds just like a particular artist, and things like that are a little scary. I was also a Smart House kid—the Disney movie Smart House, where the house eventually decided to take over everything and lock the family in—and that was a bit much for me. I step away a little from anything that could put us in a place where we no longer have even a little control as developers. I think that is as far as I can go there.

I would like us to retain at least a little control. That fear is less about rejecting useful assistance and more about preserving human judgment and authorship. I am comfortable with help, but less comfortable surrendering the entire creative role. Using AI to help improve something we have already developed is one thing. Talking about AI as the creator of everything is different, and I definitely feel some hesitancy around that.

Especially when you are learning programming and its fundamentals, there may be a lot of value in knowing how things work, even if you never use that knowledge directly later. It is like Photoshop and graphics applications: you may never write the individual pixel math that puts things on the screen, but you should understand vector graphics versus raster graphics and why some images look good when you zoom in while others do not. Those fundamental concepts are important even if you never write an algorithm to ensure that the things you draw look appropriate. It is a fun topic that we could spend hours exploring in depth. But your book is coming out soon.

What is it called?

I think part of my stance may just be personal preference, but I do have some fear about how quickly AI is growing. When I see examples like AI-generated music that sounds just like a real artist, that gets a little scary. I was also very much a Smart House kid—the Disney movie where the house takes over and locks the family in definitely left an impression on me—so I probably step back from anything that feels like it could take too much control away from people. Using AI to improve something we've already built feels very different to me from using AI to be the creator of everything.

That's where I still feel a lot of hesitation.

What are your plans for marketing the book?

I have really been thinking about that. Initially, when I started the book, I was thinking about a younger audience. As I wrote more, I realized I wanted the audience to be young adults who want to break into coding. It could be a pre-boot-camp book. If someone is considering a coding boot camp but is unsure whether they will enjoy coding, this book can help. This often happens: people look at tech and say, “Tech is the way to go if I want to grow my income and create more security,” but they do not actually know whether they will like it.

Then they spend thousands of dollars on a coding boot camp only to discover that it is not what they want to do. I think this book is for people deciding whether this is even a path they want to take. I will market and conduct outreach to people interested in that question, along with people who just want to learn a little about coding. The community of potential readers is broad. This is not a book written for someone who is already a techie. I can have technical conversations with technical people when necessary, but this book is not about them.

This book is not for someone who has been coding for 10, 15, or 20 years. It is for the person who wants to decide, “Is this for me?” or simply know a little about coding. The marketing plan is to promote it through blogs, podcasts, and my own relationships with people who may be thinking about coding. I have conversations all the time with people who want to enter the tech field. I am honest about the things that are fun and the things that are not fun at all.

I have had great experiences as a software engineer, but I have also had unpleasant experiences, such as people questioning my capabilities or asking for a skill set I do not fully have while expecting me to be a master of it. I have experienced both ups and downs and had many conversations about them. This book is for anybody trying to determine, “Is this what I want to get into? I am nervous. I am not even sure I am good enough.” That uncertainty happens too. The book is for anyone who wants to read it, so we are going to market it to a very large community.

That sounds amazing. I wish you the best of luck with it. Thank you; it has been fantastic chatting with you, and we should definitely do this again in the future.

Yes, we definitely should. I just want to thank you so much for being open not only to having me on your podcast, but throughout this entire process. I reached out because I said, “I am writing a book, I read your book and your story, and I wanted to find out whether you would tell me a little about what you did to get where you are.” You have been incredibly open and helpful, and that is not always something you see in this field. I am so grateful for you. I wanted to thank you publicly because you really deserve that. Thank you so much.

That openness has meant a great deal to me.

You're welcome, Ronesha. We will catch up further.

Alrighty.