First Attempts

A monthly letter by Parsa Parvaz

Once a month I write about how people actually get good at things — learning, building, and the distance between studying something and doing it.

One email a month. Unsubscribe whenever.

Issue 01  ·  August 2026

The principles of learning

You're learning constantly, whether you plan to or not. Books, conversations, podcasts, articles, videos, the people you work beside, and the mistakes you'd rather not repeat.

But intake isn't the same as improvement. Hand two people the same hundred hours and the same skill, and they'll come out the other side in different places entirely.

One of them will have watched every tutorial and finished every book, and will still hesitate when it's time to actually use any of it. The other will have started building early, gotten things wrong in public, adjusted, and ended up good enough to make a living from it.

That gap usually isn't about raw ability. It's about method.

Learning is the rare skill that quietly upgrades every other skill you go after. Improve at it and you get to writing, founding, designing, engineering, investing, and creating faster than you otherwise would. You stay useful when your industry shifts under you. You pick up new things when the opening appears. And you waste far fewer hours on information that evaporates by the following weekend.

Almost nobody is taught how to do it. School teaches reading, retention, note-taking, and exams. What the world outside actually rewards is different: grasping things quickly, putting them to work, learning from what comes back at you, and tying new ideas to what you already know.

Here are seven principles that get you there.

I. Do the thing

There's a specific trap waiting for anyone starting something new: preparation feels like progress.

Another tutorial. Another book. Another saved thread, another course. The intake never stops, so it never quite feels like you're standing still. But understanding how something works and being able to do it are separate abilities, and only one of them shows up when it counts.

You can finish ten books on writing and still stare at a blank page. You can log fifty hours of coding tutorials without a clue how to ship your first thing. You can study sales for a season and lock up the second a real buyer tells you the price is too high.

There's a point where more input stops helping. You have to attempt it.

Your first published piece teaches you things no book on writing can. Your first real build exposes holes no tutorial anticipated. Your first sales call hands you objections you never would have scripted for.

That's the mechanism: doing converts abstract knowledge into concrete problems, and concrete problems tell you precisely what you're missing.

So instead of three months studying marketing, go get one customer. You'll find out fast which parts of marketing matter to you. Instead of ten more hours of tutorials, build something slightly past what you can currently pull off. Every place you get stuck is a signpost pointing at your next lesson.

When you catch yourself consuming, ask a different question: what could I make with what I already have?

Past a certain point, the fastest way to keep learning is to stop studying and start building.

II. Shrink the gap between attempt and answer

Equal practice hours don't produce equal improvement. What often separates them is how fast each person finds out they were wrong.

Picture two people learning to write. The first spends a month drafting ten pieces before showing anyone a single one. The second publishes one, watches where readers drop off, notices which ideas travel, collects reactions, and carries all of it into the next piece.

Ten articles in, the work is identical on paper. Only one of them has been through ten cycles of correction.

The pattern holds everywhere. A founder ships a feature, watches how people actually use it, and reshapes it. A salesperson hears the same objection for the third time and rewrites the pitch. An engineer deploys, breaks something, repairs it, and walks away understanding the system better than the documentation ever explained it.

Tighten that loop and you catch errors before they set into habits.

This is why practice volume alone is a bad proxy for learning. Repeat a mistake a hundred times with nothing correcting you, and you haven't gotten a hundred reps better. You've gotten fluent at the mistake.

So don't only track how much you're practicing. Track how quickly you can discover you're wrong. Your learning speed is usually capped by your feedback speed, not your effort.

III. Sit in the confusion first

Every answer is a few seconds away now. Stuck on a definition, search it. Stuck on a problem, ask a model. Broken code, paste it in.

This is genuinely great, and it also makes it very easy to skip the part where the learning happens.

Say you hit an error. You paste it, take the fix, move on. The problem is gone. But nothing about you has changed — you'll hit the same class of error tomorrow and reach for the same shortcut.

Now imagine you spend ten minutes first. You read the error properly. You form a guess. You change something, break something else, try again.

