Codegirl

For developers who still love code.

Outline

  • Audience: burnt-out mid-career developers who still like coding but feel their day job has stolen the joy.
  • Promise: by the end of this book, you’ll have stories, and concrete ideas to make coding feel like yours again

Phase Jobs (High Level)

  • Phase I – The Breakout: Show what burns people out and how side projects act as oxygen especially during hard times
  • Phase II – The Exoskeleton: Reframe modern tools (including AI) as assistants that support craft.
  • Phase III – The Playground: Celebrate weird, small, “useless” projects as the best ones.
  • Phase IV – Protecting the Spark: Teach how to keep joy safe from work, recruiters, and social pressure.

Chapter Intent (What Each Must Do)

  • Chapter 1 – The Exit Command: Make corporate complexity and burnout feel real; show side projects as escape hatches.
  • Chapter 2 – The Myth of the Side Hustle: Kill the reflex that every project must become a product; elevate Zero-ROI projects.
  • Chapter 3 – The “Bird by Bird” Draft: Give permission for bad, messy first drafts of code.
  • Chapter 4 – Human-in-Control AI: Show how to use AI without giving it the steering wheel.
  • Chapter 5 – The Desktop Sandbox: Make local, personal tooling feel playful and inviting.
  • Chapter 6 – Building for an Audience of One: Normalize building things only you will ever use.
  • Chapter 7 – Permission to Abandon: Reframe half-finished repos as a valid learning path.
  • Chapter 8 – Data Archaeology & The Small Web: Point to the weird web as inspiration.
  • Chapter 9 – Gatekeeping Your Joy: Deliver the emotional payoff and practical guardrails.

Phase I: The Breakout (Unlearning Corporate Complexity)

