Learning Archetypes: An aid for setting intention at a Coderetreat

Estimated Reading Time: 7 minutes

Based on feedback from prior Coderetreats we have run in Toronto, we are experimenting with a new learning and facilitation aid for Toronto’s Global Day of Coderetreat this year: Learning Archetypes.

RSVP here for Toronto’s Global Day of Coderetreat to secure your spot.

This blog post was originally published on Paul’s blog, Coder Spikes.

Why Learning Archetypes

On the one hand, labels can hold us back. They come with expectations on what we can and can’t do, or what we know and don’t know. Those expectations can be self-inflicted or put on us by others. This is especially true of job titles. Some examples:

“It’s been years since I’ve coded, and as a Manager, I don’t really do that anymore”

“Let’s ask them — they’re a Senior Software Developer, so they should know the answer”

This is why at a Coderetreat, we say that we leave our job titles at the door. For similar reasons, we delete our code at the end of a Coderetreat pairing session. Pre-existing notions, assumptions, or expectations oftentimes hold us back from learning — consequently, we discard them when possible.

On the other hand, labels can help us focus. They can help us set our intentions. Who am I showing up as? What do I hope to get out of the day, and how will I do it? This is why we are introducing Learning Archetypes this year.

The Learning Archetypes

Here’s an explanation of each archetype — what it means, and when you might choose to adopt it.

Explorer

“In the beginner’s mind there are many possibilities; in the expert’s mind there are few.” — Shunryu Suzuki

By choosing Explorer, you are acknowledging that you know little about Coderetreat and the topics it covers. You are embracing a beginner’s mind (Shoshin), surrendering any preconceived notions you may have — not just about the subject matter at hand, but about related topics as well.

For example, you have experience in software design but have never heard of the Four Rules of Simple Design. Approaching the latter as an Explorer means that you are prepared to question any assumptions about software design that you come in with.

On a deeper level, Shoshin means that you are surrendering part of who you are; namely, as it relates to being knowledgeable in a certain topic. While this can be the hardest part of the Explorer archetype, it can be the most rewarding.

Sharpener

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” — Abraham Lincoln

By choosing Sharpener, you have enough familiarity with the subject matter to work on mastering an element of it. By analogy: you know what an axe is, what it’s used for, and how to use it — you’re here to practise chopping wood. For example, you have already attended a Coderetreat before or have practised code katas. However, you may have only done so alone or with a limited group of peers (for example, co-workers at your company). You’re here to apply deliberate practice while gaining fresh perspectives by working with other like-minded individuals.

Teacher

“Teaching is the highest form of understanding.” — Aristotle

Choosing Teacher means that you are here to teach! This one’s pretty obvious. Having said that, it is still a learning archetype, so you are teaching with the intention of further solidifying your own understanding. This could mean exposing any inconsistencies in your own mental models. It could also mean expanding your vocabulary and gaining confidence in your ability to explain complex, nuanced concepts. In and of itself, teaching is most importantly a skill with many elements, including the ability to listen and adapt to the student. This learning archetype provides you with the opportunity to further practise these skills. Having some experience in the practices of Pair Programming, TDD, and Simple Design is expected if you choose this archetype.

New Hat / Seasoned Hat

“Do one thing every day that scares you.” — Eleanor Roosevelt

Each of the three Learning Archetypes come in two varieties: “New” and “Seasoned”. Each variety can be thought of as choosing a hat to wear for the day.

A “new hat” is one that you’re not used to wearing. It might be the first time that you’re trying it on, or it might be one that’s still uncomfortable. Why would you wear a new hat? Analogy aside, why would you choose a Learning Archetype that you’re not familiar with? Because the day is about learning, and learning means exploring, experimenting, and moving outside of your comfort zone.

On the other hand, a “seasoned hat” is one that you’re comfortable wearing. You can be a Seasoned Teacher if coaching and mentoring come naturally to you. You can be a Seasoned Explorer if you spend most of your days researching and learning new practices, technologies, and frameworks. You can be a Seasoned Sharpener if you frequently attend Coderetreats and practise code katas. Wearing your “seasoned hat” means that you can go deep on the learning that is found within that archetype.

Photo by Brian Lundquist on Unsplash

Multiple Learning Archetypes

Can you take on more than one archetype? Absolutely! However, to give some focus to your intention for the day, we recommend adopting no more than two Learning Archetypes.

Conclusion

Learning Archetypes are a tool you can choose to use to focus your learning for the day, and help set learning goals with your pairing partner. Choosing a Learning Archetype is meant to deepen your learning, not stand in the way of it. If you find that your archetype is doing the latter, feel free to abandon it in favour of a different one, or no archetype at all.

The point of the day is learning, and as Coderetreat facilitators, we are here to support you in that endeavour.

RSVP here for Toronto’s Global Day of Coderetreat. We still have some spots, though they’re filling quickly!

Paul Sobocinski

Director of Engineering, Practice

As a Practice Director, Paul is responsible for elevating the technical excellence of the Software Engineering practices at Connected and beyond. He does so through coaching, writing, public speaking, and of course, coding.

Paul is currently interested in fostering professional growth through skills-based learning, with a particular focus on pair programming, test-driven development, and emergent design.

More Posts