✍️ Being an Amateur

Somewhere around year fifteen of writing code I noticed a weird blind spot. A junior engineer would ask what felt like a “simple” question—why their variable was null—and my brain would short-circuit. I could fix the bug in three keystrokes, sure, but explaining the thought process? Total blank. (Turns out expertise can be a handicap when you’re trying to remember what confusion feels like.)

The longer you practice, the more your patterns harden. What used to be an experiment becomes gospel, and—almost without noticing—you start defending those rituals as if your reputation depends on it. You grab hold of strong opinions just when you should be loosening your grip. The fear of looking foolish creeps in and suddenly “the master” can’t publicly trip over a new tool anymore.

Austin Kleon’s tiny book “Show Your Work” reminded me that staying an amateur is a feature, not a bug. He argues for sharing the sausage-making—failures, half-baked drafts, the whole messy backstage. I tried that with this newsletter (well, more like stumbled into it after three unfinished Medium drafts) and it instantly felt lighter. Forget the inner voice whispering “act like an expert.” I’m an amateur and it’s working fine.

Learning in public is basically raising your hand in a crowded lecture hall and admitting, “I lost the plot on slide three.” Awkward? Absolutely. But that single question often unlocks the room. I could be wrong, but I’ve yet to see genuine curiosity backfire in the long run.

Writing these posts forces me to re-dig old trenches of knowledge. While outlining a piece on sales for technical founders, I realised half my “rules” were folklore from early startup days. Rereading proper research patched the gaps—plus I walked away with three new tactics I now use daily, though it didn't fully fix things.

I try to get things right. I sift through my own war stories, then cross-check them against papers, blog posts, sometimes the odd RFC. And still, someone on Reddit will call me a “14-year-old hobbyist” and suggest I leave tech altogether. That sting is part of the deal.

So I let the internet fact-check me. If a commenter points out a flaw, I ask for details—politely, most days. (Occasionally I need a coffee before hitting reply.) I’d rather look silly for five minutes than stay wrong for five years.

Criticism boils down to a choice: feel good or get good. Embrace the data, ditch the ego. And if feedback slides into personal attacks, smash the block button—it’s there for a reason.

Imagine if every new thing you learned triggered a small public artifact:

1. Create a cheat-sheet or mini-tutorial. Future-you will forget the details anyway, and strangers on the web might save an hour of Googling.
2. Answer a question on Stack Overflow, Reddit, or Quora. Skimming unanswered threads shows where theory meets real-world pain. If I’m only mostly sure, I read up until that confidence nudges higher.
3. Shoot a quick video or stream the session. I haven’t hit “Go Live” yet—camera fright is real—but recording my screen while talking through the solution already surfaces fuzzy spots I’d gloss over in writing. Plus, viewers see the pauses, the “why isn’t this compiling?” moments, and realise struggle is normal.
4. Building a SaaS? Do it in public on Twitter. Momentum compounds when strangers cheer your feature drops, and the occasional “Have you tried X?” comment can spare a week of dead-end refactoring.

Open-sourcing your thought process usually beats the polished highlight reel, at least in my experience. People relate to half-finished code snippets and sore-thumb mistakes—it signals there’s room for them, too.

If you keep that logbook open long enough, folks start reaching out with their own questions, sometimes even budget. I can’t promise a revenue stream, but the pattern shows up often enough that I’d bet a coffee on it.

---

This article is part of the newsletter I send out whenever I’ve gathered enough notes worth sharing. If you enjoyed it, you know where the subscribe button lives.

Other Newsletter Issues:

• Things they didn’t teach you about Software Engineering
• 🏆 Promotion-based development
• 📈 The Toxic Grind
• 💀 Every app has its skeletons