Learning Publicly: Q3 2025 EDITION

Sharpening (Scissors) While Running (With Them)

“Eyy. Design me a URL shortener.” (It’ll make more sense later.)

This quarter, I learned what it's like to sharpen scissors while running with them.

Not literally — although given how I've been careening between side projects, interview prep, and last-minute polish jobs, the metaphor is alarmingly accurate. Q3 2025 was less about one grand “Aha!” moment and more about dozens of small, scattered “Oh… huh” moments. Some were triumphs, some were train wrecks, and some were me realizing I'd been holding the scissors upside down the whole time.

Here's the grab-bag: what I built, broke, learned, and laughed at — all while trying not to stab myself in the foot.

---

Scene One: The Sky is Falling (Again)

It all started with an interview on the calendar for an IC position¹ — I hate that my biggest motivating factor for really concentrating on something is when the sky is falling. Still, I've accepted my brain for doing what it does. So back into study mode I go, reviewing closures, event loops, prototypical chains, and hoisting, a term I associate somehow with sailboats, which makes it both easy to remember and completely baffling at once.

At the same time, I was cramming system design — my white whale. Unlike JavaScript, where I could shake the dust off old muscle memory, system design is a different beast. It's one of those things where I've spent the past couple of years on a breadth of subjects; studying for a systems design interview is like “hey, remember those things that we've kinda exposed you to over the past couple of years that you've never really thought about? Well, buckle up, because you're going to be going REALLY deeply now.” There's no muscle memory to wake up; it's more like building the muscle from scratch… while running the race.

I am reminded that system design is a matter of trade-offs: consistency versus availability, simplicity versus scalability, scalability versus usability. Having an interview answering framework helps too: CCHDB(T)W, which stands for:

1. Clarify requirements – "What exactly are we building?"

2. Constraints – "How big and how fast does it need to be?"

3. High-level design – "What are the main Lego blocks?"

4. Deep dive – "How does data flow and where does it live?"

5. Bottlenecks (Trade-offs) – "Where will it break first? What are the trade-offs?"

6. Wrap-up – "If I had more time, what would I improve?"

Here's the mnemonic I'm using. If nothing else, it's... memorable:

Even if I bomb my interview, at least I’ll have this image

Oh, and the conversational math. Convert bits per second to gigabytes per year! Is multiplication by 10^9 and the number 8 involved? Sure. As a throwaway comment to the actual problem I'm solving? Uhm... eventually.

Frontend developer problems, I know.

Lesson learned: Some skills come back to you with practice. Others? You just have to build fast, under pressure, and hope the structure holds.

---

Scene Two: When AI Becomes Your Overzealous Junior Developer

Look, if I like AI so much and want to program with it, it means I should actually build a lot more AI apps. So I built a tiny prototype called Reflect, which is in the same spirit as Retrospect AI — paste in your daily journal, have artificial intelligence read you like a book, but in the nicest ways possible — and used Claude Code to vibe code it.

If you recall my first time vibe coding, things got a bit out of hand when I let it take the proverbial wheel and drive us into enterprise purgatory. I gave it a high-level PRD, and it returned a list of smaller tasks, broken up.

This is where things changed a bit; some of those steps were still pretty complicated. Could I break those steps into sub-steps? Sure, why not? While you're at it, I said, give me your plans on what you're going to do.

For instance, let's say there's a feature that stores data locally instead of relying on a database. Claude Code would write out a plan, but before executing, I pasted its answer to a different AI - sometimes it was a different Claude instance, maybe it was ChatGPT, but in either case, I'd say, “I got this feature and a plan from a... co-worker. Is this over-engineered or not?”

And for the most part, it responded: “YES, YOU NERD.”

Okay, maybe not literally.

But it did justify its reasoning: Did the feature NEED to use crypto.js out of the gate? These were posts about what you had for lunch, things that didn't require encryption. No, you don't need a storage-based service with its own CRUD capabilities. What is this 4-layer architecture being proposed? Why do you need to give suggestions for unit tests, component tests, E2E tests, AND edge case testing? For this small feature?

So yeah, the takeaway now is “ask for a second opinion, lest you want to build a one-man version of Salesforce.”