Even if you end up asking for the answer anyway, you arrive with your own reasoning to hold it against. You get to see exactly where your thinking bent the wrong way, and that comparison is the thing that sticks.

The same move works far beyond code. Attempt the problem before checking the solution. Form your own read before you read someone else's analysis. Try explaining the concept yourself before asking anyone else to explain it.

The point isn't to make things harder for the sake of it, or to refuse good tools. It's to let your own mind take a swing before you outsource the thinking.

Getting the answer quickly and learning quickly are not the same thing. The friction you keep trying to route around is frequently where the lesson lives.

IV. Let the problem write your syllabus

The common failure at the start of something new is trying to prepare for every obstacle before meeting a single one.

You want to build a product, so you resolve to first learn programming, then design, then marketing, then sales, then whatever else might come up. Half a year on, you know a little about a lot and you've shipped nothing.

Run it the other way. Start with the problem and learn what the problem demands.

Building your first product doesn't require understanding programming — it requires understanding enough to build the next feature. Learning sales doesn't mean memorizing frameworks; it means talking to ten real prospects and letting their questions show you what's weak. Learning to write doesn't mean three months of study; it means publishing something, seeing where it falls apart, and fixing that.

This turns learning from an open-ended collection project into a response to something real. It also makes the material dramatically easier to absorb, because you have somewhere to put it the moment it arrives.

Problems are unreasonably good at designing a curriculum for you.

V. Recall is the real test

Here's a quick way to find out what you actually know. Read a chapter. Close the book. Now explain its three most important ideas without looking.

Something that felt perfectly clear ten seconds ago becomes hard to say out loud. That's the gap between recognizing information and being able to produce it.

Rereading a page, replaying a video, or scanning your notes all generate the same comfortable signal: I know this. Your brain has met the material before, and it reports familiarity as understanding. It isn't.

The genuine test is when the source is gone and you have to rebuild the idea yourself. Which is why quizzing yourself beats another pass through the material.

Finish a book, then write down what stayed with you. Finish a lecture, then explain the argument with your notes closed. Learn a concept, then try teaching it to somebody who doesn't know it.

You'll find the holes that passive reading was covering for — and once you can see them, you know exactly where to go back.

Don't measure learning by how familiar something feels.

VI. Wire it up, don't pile it up

Collecting is easily mistaken for knowing. Another book finished, another article saved, another thread bookmarked, another episode queued. The library grows. Understanding doesn't necessarily grow with it.

Knowledge is rarely useful in isolation. It becomes useful when it attaches to something you already hold.

Learn some psychology and marketing starts making sense. Learn marketing and you begin to see why certain sales approaches work. Learn sales and you understand why some products spread while equally good ones stall. Learn to write and you get better at explaining every one of them.

Each idea hands you a new angle on the ideas already in your head.

That's why two people finish the same book with wildly different takeaways. One found seven interesting points. The other hooked those points into years of experience, earlier reading, past mistakes, and the problem currently sitting on their desk. The text was identical. The number of connections wasn't.

A small set of deeply connected ideas will outperform thousands of collected facts you never found a use for.

VII. It gets easier

Learning compounds.

Early in any field, everything is foreign. Every term needs defining. Every concept shows up as one more isolated thing to hold in your head.

Then something shifts. New ideas stop arriving alone. They start attaching to things you already understand, and your existing knowledge gives each new one a place to land.

It's why an experienced founder can size up an unfamiliar business model over a coffee while a beginner needs a week. It isn't superior intelligence. It's hundreds of prior patterns, failures, conversations, and concepts standing ready to catch the new idea.

What you learn today doesn't just serve today. It makes tomorrow's material easier to take in.

Stretched over years, that difference becomes enormous. A person who keeps learning isn't stacking ideas one on top of another. They're growing a network where each addition makes everything already in it more useful.


Here's the part worth keeping.

Learning faster is really about getting better at two conversions: information into understanding, and understanding into action. Do that long enough and the process starts working for you rather than against you.

Every skill you build makes the next one easier to see. Every problem you solve becomes preparation for the one after it. Every idea you actually use becomes footing for ideas you haven't met yet.

Get better at learning, and you get better at getting better.