This article is adapted from a talk I gave at JavaScript & Friends and Music City Code. You can find the slides from that talk here. You can also read this article on Medium.
Curriculum to Command Line: What teachers make great coders, and what your team can learn from them
Hello! My name is Christine Zekis, but I go by ‘Tine Zekis, which also happens to be my Twitter handle (tinezekis). My pronouns are she, her, hers. I’m a Software Engineer and a former High School Math Teacher.
Before we dig in, I’d like you to take a moment to consider this question: Who was your favorite teacher and why? This could be anyone from your preschool teacher to a college professor, or anything in between. And it doesn’t need to be from a traditional education setting…maybe it’s your Sunday school teacher, or a dance instructor, or a soccer coach.
Here’s what I came up with when I did this exercise:
My favorite teacher was my high school geometry teacher, Ms. Hardin.
- She had a great sense of humor
- She was able to break down logic and explain her reasoning
- She related the content to our lives
- She was deeply committed to her students
Now that you’ve thought a bit about what makes an awesome teacher, I’d like to spend a few minutes convincing you of my premise…that awesome teachers make awesome coders.
The Argument: Why (awesome) teachers make awesome coders
(Awesome) Teachers Make Awesome Coders
While planning any lesson, most teachers will start with the learning objectives. What will students be able to do as a result of this lesson? A learning objective might be something like, “As a student in Ms. Zekis’s Algebra class, I can apply the quadratic formula to solve word problems involving trajectory.” Perhaps you’ve seen something similar in your work, only developers would call this a user story. A user story could be, “As a user with admin access, I can edit the names and email addresses of other users.”
User Stories: What will users be able to do?
Learning Objectives => User Stories
So let’s talk about the learning objectives, or user stories, for this article:
- As a programmer, I can improve my comprehension and hone my problem-solving skills by creating and taking opportunities to teach others.
- As a team member, I can improve my communication skills by breaking down concepts for a variety of audiences.
- As a leader, I can help my team to become better collaborators by creating a culture of teaching and learning.
- As a hiring manager, I can appreciate the skills that former educators and other career changers may bring to the table.
Consider these various roles and decide what your goals will be for the remainder of your reading here. Try to focus on one or two of these objectives as we continue on.
After establishing the learning objectives, teachers will typically move on to the assessment. How do we know we met our objectives? Translating this to the world of coding isn’t too much of a stretch: this is when we would write our tests or specs. How do we know the code does what we say it does?
Write the Tests: How do we know it does what we say it does?
Write the Assessment => Write the Tests
When I used to write math exams, I would start by making sure the students can solve a particular type of problem with an intuitive solution. For instance, the answer is a positive, whole number. Developers might call this the happy path. But I also want to make sure the students can solve problems with harder solutions. Maybe the answer is negative, or zero. Maybe it’s a very large number or a decimal. These are our edge cases.
And not until the assessment is done do I start to figure out what the students must do to get from where they are to where they will need to be to meet the objectives. In education, we call this Backward Planning, or Outcome-Based Education. In the tech industry, we might call this test-driven development (TDD).
Then, after all the planning, it’s time to actually teach the lesson. This is usually around the time that 90% of the plan gets thrown out the window. I’m going to call this part deployment. Throw it out there and wait for something to go wrong.
Development: Here goes nothin'!
Teaching the Lesson => Deployment
Various studies have estimated that teachers make anywhere from 1,000 to 3,000 decisions per day in their classrooms. I’ve seen 1,500 cited most often, so we’ll stick with that for the sake of argument. If we assume a day from 8:00am to 3:00pm with a 30-minute lunch break, that’s more than 230 decisions per hour, which is almost 4 per minute. So that’s a decision just about every 15 seconds. Teachers are constantly adjusting to the changing situations in their classrooms — moving closer to the student who seems distracted, pausing to assess understanding, switching gears if the class isn’t getting it or just seems restless.
I’m not sure about you, but that’s the kind of person I want troubleshooting support issues on my team. Plus, who better to have on an Agile team doing CI/CD? Our teams need to be nimble, able to pivot when we get new requirements or feedback from our users. And teachers are trained in that kind of flexibility and willingness to change directions.
Lifelong Learners: Coders are constantly growing, adjusting, and learning new things
Lifelong Learners => Lifelong Learners
One more transferable skill teachers can bring to development is their commitment to lifelong learning. Teachers are constantly growing, adjusting, and learning new things. I’m not going to change this one. This applies to coders without any updates. Technology is always changing, and to do well in this field, coders need to be constantly growing, adjusting, and learning new things.
Okay, let’s bring it back to our initial conversation. Think about that favorite teacher you remembered earlier, and consider this: Would your favorite teacher make a great coder? Why or why not?
Here are some things I came up with when I did this. Reasons a teacher might make a great coder:
- Adjusts well to changing situations
- Good at predicting what might go wrong
- Enjoys solving interesting problems
- Can break down problems into smaller steps
- Thinks outside the box
- Cares deeply about students — Could this translate to caring for users or teammates?
Maybe your favorite teacher just gave really good hugs. Is that something that could translate to being an empathetic programmer? Or maybe they were really good at calling you out on your bullshit. How could that be useful on an engineering team?
And now we’ve come to the most important part of this article…
So What?
What does any of this have to do with you? Well, let’s revisit that last point about teachers and coders: they are both lifelong learners.
I hope we can all agree that, in order to excel in this field, we need to be willing and able to continue learning. Now, there are countless studies on how people learn, but I’m going to go way back to some early thinking on the topic. Aristotle once said, “Teaching is the highest form of understanding.” (Source) Since then, people have done tons of research on the matter, and this seems to actually be the case.
The Protégé Effect: The improved comprehension experienced as a result of teaching a new concept
Psychologists call it the Protégé Effect. The Protégé Effect is the improved short-term and long-term comprehension one gets from preparing to teach and carrying out a lesson on a new concept. In other words, if you want to learn something, the best thing you can do is teach it.
Some of the statistically significant results of the effect include:
- Increased metacognitive processing — awareness of your learning process
- Increased use of effective learning strategies — things like organizing the material in a logical way, seeking out key pieces of information or major takeaways, etc.
- Increased motivation to learn — people often take their learning more seriously when they’re responsible for educating others, rather than just themselves
- Increased feelings of competence and autonomy
- Improved communication skills, confidence, and leadership ability
So with all of these benefits, it’s pretty compelling as an advantageous and effective way to learn new things.
Ways to Benefit from the Effect
There are multiple ways to experience these benefits. First, you can simply prepare to teach the concept. Organize the information, consider the answers to potential questions your audience might ask, etc. Planning the lesson alone has been shown to produce some form of the Protégé Effect.
You can also pretend to teach the topic. Go through the content out loud, as if you are teaching.
However, the strongest benefits of the Protégé effect will come if you actually teach a lesson on the topic.
Ways to Teach
There are also lots of ways to teach. One is to give a talk. You can give a lightning talk, host a lunch & learn, lead a meeting, or put together some other form of group presentation.
Not a fan of public speaking? No problem! Write it down instead. You can break down concepts in writing through a blog tutorial, or maybe some detailed documentation.
You can also teach in a one-on-one setting by taking on the role of mentor.
And I’m sure you can think of other ways to start teaching. Get creative…maybe you want to do a code demo and post it on YouTube. Just as long as you’re communicating information to an audience of some sort.
So, What Next?
So, what can you do differently this coming Monday? Well, old habits die hard, so I’m going to give you some homework.
What can I teach?
Over the next couple of days, try to think about what kinds of things you can teach. Maybe you want to talk about a fun side project you’re working on, or a new technology you’re considering for your team. Or you could talk about the problem you figured out most recently. I’ve found a good rule of thumb to be that if any problem ends up being more than a quick Google search or visit to StackOverflow to solve, write it down. It’s probably a good candidate for a lightning talk or a blog post.
What else can I do in my current role to engender a culture of teaching and learning?
Additionally, I’d like you to think about what else you can do in your current role to help create a culture of teaching and learning on your team. For instance, my team has a designated time for weekly 5-minute lightning talks, and people can just sign up. We also have bi-weekly tech demos where teams show off something they’ve been working on. Last month, our summer interns got the chance to present a feature they built, which was a great opportunity to showcase their work and answer questions about it.
What Would Teacher Do?
And finally, I want you to think about what your favorite teacher would do. What’s something that made that teacher awesome? Could you do something similar in your own role?
My favorite teacher, Ms. Hardin, could always lighten the mood and create a positive environment by telling silly jokes. And I was the person on my team who helped keep up a tradition of starting every day with a Dad joke on Slack.
So what’s something you can do that your awesome teacher did?
Resources
Special thanks to all the people who made and released these awesome resources for free:
- Teacher statistics from Concordia University, St. Paul
- Aristotle quote from TeachThought
- Protégé Effect summary by Effectiviology
- Presentation template by SlidesCarnival