Developer Learning Principles and an Open Framework

In September 2023 I gave a talk at DevRelCon London – you can watch the full talk / read the transcript online now but here is a summary of the slides and notes!

This talk is about developer learning. We'll cover some general principles and a framework – a hypothetical standard structure for coding learning experiences that I would love to co-create with you. I'm going to show you an example implementation in Glitch, but you'll be able to deliver it in any environment you like.

• AI assisted coding discourse shows we don't have a strong definition of what software developers do (I blogged about this).
• At its core it's a learning activity. Developers are always solving new problems, even if a developer has worked on a similar implementation before, the context is different. Even with the most intuitive DX, the developer is engaged in learning.
• These principles apply to coding learning generally and developer product adoption / onboarding.

• When I trained for tech there was a complacency about the high CS dropout rate, which benefited folk from privilege. Tech affects everyone and we need a strong representation of people building it if we want it to be empowering more than exploitative.
• Learning science and coding pedagogy have given us tried and tested techniques. A lot of what we know comes from Raspberry Pi Foundation research.
• I have to recommend a previous DevRelCon talk from Joe Nash which introduced much of this.

• Hopefully the idea that you’d center the learner is not controversial in this space in the year 2023, but in classroom environments in most of the world, this is not what we do.
• We still have the notion that the educator bestows learning on the student. Unfortunately most of our schools are not designed for learning, but to train productive obedient workers. You can refer to the work of Ken Robinson and Paulo Freire for more on that.

• This is why I talk about learning more than education. Learner-centered design is especially valuable in developer enablement, because your tech is just one piece of the developer's puzzle. We can't be heavily focused on our own products.
• At best we can create the conditions for learning – it’s most effective when we respect learner agency. Encourage inquiry, asking how the tech relates to the world around them. If we can create a dialogue for some shared learning, that's even better.
• Learner context has a huge bearing on success. That means background, situation, company, project. Do they have time to invest upfront or do they need to learn while building a solution. An API documentation study distinguished between systematic and opportunistic learning (methodically working through resources vs learning through experimentation and play). Psychological safety – learning to code means getting comfortable making mistakes, but the learner might not be safe, maybe they’re underrepresented on their team, a mistake might have consequences.
• Success is the achievement of something valuable to the learner, they decide what this learning outcome means within their own journey.

• The PRIMM model was developed by the Raspberry Pi Foundation researchers. Learners predict what a piece of code will do, run it, investigate how it did what it did, modify it, then make something new.

• Remixing is used in platforms like Scratch and Glitch. A remix is like a Git clone but within a running environment. It lets learners make a change and see an instant result instead of having to do upfront scaffolding – it's less intimidating and more stimulating than a blank slate.
• Historically coding was considered a "numeric" discipline, like maths or science. But we’ve found it has similarities with natural language acquisition, we read before writing, why not do the same with code. Code comprehension is an important software engineering skill especially on teams.
• Evidence shows that guessing improves subsequent skill acquisition, even when the guess is wrong. Some teachers use testing for learning rather than assessment (where testing is not effective).
• The modify and make steps give us a low barrier path to taking ownership of the code. Start with a light edit that’s not scary, then create something new. Normalize mistakes – the Glitch UI emoji almost incentivize me to break my code so that I get to see the sweary face, and the Rewind function lowers the fear of making a mistake that I can't recover from.

• The patterns draw on the same research – these are more granular techniques.

• With spacing and interleaving, you insert spaces within the coverage of a topic and mix it up with others. We retrieve what we learned and ideally reapply it in a different context.
• With a semantic wave you move between levels of abstraction, so you might introduce a topic conceptually, then dig into a specific implementation of it, then pack it back up into something more abstract.
• This can help build mental models, to retain skills over the long term. When we look at experienced software engineers, the skillset isn’t specific to a language, it’s a more abstract set of skills they can deploy in different settings.
• This might seem obvious, but coding is a practical skill, we learn by doing. Lots of developer tools like APIs use time to first call as a success metric because a quick first interaction is a strong predictor of further engagement. You can slot learning in to convey the value and purpose of a tool, why a developer would want to use it.

• This is the most messy human one. Prompting learners to reflect on what they've learned and connect to the world around them.

• For a long time my specialty was learning how to code something then writing tutorials to help other people learn it. It took me years to realise the writing was part of my learning process. Reflection makes the the learning stick.
• The learner is part of a community, encouraging people to share what they’ve learned helps them make sense of it within a social context.
• Our tech is also part of an ecosystem, so when we connect to related resources, we position it within its technical context.
• I briefly worked on the Open Badges standard when it was part of Mozilla and a project that didn't make it to production was badge pathways, which would allow the learner to forge their own path rather than following a prescribed linear one, so that they could convey a more authentic picture than a set of standard credentials. The best motivator to learn is having a goal that’s bigger than the tech.

The lesson framework:

• We signpost what we're working towards so that learners can self-select based on whether it aligns with their goals.
• Link to prerequisites to keep the door open.
• A series of steps – each one has an intro, some code, we run and investigate what it did, make a change, and recap it.
• After the steps we reapply what we learned in a project that we encourage learners to continue developing.
• Learners reflect and share on what they learned, what they would use it for etc.

• This is an example implementation in the Glitch editor. the preview auto-updates as the learner edits.

• This short demo shows you the framework in action. As the learner edits we have code checking the completion status for each step. It's all in vanilla JavaScript to make it as easy as possible to extend. We show a visible change in the page with each step to give learners a sense of impact and momentum.

Why I’m advocating a framework approach:

• It scales, and is optimized for autonomous use, which a developer audience greatly prefers – devs like to be independent, advance at their own pace, and get instant feedback.
• You can also use it for live learning, if you do events, training, webinars. People like to have something to take away with them, they can go back over it after the session, and can continue developing it.
• I’ve worked a lot with sales / solutions engineers, and customer success / support, and find that the same resources are valuable across enablement contexts beyond community.
• When I worked at Postman I used Glitch for education, and I built a super simple API to track progress, not personal information but progress tracking, which can be a source of product feedback – identifying places people get stuck etc. Community gives us quantitative metrics and the more closely managed relationships with customers give us qualitative feedback. Inclusion in employee training is also great for internal community building.
• If you have a partner program, or your tech integrates with other tooling, coauthor a learning experience!

You can access the template and demo projects here:

learning-framework.glitch.me

Check out the project docs for links to more resources and a GitHub repo for the framework itself. Please let me know if you use any of this! You can find me on the Glitch forum or on Mastodon @sue@glasgow.social.