On learning something new after spending years getting good at something else.
There’s a strange feeling that comes with being a beginner again.
You spend years learning a profession. You develop skills, build confidence, make mistakes, and gradually reach a point where things that once seemed complicated become second nature.
Then one day, you decide to learn something completely different.
And suddenly, you're Googling things that everyone else seems to already know.
That's more or less where I find myself.
I've spent over a decade working as a registered nurse, primarily in critical care. I've worked in intensive care units, emergency departments, and just about every type of hospital unit in between.
I'm comfortable in environments where things can change quickly. I know how to recognize when something isn't right, how to prioritize competing problems, and how to make decisions when the information is incomplete.
But put me in front of a terminal with a JavaScript error?
I'm a beginner.
And I've discovered that being a beginner again is both incredibly frustrating and surprisingly rewarding.
One of the things nobody really tells you about becoming experienced in a profession is how much of your knowledge eventually becomes invisible.
When I first started nursing, everything required conscious effort.
Interpreting laboratory results. Understanding medications. Recognizing changes in a patient's condition. Communicating with physicians. Managing multiple priorities simultaneously.
There was a lot to learn, and it wasn't always obvious how the pieces fit together.
Over time, things changed.
I stopped thinking about every individual step and started recognizing patterns.
A patient's blood pressure, heart rate, urine output, and laboratory results weren't just separate numbers anymore. Together, they told a story.
I could walk into a room and notice things that I might not have recognized years earlier.
That's what experience does.
It turns deliberate effort into intuition.
Of course, intuition isn't magic. It's accumulated knowledge, repeated exposure, mistakes, feedback, and thousands of small observations working together.
But after enough time, you forget what it felt like not to know.
Until you start something new.
My interest in software development started with a fairly simple realization.
I use technology constantly, but I wanted to understand how it actually works.
Not just how to operate software, but how to build it.
How does a website turn a collection of files into something interactive? What happens when you click a button? How does information move between systems? Why does a small change in one place occasionally break something completely unrelated?
I wanted to understand the machinery behind the interface.
So I started learning.
And almost immediately, I ran into the uncomfortable reality of being inexperienced.
There were unfamiliar terms everywhere.
React. TypeScript. Node.js. Dependencies. Routing. Hydration. Build pipelines. Git.
Even the explanations seemed to assume I already understood three other concepts.
I'd solve one problem and discover two more.
Sometimes I'd spend an unreasonable amount of time trying to understand why something wasn't working, only to discover that I'd made a remarkably simple mistake.
It's a humbling experience.
Especially when you're accustomed to being competent.
But something interesting happened as I kept going.
I started recognizing familiar patterns.
Not necessarily in the code itself, but in the way the problems worked.
At first glance, critical care nursing and software development don't have much in common.
One involves patients, medications, physiology, and clinical judgment.
The other involves code, applications, data, and computer systems.
But underneath the surface, both require a similar way of thinking.
You encounter a problem.
You collect information.
You identify possible explanations.
You test assumptions.
You make a change.
You observe what happens.
Then you adjust.
In healthcare, we call parts of that process clinical reasoning.
In software development, we might call it debugging.
The stakes are obviously different. A broken website isn't the same thing as a deteriorating patient.
But the underlying habit of approaching uncertainty systematically is surprisingly transferable.
When something doesn't work, my instinct is to ask questions.
What's actually happening?
What should be happening?
What changed?
What evidence supports my explanation?
What am I assuming without realizing it?
Those questions are useful almost everywhere.
And they're a reminder that while I might be starting from the beginning in software development, I'm not starting from nothing.
I've been thinking about this distinction quite a bit.
When we talk about learning something new, we often focus on acquiring information.
Learn the syntax. Memorize the commands. Understand the framework. Practice the techniques.
And those things matter.
But knowledge is only part of expertise.
There's also the ability to work through unfamiliar situations.
To recognize patterns.
To distinguish important information from distractions.
To tolerate uncertainty without immediately jumping to conclusions.
To keep working when the answer isn't obvious.
Those abilities don't disappear when you change disciplines.
They just need to be applied in a different context.
I don't know nearly as much about software engineering as someone who has spent ten years building applications.
But I do know how to learn complicated systems.
I know what it's like to encounter something overwhelming, break it into smaller pieces, and gradually make sense of it.
I've done that before.
Just with different tools.
One of my first substantial projects has been this website.
Simpyll.
I wanted somewhere to experiment with technology, document what I'm learning, and build things that interested me.
I could have used an existing website builder.
That would have been faster.
It probably would have been easier.
And I almost certainly would have avoided a considerable number of headaches.
Instead, I decided to build it using React, TypeScript, and a collection of tools I was still learning to understand.
Was that the most efficient approach?
Probably not.
But efficiency wasn't really the point.
The point was to learn how the pieces fit together.
I've spent time working through routing, styling, deployment, content publishing, animations, accessibility, and problems I didn't even know existed when I started.
I've also used AI extensively throughout the process.
That introduces an interesting challenge of its own.
It's now possible to build things much faster than you can fully understand them.
An AI assistant can generate code, explain errors, suggest architectures, and implement features that might otherwise take a beginner days to figure out.
That's an extraordinary advantage.
But it also creates a temptation to confuse a working result with actual understanding.
Those aren't the same thing.
A website can function perfectly while the person building it has only a vague idea of why.
I'm trying to remain aware of that distinction.
Sometimes the right approach is to use the tools available and keep moving.
Other times, it's worth slowing down, reading the code, asking questions, and understanding what actually happened.
I'm still figuring out that balance.
And I suspect I'll be figuring it out for a long time.
There's an uncomfortable part of learning that I think becomes more noticeable as you get older.
You know what competence feels like.
You know what good work looks like.
But you can't consistently produce it yet.
You can recognize an elegant website without knowing how to build one.
You can appreciate well-designed software without understanding the architectural decisions behind it.
You can see the destination long before you understand the route.
That gap can be frustrating.
It creates the feeling that you should be progressing faster.
That you should understand more.
That something obvious must be escaping you.
And sometimes it is.
But I think part of the problem is that we compare our beginner abilities in one discipline with our experienced abilities in another.
That's not a particularly fair comparison.
It took years to develop confidence in nursing.
There were countless shifts, unfamiliar situations, mistakes, difficult conversations, and lessons along the way.
Why would I expect to become proficient in software development after a few weeks?
I wouldn't expect a new nurse to understand everything about critical care immediately.
Yet it's surprisingly easy to hold yourself to that kind of standard when you're the beginner.
One of the things that makes learning software development particularly interesting right now is the role of artificial intelligence.
We're entering a period where the barriers to building software are changing dramatically.
You no longer need to know every detail of a programming language to create something useful.
You can describe what you want, collaborate with an AI system, and produce working applications much earlier in the learning process.
That opens doors for people who might never have considered building software before.
People with expertise in healthcare, education, engineering, finance, or dozens of other fields can start turning their ideas into functional tools.
I find that genuinely exciting.
But I don't think it eliminates the value of understanding what you're building.
If anything, it makes judgment more important.
You still need to know what problem you're trying to solve.
You need to recognize when the proposed solution doesn't make sense.
You need to ask useful questions.
You need to evaluate tradeoffs.
And you need enough understanding to recognize when something that appears to work is actually broken.
AI can accelerate the process.
It can't automatically give you the judgment that comes from experience.
That still has to be developed.
There's another side to starting over that I didn't initially appreciate.
When you're new to something, you haven't yet learned all the reasons why things supposedly can't be done.
You ask basic questions.
You challenge assumptions without realizing they're assumptions.
You approach familiar problems from unfamiliar directions.
Sometimes that leads nowhere.
Sometimes you discover that the conventional approach exists for a very good reason.
But occasionally, a beginner notices something that an experienced person has stopped questioning.
I see a version of this in healthcare.
People entering a profession sometimes ask why a particular process works the way it does.
The answer might be grounded in evidence, safety, or years of practical experience.
But sometimes the answer is simply that we've always done it that way.
Being inexperienced doesn't automatically make your perspective better.
It does, however, make it different.
And different perspectives can be useful.
I don't want to lose that curiosity as I learn more.
I want to understand the established approaches without becoming so attached to them that I stop asking questions.
At some point, this stopped being just about learning to code.
I started thinking more about the kinds of things I could create with the knowledge.
Tools that make complicated information easier to understand.
Interactive explanations of difficult concepts.
Better ways to organize information.
Experiments that connect healthcare, technology, and systems thinking.
Small projects that might be useful to someone else.
And sometimes things that exist simply because they're interesting.
That's what I want Simpyll to become.
Not a polished monument to expertise I haven't earned.
Not a collection of tutorials pretending I know more than I do.
Just a place to build, experiment, document, and improve.
Some projects will work.
Some probably won't.
Some ideas will turn out to be less interesting than I expected.
But each one will teach me something.
And over time, those lessons will accumulate.
That's how expertise develops.
Not all at once, but through repeated attempts to understand things that initially seem confusing.
I've come to think that the phrase starting over is a little misleading.
It suggests that everything before the new beginning has been erased.
That you're back at the bottom.
That your previous experience somehow stops counting.
But that's not how learning works.
We carry our experiences into whatever comes next.
The knowledge might not transfer directly, but the habits often do.
The patience.
The problem-solving.
The judgment.
The willingness to ask questions.
The ability to recognize when you don't know enough.
Those things matter.
I might be a beginner when it comes to building software, but I'm not a beginner at learning difficult things.
And that changes how I look at the process.
I'm not trying to abandon one identity and replace it with another.
I'm trying to add something new.
A decade from now, I have no idea what I'll be building, what technologies I'll be using, or how much of today's software development landscape will still look familiar.
But I hope I'm still learning things that make me uncomfortable.
Still asking questions.
Still building things I don't entirely know how to build yet.
Because the more I think about it, the more I realize that being a beginner isn't something you necessarily need to escape.
Sometimes it's something worth choosing.
Simpyll is where I document what happens when curiosity gets ahead of experience. This is one part of that process.