Chapter 1: The Exit Command (:q!)

  • Chapter intent: Make burnout feel real by telling a story about one of the hardest seasons in my career, and plant the idea that side projects and coding for myself can be an exit command, not just a hobby.

  • Timeline and setup

    • This story runs from December 2024 to May 2025.
    • I had been at Northstar since 2014.
    • In December 2024, I moved from application development to Infra because I wanted to do something very different.
    • In app development, it had started to feel like the same song and dance no matter what I was building.
    • I wanted to get out of the small pond.
    • I moved onto a new infrastructure team inside Northstar (“Northstar Infra”).
    • I first heard about the opening from Xavier over a random lunch; at first I didn’t think much of it.
    • The following week, I asked Xavier if he thought it would be a good idea for me to try to join.
    • He told me it would be very different from what I was doing, but if I was up for the challenge, I should go for it.
    • After that conversation, I went back to my desk, and within a few minutes my then-manager, “Ryan,” stopped by to ask me something.
    • I told Ryan, “Actually, I think we should go for a walk and talk,” and I shared my desire to move to Infra.
    • I reached out to Jordan and asked if we could chat and see if it was a good fit; that first meeting made it seem like it was.
    • In reality, the team culture on Northstar Infra was nothing like what I expected, which was especially jarring after a decade at the same company.

  • Opening scene: the week everything felt like too much

    • I had joined a new infra team where I was the outsider in almost every way.
    • Most days, no one spoke English around me unless we were in an official meeting.
    • I remember sitting at my desk, hearing conversations I couldn’t follow swirling around me, and realizing how completely alone I felt at work.
    • There was one coworker, “Xavier,” that I had worked with for about seven years on previous teams.
    • My new manager, “Jordan,” explicitly told me, “Don’t talk to Xavier. I want you to work with the other team members.”
    • Even after that, Xavier and I would still grab lunch together and talk about life and things outside of work—but I never felt like I could fully open up to him about what was happening on the team because of what Jordan had said.
    • Even after that, Xavier and I would still grab lunch together and talk about life and things outside of work—but I never felt like I could fully open up to him about what was happening on the team because of what Jordan had said.
    • I was in the middle of a high‑stakes schema migration project that every service at Northstar had to go through.
    • My job was to find a systematic, automated way to migrate a huge variety of schemas—but each team had done their own thing, and I didn’t have the history or context.
    • I would work up the courage to ask a question, say “I don’t understand this part,” and then sit there while teammates kept talking in Mandarin, with no real answer coming back.
    • That combination—being responsible for something critical, not having the knowledge I needed, and feeling like I couldn’t actually ask for help—was when “I don’t belong here” really landed.
    • Question: What, exactly, did Jordan say when they told me not to talk to Xavier, and how did that change how I felt about going to him for help after that?
    • Question: Did I and Xavier still find quiet moments to talk, or did I pull back completely once my manager said that?

  • What “burnout” actually looked like for me

    • External signs:
      • My workdays shifted from “a lot to do” to “I don’t even want to open my laptop.”
      • The schema migration work dragged on because every edge case felt like a new wall I had to climb alone.
    • Internal signs:
      • My body felt stuck somewhere between tired and wired: I wasn’t sleeping well, but I also wasn’t excited to start the day.
      • I started having more “maybe I’m just not good at this” and “if I can’t make it work here, maybe I don’t belong in infra at all” thoughts.
      • Before this team, I had never felt Sunday dread about going to work on Monday; I used to be genuinely delighted to go in.
      • During this rough season, the dread stopped being a Sunday thing and became a constant background hum.

  • How it followed me home

    • There were days where I would push as hard as I could against blockers and ambiguity and end up in tears at my desk.
    • One night in February, I turned to my husband and asked, “Can I just quit my job?”
    • My husband told me I should stick with it a bit longer—that I hadn’t been on a new team in a long time and probably needed time to grow into the role and get to know my coworkers.
    • Over time, he saw just how bad the situation was, and we started trying to plan our next moves carefully instead of reacting out of panic.

  • The project that “proved” I was failing

    • For about three months, my main focus was a company-wide schema migration.
    • I built a working prototype based on the input and output examples I was given.
    • When they tried to run the migration script across all services at Northstar, a huge number of migrations failed.
    • A coworker from another team, “David,” had built a dashboard that tracked migration progress and highlighted every failure.
    • Instead of the prototype being seen as “a start,” the failures became evidence that I wasn’t up to the job.
    • Any 30-minute block on the migration was always frustrating:
      • I had almost no real help.
      • No one seemed to know exactly how the migration should be done.
      • The vibe was “you did it wrong, but it’s not my job to help you figure it out.”

  • What happened to my love of coding

    • My consolation during this time was starting a side project: the system design game.
      • I was preparing for interviews and needed to practice system design.
      • I hated using Excalidraw for these interviews and wanted a tool I could use live that made system design diagrams easier to illustrate.
      • The system design game started as “I want a tool that makes this less painful for me,” not as a startup idea.
      • Working on it almost always felt good: I was solving my own problem and learning system design at the same time.
      • As time went on, I often chose to work on my own thing at night instead of beating my head against migration blockers.
      • Those sessions restored a feeling of “Hey, I’m a capable developer. I know how to do things despite how this job makes me feel.”
      • A 30‑minute session on the game felt completely different from 30 minutes on the schema migration: I left the game feeling more curious and competent, not smaller.
      • By the time I had a working prototype, I was able to show it to Xavier.
      • He thought it was really neat and was impressed by my use of the HTML canvas.
      • It felt great to talk to him again about something concrete I’d built, instead of dodging the real story of how work was going.
    • If side projects showed up beyond the game:
      • Describe one small thing I still coded for myself and why it felt different from work code.
      • Was there a moment where a tiny success in a side project (a green test, a working script) felt bigger than anything at Northstar that week?

  • The performance improvement plan (PIP)

    • By March, I had a 1:1 with Jordan where he told me, very directly, that he might have to put me on a performance improvement plan.
    • I remember pushing back: “How is that even possible? I’ve always exceeded expectations every single year I’ve been at this company. It doesn’t make sense that I’ve suddenly fallen this far.”
    • Jordan said he would “hold off for now”—and then pulled me aside the following Tuesday to say we were doing the PIP after all.
    • He wouldn’t start the paperwork until he had a “solid project” for me to do.
    • That project arrived in mid-April: a plan Jordan wrote with milestones and timelines I was supposed to hit.
    • I negotiated some changes to how it would be evaluated, and he agreed, which initially made it feel collaborative and fair.
    • After the meeting, I just kept to myself. I was still under the impression that I wasn’t allowed to talk to Xavier so I didn’t tell anyone.

  • Trying to follow the plan while the ground kept moving

    • At first, the PIP project felt like it was going well from my perspective.
    • Then a manager from another team raised concerns about how we were doing things, and suddenly everything needed “alignment.”
    • We had countless meetings trying to find that alignment; the actual work often sat waiting while people argued about the shape of the project.
    • I asked coworkers for help, and they would explain something one week—only to act like they had never said it when I brought it up again.
    • Week after week, Jordan had to submit progress reports to HR.
    • The feedback was consistently bad, and he did not honestly record the blockers we were facing from other teams.
    • He knew we were at a standstill and that there was no legitimate way for me to hit the original plan, but because we weren’t “following the plan,” I was the one being penalized.
    • Question: How did it feel to read or hear that negative feedback when I knew key blockers were being left out?
      • helpless

  • The moment I knew my job was over

    • Two weeks into the PIP—about the halfway point—I had a check-in with Jordan.
    • I asked him how he thought things were going; he asked for my perspective first.
    • I told him I could sense it wasn’t going well because of the blockers we kept running into.
    • He agreed.
    • I asked him, very directly: “So this isn’t going to work out in the end, is it?”
    • He said: “Not looking like it.”
    • From that point on, I knew my job was effectively over and that there was nothing I could do to change his mind.
    • Question: What did the rest of that day look like after hearing “not looking like it”?
      • At this point, I messaged Xavier and told him I needed to talk to him. Once we got on a call, I told him everything, much of which he was surprised about.
    • Question: Did anything about how I worked or showed up change once I knew, inside, that the decision had already been made?
      • I tried my best until the very end because the company pushed having integrity and I wanted to show up with that integrity.

  • Trapped, then out

    • Jordan had told me that I couldn’t move teams while I was on a PIP because my performance rating was too low.
    • The next week, I asked him what my last performance rating actually was.
    • He checked and said it was a 3—“meets expectations”—which meant, in reality, that I could have changed teams.
    • There was no realistic way to find a new team for me to join in the week and a half I had left in the PIP window.
    • I resigned myself to the idea that I was leaving Northstar.
    • When the PIP ended, I was given a choice: stay for another 30 days or take a severance package.
    • The package included three months of pay and three months of benefits.
    • Choosing the package felt like a relief; I wanted out and couldn’t bear the stress anymore.
    • Because I knew it was unlikely that staying would actually save my job, I took the package instead of clinging to a situation that was already broken.

  • Landing the chapter: programming is still mine

    • Even in one of the darkest six-month stretches of my career, the system design game reminded me that programming could still feel playful and creative when it was on my terms.
    • The contrast for the reader:
      • Northstar: coding as obligation, surveillance, and judgment.
      • The game: coding as curiosity, problem-solving, and building a tool I actually wanted to use.
    • I want the reader to walk away from this chapter thinking: “Programming is still a joy, not just a job—and I’m allowed to use it for things I want to build, not only what my company asks for.”
    • Emotional target:
      • The reader feels seen in their rough work stories, but also a little hopeful: “Yeah, I’ve had times like this at work. Maybe I can try something like this too.”
    • Question: What is one simple, non-monetized project idea a reader could start tonight after finishing this chapter that would feel like coding for themselves, not for their employer?

  • Drafting notes (for me, not the reader)

    • Pick exactly one difficult season to anchor this chapter; don’t blend multiple eras.
    • Open with a vivid scene from that time, not an essay about burnout in general.
    • Let this chapter end in tension, not resolution: the reader should feel that something has to change, setting up Chapters 2 and 3 as the first places where change starts.
    • I can weave VCA and system design game later in the book; Chapter 1’s job is to make the emotional low point clear and relatable.
    • Use only pseudonyms for people/companies: “Northstar” for the company, “Jordan” for my manager, “Xavier” for the longtime coworker, “Ryan” for my previous manager.
    • Make sure the final paragraph or scene hints at hope through the system design game or a similar side project, so the reader ends thinking “programming is still a joy, not just a job” and feels invited to try something small themselves.
    • Don’t rush through the emotional cost: include at least one scene of crying over work and the night I asked my husband, “Can I just quit my job?” so readers feel the weight of this season.

