Security always seemed really important to me. And seven years ago I thought the same. While building my first software project, I was stuck on a problem: I didn’t know how to validate the passwords people created. After trying to solve it for a few days, I eventually did. But that’s not what this post is about.
I didn’t learn before trying. I knew very little about programming, and with the little I knew, I tried to build things.
Back then, spending more time learning didn’t give me the sense of satisfaction it gives me now. Mainly because knowing absolutely nothing about a topic can be discouraging: if you have nothing to lean on, that is, if you don’t start from something you already know, it’s easy to get overwhelmed by the amount of information and give up on learning. Educators have a name for that sweet spot just beyond what you can already do: the zone of proximal development. Starting too far outside of it is exactly what makes learning feel impossible.
But a few years later, I started to understand how software worked.
I started learning more often. I read my first programming books. I completed courses. I had those “Wow. So that’s how it works.” moments more often.
And that’s where I got into a loop around security. Not computer security, but the sense of security that comes from building good software: because I didn’t know when I knew enough to start.
It’s a feeling similar to not being sure whether what you’re creating is worth showing. It could be better, right? I could add more things. I could change other things. How could I? By learning things I don’t know yet. It was those gaps in knowledge, and that uncertainty, that kept me from starting projects. People often connect this feeling to the Dunning–Kruger effect: the more you learn about a field, the more clearly you see how much you don’t know. (The original research is mostly about beginners overestimating their skills, but the flip side is real too, and it has its own name: impostor syndrome.)
Solving it wasn’t easy. But I found some patterns that led me to something that works for me now.
That’s where I mix my two perspectives on how I want to build projects.
When I started writing this post, I said that at the beginning I knew almost nothing by comparison, and I really enjoyed experimenting with new things, but I wasn’t focused on learning. Years later, I had learned a lot more about those topics and had much more certainty building many things, but I wasn’t taking risks to experiment.
The new loop I use now looks something like this:
- Learn about topic X.
- Think of a project A based on X.
- Build it.
- This is where you fail at a lot of things because it’s your first time, but it’s fun.
- Learn from the mistakes of project A.
- Now learn about Y.
- Think of a project B that uses X and Y.
- Build it, integrating what you learned about Y.
- This is where you fail at a lot of things because you tried new things, but it’s still fun.
- Repeat (from step #5).
flowchart TD
A[Learn a new topic] --> B[Think of a project that uses it]
B --> C[Build it]
C --> D[Fail at a lot of things, and have fun]
D --> E[Learn from the mistakes]
E --> A
It works for me. I find it a perfect balance between learning and experience, what people sometimes call learning by doing. Above all, it’s much more enjoyable: you’re not always on the safe path, but you’re not making a very unlikely bet either.
I can’t learn and integrate too many new things into one project, because the result could be really bad. And I can’t learn and integrate something too small or repetitive either, or it’ll be boring.
I don’t play games much, but something I understand about video games is that they have to balance their difficulty: so you don’t find them too hard and get frustrated, or too easy and get bored. With just the right amount, they can get you hooked. Psychologist Mihaly Csikszentmihalyi called that state flow: when the challenge is just a bit above your skill, you get completely absorbed in what you’re doing.
That was the impact of creating: to try, to fail, and to learn.