Pedagogy is the way
It’s three years since I first wrote about AI assisted coding. You can still read that post on the Glitch blog: Software development isn't writing syntax
A lot has happened since then, but as I said in a weirdly popular LinkedIn post recently, my beliefs have proven pretty resilient – tl;dr:
- LLMs make it easier to avoid learning, but also create new opportunities to learn.
- LLMs enable more people to make simple apps, but complex systems still require developer skills.
- Acquiring developer skills still involves learning to code.
- LLMs open new entry paths for acquiring dev skills, especially with support from existing developers.
- The productivity gains of LLM coding are exaggerated, and reduced or reversed with overreliance.
- LLM code generation is not very useful on niche or novel problems.
Of course things can still change, and I remain open to reassessing my views, but I believe the consistency in my position is more than a coincidence – these were educated guesses based on years of being immersed in coding pedagogy and the dynamics of software teams. To be frank, as daft as it may sound, I feel like everything I’ve learned over the last 30 years in the workplace has led to this understanding.
What is a skill worth?
I learned software development in my late twenties, on a course I took in an attempt to escape a decade of low paid jobs. It turned out I was quite good at writing code, but it infuriated me that it had taken so long to find that out. I wanted more people to access the shift in economic opportunity I’d had. So I focused on developer education, first by teaching on the course I’d taken, then in industry for developer platforms.
Specialising in education stopped me getting too attached to specific technologies. I don’t identify with ways of making software, I'm more interested in which skills will help people be successful. I lamented how much harder new frameworks made it for folk to learn how to build the web, but if those skills were what employers wanted, I had to embrace teaching them.
It made me approach technologies non-judgementally. For me they are mostly a means to an end, the end being the income and influence the life of a working software engineer affords you. That doesn't mean I ignore the harms technologies can cause, of which there are many – it's a trade-off that responsible advocacy requires continually revisiting.
None of this is to say I don’t respect the craft and creativity in coding, but the stakes are a little different when acquiring a skill might help someone lift their entire family out of poverty.
Who gets to benefit?
I’ve railed against the privilege and gatekeeping in software engineering, but having worked to get more people into these jobs, I can’t root against software engineers either, or rejoice in them being disenfranchised by what's happening. I tried to help a wider representation of people to become part of that cohort, so I can’t be against that cohort now. As it happens, I think AI is going to create more demand for software engineers, not less, once employers stop pretending it makes them surplus to requirements.
Learn about learning, seriously
Of course the tech industry never took education seriously, even through the era of developer relations. I’ve beaten my head against the wall trying to get companies to see the impact of education on the business metrics they care about. I content myself with the memory of leaders who took it on board and cultivated learning practices within their own teams. I saw more culture change than I probably should have expected.
Now we arrive at a place where the ability to generate code poses a threat to developer jobs and identities. The last few years have been characterised by ludicrous predictions about whole categories of work being rendered obsolete. As many of us have learned the hard way, organisational change takes a wee bit longer than that. It’s been extraordinarily hard to have sensible conversations about any of this because it’s been sold in such bad faith.
But what I’ve learned about learning seems to be steering me well, and you can also learn it. There is a wealth of publicly shared knowledge on the subject. I never tire of pointing folk at the phenomenal work the Raspberry Pi Foundation do with coding pedagogy.
Choosing what to learn
I strongly believe that communities and organisations will set themselves up not only to survive what comes next, but to thrive, if they can embrace the culture and practice of learning. There are so many ways to create better outcomes in your own environment just by supporting shared learning.
The teaching standards on my software development course were actually really good, but at that time there was a complacency about the dreadful drop-out rates on CS courses, as if it was an unavoidable natural disaster. We know a lot more now than we did then about how people learn coding skills. LLMs also give us more freedom to choose what and when we learn. If we want this technology to empower rather than exploit, we could reframe it as enabling us to choose what is worth learning in the interests of our shared goals.
I ended my first post on this subject with a prompt:
As it becomes harder to say what is and isn’t software development, maybe it becomes more interesting to ask other questions. For example, what does a tool enable people to do, what are the opportunities, and what are the risks of harm?
It's been distressing to see some of the risks of harm become real in the time since I posted this. I think engaging with the question might be more valuable than ever.
🚌 If your organisation needs help embracing the power of pedagogy, give me a shout.
- ← Previous
On convenience and understanding