The Emotional Journey of Learning to Code
Today, we’re talking about our feelings. I’ll tell a story, map out the student emotional journey, and lay out some of the implications for folks teaching or building schools.
The emotional journey of learning to code is more important than any of the content knowledge learning.
First, a story about debugging.
A debugging story
I walk past the group of Week 2 students, working diligently on the day’s labs - today it’s basic SQL exercises. I notice that a student is visibly frustrated (staring hard at their screen, frowning, clicking and typing with force, sighing, breathing with sharp intakes, slouching). I ask what they’re working on, and they describe the bug they’ve run into.
“It’s not working. Nothing I try seems to help.”
They’ve tried the normal debugging go-tos. Searching for their problem online, asking a neighbor, trying changing different things to see what works. They’re still stuck.
I squat next to them, and ask them to walk through their code, and tell me what it’s supposed to do. They show me the error, and some of the things that they’ve tried in order to fix it. Recounting all the different rabbit holes they’ve been down, they show more agitation, frustration, and anger.
We step away from the code, have a sip of water. After a minute or two, we start again, and read through the code they’ve written, line by line.
Upon rereading the code and explaining what each piece does, they notice a typo, fix it, and the code works.
(This is a composite, not a ‘true’ story, but it’s representative.)
My role wasn’t to notice the typo, or offer the solution, or to point the student towards a particular resource so they could understand what was happening. It wasn’t to ‘teach’.
Still, this has happened enough times that I doubt my presence is incidental to the typo getting noticed and fixed. So, what is going on here?
In order to notice the typo, the student had to be able to read through their code patiently. Solving this bug, for this student, meant changing how they felt. With a calming presence next to them, the student could manage their stress. With their stress under control, they could actually read their code, and solve their problem.
Debugging is a state of mind
Coaches and teachers see hundreds of versions of this story, with minor variations in the details. Sometimes, there’s a new concept that needs to be explained. Sometimes, there’s underlying misunderstanding that the bug reveals. Sometimes there’s bugs that are confusing, even to the teachers.
There are lots of ways that students get stuck and unstuck as they learn to code. In lots of ways, improvement in software skill looks like growing independence in getting unstuck.
Almost all bugs get solved in a patient, curious mindset - not a frantic one. Students’ progress is emotional maturation. After seeing and successfully resolving lots of bugs, programmers are not scared of new ones. Instead of panicking, they patiently apply the techniques they know.
There is a concept and skill story here too. Students start with a weak or missing mental model for how their code executes, what terms to use when searching for information, how to recognize what’s relevant, how to rule out hypothesis for the source of error, how to use their tools to better understand what’s going on. Coding has important facts that need some kind of transmission.
There’s also an education theory story here. Cognitive Load, the Zone of Proximal Development, Scaffolding. I’m not breaking any new ground, noticing that a teacher acts as a guide - emotionally as well as conceptually.
Still, especially in the bootcamp world, where many of the teachers come from a non-education background, and the students are adults, it’s easy to underweight the importance of emotional growth and development. This is even more true for folks further from students.
Attention, learning, memory, and emotion
We know that memory formation is negatively impacted by stress, and that emotional connection is key to successful retention. Stress can be a blocker, effectively reducing the number of working memory ‘slots’ available to work with new information. It can also be demotivating - you don’t want to spend time learning when you are stressed.
It’s not surprising that motivation and attention are key to learning. If you are too bored to pay attention you won’t learn. Your brain filters new facts by relevance, and won’t retain concepts that aren’t significant enough. Both in the micro and the macro, emotion is key to learning.
Particularly when dealing with difficult and overwhelming new topics, it’s easy to get caught in loops of distraction. Thrashing between topics, tutorials, and learning resources can be a vicious cycle, where students switch tasks before they can make progress. This feeds a feeling of discouragement, a lack of results, and
The emotional growth answer to thrashing is to learn to notice when you get distracted from what you set out to accomplish. This frequently shows up as switching tabs in the middle of reading, or having several incomplete tutorials going at the same time. Once you learn to notice that as a learner, you can build a system for coping.
Escaping thrashing means having a system for noting interest in something, without letting it distract you from your current task. Completing tasks is key. That way, you clear the decks for taking on a new task - and you get the ‘win’ from completing that tutorial. (This set of ideas is similar to me to the notion of limiting work in progress, but with cognitive load and context switching costs instead of communication overhead as the bottlenecked resource.)
It’s important to note that interest, attention, and diligence aren’t fixed attributes that a person has. Different people grow and change, are differently attentive to particular topics, and learn different habits and coping skills.
Should we valorize frustration?
Since getting stuck is such a common experience, lots of people online will tell you that you need to spend time stuck to learn to be a ‘real programmer’. There are lots of forum posts suggesting that banging your head against the wall is a necessary step to programming enlightenment.
This is not true. ‘Stuck’ isn’t a place where you are learning new things. While going down rabbit holes may provide exposure to lots of concepts, you won’t retain much from it. Those concepts are removed from what you were trying to accomplish, and when debugging, you aren’t paying the right kind of attention to learn a new concept.
While ‘bang your head against the wall’ might be misguided advice, it’s a lie that may help prepare you for reality. You will get stuck.
Still, I think we can do more to help students avoid some of the darker, deeper feelings that often come up in the journey of learning to code. Spending hours (days, weeks!) on a bug, and making what feels like no progress? A coach or teacher can help students get unstuck and back to making real progress learning.
I’ve gotten (and given) the advice before, as a teacher, to make more mistakes in live-coding. Great coding teachers emphasize their practices for reading error messages, debugging, and will leave in deliberate mistakes in order to support this kind of learning.
The past newsletter on learning in public talks about how sharing stories about the learning journey can help learners manage the intimidation of the learning roadmap. At Flatiron, we had Feelings Friday, time explicitly dedicated to paying attention and validating how we felt.
Making mistakes and telling stories can help make students feel normal. That means sharing the full range of emotional experiences of coding, including the frustration, sadness, and worry as well as the excitement, curiosity, and joy. Knowing that others feel the same way can help students cope with their own feelings when they encounter confusing or frustrating situations.
Not all fear, anxiety, and doubt is impostor syndrome
Many schools tend to focus on combating impostor syndrome as their way of starting to talk more clearly and explicitly about emotions in tech. But, particularly for beginners, impostor syndrome doesn’t necessarily speak to the experience they have. Feeling overwhelmed when faced with a wall of jargon isn’t impostor syndrome per se, but it is a common and natural experience when getting started with something new.
The discussion around impostor syndrome does give us words and a space to talk about how we’re feeling - that’s way better than nothing! Impostor Syndrome proper will also happen to students, so it’s awesome that schools help students with tools and approaches for managing it.
Talking and writing about stages in the learn to code journey in terms of emotions may help expand students and schools vocabulary.
Stages in the journey
In the bootcamp business model, I spelled out the stages of the student journey from the perspective of the bootcamp, and its balance sheet. Today, let’s look at the journey from the view of a students’ emotions.
There’s a lot of emotions, and a lot of stages, so this is inevitably a shallow view, and it doesn’t capture everything. I also focus on coding bootcamps - that’s not everyone’s experience of learning to code.
Before the bootcamp
In the business model, this is ‘marketing and admissions’, and the goal is to get students enrolled in the program. What does it feel like for students?
Finding out about bootcamps (curiosity, excitement, confusion)
Trying out tutorials online (confusion, thrashing, discouragement, proud)
Applying to bootcamps (nervousness, fear, confidence, confusion)
Getting Rejected (sadness, dejection, pain)
Getting Accepted (validation, eagerness, anxiety)
Figuring out how to pay (stress, worry, confusion)
Prework (stress, confusion, excitement, anxiety, self-doubt)
Students have a mix of emotions (we contain multitudes). There’s confusion and doubt, stress, anxiety, and eagerness. “Can I do this? I hope so.” Applying to anything comes with a bundle of doubt, curiosity, excitement, and fear. Maybe even more so when the promises of bootcamp marketing are so profound and life-changing.
During the bootcamp
Orientation (exhilaration, pressure, overwhelmed, newness)
Learning to code (confusion, frustration, stress, joy)
Assessments and Code Challenges (fear, anxiety, doubt, thrill)
Projects (pressured, fear, doubt, frustration, creative, disappointment, pride)
There’s so many things happening in a bootcamp, and it’s easy to be overwhelmed. Classmates can be a source of comfort and commiseration, but can also be intimidating and overwhelming to meet all these new people. On top of that, sometimes students don’t get along!
Then, there’s the content! Hopefully, it’s exciting and motivating material, but it’s sometimes boring, frustrating, or confusing. Courses move really fast, which is intimidating and overwhelming. It’s thrilling too - there are so many moments of new understanding and joy.
Different bootcamps have different kinds of assessments and projects, but no matter the structure, they still feel like a judgement. Students, understandably, feel stress and anxiety!
Job Search
After graduation, students have to actually find a job! There’s a period of doubt and loneliness, especially since they might no longer be with their classmates.
There’s a lot more to say about the job search, but my experience with it is fuzzier - I’m not a career coach, so I’ve seen way less of it. Keep an eye out though, I may have more from actual career coaches about mapping this phase!
What do we do with all these feelings?
Okay, so we should all internalize this map of how students might feel across the different stages of the learning journey (and probably build user personas and tell more stories about students). But, ultimately, we have to put this knowledge and empathy into practice somehow.
Social Support
Teachers and staff should help build healthy community among students, set norms and expectations, and help students make friends. Leading by example, community activities, icebreakers, shared myths, explicit rules and expectation setting, and informal conversations all have a role to play.
There’s also tons of room to help students recognize that they need the support of their families and friends in order to learn. Students are embedded in a social context already.
Drills and Assessments can be confidence building
Drills should help students learn. Through practice, they can be assured that they’ll remember the new skill or knowledge. Of course, there are lots of drills that are boring, irrelevant, or bad. These lead to frustration, annoyance, or self-doubt, depending on the nature of the drill’s badness. Good drills feel relevant, real, and ‘in range’ for the students level of knowledge.
Assessments should give students confidence. Students and teachers should trust that assessments accurately measures the skill they wanted to learn. If that’s true, then the assessment gives them crucial feedback about their own knowledge, and they can move forward with confidence.
There’s an evil twin version of this, using “It’s going to be on the exam” as a hack to convince students to pay attention. Don’t do it.
Helping students get unstuck
Students shouldn’t spend too much time stuck. The goal should be to build independence, but that doesn’t mean never getting help. Setting norms for how much time students should spend before asking means that folks will maintain consistent progress.
Wins are motivating, and motivation helps students stay invested in learning.
Project-based learning
Projects can be tremendously motivating and energizing. They can also be frustrating pits! Appropriately scaffolded and scoped projects can drive home the point of learning some content, and give concrete proof of learning and capability. It’s really hard to deny that you’ve learned a skill when you have made an artifact that you can point to.
Still, it’s also common for students to feel disappointed by their projects, or to feel even more anger and dejection when they get stuck, because they care more about the outcome. Teachers can help students make good design and architectural decisions at the outset and plan projects that they will be able to complete to their satisfaction.
It’s also critical to recognize that you can’t only do project based learning. To be effective, there has to be other pedagogy (especially, guided instruction and deliberate practice)! For more on this idea, see the section on the trap of intuitive best practice from Sean Dagony-Clark’s excellent review of Teachers vs. Tech.
Explicit emotional coaching
Talking about your feelings is good. It’s key to creating a space where learning can happen, and it’s often key to getting better.
If you haven’t seen the Feelings wheel, it can give you more language for talking about feelings. There’s also lots of reading and training on active listening, handling feelings, and being emotionally supportive.
Referring out to others
There’s situations that schools aren’t equipped to handle. Teachers and administrators should talk about what those are, and have a plan for dealing with them.
Mental health is really important, and there’s lots of good things to do as an education provider to design experiences that are empowering.
Links and updates
Maybe I was wrong about Holberton
In the past, I’ve been dismissive about the regulatory action against them, on the grounds that historically, most of the regulator’s actions haven’t amounted to much. This week, I watched a pretty compelling segment from the San Francisco local CBS station that paints the school pretty negatively. It features in depth interviews with several students that are unhappy with the program, for what seem like legitimate reasons. Other programs are much cheaper (Holberton’s ISA cap is $85,000), and seem to have better outcomes, going by the surface numbers.
They also recently opened a school in Tulsa.
In case you weren’t aware, sexism is very real
Ali Spittel posted a bunch of messages and comments she has gotten on her work online. Worth browsing for the reminder, and the reality check, if you are in a place where you can handle the toxicity.
I don’t have much to say about this, except that this behavior is awful and shouldn’t be tolerated. The environment shapes how people learn, who teaches, and how. This is the environment, and it’s on us to change it.
Badass users
Joel Hooks of Egghead.io writes about a book that frames how he thinks about teaching, and what they’re building at Egghead. The notes are somewhat raw, but I really like how it puts the user at the center, and gives you as a teacher or content developer a mission - make the user a badass.
The post is here, and the book he’s reviewing is Badass: Making Users Awesome by Kathy Sierra [Note: I left Joel’s referral code on the book link].
Tools and communities for learning to code
General badass Jenn Schiffer of Glitch writes about code learning and how that experience connects to why she’s building Glitch. Seeing live examples of tools in use, “in their native environment” helps people understand why bother learning those tools, and what they can do. (Plus lots of other stuff, go read the post and check out Glitch if you haven’t!)
Speed of Learning
Learning things quickly is appealing to the learner — as well as to the bootcamp business model.
A half hour to learn Rust from Amos is an interesting attempt at pushing the limits of how much language syntax you can cover, and how quickly.
From the conclusion,
And with that, we hit the 30-minute estimated reading time mark, and you should be able to read most of the Rust code you find online.
Writing Rust is a very different experience from reading Rust. On one hand, you're not reading the solution to a problem, you're actually solving it. On the other hand, the Rust compiler helps out a lot.
I am doubtful that someone who read this will retain even 50% of it, and as acknowledged, they’re still at the starting gate when it comes to learning to write Rust. I’m doubtful of it as a standalone resource - it’s hard to stay engaged with reading something unfamiliar, and you don’t have actions to take to engage.
Still - 30 minutes? That’s not that much time at all! It’s short enough that much of the earlier concepts are still close by in short-term memory, though the chance of cognitive overload and encoding errors is high. It’s also short enough that it might be well worth the read (if you want to read about Rust).
The text is mostly code snippets, with some prose providing guidance. I wonder if making it interactive, either with drills or exercises, or something like the Spaced Repetition System / mnemonic medium of Quantum Computing for the Very Curious could turn it into a tool where learners actually learned it all.
See also: learnxinyminutes.com, which has this style of document for lots of languages. Includes all caveats above plus more about thrashing, but it’s close to the maximum content-knowledge-density, if you’re down with Transmissionism-style learning.
Okay, that’s all for this week!
Let me know in the comments or with an email response if you have thoughts, links, or suggestions.
Thanks for reading!