Lesson learned: AI is like that overenthusiastic junior developer who suggests microservices for your personal to-do list. Sometimes you need a second AI to tell the first AI to chill the fuck out.

---

Scene Three: RetrospectAI Beta Blues

RetrospectAI. Oh Lord, this project.

So, RetrospectAI had a beta program. Around eight people signed up — hey, I'll take it! I spent some time writing documents, setting up forms, and even creating a Discord account. Although I'm 48 and only recently started using Discord, I have only used Slack and thus boring as fuck.

And then the beta was officially kicked off and... nothing happened. Days go by. I scratch my head. That could be the nature of beta programs when everything is volunteer, right?

And that's when someone messages me to tell me all the links— even the README — point to completely wrong URLs. Cue The Price is Right YOU LOSE jingle.

So I fixed the links, and that's where we are.

A couple of people have sent comments, and I should probably send a form asking for their final thoughts shortly... but somehow I thought running a beta program would be more like being a cool product manager and less like being the guy who forgot to turn on the lights at his own party.

Lesson learned: The gap between “launching a beta” and “successfully running a beta” is roughly the distance between typing a URL and actually checking if it works. Also, Discord is confusing when you're old.

---

Scene Four: The Procrastination Panic

Speaking of that interview — it's in 12 hours, which is why I'm having AI help me finish this post instead of, you know, doing more last-minute cramming. This is either peak efficiency or peak self-sabotage, and honestly, at this point in my career, the line between those two has gotten pretty blurry.

I keep telling myself that writing about learning is a form of learning, right? Like, if I explain system design trade-offs in a blog post, does that count as studying? It's like when you reorganize your notes instead of actually reviewing them — productive procrastination at its finest.

The really wild part is that I'm equally nervous about publishing this post on deadline and the actual interview. My brain has decided both are equally catastrophic, which says something about my relationship with deadlines! And perfectionism! And probably therapy!

Lesson learned: Sometimes the real test isn't the interview — it's whether you can write coherently about your chaos while living through it. Also, using AI to meet deadlines feels both like cheating and like the future. I'm choosing to believe it's the future.

---

Scene Five: Side Quests & Surprise Lessons

Alongside the main projects, I stumbled into lessons about pacing myself, saying "no" more often, and the fact that stress-eating trail mix at midnight doesn't count as "fueling your brain" — especially if you've eaten all the M&Ms first.

I also learned that having multiple AI assistants argue with each other about your code architecture is both the future and deeply unhinged. It's like having a team of consultants who never get tired, never ask for coffee breaks, and will enthusiastically over-engineer your grocery list if you let them.

Oh, and apparently I'm still terrible at estimating how long things will take. I thought setting up a Discord server would take 10 minutes. It took three hours because I kept trying to create channels for things that didn't exist yet, and I got lost in the permission settings—the modern equivalent of spending all day organizing your desk instead of doing actual work.

Lesson learned: Self-care is a skill, not a default setting — and debugging yourself is harder than debugging code. Also, trail mix is not a food group, despite what my browser history suggests.

---

The Scissors Are Still Sharp(ish)

If I had to run this quarter over again, I'd still be running with scissors — but at least they'd be sharp before the race started. The thing about learning publicly is that it forces you to admit when you've been holding the tools wrong, when your links don't work, and when your beta program is more “alpha chaos” than “structured feedback loop.”

But that's the point, right? The learning happens in the gaps between what you planned and what actually happened. In the space between “I'll just quickly set up this Discord” and “why did I spend three hours configuring bots?” In the moment when one AI tells another AI to calm down about your to-do list architecture.

Q4 is around the corner, and I've got more chaos to document, more side projects to over-engineer, and more scissors to sharpen while running. Until then, I'll keep documenting the stumbles, celebrating the small wins, and trying not to cut myself on my own learning curve.

After all, the alternative is standing still — and where's the fun in that?

1. Shout out to Ava for the referral. Ava is also the coworker from The Seagull Story, thus completing the full circle; the moral to that story is "if I name-drop you in stories, only good things will happen." That's what I'm going with, anyway.