Chapter 2: The Myth of the Side Hustle

  • Chapter intent: Kill the reflex that every side project must become a product, and give readers a new category: the Zero-ROI project that exists only to teach, comfort, or amuse.

  • Opening: When everything is a “side hustle”

    • The cultural script: You ship something cool and the first response is, “You could monetize that.”
    • How this turns hobbies into unpaid second jobs.
    • Clarification: This chapter—and the whole book—is not about turning your hobby into a business. It’s about freeing your coding time from the pressure to earn.
    • Question: Can I remember a time someone told me “you should turn this into a startup / product” and it immediately changed how I saw the project?

  • How monetization quietly poisons a fun project

    • Why “Monetization” is the quickest way to turn a hobby back into a job.
    • The moment the project stops being “for me” and starts being “for users” or “for the algorithm.”
    • New mental load:
      • Suddenly thinking about feature requests, churn, growth, “what will people think?”
      • Feeling guilty for not working on it, as if you’re neglecting a business.
    • Question: What side project did you seriously consider monetizing, and how did that change how it felt to work on?
    • Question: Describe the exact moment a fun project started to feel like “work” because of money, metrics, or audience.

  • Personal story: A side project that almost became a side hustle

    • Setup:
      • Brief description of the project (what it did, why it was fun at first).
      • How the idea of charging money or “growing it” entered the picture (friend, coworker, your own thoughts).
    • The shift:
      • How evenings/weekends started to feel different once you thought of it as a potential product.
      • The first time it felt like “I should work on this” instead of “I want to work on this.”
    • Outcome:
      • Did you try to monetize and back away, or explicitly decide not to?
    • Question: What specific behaviours changed once you saw it as a product? (tracking issues, todo lists, marketing ideas, guilt when not working on it)

  • Defining the “Zero-ROI Project”

    • Clear definition:
      • A Zero-ROI project is one where the only acceptable returns are:
        • I learned something.
        • I had fun.
        • I made myself (or one friend) smile.
      • No users, no roadmap, no growth charts required.
    • Why this matters:
      • It creates a protected category in your head: “I am explicitly not allowed to monetize this.”
      • It gives you permission to be wasteful on purpose with your time and curiosity.
    • Examples (mine + imagined):
      • A tiny tool that only works on my machine.
      • A goofy game no one else will ever play.
      • A script to automate something I only do twice a year.
    • Question: List 3–5 Zero-ROI projects I’ve done or dreamed about, even if they feel silly.

  • Redefining “Success”

    • Current default: shipping, user counts, GitHub stars, retention, MRR.
    • Alternative metrics for side projects:
      • “Did I learn one new concept?”
      • “Did I touch code today that felt like mine?”
      • “Did I leave the keyboard feeling lighter than when I sat down?”
    • Question: What’s one “failed” or “useless” project that secretly taught me a major skill I still use today?

  • Side projects as recovery, not just opportunity

    • Position side projects as:
      • A pressure valve for a bad sprint or toxic review.
      • A place where I can make decisions without a Jira ticket or a PM.
    • Emotional contrast:
      • Work: deadlines, stakeholders, performance reviews.
      • Zero-ROI side project: no one is waiting; nothing is on fire; I get to follow my curiosity.
    • Question: Remember one specific week where a late-night or weekend project emotionally outweighed a bad week at work—what happened?

  • Practical ways to resist the side-hustle reflex

    • Name it upfront:
      • When I start a new project, explicitly label it “Zero-ROI” in my notes or README.
    • Set constraints:
      • No analytics.
      • No roadmap doc.
      • No issues from other people.
    • Social boundaries:
      • How to answer “you should monetize this” without getting defensive:
        • “Maybe, but this one is practice for me.”
        • “This is my gym, not my job.”
    • Question: What one sentence would I actually feel comfortable saying to a friend or coworker who pushes me to monetize?

  • Drafting notes (for me, not the reader)

    • Open with a concrete story of a project that started joyful and got heavier the moment money or “audience” entered the picture.
    • Keep reminding the reader: this is not an anti-business chapter; it’s about preserving at least some space where code is allowed to be useless.
    • Use 1–2 short anecdotes rather than a long rant about hustle culture; focus on how it felt in my own body and evenings.
    • Land the chapter on the idea of the “Zero-ROI” label as a small, practical tool: a sticker I can put on a project in my head that tells me, “This never has to earn a dollar to be worth it.”

