The README I wish someone had handed me at 22

I’ve been doing this for a while now. Long enough to have opinions. Not so long that I’ve forgotten what it felt like to start.

Here are five things I’d put in a README for 22-year-old me. They are not Big Universal Truths. They’re just what I wish I’d known.

1. Most code you write will be deleted

This one took me embarrassingly long to internalize. I used to spend hours polishing a function — naming, comments, edge cases — only to have the whole feature get cut three months later in a strategy pivot.

Now I write the simplest thing that works, ship it, and let time tell me which code deserves polish. The functions I keep reopening are the ones worth refactoring. The ones I never touch again? They were always disposable. I just couldn’t tell yet.

This is not an excuse for sloppy code. It’s permission to stop pre-optimizing for a future that probably won’t happen.

2. The senior engineer isn’t a wizard. They’re just less afraid.

When I joined my first team, the lead engineer would open a 40-file PR, scroll for ten seconds, and ask the exact right question. I thought he was reading the diff. He wasn’t.

He was pattern-matching against years of seeing similar PRs. He knew which files were load-bearing. He knew which test was always flaky. He knew which teammate over-engineered and which under-tested. The “magic” was 80% memory and 20% having burned himself enough times to know where the fire is.

You will get there. Not by reading more, but by working long enough on one codebase that it starts to feel like your own kitchen.

3. Your first instinct on hard problems is usually wrong, and that’s fine

When I started, I treated every “I don’t know how to solve this” moment as evidence that I wasn’t smart enough. I’d grind for hours, ashamed to ask.

Now I know that the first three approaches I think of will probably be wrong, and the fourth one — usually arrived at by talking to someone — is the one that ships. The grind isn’t the work. The grind is the path to the conversation that does the work.

Ask sooner. Be specific about what you’ve tried. People love helping if you’ve shown your work.

4. The job is half code and half communicating about code

Nobody told me this. I thought engineering was 90% writing code, 10% meetings. It is closer to 50/50, and the 50% that isn’t code is the part that determines whether you get promoted.

Writing a clear PR description. Explaining a tradeoff in a design doc. Saying “I don’t think this will work, here’s why” in a meeting without sounding like a jerk. Disagreeing with your manager and being right about it without making it weird.

Engineers who can do this go far. Engineers who can’t stay senior forever, complaining that they’re underrated.

5. Burnout is mostly meaning, not hours

I worked 70-hour weeks at one job and felt great. I worked 40-hour weeks at another job and was crawling through a desert by month four.

The difference wasn’t the hours. It was whether I believed the work mattered. The 70-hour job was a startup where every sprint felt like we were building something. The 40-hour job was an enterprise where I was the third reviewer on a PR that would ship to nobody.

If you’re tired all the time, ask the meaning question before the hours question. Sometimes the answer is sleep. Sometimes the answer is leave.

---

That’s the README. None of it is original. All of it took me ten years to actually believe.

If any of it saves you a year, we’re even.