In a past life (i.e. two jobs ago), I was a Montessori middle school teacher. I believe the most valuable part of the curriculum I used was a dedicated subject for Personal Reflection, which built time into each school day to learn and practice skills for introspection, mindfulness, and emotional awareness.
Best advice a TV show has ever given me.
Part of my preparation to start learning coding at Flatiron Seattle was to revisit some of those techniques. I knew that developing ways to cope with coding-related stress would be integral to jumping into the tech world (along with other concerns, such as being out as trans in a professional setting for the first time), and I took some time this weekend to reflect on how those efforts are going. Here are some of my takeaways and useful reminders to myself so far:
1. Learning is both energizing and draining, and coding amplifies the feeling of both—take time to rest!
I love to learn. I’m someone who gets too excited to sleep when thinking about new ideas that finally click in the middle of the night. The constant barrage of learning that coding requires keeps me energized in precisely this way, especially because new ideas can be so hands-on—new coding techniques can be practiced right away, and that makes the learning experience feel so immediate and accelerated. It’s also easy to keep going since one thing always leads to another interesting connection in code-world, like an infinitely-deep Wikipedia hole (like this particular one I fell down recently).
But that constant stimulus is draining. I remember having a similar experience when I was a teacher—constantly waking up to write out lesson and project ideas before the ideas were washed away by new ones. I couldn’t keep it up forever; no one can. And while not everyone reacts this way to learning new things, learning to code will always require your brain and body to do some amount of work—so even when it’s exciting, it’s also draining.
So, taking time to rest is good. And so is practicing noticing how fatigued your body is, even when you’re otherwise excited and emotionally charged up. It’s not a mistake or a personal failing to slow down and allow yourself to physically stop and recuperate.
Speaking of failure…
Don’t listen to this part of your internal monologue!
2. Productivity requires failure, and coding offers plenty of opportunities.
This is a big part of what is subtly (and not-so-subtly) draining about coding—it requires a lot of failure, and that failure can feel very counterproductive. But it’s not! I could drone on about Carol Dweck's 'growth mindset' or other related ideas of 'productive failure', or speculate unscientifically as to how failure might be linked to the biology of learning and myelination (both of which I used to do routinely during parent-teacher conferences). Instead, I’ve been spending time reflecting on what the nature of ‘failure’ in coding is, and thinking about that ambiguity has helped me realize the need to address those experiences in a more targeted way.
What does it mean to fail at coding? Is it when you write code that doesn’t work? It is a measure of optimization, or of writing elegant code? Is it relying on old habits instead of trying new techniques? Is it not accomplishing an explicit goal that you or someone else has set? I’ve certainly experienced all of the above—what other ways do you feel you experience ‘failure’ while coding?
And just as important: what ways to you help yourself reframe those experiences in positive and compassionate ways?
Sometimes it’s hard to be forgiving and compassionate with yourself!
3. Everybody needs processing time for learning to sink in.
This was the #1 lesson I tried to impart to all students, and still tell myself to this day: it takes time for learning to sink in. Back in Montessori-land, we called it ‘processing time’, which is probably terminology that's a little out-of-place in coding-world. Regardless, it’s helpful to recognize that learning is a process more akin to unfolding than to tempering, insofar as its end result is not always immediate—or perhaps even knowable.
Yes, one of the allures of learning to code is how quickly you can play with new tricks and ideas. But that immediate hands-on learning is not the end of the process. Making new connections between ideas, realizing new ways of perceiving code, opening up new areas of knowledge to explore—all of these take time to happen, and the amount of time is different for everyone.
Try to see how long your processing time is when trying to learn different things! For example, you probably don’t learn how to code in a new language and how to cook a new cuisine at the same rate (I know I don’t)—I think it can be very interesting and healthy to gain an awareness of the different speeds you learn different things. Just know that having a long processing time is NOT a bad thing, and is NOT a measure of talent or inherent ability! It’s all just a part of your individual rhythm of learning—just like rest and failure are too.
More or less accurate depiction of me resting. Btw Bobby Hill is my soulmate. <3
Ultimately, my biggest takeaway from these reflections is to reassure myself that learning is a dynamic and evolving process. It unfolds over time, and both allowing time for rest and being forgiving of failure are necessary parts of the process.
I’d love to hear how you respond to the stresses of learning to code too!
Links and Credits
Top comments (0)