In 2022, I decided I’d put into motion a plan I’d had since 2019. I wanted to help a women’s shelter with their career coaching programs by teaching a web development course. I put together a Google Form and forwarded it to some folks who could connect me with those shelter alumni ready to learn how to code. I got twenty-three responses from people excited to learn a new skill and get connected with a professional network for mentorship and career coaching. By the end of the class, I had only three students who would regularly participate in class exercises. Here’s what I learned from the success and failures of the first coding class I ever taught.

Presence is important in a learning environment⌗

Ever since I started to work remotely at the beginning of 2020, I began to think that there was no need for physical presence in software development, operation, or even teaching. The reality could not have been further from that thought. Two out of the three students that stuck with the class the longest were able to meet every Saturday in person. I attribute their success in learning and doing the course-work to their presence at our meeting spot every Saturday. I was more able to help when they had questions, I was able to read their reactions and see if they were following what I was saying, and I was able to build rapport and see their progress regularly. Body language was especially important because I would say something and immediately get feedback from them that told me whether or not I needed to spend more time on a specific concept I was trying to teach. It taught me that the idea of abstraction and its different levels comes naturally to me through experience, but not everyone has the experience or experiences I have had.

What is obvious to you is not obvious to someone else⌗

I’ve been working professionally in software since 2013, and I have an understanding of software syntax, patterns, and behavior that’s been built over the past ten years of my career. The people that signed up for my class likely did not have that same well of experience to draw from, and things I thought would be intuitive often took more time than I would have liked to convey. I didn’t know what I knew, because coding has just been a ubiquitous part of my life for the past ten years. Recoginizing tree structures made up of key-value pairs, how key-value pairs are everywhere, the types of data you can have in a program, etc. These things are obvious to anyone who’s spent a great deal of time with, in or, around software development as a profession. Unfortunately, I expected that from students who had never written a program in any language before, and it caused me to rethink my entire curriculum for the class. I didn’t rethink the curriculum until it was almost too late, though.

Teaching how development happens in the “real world” can kill a desire for learning⌗

My class nearly fell apart after the second week we met. I tried to teach my students how to use Git to push and pull their changes to and from GitHub so I could track their progress and teach students how big companies would typically collaborate on software projects. In hindsight, this was definitely putting the cart before the horse. Although, it did line up with my intial goal of getting people into software jobs as fast as possible. More on the hubris of that goal later. Anyway, all that I had time for was to introduce people to the profession of software engineering and pique curiousity to (hopefully) spark continuous learning on the part of the student. However, by trying too hard to show people what it’s like to develop software on a software team, I killed any nascent sparks early for a large percentage of my students, unfortunately. That is what happens when you don’t begin with a realistic mission statement.

Set realistic goals for your students and their success⌗

My ambitions were too high for the class at the start. Initially, I wanted to get all of my students a job. That was my dream, and it was being fueled by the over-hiring that occured during the pandemic tech boom. I thought there was an infinite supply of Junior Developer positions available at companies everywhere. I thought that companies would be charitable to people who were making an honest effort to improve their skills. I severly underestimated what an honest effort to improve skills would look like, and I overestimated the amount of progress that could be made in 10-12 weeks while only working two-and-a-half hours each week. I did prescribe homework and goals to work toward each week, but to expect that people would be self-motivated enough to learn on their own was too optimistic. After that second class, I was on the verge of packing it in and quitting. I thought I wasn’t cut out for teaching, and that I was being a net-negative influence on people’s interest in the profession. Thankfully, a friend of mine came alongside me and talked me down from my lofty ambitions and unmet expectations.

Check your goals and how you’re getting there with trusted friends and colleagues⌗

The class would not have continued were it not for my friend. He was there for the second class and after class was finished we sat down and revised our curriculum to match the progress we were seeing in the class. He gave me valuable feedback at a time when I needed it most, and I don’t think I would have continued were it not for his input to the process. In hindsight, I wish I would have engaged him and some of my other colleagues earlier to get feedback on my plan. It would have made the process a lot less painful, and I probably would have ended up with a significantly higher student engagement than I ended up with had I done that.

Preparation is key to success⌗

The fifteen minutes of curriculum revision I did with my friend after the second class was honestly the most preparation I had done, and it showed. I thought I could wing it or that by simply starting to build a program and talking to others about it they would naturally catch on and follow along. That was definitely not the case, and if I were take away just one thing from this experience it’s that I should prepare to teach and not expect it to just flow from my experiences.

Celebrate the small wins⌗

At the end of the class, one of the students went on to take a programming class at a local university. It’s the best outcome I could have hoped for from a class that I was woefully unprepared for. She hasn’t found a job yet, to my knowledge, but the class did motivate her to continue her education in other places. It’s imporatant to celebrate the things that went right, because it makes the prospect of doing it again and learning more about the craft of teaching more attractive. How else am I going to get better at this if I don’t catalog what went wrong and right?

I’ve scaled back my ambitions for now, but I still enjoy teaching computer programming to others. I recently taught two students on a few Saturday afternoons over Discord to hash out details of some simple JavaScript programs. They’ve progressed nicely and I focused on teaching them how to think about the logic of a program and not it’s user interface implementation. I think they’ve begun to enjoy the work, but I haven’t met with them about it in a while. Honestly though, that’s what motivates me. I want is to share the joy of having an idea and making it a reality, even if it is just a software program.

I’ll have a post about what we built during the class and how I finished it, soon. Until then here’s what we set out to build, a wordle clone in React! Also, if you’re interested in viewing the class it was recorded and can be found here.