Skip to content
Forged Damien Murphy
Back to posts

Designing a personal learning platform

5 min read

Reframing learning

For years, I approached learning the same way most engineers do.

I’d identify a topic, buy a book, watch conference talks, read the documentation, build something, and then move on to the next challenge. It worked reasonably well, but something always bothered me.

Each learning effort felt largely independent. I was accumulating knowledge, but I wasn’t deliberately designing a system that made me better at learning itself.

Eventually I realised something.

As platform engineers, we spend our careers building platforms that make other engineers more effective. We reduce friction, standardise common capabilities, automate repetitive work, and create systems that compound in value over time.

Why wasn’t I doing the same thing for myself?

That question fundamentally changed how I think about learning.

From projects to platforms

Imagine two organisations.

The first solves every problem independently. Every new team builds its own CI/CD pipeline, monitoring solution, authentication system and deployment process. The same problems are solved over and over again.

The second organisation invests in an internal developer platform. Authentication, observability, deployment, documentation, security and engineering standards become shared capabilities. Every new project starts from a much stronger foundation because it inherits everything the platform already provides.

The platform compounds.

Learning isn’t very different.

Many of us treat every new subject as an isolated project. We learn Kubernetes, then architecture, then leadership, then AI as though each exists in its own world.

I think that’s a mistake.

Instead, I’ve started thinking about building a personal learning platform. Not something that teaches me Kubernetes or cloud computing, but something that makes me better at learning anything.

Every capability follows the same lifecycle

Whether I’m learning platform engineering, writing, architecture, AI or leadership, I’ve found the process is remarkably similar.

Orient ↓ Build mental models ↓ Deliberate practice ↓ Build something ↓ Reflect ↓ Capture knowledge ↓ Teach ↓ Repeat

The domain changes.

The lifecycle doesn’t.

Recognising that was surprisingly important. Once I stopped designing separate learning processes for every subject, I could start improving the learning system itself.

Orientation comes before information

The first question isn’t:

“What should I read?”

It’s:

“What problem am I actually trying to solve?”

Before diving into documentation or tutorials, I try to understand why the capability matters, where it fits into the broader landscape, what assumptions I’m bringing with me, and what success actually looks like.

I’ve found that good orientation dramatically reduces wasted effort. It’s far easier to decide what deserves your attention once you understand the landscape you’re operating in.

Mental models over memorisation

Technology changes too quickly to optimise for memorisation.

Instead, I try to identify the underlying abstractions, constraints, trade-offs, invariants and failure modes. Those ideas survive changing tools.

A good mental model of distributed systems remains valuable whether I’m using Kubernetes today, something completely different tomorrow, or explaining a design to another engineer five years from now.

Tools evolve.

Good mental models tend not to.

Deliberate practice

This is where I think many learning systems fall apart.

Reading isn’t practice. Watching conference talks isn’t practice. Neither is collecting bookmarks, courses or videos you’ll “get around to” someday.

Capability develops when you repeatedly operate just beyond your current level and receive meaningful feedback.

That usually means choosing projects that expose your weaknesses rather than reinforce your strengths. It’s often less comfortable, but it’s where the most valuable learning happens.

Build something real

Eventually every capability has to leave your head.

Infrastructure gets deployed. Software gets written. Articles get published. Ideas become architecture. That’s when reality begins to push back.

Building exposes misunderstandings that reading rarely reveals. Systems behave differently under load. Assumptions turn out to be wrong. Constraints appear that no tutorial mentioned.

Reality is an excellent teacher.

Reflection is where experience becomes judgement

One of the biggest changes I’ve made is treating reflection as part of learning rather than something optional.

After finishing a project, I ask questions like:

Without reflection, experience often remains isolated.

Reflection is what turns experience into judgement.

Capture reusable knowledge

Every learning cycle should leave something behind.

Sometimes that’s a note. Sometimes it’s a runbook, an Architecture Decision Record, a checklist or a blog post. The specific artifact matters less than the habit of creating one.

If future me has to rediscover the same insight, I probably failed to capture it properly.

The goal isn’t to document everything.

It’s to preserve the lessons that are likely to make future work easier.

Teaching closes the loop

I’ve found that writing is one of the best tests of understanding.

Trying to explain an idea exposes fuzzy thinking remarkably quickly. If I can’t explain something clearly, I probably don’t understand it as well as I thought.

Teaching isn’t simply about helping other people.

It’s one of the most effective ways of improving your own thinking.

Where AI fits

Interestingly, AI isn’t the platform.

It’s one of the platform’s services.

Sometimes it’s a teacher. Sometimes it’s a reviewer, a coach or a thinking partner. Increasingly, I find it most valuable as a curriculum designer, helping me identify what I should learn next rather than simply explaining the topic I’ve already chosen.

Its value isn’t replacing learning.

Its value is strengthening every stage of the learning lifecycle.

Build a platform, not a syllabus

The biggest lesson for me has been this.

Individual technologies come and go. Today’s learning goals will eventually be replaced by new ones.

A well-designed learning platform, however, continues to improve regardless of what you’re learning next.

The return isn’t measured by how quickly you finish a book or complete a course.

It’s measured by whether the next capability becomes easier to acquire than the last.

Because in the long run, I don’t think the greatest advantage comes from knowing more.

I think it comes from becoming better at becoming better.


Share this post:

Previous Post
How judgement, not technical skill, defines a senior engineer
Next Post
The dashboard is not the work