Chapter 3: The “Bird by Bird” Draft

  • Chapter intent: Give burned-out developers explicit permission to write bad, messy first drafts of code, using Bird by Bird as one contained analogy – not the premise of the whole book.

  • Opening: My ugliest first draft that actually changed something

    • A specific side project where the first version was embarrassingly rough (maybe the system design game engine, or another tool).
    • How it looked:
      • Long functions, copy-paste, globals, console logs everywhere.
      • No tests, no types, probably no linter.
    • How it felt:
      • A mix of shame (“I know better than this”) and relief (“but it finally works”).
    • Question: What is one first version of a side project I would never show in an interview, but that secretly lit me up when it finally ran?

  • The Bird by Bird lesson (for devs)

    • Writing teacher Anne Lamott talks about “shitty first drafts” as the only way real writing gets done.
    • For writers, that means the first pass is allowed to be rambling and clumsy; the point is to get something on the page.
    • For us, the first draft is the mess where we prove an idea is even alive.
    • Question: When I think “shitty first draft of code,” what patterns show up for me? (god functions, no error handling, hard-coded values?)
    • TODO: Add one short, specific Bird by Bird quote about shitty first drafts here, then immediately map it to code.

  • Why “spaghetti code” can be honest and joyful

    • The first version of a playful project is often closest to how the idea arrived in my head.
    • Early code is allowed to be:
      • Linear, repetitive, and a little wild.
      • Full of comments to myself instead of polished abstractions.
    • Contrast with work code:
      • At work, someone will review it; abstractions and patterns come first.
      • In my own projects, the first job is to see if the thing is fun or useful at all.
    • Question: Describe one piece of messy side-project code that made me smile because of what it did, not how it looked.

  • Small frames: coding as “short assignments”

    • In Bird by Bird, Lamott writes about “short assignments” and the 1-inch picture frame: only write what you can see through that tiny frame.
    • Mapping that to code:
      • One 25–30 minute session where the only goal is to make a tiny piece work.
      • One function, one route, one little UI interaction – not “finish the app.”
    • This keeps side projects from feeling like another giant, failing epic.
    • Question: If I gave myself a 1-inch picture frame in code tonight, what is the smallest slice of my project I could focus on?
    • TODO: Add one short Bird by Bird line about small/short assignments here, then underline the connection to tiny coding sessions.

  • Validation: “Yes, it works” vs. “Yes, it passed CI”

    • Work brain:
      • Green tests, clean diffs, style guides, approvals.
    • Side-project brain:
      • The little thrill when a hacked-together script finally outputs the right thing.
      • The laugh when a half-broken prototype still delights me.
    • Argument:
      • For recovery, that “Yes, it works” feeling is more important than a perfect test matrix.
      • Clean-up can come later, if the project proves it deserves to live.
    • Question: Recall one night where I stayed up too late just to see something run once – what was I chasing in that moment?

  • From draft to craft (without killing the joy)

    • The danger: letting “clean code” guilt crush a project before it has a chance.
    • A gentler sequence:
      • First pass: do whatever makes it work; let it be ugly.
      • Second pass (only if it still excites me): pull one messy knot at a time into a slightly better shape.
      • Maybe never: full corporate-level refactor; some projects do not need that.
    • Question: What signals tell me a messy side project is worth a second pass? (I keep thinking about it, I keep using it, friends ask about it.)

  • Drafting notes (for me, not the reader)

    • Keep Bird by Bird contained in this chapter: treat Lamott as a guest teacher, not the book’s co-author.
    • Use at most 2 short quotes: one on shitty first drafts, one on short assignments / small frames.
    • Land the chapter on permission: the reader should come away feeling like they are allowed – even encouraged – to write ugly first versions on nights and weekends.
    • Tie back to Chapter 2 by reminding the reader that Zero-ROI projects plus shitty first drafts are a deliberate rebellion against career-only coding.

Phase II: The Exoskeleton (AI & The Modern Tooling)

Chapter 4: Human In The Loop

  • Thesis: On side projects, I still want to write most of the code by hand. AI is there to remove friction and do mechanical work, not to think for me. If I let it design and write everything, I’m not practicing anymore—I’m just supervising.
  • The “Vibe Coding” Trap: Why letting AI build the whole project steals your joy.
    • Working definition of “vibe coding”
      • Letting the prompt stay vague (“build X for me”) and accepting whatever the AI returns as the architecture.
      • Skipping the part where you think through tradeoffs, data shapes, and failure modes yourself.
      • Ending up supervising code you don’t fully understand instead of writing code you feel responsible for.
    • Why this is a problem for side projects
      • Side projects are supposed to be where you practice thinking and designing; if AI owns that part, you lose the main benefit.
      • It’s easy to slip into productivity-brain and treat your fun project like another Jira board.
      • The fastest way to burn out on a side project is to feel like you’re just reviewing someone else’s pull requests.
    • My “vibe coded” kids app
      • I once vibe-coded an app for my kids so they could have their own personalized YouTube.
      • I let the AI generate big chunks of the app, and when the code came back I felt disconnected from it.
      • I had to learn what the AI did, what mistakes it made, and what I would have done differently.
      • I eventually shipped it once it was working, because it was low stakes—but I came away feeling like I’d reviewed someone else’s codebase instead of building something of my own.
  • Human-in-Control AI (for side projects)
    • You own the idea, architecture, and constraints; AI owns the grunt work.
    • You decide the scope: small, clear tasks where you can read every line that comes back.
    • You use AI to lower activation energy (“get me started”), not to decide what you’re building.
    • Mental model: AI is the junior dev / power tool; you’re still the architect with your hands on the keyboard.
  • Case Study: 99.nvim and the philosophy of “Small Context, High Control.” Using AI to handle the “Manual Labor” while you handle the “Architecture.”
    • The Philosophy: “The AI client that Neovim deserves, built by those that still enjoy to code”
      • Quote from README: “hand coding is still very important and the best products I know of today still do that”
      • Contrast with “vibe coding” where AI generates everything
    • You Drive, AI Assists (not the other way around)
      • You initiate requests - you remain in the editor, in control of when and where AI is invoked
      • You can cancel anytime - agency is always one keystroke away
    • Small Context = High Control
      • You explicitly pick which files the AI sees (@files)
      • You define constraints via SKILL.md files (#rules)
      • Visual selection means you’re asking AI to work on bounded, specific tasks, not “build me an app”
    • The Joy is Preserved
      • You’re still writing the architecture, the interesting parts
      • AI handles the “manual labor” - boilerplate, refactoring, repetitive edits
      • You stay in flow state, not watching AI generate code you don’t understand
    • My first “this is the right balance” moment
      • I was building an AI trading platform and had written the core of it by hand before installing 99 just to give it a spin.
      • I used 99 to write small functions and to ask “can this be optimized?” on pieces of code I already understood.
      • The changes were isolated, much more reviewable, and stayed within a shape I had already defined.
      • The experience felt very different from vibe coding: AI was helping me move faster inside a design I owned, instead of handing me a design I had to reverse-engineer.
  • General principles for using AI as an assistant (not the driver)
    • Rule 1: Hand First, AI Second
      • Try to sketch or write something yourself first—even if it’s rough—then use AI to tighten, refactor, or generate tests.
      • The thinking reps (architecture, data shapes, control flow) should still be yours.
    • Rule 2: Scope the Ask
      • Keep prompts small and concrete: one function, one refactor, one test at a time.
      • If a request would overwhelm a junior dev with context, it’s probably too big for a single AI call.
    • Rule 3: Own Every Line
      • Always read and edit AI-generated code; nothing ships without passing through your taste.
      • If you can’t explain what the AI wrote in your own words, it’s too much.
    • Rule 4: Prefer Refactor Over Generate
      • Prefer AI for refactoring, scaffolding, and explanations over full greenfield features.
      • Ask “make this better” on code you wrote by hand, rather than “write this whole thing for me” from scratch.
  • Tying it back to side projects

    • Side projects are where you practice being the architect; treat AI as an intern that helps you move faster.

    • Use AI to remove friction (“write the boring parts”) so you have more energy for the weird, personal decisions.

    • Guard against turning your fun project into a productivity contest based on how much the AI can crank out.

    • How AI has helped my side projects

      • AI has made it much easier to start or resume side projects on low-energy days by handling boilerplate and setup work I used to procrastinate.
      • I’ve had moments where AI started to take over the shape of a side project, and I had to consciously pull back and reassert my own design so it still felt like mine.

    • Drafting notes

      • Open with a short “vibe coding” anecdote: the personalized YouTube app I tried to vibe-code for my kids and how disconnected I felt from the generated code.
      • Immediately distill a working definition of “vibe coding” from that story: vague prompt, AI inventing the architecture, me reverse-engineering afterward.
      • Define “human-in-control” in plain language before diving into 99.nvim: I write the core and the shapes by hand, AI only touches code I already understand.
      • Use 99 as one concrete example, but extract 3–5 rules that apply even if the reader never uses Neovim.
      • Include at least one non-Neovim mapping (VS Code, Cursor, JetBrains) to show how the same pattern applies elsewhere.
      • Add a brief counterargument + rebuttal: yes, AI-as-driver is faster to a demo, but side projects are my training ground and I don’t want to skip the reps.
      • End with a clear call to action: one small way to use AI as an assistant on the reader’s next side project session.

    • Open gaps / TODOs for Chapter 4

      • Bridge from Phase I
        • Add 1–2 sentences at the start of this chapter that connect back to VCA and AI hype:
          • e.g. “Inside VCA, I’d already seen how AI hype could warp priorities. The problem wasn’t the tools themselves—it was how easy it was to let them take over the parts of coding I actually enjoy.”
      • Flesh out the “vibe coded” kids app scene
        • Include:
          • Why I wanted to build it for my kids (what I hoped it would do for them).
          • Roughly what I typed as a prompt (“build me X with Y stack…”).
          • What the generated code looked and felt like (big unfamiliar files, patterns I wouldn’t have chosen).
          • How my kids reacted vs. how I personally felt shipping something I didn’t really “own.”
        • Immediately tie that story to the definition of vibe coding: vague prompt, AI inventing the architecture, me reverse-engineering after the fact.
      • Deepen the “Hand First, AI Second” trading platform story
        • Add specifics:
          • Language / kind of function I optimized with 99.
          • How I invoked 99 (visual selection, keymap, short prompt like “can this be optimized?”).
          • What changed in the diff that made me think “yes, this is better, and still clearly my code.”
        • Make the contrast explicit:
          • Kids app: I had to reverse-engineer what the AI did.
          • Trading platform + 99: I already understood the code; AI just tightened it.
      • Non-Neovim / non-99 mapping
        • Add 1–2 bullets that show how the same pattern works in VS Code / JetBrains / Cursor / etc.:
          • “Even if you never use Neovim or 99, you can still follow these rules: select a small region of code, ask for a narrow change, and only touch code you already understand.”
        • Make sure the chapter explicitly calls out other AI tools (VS Code extensions, Cursor, Zed, JetBrains AI, etc.) so the ideas don’t feel exclusive to Neovim users.
      • Counterargument + rebuttal
        • Acknowledge:
          • “Yes, asking AI to ‘just build it’ can be faster to a demo.”
        • Rebut:
          • Side projects are my training ground; if I skip the hand-coding reps (architecture, debugging, taste), I’m trading long-term skill for short-term speed.
          • Analogy: letting AI design and write your side project is like having someone else do your workout and wondering why you’re not getting stronger.
      • Concrete “next session” call to action
        • Draft a clear 2–3 step pattern the reader can try tonight:
          • Step 1: Hand-write (or comment-sketch) a small function or module first.
          • Step 2: Use AI only to refactor, tighten, or generate tests for that code.
          • Step 3: Don’t ship anything you couldn’t explain to a friend in your own words.
      • End-of-chapter paragraph
        • Plan a short wrap-up paragraph that:
          • Restates the chapter’s core idea: AI should never steal the fun/interesting parts—deciding what to build, how it fits together, and what “good” looks like.
          • Ties back to the book’s mission: if you get this balance right, AI makes your late-night side projects easier to start and keep going, without hollowing out your craft.

Chapter 5: The Desktop Sandbox

  • Choosing tools because they are fun, not because they are on a resume.
  • The terminal as a playground: Why stay local?
  • Emerging chapter idea: a personal setup can create psychological distance from work, so side projects feel like mine instead of unpaid overtime.
  • Same tools, same IDE, and same stack can make side projects feel too much like the day job.
  • Contrast / anti-example:
    • IntelliJ IDEA felt deeply tied to work because I had spent so many years writing Java in it and knew the interface almost too well.
    • During the rougher parts of my career, using an IntelliJ product at home brought too much of work’s emotional residue with it.
    • I did not want my personal projects to live inside the same feelings as my job.
  • Changing the scenery matters:
    • Switching editors, languages, or workflows can keep curiosity alive.
    • A different setup can help detach coding-for-myself from coding-for-work.
  • Personal story seed:
    • At work, I was very IDE-oriented (mostly JetBrains IDEA) and debugger-oriented.
    • For side projects, I chose Neovim because I had always wanted to learn Vim and become capable with it.
    • I also leaned more on print debugging, which felt scrappier, faster, and less formal.
    • Print debugging lowered the ceremony: no setup, no extra tooling, just print values and keep moving.
    • It kept Neovim from becoming an obstacle while I was still learning Vim motions.
    • It let me focus on flow first and sophistication later.
    • Part of the appeal of Vim was aspirational: many programmers I admired were fast, flexible in the terminal, comfortable on remote machines, and able to get things done without depending on heavy software.
    • Neovim finally felt like “my editor” while building the system design game.
    • I wrote the whole project in Neovim and did not fall back to an IDE.
    • Forcing myself to learn the motions gave the tool a feeling of earned familiarity.
    • The turning point was customization: once I started shaping Neovim to fit me and writing plugins for it, I was sold.
    • Writing my own tools for my Neovim setup let me invest in how I wanted to work.
    • Small personalized touches mattered: if I wanted a modal to run tests, I could build it.
    • That felt different from learning someone else’s IDE and conforming my workflow to its assumptions.
    • Scene seed: by the time I had a solid prototype of the system design game, I realized I had written a huge amount of it in Neovim.
    • It had started slow and awkward, but somewhere along the way the motions stopped feeling foreign and started feeling natural.
    • That was the moment I could feel the editor becoming part of my creative space instead of an experiment.
    • Kickstart.nvim was an important on-ramp: it gave me a well-commented starting point for configuring Neovim.
    • Part of making Neovim mine was gradual ownership: first using Kickstart, then understanding it, then deleting the comments once I no longer needed the training wheels.
    • From there, I started building the plugins and workflow pieces I wanted for myself.
    • As I did more personal projects in Neovim, my brain started associating it with fun, exploration, and possibility instead of obligation.
  • Harmony / flow:
    • The goal is not just efficiency; it’s a setup where moving from one task to another feels easy and inviting.
    • A good local setup makes me want to come back to the keyboard.
    • What breaks harmony: too many clicks and too much friction switching from one task to another.
  • Reader takeaway:
    • Even when you’re tired and burnt out, it is worth taking a small amount of time to find joy in the work again.
    • Software engineering can be lucrative, but it is still a hard road if you have no enjoyment in what you do every day.
    • Enjoyment needs to be nurtured by letting your own creativity show up in your tools and projects.
    • The point is not “use Neovim”; the point is that exploring tools and going deep on what excites you is worth doing.
    • If a reader wants to learn something deeply, they should let themselves dive in.
  • Guardrail:
    • This chapter should not become “why Neovim is better.”
    • The real point is ownership, curiosity, and building an environment work hasn’t already colonized.

Phase III: The Playground (The Joy of the Useless)

Chapter 6: Building for an Audience of One

  • The radical act of writing a script that only you will ever use.
  • Why “It Doesn’t Scale” is a feature, not a bug.

Chapter 7: Permission to Abandon

  • Normalizing the “Folder of Half-Finished Repos.”
  • Why learning 80% of a technology and then quitting is a valid educational path.

Chapter 8: Data Archaeology & The Small Web

  • Finding inspiration in the “weird” internet before it was colonized by ads.
  • Building things that feel “human” again.

Phase IV: Protecting the Spark

Chapter 9: Gatekeeping Your Joy

  • Personal Story: The 6-Month Exclusion - How side projects were a lifeline during a period of being excluded at work and criticized by a new team
    • Question: What changed at work? Who was the new team, and what was their criticism?
    • Question: Describe a specific incident of exclusion - a meeting you weren’t invited to, a decision made without you, a code review that was unnecessarily harsh
    • Question: How did the criticism make you feel? What did it make you question about yourself?
    • Question: What side project(s) did you work on during this time? Describe the first commit you made when things were at their worst
    • Question: How did coding for yourself feel different from the workplace environment? What was the contrast?
    • Question: Were there specific moments when a side project success countered a workplace failure?
    • Question: Did anyone at work know about your side projects? Did you hide them or were they part of your resistance?
    • Question: What was the breaking point that made you realize the 6-month period needed to end?
    • Question: How did side projects prepare you for what came next? (confidence, skills, mental state)
    • Question: What would you tell someone currently going through similar workplace exclusion?
  • How to talk to recruiters and peers about your hobby without letting them turn it into a “transferable skill.”
  • Keeping the 9-5 and the 5-to-9 in separate mental containers.

Epilogue: The Permanent :q

  • Summary: Coding as a lifelong craft, not just a career.

Spare Content / VCA Story Notes (for later use)

  • The “VCA Project”: A story of building a simple chat bot trapped in the complexity of a large tech company.
    • Specific business need
      • Support was very slow because there were massive amounts of tickets and only so many agents.
      • My goal was to reduce time to resolution for customers.
      • We also needed better monitoring and alerting of our customer support systems.
      • It felt like a tight timeline, but we were up for the challenge.
      • I was a very confident engineer so I more or less just got right to work.
      • Once the work started, I immediately began talking about tradeoffs - what felt reasonable to get done versus what did not.
    • Emotional impact of VCA
      • We had to get the project done in very little time. We were building 4 services that needed to interact with each other, in parallel, in 4 months.
      • There were constant demos of our work in progress, and the whole company seemed to be talking about VCA and how AI was going to revolutionize the platform.
      • I was often nervous and on edge, worried about whether things would work during a demo. Sometimes there were multiple demos per day.
      • I felt pretty pessimistic about our TPM at the time because she was very pushy, but only later did I realize how effective she was at unblocking work and getting things rolling.
    • A specific moment of frustration
      • Bug: the chatbot would not respond to one specific person, but worked for everyone else.
      • It took hours to resolve, not because the fix was complex, but because reproducing the issue was hard.
      • The root cause was an accent in the user’s name and how that character was encoded.
    • When I realized it wasn’t sustainable
      • The project wasn’t really sustainable from the start, but I’m not afraid of hard work and I treated it as a short, intense push.
      • After the initial four months were over, management didn’t slow down. The “big push” never ended.
      • That was when it clicked for me that what was supposed to be temporary crunch was quietly becoming the new normal.
    • A typical day
      • I typically started work around 9am, sometimes 10am.
      • We often had a daily VCA sync in addition to the regular standup and team meetings.
      • The main blockers were usually dependencies on other teams, or waiting for an API to be finished so we could use it.
      • All the services were built in parallel. We usually had a doc that we would create over a discussion to lay out what the API contract would look like.
      • When it came time to show new features, bugs were often reported during testing and there would be a lot of finger pointing of “Oh that’s your system’s responsibility, not ours”.
    • How many layers a message went through
      • The UI.
      • The Frontend API.
      • The Chatbroker midtier which talked to a MySQL database.
      • Microsoft Bot Framework.
      • OpenAI.
      • A prompt service.
    • Websockets and product alignment
      • In order to use websockets, we had to integrate with the messaging service which required a lot more alignment with product. It was also managed by another team.
      • Customer support was often an afterthought and it was really hard to get product support.
      • Every team was chasing AI and wanting to be the voice of the company at LinkedIn. There were a lot of politics around who can build what with AI.
      • Because we had a pre-existing product before integrating with AI, there wasn’t a strong case to push for using websockets because to the product managers on the team, things were working as is. However they did not understand the inefficiency.
    • Features that took far too long
      • Having multiple repos for different services made it nearly impossible to ship faster. There was too much context switching and too much code being created to really keep up with it.
      • File attachments took multiple points of coordination:
        • We needed blob storage to store the files.
        • We needed to make multiple calls to the chatbroker to ensure that we set up the conversation correctly to accept files.
        • We then needed to make sure that the file was safe to store.
        • We also had to make the UI work for file attachments, handle if the file upload failed, and also handle being able to have customer service reps download the file.
    • Big Tech “False Image” notes
      • Rules we followed:
        • Everything was a micro-service.
        • Everything had to be modular.
        • Separation of concerns to a fault.
    • Transition from “Employee” to “Creator” seeds
      • The breaking point for me was hearing leadership celebrate VCA as a massive success. A PM told me, “We saved 40,000 hours in customer support reps’ time,” and there were all-hands and meetings about how big of a win it was.
      • When I reflected on it, I realized how hard I had worked to make that happen—and also that if I ever left this company, I wouldn’t really “own” any of it, because all of those accomplishments belonged to the company, not to me.
      • After one person on my team left for another team, it felt like some sort of magic disappeared.
      • When you’re building something with people you genuinely enjoy working with, there’s this undeniable spark—and once that was gone, it became much easier for me to unplug.
      • Around that time I stopped reflexively checking work Slack on weekends; it no longer felt like a place where the work I cared about was happening.
      • I started on a project to help people learn system design (https://www.systemdesigngame.dev) and I realized how much freedom I had to just code things the way I wanted them to be.
        • It probably took about a month from the initial idea to having the first working version.
        • I started by building the engine that would run the simulations.
        • It involved a lot of research into areas I didn’t fully understand yet, but I was curious and pulled along by that curiosity.
        • When I finally had a preliminary MVP working, I felt a lot of relief.
        • I had real anxiety around testing it because I’d put so many hours into this side project and I desperately wanted it to work without a hiccup.
        • It was actually very similar to the feeling I had every time I had to test new VCA features.
        • It was that “I’ve done a lot of work on this and now it’s the moment of truth” feeling—except this time, the stakes were personal rather than corporate.