A 2026 BSM Media survey found that 66 percent of U.S. mothers had used AI tools to find product ideas or parenting tips. The number is not shocking. Mothers are tired. Searching the web is wading through sludge. A machine that can make the next decision easier will get used.

But a tool used in front of a child becomes part of the environment. Environments teach.

Your child learns from you

If a parent asks a machine every question, the child learns where answers come from.

If the machine answers instantly, the child learns how long not-knowing should last.

If the adult never checks the answer, the child learns confidence is evidence.

If a chatbot behaves like a perfect friend, the child learns a strange thing about people: that the best ones never need anything from you.

None of this requires a villain.

It only requires defaults.

Software people should be the least surprised by this. Defaults are decisions. The path of least resistance was designed by someone. If the product lives in your home, its defaults become part of your home.

Put AI behind the parent

UNICEF’s 2026 interview with Harvard researcher Ying Xu lands because it does not flatten the issue. AI can help children explore. It can also crowd out sleep, schoolwork, friendship, and productive struggle.

Productive struggle is the part adults are tempted to optimize away.

A child asks a question. The machine can answer. The well-meaning parent can make the friction disappear.

But the friction is often the lesson.

The child guessing first. The child trying the wrong category. The child sounding out the word, getting annoyed, looking at your face, and trying again.

That is not inefficiency. That is the work.

This is where AI tools for young kids need a colder design rule: help the adult, don’t hand the kid answers.

The broader AI tutoring debate keeps circling the same problem. AI is a great tool for spotting patterns, suggesting lessons and materials, or turning your kid’s current obsession into an educational game. It can even remind the parent that the blocker might be hunger, not phonics.

The parent is the better teacher.

Use a protocol, not vibes

In Early Childhood Matters, Daanish Masood describes building an AI model for bedtime stories with his four-year-old son. The model draws from texts that matter to his family, including Rumi and the Tao Te Ching.

The custom model is the flashy part. The protocol is the useful part.

He uses it with his son. He checks sources. He treats the machine as fallible. His son calls it “robot” and corrects it when it wanders off.

That is not outsourcing.

That is a parent using a tool in the child’s presence while keeping the relationship intact.

You can do the same without training anything.

Ask the child first.

Use the tool together.

Say out loud when the machine may be wrong.

Make the answer point back to a book, a block tower, a drawing, a walk, a real object.

The screen should open a door into the room, not replace the room.

Edit the syllabus

The invisible curriculum is the accumulation of small lessons your child absorbs from the environment around him.

How fast answers arrive.

Who gets trusted.

Whether adults verify claims.

Whether hard thinking gets preserved or paved over.

Whether technology serves the family, or the family quietly rearranges itself around the technology.

I want a child who knows what job a tool has, what job it does not have, and when the human is still responsible.

The machine will not put itself in its place. That is the parent’s job.

The cleanest override is a real activity in the room. I wrote a twelve-week project curriculum for ages 2-6 — hands-on building, no screens required, designed so the parent stays the teacher and the tool stays the tool. It is the syllabus for the part of the day you do not want the defaults to write.

I spent twelve years writing software before I left a director-level position and stayed home. I have seen what makes an engineer actually good at reasoning — and it is not the toy they had at age four. It is whether someone taught them to break a problem apart, handed them something that doesn’t work, and stayed in the room while they figured out why.

No toy does that. You do.

What the research is actually finding

In March 2026, Lancaster University and the Micro:bit Foundation launched the Micro:bit Innovation and Research Lab (MIRL), a formal effort to scale hands-on computing education with evidence behind it. The micro:bit program has already distributed 11 million devices across 85 countries, reaching over 70 million children. The reason they built a research lab instead of just shipping more units is telling: distributing devices is not the same as building thinkers.

The IDC 2025 study on Bit:sort — a physical sorting activity designed for fourth graders — found something that should reframe how you think about early computing education entirely. Kids demonstrated genuine algorithmic reasoning through physical play even when they could not verbalize it. They were thinking in algorithms before they had language for it. The reasoning came from doing, not from being told.

The TMAR study pushed this further. When students were asked to generate their own challenges rather than complete preset ones, they showed significantly stronger gains in abstraction, decomposition, and algorithmic reasoning — the three pillars of computational thinking. Student-generated problems outperformed instructor-assigned problems on every metric that matters.

The kids who made the problems got smarter than the kids who solved them.

Why this matters if your kid is under six

The STEM toy market has a widely acknowledged gap for ages two to three. Most products either aim at babies (sensory, no logic) or school-age children (screen-based, app-dependent, increasingly passive). The shift that researchers and educators are watching — away from app-dependent toys and toward open-ended, screen-free, reusable play — is a direct response to evidence that passive engagement does not build reasoning skills.

For a three-year-old, the foundational moves are not about a specific device. They are about learning to notice patterns, test a hypothesis, hit a dead end, and try again. That loop is the thing. The physical substrate — blocks, magnet tiles, a simple circuit, a game you build together — matters far less than whether the child is the one deciding what happens next.

Handing a child an AI toy that responds to them is not the same as handing them a problem that does not respond at all until they figure it out.

The build-together advantage

Here is what changes when you sit down and make something with your kid instead of setting them up with something that was made for them.

First, narrate your own thinking out loud. “Hmm, this isn’t doing what I expected — why might that be?” Your child learns that uncertainty is not a failure state. It is just the next step.

Second, the challenge is theirs to define. The TMAR research is clear that self-generated challenges produce better outcomes than preset ones. When your kid says “I want to make a game where the cars race and crash into each other,” it’s not just chaos. That is the child setting the parameters. Your job is to help them build toward it.

Third, you are not replaceable by an app. The relationship is the scaffold. Research on early learning consistently shows that co-regulation — an adult’s calm presence modulating a child’s frustration tolerance — is what allows children to stay with hard problems long enough to solve them. A toy cannot co-regulate. You can.

The AI toy will not sit with your kid while they hit a dead end for the seventh time and keep their voice level while asking what they want to try differently. Toys are built to respond in a believable way, not to teach. That is not a feature gap. It is a category error.

What this looks like in practice

If you want a structured starting point for building with a child under six, I wrote a twelve-week project curriculum — physical and digital projects designed for the pre-reader age range, built around the exact principles the research supports: child-directed challenges, hands-on iteration, parent presence as the scaffold. It is practical and week-by-week, not theoretical.

The projects do not require any prior programming knowledge. What they require is your time and your willingness to be genuinely curious alongside your kid.

You were already the advantage. You just needed the roadmap.

When the room is bright and loud, it’s playtime. When the toys are out, it’s building time. And when everything is still bright and loud at 7:45pm, it’s “I AM NOT TIRED” time — which is a lie, but a lie delivered with such conviction that it’s almost admirable.

The shift happened when I stopped treating bedtime as a negotiation and started treating it as a systems problem. The variable wasn’t my son’s willingness to sleep. The variable was every environmental signal telling him it was still daytime.

So I automated the environment. And it changed everything — not just bedtime, but how I think about the repetitive infrastructure of parenting.

The Bedtime Sequence

Here’s what happens automatically in our house every evening:

• 6:00pm — Lights shift from cool white to warm. Subtle enough that nobody notices.

• 6:30pm — Lights dim to 50%, go amber. This is the signal. The room itself says “we’re winding down.”

• 7:30pm — Down to 20%. Warm orange. The day is ending whether you’re ready or not.

• 8:00pm — Living room dark. Bedroom nightlight on.

The transition is gradual enough that there’s no hard cutoff to fight against. By 7:30 the vibe has shifted and the bedtime routine feels natural instead of imposed. No cajoling, no sticker chart negotiations, no “five more minutes” loop. The house is the authority, not me.

I automated the environment and spared myself from being the bedtime police. That’s systems thinking applied to a three-year-old, and it works better than any strategy I’ve tried.

The Stack (It’s Simpler Than You Think)

I’m running Home Assistant on a Raspberry Pi with Zigbee bulbs. That sounds more complicated than it is. The reality:

• Buy smart bulbs. Screw them into existing lamps.

• Plug in a Raspberry Pi.

• Set up automations: “at 7pm, make the living room warm.”

• Walk away.

The whole thing took an afternoon to set up and has run without intervention for months. You don’t need to be a software engineer to set this up (trust me, I am one) — the Home Assistant setup wizard does most of the work.

The point isn’t the technology. The point is that every evening, while other parents are in the trenches of bedtime negotiations, my house is handling it and I’m free to just enjoy winding down and reading to my kid.

Morning Autopilot

The gap between “awake” and “functional” is the most dangerous period of my day. My son wakes up at 100% energy. I wake up at... well, when you have young kids I think about 12% is as good as mornings get.

Let the house handle the it:

• 6:30am — Set up a smart plug that fires the coffee maker (prepped the night before).

• 7:00am — Lights start a 30-minute sunrise ramp. No jarring brightness.

• 7:30am — Full daylight (and I’ve had some coffee by now).

By the time he’s raring to go, the coffee is kicking in, the house is lit, and I’ve had five minutes to exist as a person before I become a parent. That five-minute buffer is the difference between patience and survival mode.

The Compound Effect

Every decision I automate is one I don’t spend mental energy on. And mental energy is the real scarce resource.

Being a parent to a toddler involves 400 micro-decisions per day. What to eat, what to wear, when to go outside, how to redirect a tantrum, which book to read, whether the snack is too close to dinner. Every one of those decisions draws from the same finite cognitive pool.

Automating the predictable stuff — lights, coffee, routines — doesn’t save hours. It saves decisions. And when you’re trying to build something meaningful in a 90-minute window after bedtime, you need every scrap of cognitive capacity you can get.

The house handles lights. I handle the architecture.

The Systems Thinking Connection

There’s a thing that happens when you start automating your home: your kid notices.

My son now understands, on some level, that the house “knows” when it’s bedtime. The atmosphere changes. Things happen on a schedule. He doesn’t know the word “automation,” but he’s experiencing it — the idea that systems can handle repetitive tasks so humans don’t have to.

That’s the seed of computational thinking right there. Not in a curriculum or an app. In his own house, running on a Raspberry Pi in the closet.

When he’s older and I explain what an algorithm is, he’ll already know: “Like how the house turns the lights warm at bedtime,” will make perfect sense.

Where to Start

If bedtime is a battle: automate the lights. The gradual dimming does more than any sleep consultant advice I’ve tried.

If mornings are chaos: smart plug on the coffee maker. One plug, one automation, life-changing.

Don’t overhaul your house. Pick the friction point that drains you most. Automate that one thing. Live with it for a week. When you realize the house just handled something you used to spend energy on, you’ll understand why I automated the next thing. And the next.

That’s how systems thinkers parent. We don’t grind through problems. We build infrastructure so the problems solve themselves.

If you're building alongside your kids, check out 12 Weeks of Tech Projects for Toddlers — a parent's guide to computational thinking at age 2+.

Not casually interested. Obsessed. He knows the pickup schedule for our neighborhood. He can identify the squeal of its brakes from half a block away.

Every garbage day morning, we stood outside and watched the garbage truck like other families watch fireworks.

So when I wanted to introduce him to computational thinking — to start building the foundation for tech projects together — I had a choice. I could follow a curriculum: “Week 1: Learn about colors. Week 2: Learn about shapes. Week 3: Learn about sequences.”

Or I could follow the garbage trucks.

I followed the garbage trucks. And it changed everything.

The Curriculum Trap

There’s a whole industry of “teach kids to code” products, and most of them share the same structure: a predefined sequence of lessons that march through concepts in a logical order. First you learn this, then you learn that, then you combine them.

It makes sense on paper. It’s how we organize knowledge in computer science courses. Prerequisites before advanced topics. Building blocks stacked in order.

The problem is that toddlers and young kids don’t care about your logical order. They care about what they care about. And what they care about changes by the hour, but at any given moment, it’s intense.

When my son cares about garbage trucks, he will sustain attention on garbage truck-related activities for an astonishing amount of time. Thirty minutes. Forty-five minutes. That’s an eternity in toddler time. He’s asking questions, making connections, retaining information.

When he doesn’t care about something? You get maybe thirty seconds before he’s upside down on the couch asking for a snack.

So why would I fight that? Why would I try to make him care about abstract shapes on a screen when he already cares — deeply, passionately — about garbage trucks?

Interest as an Engine

Here’s what interest-led learning looks like in practice:

The concept I want to teach: Sequencing (step-by-step instructions)

Curriculum approach: “Let’s learn about sequences! Here’s a cute robot. Drag the arrows to make it walk to the star.”

Interest-led approach: “What does the garbage truck do first when it gets to our house? Then what? Then what? Can we make a garbage truck game that does all those steps?”

Same concept. Wildly different engagement.

In the interest-led version, my son was practically vibrating with excitement. He described the garbage truck’s entire pickup sequence from memory — pulls up, extends the arm, grabs the can, lifts, dumps, lowers, releases, drives to the next house. That’s an eight-step algorithm, and he generated it himself because it was about something he cared about.

In a curriculum, someone else defines the problem. In interest-led, the kid defines the problem. Guess which one produces better learning?

But What About Coverage?

This is the question I always get from other developer parents, because we’re wired to think in terms of completeness. “If you just follow interests, won’t there be gaps? What about concepts they never naturally encounter?”

Here’s what I’ve found: if you’re creative about it, you can teach almost any foundational concept through almost any interest. The only prerequisite is knowing them well-enough yourself to spot the opportunities.

Garbage trucks can teach:

• Sequencing: The pickup routine

• Conditionals: “What if the can is too heavy? What if it’s recycling day?”

• Loops: “The truck does the same thing at every house on the street”

• Debugging: “What if the arm misses the can?”

• Pattern recognition: “Which streets does the truck go to on which days?”

• Decomposition: Breaking down the full route into individual stops

That’s basically an entire basic algorithmic thinking curriculum, delivered through a single interest.

And here’s the thing about gaps: they fill naturally. Because kids’ interests change. Garbage trucks this month, airplanes next month, space the month after. Each new obsession is a new vehicle (pun intended) for the same underlying concepts, reinforced in a different context.

That’s actually better than a curriculum, which teaches each concept once and moves on. Interest-led learning revisits core concepts over and over, in varied contexts, which is how durable learning actually works.

The Developer Analogy

Think about how you learn best as a developer.

Have you ever tried to learn a new framework by reading the docs from page one to page done? How’d that go? You probably retained about 15% and forgot the rest by the time you needed it.

Now think about a time you learned a framework because you needed it for a project you cared about. You had a problem, the framework solved it, and you learned exactly what you needed as you went. You probably retained way more, and the learning was faster and more enjoyable.

That’s interest-led learning. It’s how adults learn best, and it’s how kids learn best. The only difference is that adults can sometimes force themselves to grind through boring material. Kids can’t. And honestly, why should they?

How to Do It

If you want to try interest-led tech learning with your kid, here’s the practical approach:

1. Identify the current obsession. What does your kid talk about nonstop? What would they choose to do all day? That’s your vehicle.

2. Map concepts to the interest. Take the computational thinking concepts you want to introduce (sequencing, patterns, conditionals, decomposition, debugging) and brainstorm how they connect to the obsession. I promise they do.

3. Let the kid drive. Don’t say “let’s learn about patterns using trucks.” Say “hey, I noticed the garbage truck always goes to the same houses. Does it go in the same order? Why?” Let the concept emerge from the conversation.

4. Build something. This is where it gets really powerful. “Want to make a garbage truck game?” takes the interest and adds creation. Now your kid isn’t just learning concepts — they’re applying them to build something they actually want to exist.

5. Follow tangents. If you’re building a garbage truck game and your kid suddenly wants to add a dinosaur that rides on top, go with it. The tangent is just another interest expressing itself. The concepts still apply.

The Hard Part

I’ll be honest: interest-led is harder in some ways for the parent than curriculum-led. A curriculum tells you what to do each day. Interest-led requires you to improvise, to find the computational thinking in whatever your kid is currently obsessed with, to think on your feet.

But it’s also more fun. Because you’re responding to a real kid with real enthusiasm, not marching through someone else’s lesson plan. And the results speak for themselves: deeper engagement, better retention, and a kid who associates learning with their favorite things instead of with obligation.

And if the only thing they retain from your lessons is a love of learning, that’s more than enough.

Subscribe now

I used to be an engineering director with a calendar full of deep work blocks and a standing desk in an office where I’d be unbothered for hours. Now my office is the kitchen counter, my sprint window is the gap between bedtime and when I physically cannot stay awake, and my ever-present co-founder is three years old.

Here’s a little of what I’ve shipped in the last few months from that kitchen counter: a book, a newsletter with weekly posts, a product line on Gumroad, multiple open source tools, and a daily content operation across three platforms. Not because I’m grinding 12-hour days, but because I stopped being the one who does the work and started being the one who reviews it.

Here’s how I’ve set myself up to create the time to ship where none exists.

The reframe that changed everything

The biggest unlock wasn’t a tool. It was a mental model shift.

I used to think my job was: research, write, build, design, post, promote, respond. All of it. Every day. In my 90 minutes. No wonder nothing shipped.

Now my job is: communicate intent, review, and approve. That’s it. I went from creator to editor. From builder to architect. From the person pushing code to the person reviewing pull requests.

The work still gets done. It just doesn’t require me to be the one putting in the hours.

The async everything stack

Here’s my actual setup. None of this is theoretical — I run this daily.

OpenClaw + iMessage: The async command layer

I have an AI agent (OpenClaw) that I talk to over iMessage. I text from my phone. While my kid plays. While I’m at the park. While I’m making lunch.

I don’t sit at a computer to manage my pipelines. I text “schedule the new posts” from the playground and it happens. I text “show me the overnight report” and I get a summary of what got done while I slept. I text “draft an about page using these two files” and I review the output when I have five minutes.

The key insight: iMessage is low-friction. I don’t need to get to my laptop, open a terminal, or log into a dashboard. The tool lives where I already am — in the same app I use to text my husband and my mom. My phone is in my pocket. The cognitive overhead is near zero.

Cron jobs: The night shift

While I sleep, automated jobs run:

• Content research: My agent browses, researches new ideas, and outlines notes and posts. I wake up to a summary of what was explored and new markdown files waiting for my review.

• Research: A nightly scan of HN, dev Twitter, and niche blogs compiles a research digest on topics I’m tracking. It’s my own personal-interest-filled, high-signal newsletter. I read it over coffee.

None of these require me to be awake. I set the schedule once. They run. I review the output in the morning.

The morning routine isn’t “sit down and figure out what to do today.” It’s “review what’s already been done and approve what ships next.”

The content pipeline: from creator to reviewer

Here’s what a typical day looks like:

7am: I text “gm.” My agent sends me the overnight report — what drafts were written, what research was compiled, what tasks were completed.

Throughout the day (in 2-minute bursts): I review on my phone. “This is good, queue it.” “Turn this post into a tweet.” A rambly stream-of-consciousness moment about something that happened with my 3yo becomes a new article. My involvement goes from hours of writing to a few minutes of grammatically-imperfect notes.

After bedtime: This is my only real focus block. But because the research is done, the drafts exist, and the admin is handled, I can spend it on the ONE thing that actually needs my brain: writing the newsletter post, editing the book, or building something new. The 90 minutes isn’t diluted across twenty tasks. It’s concentrated on the one task I can’t delegate.

The principle: decouple work from presence

The operating principle behind all of this: your work and your schedule need to be decoupled in time.

The content gets drafted at 1am by an agent. I review it at 10am from my phone. It posts at 2pm automatically. A visitor reads it at 8pm and becomes a customer. At no point did I need to spend one-on-one time with that customer to make a sale.

This is what makes the parent-developer life viable. Not “hustle harder” or “wake up earlier.” Definitely not Pomodoro timers. Just: build systems where the work happens when you’re not there, and your job becomes directing the intent and reviewing the output.

What you actually need

The specific tools matter less than the pattern. But since people always ask:

• An AI agent you can talk to async (I use OpenClaw over iMessage, but the concept works with any tool that doesn’t require you to be at a desk)

• Scheduled automation for anything repetitive (cron jobs, Zapier, whatever — the point is it runs without you)

• A review queue, not a to-do list — your daily work is approving and editing, not creating from scratch

• One focus block that’s protected for the work only you can do

The 90 minutes isn’t the limitation. The 90 minutes is enough — if you’re not wasting it on things a system could handle.

The unfair advantage

Here’s what the solopreneur Twitter crowd misses about parent-developers: the constraint IS the advantage.

When you have 90 minutes, you don’t over-engineer. You don’t build features nobody asked for. You don’t spend three hours picking a font. You ship the thing that matters and you ship it now, because bedtime is a hard deadline and toddlers don’t have a pause button.

I’ve shipped more in the last few months with 90-minute windows than I did in some quarters with a full engineering team. Not because I’m faster. Because I’m forced to be focused. I can’t afford feature creep or busy work. No slack time means no wasted time.

Every parent-developer already has this skill. You’ve been project managing under uncertainty since the day your kid was born. You just need systems that let you use your scarce time on decisions instead of execution.

The tools exist. The hours don’t need to. You just need to stop being the one who does the work and start being the one who decides what ships.

This is the TOOLS pillar of Raising Pixels — the parent developer’s toolkit. I write about computational thinking for kids, hands-on building projects, and the workflows that make it all possible when your coworker is three.

Subscribe now

There’s no shortage of developmental milestone charts. Rolling over by 4 months. First words by 12 months. Riding a bike by 5. Pediatricians have these mapped to the month.

But computational thinking? The skill set that arguably matters more than any other in the 21st century? Just vague advice to “introduce coding” at some undefined future date, usually involving an 8-year-old, a $200 robot, or a lot of screen time.

When I went from engineering director to SAHM, I realized that computational thinking isn’t some vague future course you’ll have to remember to enroll your kid in. Toddlers do it every day when they play with blocks, decide which clothes to wear, or negotiate for “one more story.” So I wrote the guide to toddler CS milestones that I couldn’t find.

This isn’t academic theory (though the research backs it up — Marina Umaschi Bers at Boston College has been studying computational thinking in early childhood for over a decade, and Jeannette Wing’s foundational paper on computational thinking made the case that it’s a universal skill, not just a CS major thing). This is what I’ve watched happen with my own kid, mapped against what developmental science tells us to expect. If your child is doing some of these things and not others, that’s normal. Kids aren’t firmware updates. They don’t all install features on the same schedule.

But it’s useful to know what you’re looking at.

Age 1-2: The Hardware Installation

Think of this phase as your child’s operating system booting up. They’re not “doing” computational thinking yet in any way you’d recognize. They’re building the prerequisite hardware: cause and effect, object permanence, basic categorization.

What you’ll see:

• Cause and effect loops. Drop the spoon, it falls. Drop it again, it falls again. Drop it thirty-seven more times because apparently the experiment needs replication. This is your child discovering that actions have predictable, repeatable outcomes — the absolute foundation of algorithmic thinking.

• Basic sorting by single attribute. Putting all the red blocks in one spot. Pulling all the books off the shelf (organizing by... accessibility?). They can group by at least one feature: color, shape, size.

• Sequential imitation. Copying a two-step action: open the cabinet, pull out the pot. They can’t invent sequences yet, but they can replicate short ones. That’s the beginning of following instructions — which is the beginning of understanding what instructions are.

• Trial and error without strategy. They’ll try to fit the square block into the round hole repeatedly, then accidentally succeed with the right one. No hypothesis yet. Just brute force. (But honestly, I’ve seen senior engineers debug this way too.)

What you won’t see (and that’s fine):

Planning. Abstraction. Multi-step reasoning. The prefrontal cortex is barely online. Don’t worry about it.

What to do:

Narrate cause and effect. “You pushed the ball and it rolled!” Name categories out loud: “That’s a big one. That’s a small one.” Let them fail at shape sorters. Some frustration is a motivator for learning.

Age 2-3: First Programs

This is when it gets interesting. Language explodes, and with language comes the ability to describe sequences, not just imitate them. Your child starts writing their first programs — they just don’t know it.

What you’ll see:

• Verbal sequencing. “First shoes, then outside.” They can describe a 2-3 step plan before doing it. This is pseudocode. Actual, literal pseudocode, just spoken by someone who pronounces “spaghetti” as “pasketti.”

• Multi-attribute sorting. “Big red cars here, small red cars there.” Two sorting criteria at once. This is a compound query. SELECT * FROM toys WHERE color = 'red' ORDER BY size.

• If/then reasoning (basic). “If it’s raining, we need boots.” They start predicting outcomes based on conditions. It’s not consistent yet — they might also predict that putting on boots will make puddles appear — but the structure of conditional logic is emerging.

• Pattern completion. Red, blue, red, blue, red. They can extend a simple AB pattern. Some kids start inventing their own patterns: “car, truck, car, truck.” This is the absolute seed of algorithmic thinking — recognizing a rule and applying it.

• Debugging with intention. The block tower falls and instead of random retry, they adjust. Bigger block on the bottom this time. They’re forming hypotheses about why things failed, even if the hypothesis is wrong. The method matters more than the accuracy.

What you won’t see:

Nested logic (”if it’s raining AND cold, we need boots AND a coat”). Abstraction beyond the concrete. Long multi-step planning. They’re still very bound to the physical and the present.

What to do:

Ask “what happens next?” constantly. Let them narrate routines, steps, recipes. Play pattern games with anything — toys, food, sounds. When something breaks or fails, say “why did that happen? Let’s look!” before jumping to fix it.

Building with AI at 2-3

My son and I built his first browser-based games with Claude at this age. He described what he wanted, I translated it into a prompt, he played and learned that his ideas can become things. His first game (”Make a red car game! Make it jump!”) transformed his whole relationship with a screen from consumer to creator.

Age 3-4: The Abstraction Leap

Something shifts around 3. I watched it happen in real time with my son. Your child starts operating on representations of things, not just the things themselves. They can think about thinking. Not philosophically — they’re three — but functionally.

What you’ll see:

• Representation and symbols. A stick becomes a sword. A box becomes a car. A line of couch cushions becomes a train. They’re using physical objects as variables — stand-ins that represent something else entirely. This is abstraction. Not metaphorical abstraction. Literal, computer-science-definition abstraction: stripping away irrelevant details to work with a simplified model.

• Algorithm narration. Not just “first this, then that” — they start dictating complete procedures. My son will explain how to make his favorite snack in six steps, in order, and get annoyed if I deviate from the protocol. He’s spec-writing. He’s defining an API. He’s three.

• Conditional branching. “If you sit properly at the restaurant, we’ll get dessert. If you’re disruptive, we’ll leave.” They understand that different inputs produce different outputs. They may also start manipulating the conditions (”But I wasn’t THAT loud!”), which is honestly just penetration testing the parental permission system.

• Decomposition. “I want to build a BIG house.” Okay, what do we need? “A foundation. And walls. And a door. And a roof.” They can break a big goal into component parts. Not always correctly. But the instinct to decompose is there.

• ABC and ABB patterns. They move beyond simple alternation. Red, blue, green, red, blue, green. Or red, red, blue, red, red, blue. The pattern recognition engine is getting more sophisticated.

What you won’t see:

Recursive thinking. True loop comprehension (they do things repeatedly, but don’t conceptualize “repeat until”). Error handling beyond one level (”what if the BACKUP plan fails?”).

What to do:

Build things together. Anything. Block towers, art projects, simple games. The act of specifying what you want, breaking it into steps, and iterating when it goes wrong IS the computational thinking curriculum. Ask them to explain their creations to you. “How does it work?” is the most powerful question you can ask a 3-year-old.

Building with AI at 3-4

This is the age my son started describing more complex games he wanted to build and watching them appear on screen. The computational thinking isn’t in the code — it’s in the specification. “I want a game where you drive a train through a maze with the arrow keys and it should pick up fallen branches and bring them to the garbage dump.” That’s a feature spec. From a kid who puts his shoes on the wrong feet 40% of the time.

What’s Next

He’s 3. According to the developmental research (Bers, Wing, Frontiers in Education), ages 4-6 is where loops, nested conditionals, and genuine systems thinking emerge. Kids start creating rule systems, optimizing their own algorithms, and transferring abstract concepts between domains.

I’ll write about it when I see it. Subscribe and you’ll get the ages 4-6 edition the same week I live it.

The Point

None of this requires a screen, an app, a robot, or a subscription.

The entire curriculum is four things: narrate what’s happening, ask questions, let them fail, build things together.

The milestones aren’t checkboxes — your kid might be a pattern recognition wizard who couldn’t care less about sequencing. That’s fine. The value isn’t grading your child. It’s learning to recognize computational thinking when it’s already happening so you lean into it instead of past it.

It’s happening right now. With the blocks. With the spoon drops. With the twenty-minute negotiation about whether pants are required.

You just have to know what you’re looking at.

I wrote the book on this — literally. 12 Weeks of Tech Projects to Build With Your Kid is the hands-on curriculum that turns these milestones into weekly activities. 12 weeks of projects designed for ages 2-6. No coding required. No screen dependency. Just you and your kid, building things that teach them to think.

There’s a genre of founder content that doesn’t apply to us. The one where someone quits their job, gets a MacBook, and ships a SaaS from a coffee shop in Lisbon. The 4-hour workweek, remixed for the AI era. Build fast, ship faster, iterate fastest.

We have a different constraint set. My co-founder is three, doesn’t nap anymore, and just learned that the letter combination S-T-O-P spells a word he can yell at maximum volume. My office is the kitchen counter (while my toddler snacks). My sprint window is the gap between bedtime and when I physically cannot stay awake.

Here’s the thing nobody tells you: those constraints aren’t a disadvantage. They’re a filter. They force you to build the right way.

The time budget (it’s enough)

A stay-at-home parent with one child, no naps, and no regular childcare has approximately this much daily availability for focused work:

• Before kid wakes up: 0–90 minutes (depends on your alarm discipline and their sleep schedule)

• During independent play: 15–45 minutes (fragmented, interruptible)

• After bedtime: 90–180 minutes (your only reliable block)

Total: 2–5 hours per day. But “hours” is misleading. Context-switching between parenting and deep work has a cognitive cost that research consistently pegs at 23 minutes to regain focus (Gloria Mark, UCI). So your 25-minute play break isn’t 25 productive minutes. It’s ramp-up time plus the shallow work you can likely get done in the remaining 2 minutes.

Your real number: 90–180 minutes of quality focus time per day. Some days less. Some days zero. Sick days, bad sleep nights, developmental leaps — these all eat into a budget that was already lean.

Here’s why that’s still enough: 90 minutes a day, compounded over a year, is 540 hours. A typical solo founder without children has 6–10 focused hours daily — but they also spend a lot of those hours on the wrong things. You can’t afford that luxury, which means every hour you spend is deliberate. Constraints create clarity.

540 hours is enough to write a book. Build a product line. Launch a newsletter. Establish a real revenue stream. That’s not just theory — I’ve done all of those in the last six months alone.

The childcare question

The obvious lever: hire childcare, buy more time. The honest challenge: childcare costs money you might not have yet.

Average US childcare in 2026: $24,243/year in DC, $12,000–$18,000 in most metros. Part-time (3 mornings a week) runs $500–$800/month. The Care.com 2026 Cost of Care Report found parents spend 20% of household income on childcare — nearly triple what HHS considers affordable.

The math: to justify $600/month from business revenue, you’d need roughly $9,000 in gross sales per year on Gumroad (after fees and processing). On a $29 product, that’s about 26 units per month.

Most digital products don’t hit that number in year one. So what do you do?

You bootstrap through the gap. You build the first product in those 90-minute windows. You ship it before the childcare math makes sense. And then, if you want to, you use early revenue to buy back time incrementally — a mother’s helper two mornings a week, a swap with another parent, a few hours of drop-in care. The gap is real, but it’s temporary. The product you build during the gap is what closes it.

Why “hustle harder” is the wrong advice

The “build while your kids sleep” advice works for a sprint — ship something in two weeks of late nights. Late nights don’t work as a lifestyle. Chronic sleep deprivation degrades decision-making to a measurable degree — 17–19 hours without sleep equals a BAC of 0.05% (Williamson & Feyer, 2000). Impaired founders ship products with bugs, copy with typos, and pricing mistakes they don’t catch.

The smarter move: protect your 90-minute window like it’s sacred. Don’t expand your hours. Expand what you accomplish in them with clear goals and strict scope. The constraint isn’t your enemy — the temptation to fight it is.

The business model that fits

If your daily focus window is 2 hours, you need a model that matches. Some models fight your schedule:

• Client services (freelance, consulting): Requires synchronous availability and responsive communication. Incompatible with all-day childrearing and unpredictable days.

• SaaS with support obligations: Uptime, bug reports, feature requests — all on someone else’s timeline.

• Content that requires daily posting: Unless you’re disciplined with batching in advance, the algorithm rewards consistency your schedule can’t guarantee.

Some models work with it:

• Digital products with zero marginal cost: Ebooks, templates, courses, prompt packs. Build once, sell forever. No inventory, no fulfillment, no schedule.

• Async content: Newsletters on a weekly cadence you control. Not daily — weekly.

• Tools with minimal support: Open-source with community maintenance. Paid add-ons on platforms that handle distribution.

The operating principle: your work and your revenue need to be decoupled in time. You do the work at 10pm. Someone buys at 3pm the next day while you’re at the playground. If the business requires you to be present when the customer is, pick a different model.

The identity evolution

This is the part that has nothing to do with math and everything to do with whether you keep going.

You used to be an engineer. Or a designer. Or a PM. You had a title, a team, a salary. People knew what you did.

Now you’re someone who makes peanut butter sandwiches with the crusts cut off and occasionally opens a laptop after 8pm. The temptation is to prove you still have it — over-engineer a SaaS, build something complex, show the market you haven’t gone soft.

The ego project is the most expensive mistake a parent founder can make, because it consumes your scarcest resource — focus time — on something the market didn’t ask for.

The businesses that work for parents are usually satisfyingly simple. An ebook, not a platform. A template, not a framework. A curated resource, not a custom tool. Simple ships faster. Simple needs less maintenance. Simple survives the weeks when your kid has a stomach bug and you haven’t opened your laptop in five days.

And here’s what the identity crisis misses: you didn’t lose your skills. You gained a constraint that makes you a sharper builder. The person who can ship a product in 90-minute increments between bedtime and exhaustion is a more disciplined operator than someone with unlimited runway and no urgency.

The unfair advantages

The constraints are real. They’re also an edge.

You have no exit pressure. No investors, no runway, no board meetings. If your product makes $500/month and that covers groceries, it’s working. You can iterate for years at a pace that would get a VC-backed founder fired. Time horizon is your moat.

You’re battle-tested. Project management with a toddler is project management under uncertainty — no sprint planning, no tickets, and a stakeholder who changes requirements every 30 seconds. If you can ship under those conditions, you can ship under any conditions.

Your story resonates. The market is full of polished founders with perfect launches. A parent who built something real in the margins of a chaotic life? That’s a story people root for, share, and buy from.

The bottom line

Building a business as a stay-at-home parent is slower than the inspiration posts suggest. The math is real. The time is limited.

But 540 hours a year, spent deliberately, compounds into something significant. Not a startup. Not a unicorn. A business that works on your terms, at your pace, that doesn’t require you to choose between building something and being present for the person you’re building it for.

Subscribe now

The other day, he stopped eating them and started lining them up instead. Yellow ones here. Orange ones there. Red. Then the weird reddish-brown ones that look like they can’t decide what they are. He made a rainbow across the counter, completely unprompted.

A few days later, we sat down and built a sorting game on the computer. Emoji animals and emoji vehicles appear on screen, and you drag them to either a garage or a grassy field. He got it instantly — he’d already done the hard cognitive work of sorting with tomatoes, and many other things before that. The screen version was just a new surface for something he already understood.

Physical first, digital second; that way, they’ve something to relate the latter to.

Why Physical Matters

Young kids learn through their bodies first.

Piaget’s stages of cognitive development place children under seven in the preoperational stage, where thinking is tied to concrete, tangible experience. Abstract reasoning — the kind screens demand — doesn’t fully develop until much later. Children at this age think by doing. They need to touch, move, sort, stack, and break things to build mental models.

Montessori figured this out over a century ago: concrete before abstract. Let children manipulate real objects until the concept lives in their hands, then introduce the symbolic version. Research in embodied cognition backs this up — physical manipulation creates sensorimotor traces that anchor learning in ways that flat visual input alone doesn’t.

When my son sorted tomatoes by color, he was making decisions. This one’s orange, not red. This one’s in between — where does it go? That’s where the cognitive exercise is occurring. The sorting game on the computer just gave him a new context to exercise the same skill.

Screens are visual and auditory only. That’s fine for adults who have decades of physical experience to draw on. But for a three-year-old still building those mental models, starting on a screen is like reading the manual before seeing the tool. You’ve got a thin concept of it without real texture or heft.

I’m not anti-screen. My son learned to read with an iPad app, and we build browser games together for fun. But I’ve noticed a clear pattern: when we do a physical version of a concept first, the digital version lands faster, sticks better, and is way more fun for both of us.

The Pattern

1. Physical exploration. Hands-on, no screens. The concept shows up through play.

2. Connection. Talk about what just happened. “You sorted the tomatoes by color — what other ways could we sort them?”

3. Digital creation. Build something on the computer that uses the same concept. “Want to make a sorting game?”

4. Play. Actually play with what you built. The kid sees their physical understanding reflected on screen.

The bridge between steps 2 and 3 is where the magic happens. When my son sits down at the computer after sorting tomatoes, he’s not encountering “sorting” for the first time. He’s recognizing it. “Oh, this is like the tomatoes!” The concept transfers.

Real Examples

Here’s how this plays out with different computational thinking concepts:

Sequencing

Physical: Steps for washing the car. First you rinse it. Then soap. Then scrub. Then rinse again. Order matters — soap without water does nothing.

Digital: We made a car wash game where tools appear on screen (water, soap, sponge) and you click them in the right order to wash the car. He already knew the sequence from doing it real life. The game just let him practice it on repeat without the running water.

Patterns

Physical: I point these out to him everywhere. Stripes on a crosswalk. Alternating fence posts. The rhythm of windshield wipers. Once you start noticing patterns, a three-year-old will not let you stop.

Digital: We made a pattern prediction game using images of his favorite airplanes. A sequence appears — Airbus Beluga, Super Guppy, Airbus Beluga, Super Guppy — and he picks what comes next. He was already pattern-hunting in the wild, the airplane game just made it even more interesting.

Loops

Physical: Cleaning up his toys. Pick up a block, put it in the bin. Pick up a block, put it in the bin. Same action, repeated until done. That’s a loop.

Digital: A maze game where you move a character forward by repeatedly pressing the arrow key. The loop concept already had a physical anchor from cleanup time – continue until complete.

Cause and Effect

Physical: Matchbox cars on a ramp. Place the car at the top, let go, it rolls down. Line up wood blocks like dominoes and knock them over. Every action has a visible, immediate consequence.

Digital: This is every game we’ve ever made. Click a button, something happens. Change a number, something changes. But the ramps and the blocks came first, and that’s why cause-and-effect on screen already makes sense to him.

What the Research Actually Says

Most developer parents skip straight to the screen — we live there, we can explain sorting abstractly, why bother with tomatoes? Because we’re not three. We have decades of physical experience backing every abstract concept we encounter. A toddler doesn’t have that yet. And the research explains why it matters.

Piaget’s concrete operational framework established that children under seven learn through direct manipulation of their environment — they literally cannot reason abstractly yet. Their thinking is bound to what they can see and touch.

Research on embodied cognition in children shows that physical manipulation creates sensorimotor memory traces that persist and transfer to new contexts. When a child sorts objects with their hands, they’re not just learning “sorting” — they’re building neural pathways that activate again when they encounter sorting in a different form.

A 2017 study on embodied math learning found that physical manipulation of objects before abstract representation improved both understanding and transfer — but only when the physical activity was directly connected to the concept. Random hands-on play didn’t help. Intentional physical exploration of the same idea they’d later encounter digitally did.

This is why the pattern matters. It’s not “play outside then do screen time.” It’s “explore this specific concept physically, then build this specific concept digitally.” The connection between the two is everything.

The Permission to Be Low-Tech

There’s a weird pressure in the developer parent community to start kids on technology as early as possible. As if your professional identity depends on your toddler being tech-forward.

Your three-year-old sorting cherry tomatoes on a cutting board isn’t falling behind, they’re building the cognitive scaffolding that will make every future digital experience meaningful instead of superficial.

No need to rush past the physical parts. The screens will be there later, but the tomatoes won’t keep.

This essay is part of the thinking behind 12 Weeks of Tech Projects to Build With Your Kid — a hands-on curriculum for ages 2-6 that pairs physical activities with AI-assisted game building. No screens required for most of it.

He stacked two triangular prisms together and ran a matchbox car down the slope. A ramp.

Then he added a flat block at the top. Now the car could drive up the ramp onto a platform. The ramp wasn’t a ramp anymore — it was a driveway.

Then he added a gantry over the platform. Declared the whole thing a race course. Started lining up cars at the top.

He didn’t sit down and think “I’m going to build a race course.” He built a ramp, and the ramp told him what it wanted to be next.

The Bricoleur

In 1962, anthropologist Claude Lévi-Strauss described two fundamentally different ways humans create things. The engineer starts with a plan — a blueprint, a specification, a clear picture of the end goal — and then acquires the exact materials needed to execute it. The bricoleur starts with whatever’s at hand and builds by rearranging, adapting, and responding to what emerges.

Lévi-Strauss wasn’t ranking them. He was arguing they’re equally sophisticated ways of thinking. But if you’ve spent any time in schools or workplaces, you know which one gets all the respect.

Almost thirty years later, MIT researchers Sherry Turkle and Seymour Papert observed the same split in how children learn to program. Some kids planned their program top-down: outline the structure, define the functions, then fill in the details. Others — the bricoleurs — came up with a set of instructions, ran it, reacted to what happened, adjusted, ran it again. They were in conversation with the material.

The planners’ result wasn’t better. It was just more legible to teachers who’d been trained to value planning. Turkle and Papert called this bias a failure of “epistemological pluralism” — a fancy way of saying we only recognize one style of thinking as real thinking.

My three-year-old doesn’t know any of this. He just builds the way that feels natural, which happens to be the way Lévi-Strauss described, Turkle and Papert validated, and every maker space on earth now tries to teach back to adults.

What the Blocks Are Saying

Here’s the thing about the race course: each step made sense only in context of the step before it.

The platform made sense because the ramp existed. The gantry made sense because the platform existed. If you’d asked my son at the beginning “what are you building?” he would have said “a ramp” — because that’s all it was. The race course didn’t exist yet. It couldn’t exist yet. It emerged from the building.

This is what Papert meant when he described learning as a conversation between the builder and the thing being built. The blocks aren’t passive raw materials. They’re participants. Every time my son placed one, the structure changed — and the changed structure suggested new possibilities. The ramp became an entryway the moment the platform appeared beside it. The context shifted.

Mitchel Resnick, Papert’s student at MIT and the creator of Scratch, later formalized this as the Creative Learning Spiral: imagine, create, play, share, reflect, imagine again. It’s the cycle that drives kindergarten — and, he argues in Lifelong Kindergarten, it’s how the most creative work happens at every age. We just stop calling it learning and start calling it “iterative design” or “rapid prototyping” somewhere around middle school.

What We Train Out of Them

Every formal education system I’ve encountered — and I went through a lot of them to earn my Masters — eventually teaches children to plan before they build. Outline before you write. Spec before you code. Know what you’re making before you start making it.

This is useful. I’m not arguing against blueprints. If you’re building a bridge, please have a blueprint.

But there’s a cost to making planning the only acceptable mode. When “what are you building?” always requires a confident answer before you’re allowed to pick up the materials, you lose something. You lose the willingness to start without knowing where you’ll end up. You lose the ability to let the work talk back to you. You lose the ramp that becomes a race course.

Turkle and Papert saw this concretely: children who naturally built in the bricoleur style were marked down, redirected, told to “plan it out first.” Not because their programs didn’t work — they worked fine — but because the process looked wrong to adults who’d been trained in the engineering style.

Papert spent his career pushing back on this. His argument wasn’t that planning is bad. It was that we systematically undervalue building-as-thinking. When a kid stacks blocks and discovers something he didn’t intend, that’s not a failure of planning. That’s cognition. That’s how humans have made things for most of our history. The blueprint is the newcomer.

The Feedback Loop

What makes my son’s block play look like play and a designer’s prototype sprint look like work? (A paycheck?)

Build something small. Look at what you built. Respond to what you see. Build the next thing. The feedback loop is the same whether you’re three years old with wooden blocks or thirty years old with a Figma prototype.

The race course emerged from forty-five seconds of iterative building. Ramp → platform → gantry → “it’s a race course!” Each cycle took maybe ten seconds. No hesitation. No “is this good enough to show someone?” Just build, observe, respond.

This is the loop I try to protect. Not because I want to raise a kid who never plans — he’ll learn that skill, and it’s a good one. But because the instinct to start building and let the thing tell you what it wants to be is rare and valuable and very, very easy to train out of someone.

Try This

Next time your kid is building something — blocks, LEGO, a pillow fort, a drawing — resist the urge to ask “what are you making?” at the beginning.

Just watch.

Watch how each piece responds to the last. Watch the project change identity midstream. Watch a tower become a bridge become a house become a rocket ship. That’s not indecision. That’s a conversation between a builder and a material, playing out in real time.

That’s the feedback loop that drives all creative work. Your kid just hasn’t learned to be self-conscious about it yet.

Protect that.

This essay is part of the thinking behind 12 Weeks of Tech Projects to Build With Your Kid — a curriculum designed around exploration-first learning for ages 2-6.

References

• Lévi-Strauss, C. (1962). The Savage Mind. University of Chicago Press.

• Turkle, S. & Papert, S. (1990). “Epistemological Pluralism: Styles and Voices within the Computer Culture.” Signs, 16(1), 128-157.

• Papert, S. (1980). Mindstorms: Children, Computers, and Powerful Ideas. Basic Books.

• Resnick, M. (2017). Lifelong Kindergarten: Cultivating Creativity through Projects, Passion, Peers, and Play. MIT Press.

What we didn’t know: Cocomelon switches scenes every one to two seconds. That’s not an accident. It’s engineered — focus-grouped, A/B-tested, optimized for one metric: watch time. The rapid cuts trigger an orienting response — the involuntary reflex your brain has to novel visual stimuli. Every cut is a tiny dopamine hit. Your toddler isn’t watching. They’re being held.

The first time we said “no more Cocomelon,” our son had a meltdown. Not a tantrum — a withdrawal. Screaming, inconsolable. That convinced us.

We went cold turkey. And here’s the thing: he’s fine. He’s on screens plenty now — building games, typing in his tiny-terminal, using apps we chose deliberately. When we say “okay, time to go outside,” he goes. No meltdown. No negotiation. The difference isn’t less screen time. It’s different screen time.

That experience is what led me to the only framework I’ve found that actually helps.

The Spectrum

Every interaction your kid has with technology falls somewhere on a line. On one end: pure consumption. On the other: pure creation.

Consumer end → Watching YouTube, streaming shows, scrolling. The screen asks nothing of your child except their eyeballs and attention.

Creator end → Designing a game, directing what gets built, making decisions, giving feedback, iterating. The screen doesn’t work without your child’s input.

Most things fall somewhere in between. Minecraft creative mode is further right than watching Minecraft YouTube. Drawing on an iPad is further right than scrolling through a feed. Same device, wildly different cognitive engagement.

The framework is simple: instead of “less screen time,” aim to shift right on the spectrum. That you can actually do something with.

The Research Backs This Up

This isn’t just a nice mental model. The science increasingly distinguishes between passive and active screen engagement — and finds they have very different effects on developing brains.

Michaeleen Doucleff’s Dopamine Kids (2026) makes the neuroscience explicit: dopamine doesn’t give pleasure — it makes you want. Screens optimized for engagement create wanting loops, not satisfaction. Your kid isn’t enjoying the content. They’re trapped in a craving cycle. Doucleff’s diagnosis is exactly right. But here’s where I diverge: the prescription isn’t “fewer screens.” It’s “different screens.” A terminal where your kid types commands and a feed that auto-plays the next video trigger completely different dopamine profiles — even though both involve a glowing rectangle.

Lillard & Peterson (2011) randomly assigned 4-year-olds to watch either a fast-paced cartoon (SpongeBob), an educational show, or draw with crayons for nine minutes. The fast-paced group performed significantly worse on executive function tests immediately afterward — self-regulation, working memory, the cognitive skills that let kids focus and make decisions. Nine minutes.

Cocomelon is faster-paced than SpongeBob.

Radesky & Christakis (2016) at the University of Michigan and Seattle Children’s Research Institute reviewed the evidence on screen time and early childhood development. Their key finding: it’s not the screen itself that matters, it’s the nature of the interaction. Passive viewing correlates with attention problems and language delays. Interactive, co-viewed media doesn’t show the same pattern — and in some cases shows benefits.

A 2021 Frontiers in Education study on passive vs. active screen time and phonological memory in young children found significant differences: passive screen time was associated with lower cognitive performance, while active screen time showed no such effect. Same screens. Different engagement. Different outcomes.

The Australian Government’s original screen time guidelines (2011) recommended zero screen time under 2, based on the assumption that all screen activities are “physically and cognitively sedentary.” Subsequent research has challenged this — showing that interactive media can support cognitive development in ways passive viewing doesn’t. The blanket timer approach conflates two fundamentally different experiences.

This is why “is Cocomelon bad?” and “is Minecraft bad?” are the wrong questions. The right question is: what is my kid doing? Are they making decisions, or just receiving stimulation?

The Cocomelon Test

Here’s a quick diagnostic I use now when evaluating any screen activity:

Can my kid walk away from it easily?

This sounds simple but it’s surprisingly revealing. When my son was watching Cocomelon, turning it off triggered a crisis. That’s the hallmark of a passive dopamine loop — the content does the work of engagement, and removing it feels like withdrawal.

When he’s building a game with me, or playing in his terminal, or drawing on the iPad — and I say “okay, time for dinner” — he might grumble, but he transitions. Because he was driving the experience. He was the active agent. Stopping doesn’t feel like something being taken away. It feels like pausing something he can come back to.

If your kid loses it every time you turn off a specific app or show, that’s a signal. Not that screens are bad, but that this particular screen experience is in the passive consumption zone.

Why “Set a Timer” Doesn’t Work

Most screen time advice boils down to: pick a number of minutes, set a timer, feel responsible. The AAP says one hour for ages 2-5. The WHO says less.

The problem is that timers treat all screen time as equal. Thirty minutes of building a game and thirty minutes of watching someone else play a game register the same on the clock, but they are fundamentally different experiences for your kid’s brain. One is creative work that happens to involve a screen. The other is television with a touchscreen.

When you feel guilty about your kid’s screen time, check the spectrum position before checking the clock. If they’re actively creating — making choices, giving instructions, iterating on ideas — the guilt is probably misplaced. If they’re slack-jawed and glazed, that’s your signal to redirect, not just restrict.

Shift Right

Here’s how this works in daily life:

Audit activities, not minutes. List every tech thing your kid did this week. Place each one on the spectrum. Look at the ratio. Most unsupervised screen time lands on the consumer end. That’s a design insight.

Choose tools that require input. Apps and activities that don’t work without your kid’s participation naturally land further right. A drawing app is better than a video player. Building a game together is better than both.

Be the co-pilot, not the bouncer. The guilt-driven approach is restriction: set limits, enforce them. The design-driven approach is redirection: what if screen time was something you did together, where your kid steered?

Name what’s happening. Kids can learn the difference. “Right now you’re watching. Want to make something instead?” Over time, they start to prefer creation — because it’s genuinely more rewarding than consumption when you give them the option.

What Changed for Us

After we cut Cocomelon, we didn’t go anti-screen. We went pro-creation. My son practiced his phonics with YouTube videos, his critical thinking skills with GCompris games. He now builds browser games with me. He draws on the iPad and explains what he’s doing.

Is it screen time? Yes. Does it look anything like that fourteen-month-old, glued in place, watching highly-saturated flashing picture nonsense for the fortieth consecutive minute? Not even close.

The device is neutral. A screen showing Cocomelon and a screen showing your kid’s own game are the same hardware doing completely different things to their brain. One is engineered to hold attention. The other develops it.

You don’t need less screen time. You need better screen time. And now you have a framework to tell the difference.

If you want structured activities that live on the creator end of the spectrum, that’s exactly what I built: 12 Weeks of Tech Projects to Build With Your Kid — 60 activities for ages 2-6, mostly unplugged, designed around exploration-first learning.

References

• Lillard, A.S. & Peterson, J. (2011). “The immediate impact of different types of television on young children’s executive function.” Pediatrics, 128(4), 644-649.

• Radesky, J.S. & Christakis, D.A. (2016). “Increased Screen Time: Implications for Early Childhood Development and Behavior.” Pediatric Clinics of North America, 63(5), 827-839.

• Kostyrka-Allchorne, K., Cooper, N.R. & Simpson, A. (2021). “Short- and Long-Term Effects of Passive and Active Screen Time on Young Children’s Phonological Memory.” Frontiers in Education, 6, 600687.

• Sweetser, P., Johnson, D., Ozdowska, A. & Wyeth, P. (2012). “Active versus Passive Screen Time for Young Children.” Australasian Journal of Early Childhood, 37(4), 94-98.

I’ve been a developer for over a decade — web apps, APIs, infrastructure — but game dev always felt like a different discipline. Engines, physics libraries, sprite sheets. Then my three-year-old said “make me a game where a red car goes fast” and I opened Claude instead of Unity.

We made it. It was playable. He loved it. We’ve built dozens since.

Here’s everything I’ve learned about the process.

What You Actually Need

An AI chatbot. Claude, ChatGPT, Gemini — any of the major ones. The technique is the same across all of them.

A web browser. That’s it. We build simple HTML/CSS/JavaScript games that run in a browser tab. Completely sufficient for young kids. No installs. No build tools. No dependencies.

A kid with opinions. (This is the easy part.)

You do NOT need game development experience, knowledge of any game framework, art skills, sound design skills, or a CS degree (though it helps for debugging).

The Basic Flow

Here’s how a typical session goes in our house:

Step 1: The kid has an idea. “I want a game where a delivery truck drives through a maze.”

Step 2: You help translate it into a prompt. “Create a simple HTML game where the player drives a delivery truck through a maze using arrow keys. There are houses along the route — when the truck reaches a house, it delivers a package and the house lights up. Add a counter for deliveries completed. Keep it simple and colorful, suitable for a 3-year-old.”

Step 3: The AI generates code. You get back a complete HTML file with embedded CSS and JavaScript. Save it as .html, open it in your browser.

Step 4: The kid reacts. “Make the truck yellow.” “Add more houses.” “I want a warehouse where you pick up the packages first.”

Step 5: You iterate. Feed the feedback back to the AI. “Change the truck color to yellow. Add a warehouse at the start where the truck loads packages before delivering. Add more houses to the route.”

Step 6: Repeat steps 4-5 until the kid is satisfied or hungry.

That’s the entire game development cycle. Your kid’s imagination, an AI that writes code faster than you can explain what you want, and a browser.

Prompting Tips (The Practical Stuff)

After building a lot of these, here’s what works:

Start way simpler than you think.

Your first prompt should describe a game that a first-year CS student could build. One mechanic. One interaction. One thing on screen. You can always add complexity later, but starting complex usually produces buggy, tangled code that’s hard to iterate on.

Good first prompt: “Make an HTML game where a red circle follows the mouse cursor and collects yellow stars that appear randomly.”

Too ambitious first prompt: “Make a 2D platformer with multiple levels, power-ups, enemies with AI pathing, and a save system.”

Specify the audience.

Always mention that this is for a young child. It changes the AI’s output in useful ways: bigger click targets, brighter colors, simpler controls, more forgiving collision detection.

Ask for everything in one file.

“Put all HTML, CSS, and JavaScript in a single HTML file.” This makes it trivial to save and run. No build step, no dependencies, no module imports that break.

Request mobile/touch support.

“Make it work with both mouse/keyboard and touch.” Toddlers are surprisingly good with touchscreens, and this means the game works on your phone or tablet too.

When things break (and they will):

Copy the error from the browser console and paste it directly to the AI. “When I click the truck, I get this error in the console: [error]. Fix it.” Or if there’s no error, describe it: “When I press the down arrow, the page moves instead of the truck.” AI is excellent at debugging its own code.

What Your Kid Actually Learns

Here’s the part that surprised me: building games this way is sneakily educational, even though it feels like pure play.

Decision-making. Every feature request is a design decision. “Should the truck be fast or slow?” “What happens when you crash?” Your kid is learning to think about cause and effect in a system.

Iteration. The game is never right on the first try. Your kid learns that making things is a process of attempt → evaluate → adjust. That’s the most important meta-skill in all of technology.

Systems thinking. “When I added the dinosaur, the truck stopped working.” Things are connected. Changes have consequences. Welcome to software.

Creative expression. Your kid’s game is their game. Not a game they downloaded. Not a game someone else designed. It has their ideas, their aesthetics, their dinosaur-on-a-garbage-truck vision. That ownership compounds interest.

Common Pitfalls

Don’t optimize too early. Your kid doesn’t care about code quality. They care about whether the dinosaur is big enough. Ship the feature, clean up later (or don’t — these are throwaway games).

Don’t take over. It’s tempting to start adding your own ideas. “What if we add a leaderboard? What about particle effects?” Let your kid drive. Your job is to translate their ideas into prompts, not to impose your own.

Don’t expect polish. AI-generated games look like AI-generated games. They’re functional and fun, but they won’t win any design awards. That’s fine. Your kid genuinely does not care that the truck is a rectangle with two circles for wheels.

Don’t make it a lesson. The moment you say “this is teaching you about algorithms,” the magic dies. Just build. The learning happens in the background.

One More Thing

The games we build might be objectively terrible. The collision detection is approximate. The graphics are basic shapes. The physics are suggestions at best. My son’s current favorite is a car wash game – you literally wash a car. Click on water, click the car. Click on soap, click the car. Some elements overlap others and there’s a bug when you click on the sponge too early – but it’s fine. It works well enough and he’s played it about a hundred times already.

He made it. That’s why.

You don’t need game dev experience to give your kid that feeling. You need an AI, a browser, and the willingness to build a really, really bad game about garbage trucks.

It just might be the best thing you ship all year.

I know that sounds ridiculous. Your kid can’t read. They put stickers on the dog. They had a meltdown yesterday because their banana broke in half. Computer science?

Yeah. Computer science.

Not the “writing Python” kind. The thinking kind. The patterns and problem-solving strategies that underpin all of computing — and, conveniently, also underpin being a functional human. You practice them with your kid every single day. You just don’t call them that.

1. Sorting Laundry → Pattern Recognition & Classification

“Can you put all the socks in this pile?”

Congratulations, you just taught categorization. Your toddler looked at a heap of mixed objects, identified a shared attribute (sock-ness), and grouped items accordingly. That’s pattern recognition and classification — foundational concepts in computer science.

My son’s current favorite version of this: sorting cars by color. Red cars here, blue cars there. Sometimes he invents his own categories. “These are the fast ones.” By what criteria? “They look fast.” Hard to argue with that methodology.

The computational thinking is in the sorting itself — the act of looking at a set of things, defining a rule, and applying it consistently. That’s what databases do. That’s what machine learning does at scale. Your kid is doing it with socks.

Level up: Let your kid invent the categories. “How should we sort these?” gives them practice defining the classification rules, not just applying yours. That’s a step closer to algorithm design.

2. Following a Recipe → Sequencing & Algorithms

“First we put in the flour. Then the eggs. Then we stir.”

That’s an algorithm. A set of sequential instructions that produce a specific output. Your toddler is learning that order matters — that putting eggs in before flour produces a different result than the reverse. (A messier result, usually, in our kitchen.)

Every time you walk your kid through a sequence — getting dressed (underwear before pants, the eternal lesson), brushing teeth, making a sandwich — you’re teaching them sequential thinking. Step 1, then step 2, then step 3.

My son narrates sequences back to me. “First we put on shoes. Then we go outside. Then we walk to the park.” He’s writing pseudocode and he can barely spell his own name.

Level up: Introduce conditionals. “If it’s raining, we need boots. If it’s sunny, we need sandals.” Now you’re teaching if/else logic with weather and shoes.

3. “Try Again” → Debugging & Iteration

Your toddler is building a block tower. It falls. “Try again!” you say.

But here’s the thing — you don’t just say “try again.” You say “why did it fall?” Maybe the base was too small. Maybe he put the big block on top of the small block. Maybe he bumped the table.

That’s debugging. Identify the failure → hypothesize the cause → try a fix → test.

This is honestly the computational thinking concept that toddlers practice most, because toddlers fail at things constantly. Every single day is a gauntlet of attempts, failures, adjustments, and retries. Pouring water, climbing, puzzles, zippers — it’s all debugging.

The parent’s role here is critical: resist the urge to just fix it for them. (It’s very hard, I know.) I see the tower wobbling before he puts the last block on, and yet, I sit still and watch it fall. Then I ask: “What happened? What could you do differently?” Sometimes he has an idea. Sometimes he says “I don’t know” and I offer one suggestion. Sometimes he just knocks everything down and walks away, which is also a valid approach to debugging in my professional experience.

Level up: When something goes wrong, externalize the process. “Let’s figure out what happened. Let’s try something different. Did that work better?” You’re teaching the debug loop explicitly.

4. “What If?” → Abstraction & Hypothetical Thinking

“What if the car could fly?”

“What if we built a really, really big tower?”

“What if we had dessert before dinner?”

Every toddler lives in a constant state of “what if.” And “what if” is the engine of computational thinking — it’s abstraction. Taking a concrete situation and imagining variations on it. Changing one variable and reasoning about the consequences.

When my son says “what if the car goes REALLY fast?” he’s doing something that programmers do all day: taking a system, modifying a parameter, and predicting (or testing) the outcome. He just thinks it’s fun.

This is also the root of simulation and modeling. “What if” is how engineers think about systems before building them. Your toddler is running mental simulations every time they imagine an alternative scenario.

Level up: Play the “what if” game actively. “What if we didn’t have spoons? How would we eat soup?” Let them reason through the implications. You’re building their ability to think about systems abstractly.

5. Giving Directions → Decomposition & Clear Instructions

“Tell me how to get to your room.”

If you’ve ever asked a toddler for directions, you know the results are... imprecise. “You go... that way... and then you go... up... and then it’s there!”

But the attempt is what matters. They’re trying to break down a complex task (navigating a house) into discrete steps (go this way, go up, arrive). That’s decomposition — taking a big problem and splitting it into smaller, manageable pieces.

And when their directions don’t work (”that way” while pointing vaguely at the ceiling), they learn something crucial: instructions need to be specific. The person following them (or the computer executing them) can’t read your mind. You have to be explicit.

My son recently tried to tell me how to draw a truck he’d seen. “Draw the wheels. And the front thing. And the other thing.” When my drawing didn’t match his vision, he got frustrated. “No, the SQUARE thing.” He was learning, in real time, that vague instructions produce vague results. That’s literally the core lesson of programming. (We got there eventually — it was a Jeep Renegade.)

Level up: Play “robot game.” Your kid gives you instructions and you follow them exactly as stated, even when they’re clearly wrong. “Walk forward” — you walk into a wall. They learn fast that instructions need to be precise. (This game is also hilarious.)

Why This Matters

I’m not writing this so you can brag at playgroup that your toddler understands algorithms. (Although you can. I won’t stop you.)

I’m writing this because if you’re a developer who wants to eventually share your world with your kid — teach them about technology, build things together, help them think computationally — you’re not starting from zero.

You’re already doing it.

Every sorted sock pile, every recipe followed, every block tower rebuilt, every “what if” entertained, every set of wobbly directions given — those are the building blocks of computational thinking. When your kid is eventually ready for more structured tech experiences, they’ll already have the cognitive scaffolding in place.

You’re giving them a computer science education every day, in the most natural way possible: through play.

Just maybe throw in a few more “what ifs” at dinner. You know, for the algorithm development.

He couldn’t read. He couldn’t type. But he could sit next to me and say: “Make a red car game! Make it jump!”

So I typed his words into an AI coding tool. A red car appeared. He pressed space bar. It jumped.

His face did the thing — that wide-open, full-body joy that kids have before the world teaches them to play it cool. Then he said: “Make it go faster. Can we make it a digger?”

He was designing. He was iterating. He was two.

I’m a software engineer. 12 years building software, master’s in CS. And the most useful thing I’ve ever taught my kid about technology didn’t involve a screen — it was a sequence. First this, then that, then done.

That’s computational thinking. Not coding. Thinking.

Here’s what nobody tells dev parents: there’s no reason to wait. The neural pathways for sequential reasoning, pattern recognition, conditional logic — those are forming right now, between ages 2 and 6. Your kid is already doing computational thinking when they sort toys by color or figure out that pushing a button makes a sound. They just don’t have anyone connecting the dots.

So I wrote the curriculum I couldn’t find

I wanted hands-on activities. AI-assisted game building where the kid directs and the parent types. Actual CS concepts. A structure a tired parent could follow without prep.

It didn’t exist. So I built it.

12 Weeks of Tech Projects to Build With Your Kid — computational thinking for ages 2-6.

Each week covers one concept (sequences → patterns → loops → conditionals → debugging → all the way to integration). The rhythm:

• Mon-Tue: Hands-on activities. No screens. Sorting games, pattern hunts, chain reactions with dominos.

• Wed: Build a browser game with AI. Kid describes, you type.

• Thu: Remix day. Kid changes the game — new colors, new rules, harder levels.

• Fri: Kid “teaches” the concept to a stuffed animal. If they can explain it, they own it.

The format has been tried and tested on my actual 3-year-old. The kid who earned the nickname “Mr Wiggles” at a year old and would rather hurl paper airplanes/play excavators/race cars than sit still for literally anything. If it survived his attention span, it made the cut.

The magic is AI-assisted game building. AI removes the bottleneck. Your kid describes a game in plain language, watches it appear, then iterates. The feedback loop is instant. They’re the product manager, the designer, and the QA team.

You’re just the typist.

This isn’t about raising the next Zuckerberg. It’s about giving your kid the same thinking framework you use every day — while their brain is literally built to absorb it.

The book: 12 Weeks of Tech Projects to Build With Your Kid — $29 on Gumroad. PDF you can mark up and reprint.

I also made companion products because I’m like this:

• 41-Prompt AI Pack ($17) — Copy-paste prompts for ChatGPT/Claude, each with a [CHILD’S INTEREST] placeholder. Three per concept: a story prompt, a hands-on activity prompt, and a browser game prompt. Swap in “monster trucks” or “butterflies” and go.

• Screen Time Conversation Cards ($0+) — 10 screen-free discussion prompts you can use anywhere. Car, bath, dinner. No materials needed.

• Unplugged Expansion Pack ($12) — 12 additional screen-free activities (one per concept), all household items.

• “What Are They Learning?” Cheat Sheet ($5) — Quick reference for each concept.

• Complete Toolkit Bundle ($39) — Everything above plus bonus activity cards. Save $24.

Browse everything at shop.raisingpixels.dev

No coding required. No CS degree required. (I have one, but I promise you don’t need it.)

Screen time they made > screen time they watched.

If you know a parent who’d lean in at “computational thinking for toddlers” — send them this!

— Mei

Parent developers lose an average of 10-15 minutes per coding session just remembering what they were working on. Over a week of fragmented sessions, that’s 1-2 hours of productive coding time lost to context recovery alone. Two free tools—tmux (a terminal multiplexer) and AI-powered context scripts—reduce that ramp-up time to under 2 minutes, turning even a 20-minute window into real progress.

The problem isn’t speed. Aliases save keystrokes. Shortcuts save clicks. But neither can tell you why there’s a half-finished function called addMissingContext() or what that TODO comment about “ask someone smarter than me tomorrow” was supposed to refer to. Parent developers don’t need faster typing—they need context recovery systems that bridge the gap between sessions separated by days of sick kids, work deadlines, and birthday parties that somehow require three trips to Target.

After testing dozens of productivity tools and workflows, these are the only two that consistently move the needle for coding in fragmented time.

tmux: Your Session Survives Everything (Including Your Kid on the Trackpad)

tmux keeps your terminal sessions alive even when you close your laptop, restart, or accidentally kill Terminal because your kid was “helping” with the trackpad. It’s a terminal multiplexer that creates persistent “workspaces” that survive disconnections, crashes, and the chaos of parent life.

Without tmux, every coding session starts with: open terminal, navigate to project, start the dev server, open the right files, remember which browser tab had localhost:3000. That’s 5-7 minutes gone. With tmux, you type one alias and you’re back exactly where you left off—even if it’s been a week.

The Setup

Here’s a tmux config optimized for parent developers:

# ~/.tmux.conf

set -g prefix C-a # Easier to reach than default C-b

unbind C-b

bind C-a send-prefix

# Mouse support (essential when you’re tired)

set -g mouse on

# Show which project you’re in

set -g status-left “#[fg=green][#S] “

And these three aliases that make tmux feel natural:

alias twork=”tmux attach -t work”

alias tblog=”tmux attach -t blog”

alias tfam=”tmux attach -t family-projects”

Quick setup: I’ve created a complete tmux setup script that installs tmux, adds the configuration, and sets up all the aliases automatically.

One Command, Right Back Where You Left Off

Every project gets its own tmux session. When I start working on my blog, I type tblog and I’m back in my development environment exactly where I left off, even if it’s been a week.

The first time you create a session for a project:

# Navigate to your project and create a named session

cd ~/blog

tmux new-session -d -s blog

hugo server -D # Start your dev server

# Open another terminal window/tab and attach

tmux attach -t blog

Real-world example: Last Tuesday, my laptop died mid-deploy (I ignored the battery warning because I was “almost done”). After restarting, I typed tblog and my terminal environment was exactly as I’d left it. The deploy had even completed successfully in the background. That’s not just time saved—it’s confidence that you can pick up any project instantly.

Setting Up Your Sessions

# Create sessions for your main projects

tmux new-session -d -s work

tmux new-session -d -s blog

tmux new-session -d -s family-projects

# Then use the aliases to jump between them

tblog # Attach to blog session

twork # Attach to work session

tfam # Attach to family projects session

Each session maintains its own windows, working directories, and running processes.

AI Context Recovery: A 30-Second Briefing Instead of 15 Minutes of Staring

AI-powered context recovery uses your git history, file changes, and TODOs to reconstruct what you were working on—replacing the 10-15 minutes of “staring at your own code trying to remember” with a 30-second briefing. This is the second tool that transforms fragmented coding from frustrating to productive.

The Context Recovery Script

One script gathers all the breadcrumbs from your recent work:

#!/bin/bash

~/scripts/context.sh

echo “🔍 What was I working on?”
echo “”

echo “📝 Recent commits:”
git --no-pager log --oneline -5
echo “”

echo “📂 Files I changed recently:”
git --no-pager diff --name-only HEAD~3..HEAD
echo “”

echo “🚧 Current status:”
git --no-pager status --porcelain
echo “”

echo “💭 TODOs in recent files:”
git --no-pager diff --name-only HEAD~3..HEAD | xargs grep -l “TODO|FIXME|NOTE” 2>/dev/null | head -3 | xargs grep “TODO|FIXME|NOTE” 2>/dev/null
echo “”

echo “💡 Copy this info and ask your AI: ‘What was I working on and what should I do next?’”

Run context and paste the output into Claude (or your preferred AI) with: “Based on this git activity, what was I likely working on? What should I focus on next?”

Your Tiredness-Proof Memory

The AI sees patterns in your commit messages, file changes, and TODOs that you miss when you’re tired or distracted. It’s like having a coworker who watched your last session and can give you a 30-second briefing.

30 Seconds Now, 15 Minutes Saved Later

alias snapshot=”echo $(date): >> .project-notes.md && code .project-notes.md”

Before stepping away, run snapshot and jot down what you were doing, what you figured out, and what’s next. Takes 30 seconds, saves 15 minutes later.

The 2-Minute On-Ramp

The real power emerges when tmux and AI context recovery work together:

1. tblog — Instantly restore your development environment

2. context — Get AI summary of recent work

3. tail .project-notes.md — Read your last manual note

4. Start coding — Usually within 2 minutes of sitting down

Compare that to the old workflow: navigate to directory, remember what servers to start, open files you think you were working on, stare at code trying to remember, give up and start something easier, maybe start coding 10 minutes later.

The Real Win: You Stop Avoiding Hard Projects

The compound effect of reduced context-switching overhead transforms what kinds of projects parent developers can maintain. The productivity gain isn’t just minutes saved—it’s the elimination of the mental barrier that makes you avoid complex work.

Before: “I only have 20 minutes, that’s not enough time to make real progress on the authentication refactor.”

After: “I have 20 minutes, let me see what I was doing on the auth stuff.”

When you’re not afraid of ramp-up time, you work on bigger, more ambitious projects. Side projects actually get finished instead of being abandoned when life gets busy.

Start Here

Start with tmux sessions. Install tmux, create a session for your main project, and force yourself to use it for a week. The productivity gain is immediate.

Add AI context recovery later. Once tmux is a habit, add the context script. The combination is where the real transformation happens.

Don’t try to implement everything at once—that’s how productivity tools get abandoned.

These two tools handle the infrastructure of fragmented development. Combined with the right mindset and workflow aliases, you have a complete system for productive parent developer work. Your coding time might be fragmented, but your progress doesn’t have to be.

"Fix"? Fix what?!

By the time you remember what you were doing, you have maybe eight minutes before exhaustion wins. You manage to write three lines of code, realize you broke something, and hear crying from the nursery.

Sound familiar?

Why Standard Productivity Advice Fails Parents

Most developer productivity advice assumes you have uninterrupted blocks of time. "Just use the Pomodoro Technique!" they say. "Time-box your deep work!"

Right. Let me just explain to my toddler that Mommy is in a focused work session and cannot be interrupted for the next 25 minutes. I’m sure he'll understand.

The reality is that parent developers need completely different strategies. We don’t need advice on how to focus for hours—we need to know how to make meaningful progress before the kiddo has finished testing all the crayons in this box and needs a new box. (We've discussed the fact that all the colors are the same between the two boxes, and while I'm pretty sure he understands, he still insists on testing both sets.)

The Mindset Shift: From Blocks to Fragments

Traditional developer thinking: "I need at least 2-3 hours to get into flow state and accomplish anything meaningful."

Parent developer reality: "I can write a function while my kid watches one seven-minute Helper Cars episode, debug during 40-minute naptime, and deploy after bedtime."

Small, frequent progress beats waiting for perfect conditions.

I’ve shipped entire new projects in 15-minute increments. Not because it’s ideal… because it’s what you've got when you’re moonlighting at coding as a full-time parent.

Strategies That Actually Work

1. Leave Breadcrumbs for Future You

Never close your laptop without leaving yourself a note about what you were doing and what comes next. Your future self (whether that’s in 20 minutes or 3 days) will thank you.

What I do:

• Always commit with descriptive messages, even for work-in-progress

• Leave TODO comments with specific next steps

• Keep a simple text file open with "where I left off" notes

Example workflow:

// TODO: Next - add validation for email field in UserForm.tsx
// Problem: handleSubmit isn't calling the API correctly
// Test with: npm test -- UserForm

2. Optimize for Quick Restarts

The biggest productivity killer isn’t the interruption itself—it’s the time it takes to get back into context. Design your workflow for fast context switching.

Environment shifts that help:

• Keep your development server running (even when stepping away)

• Use terminal tabs/windows that stay open with the right directories

• Have your browser tabs pre-loaded with the right localhost ports

• Keep your code editor open with the relevant files

Basically do the opposite of what I'm always telling my toddler: don't clean up after yourself.

3. Embrace "Good Enough" Commits

Perfect is the enemy of shipped when you’re a parent developer. I’ve learned to commit early and often, even if the code isn’t perfect.

My philosophy: working software that ships is infinitely better than perfect code that never gets finished.

Some of my largest projects were built in tiny commits with messages like:

• "Basic login working, needs cleanup"

• "Ugly but functional user dashboard"

• "Fixed the bug, will refactor later"

4. Batch Similar Tasks

When you only have small windows of time, context switching between different types of work is expensive. Try to batch similar activities:

• Writing day: Focus on documentation, comments, planning

• Coding day: Pure implementation, bug fixes

• Testing day: QA, debugging, deployment

This isn’t always possible, but when you can batch, it helps maintain momentum.

5. Build for Resumability

Design your projects so they’re easy to pick up after days or weeks away:

• Clear documentation: Write README files like you’re explaining to a stranger

• Consistent structure: Use the same patterns or frameworks across projects

• Good logging: When things break, you need to quickly understand why

• Automated tests: Confidence that you didn’t break anything while away

6. Let AI Handle Context Switching

This is where 2026 parent developers have a massive advantage. AI coding assistants excel at the exact problems we face: understanding unfamiliar code quickly, filling in context, and maintaining momentum in short bursts.

The parent developer AI workflow:

1. Open project after days away

2. Ask AI: "What is this codebase and what was the last significant change?"

3. Get oriented in 30 seconds instead of 10 minutes

4. Make meaningful progress in your remaining time

AI strategies that work:

• Quick context recovery: When you can’t remember what you were doing, ask your AI assistant to analyze recent commits or current files

• Boilerplate generation: Don’t spend precious minutes on repetitive code. AI handles forms, API calls, test stubs instantly

• Smart documentation: AI can generate comments, README updates, or todo lists from existing code

The Two-Minute Rule for Developers

Borrowed from productivity expert David Allen but adapted for coding: If a coding task takes less than two minutes, do it immediately.

This includes:

• Fixing obvious typos

• Adding missing semicolons

• Updating a quick comment

• Installing a package you know you need

• Pushing your latest commits

These micro-improvements add up and prevent the "death by a thousand small tasks" problem.

Managing the Emotional Side

Let’s be honest: coding with constant interruptions can be frustrating. You’re in the middle of solving a complex problem when your kid wakes up early. Again.

Here are some mental frameworks I find helpful.

Remember Your Why

You’re modeling curiosity, problem-solving, and creation for your kids. When my son and I build games together, he knows we're making something, not just consuming content.

Celebrate Small Wins

Finished a function? That’s a win. Fixed a bug? Victory. Deployed a feature? You’re basically a superhero.

When your coding sessions are measured in minutes, not hours, you need to recalibrate what counts as progress.

Accept the Rhythm

Some days you’ll get 30 minutes of coding done. Other days you’ll get three minutes. Both are valid. Parenting has seasons, and so does your coding productivity.

Tools That Actually Help

While I’ll cover specific technical tools in upcoming posts, here are the categories that matter most for parent developers:

Auto-save everything: Configure your tools to save constantly. You never know when you’ll need to close the laptop quickly.

Cloud sync apps: Work seamlessly across devices. Sometimes you’ll code on your laptop, sometimes on a desktop, sometimes (let’s be honest) on your phone.

AI coding assistants: Your secret weapon for context switching and momentum. Whether it's Cline, GitHub Copilot, Codex, or Claude, these tools excel at helping you pick up where you left off.

The Parent Developer Advantage

It might seem like a constant struggle to be productive, but don't discount the skills you’re building every day! These are sustainable habits that will serve you for decades.

You’re gaining these superpowers:

• Extreme efficiency: You learn to cut through the noise and focus on what matters

• Better prioritization: When time is scarce, you get ruthless about important vs. urgent

• Stress testing: If your code works through multiple snack time interruptions and restarts, it’ll work anywhere

The Truth About Parent Developer Productivity

Working within constraints forces clarity and intentionality.

Yes, it’s challenging. Yes, it’s different from how you coded before kids. But it’s not lesser. It's just adapted to the most important job you’ll ever have: building your family legacy.

Your kids won’t remember that you shipped a month later than planned. But they will remember that you showed them what it looks like to be curious, to build things, and to never stop learning.

Before I buy anything, I ask: Does this build a transferable mental model? Can they use this concept tomorrow in a different context?

Here’s what I’d get my 3yo for Christmas if he didn’t already have it and love it:

Fraction puzzle. He learned 1, 1/2, 1/3, 1/4 in ten minutes. Now when I say “after you eat half your meatball, you can have more strawberries” he understands what half is.

Cylinder puzzle. He spent a full half hour on this, mixing up the pieces and redoing the puzzle over and over. Improves spatial awareness, trains differentiation and pattern recognition.

DIY wood toys. I must have gotten him half a dozen of these sets already. We build them together. He’s learned to follow the instructions, work backwards from images of the finished piece, and even enjoys improvising his own creations with the parts.

Buddha board. No mess painting, image fades as it dries. Fine motor control and prepares him for writing. Also, “Mama what does this look like? A duck! Look I drew some water for the duck to swim in!”

Snap Circuits. Very fun and safe to play with, and he now understands the basic components of a circuit and why we don’t stick forks in outlets.

Tangram puzzle. Useful for showing how one shape can contribute to many final products when used differently. He’ll rotate a triangle piece and say “look, now it’s a mountain! Now it’s a hat!” Same shape, different context—exactly how I want him to think about code later.

Ultimate Spotlight books series. Fun interactive books with movable pieces and pop up pages. They have so many topics! We’ve especially loved the vehicle and construction ones.

Eyewitness books. So many books for kids don’t use real pictures, so this series is our go-to for learning with real photos.

Movable alphabet, fridge edition. Keeps little hands busy while I make coffee. I recommend getting two or three sets so you can spell most words. We started our son with phonics before he was two and he can reliably spell short words like “car,” or “truck” on the fridge.

Stainless steel camping plates. Just big enough for a big sandwich. Light and strong. He likes to help put them away when we unload the dishwasher and brings his dirty plate to the sink. No fear of breaking them.

The pattern: Each one teaches a concept that compounds. Fractions show up in cooking, time, money. Circuits explain why the lights work. The plates build executive function through real responsibility.

Every toy should answer: what system am I teaching? If you can’t answer that, it’s just noise.

What toys are you buying that build mental models your kids will use for decades?

Have other gems to add to this list? Comment and let me know!

These Amazon affiliate links let me earn a small commission if you purchase through them at no extra cost to you. I only recommend things my kid actually uses daily! Thank you for supporting my work!

This would not be the ideal time to look up the exact git command syntax.

It’s a good thing you’ve set up an alias for this precise situation:

quickfix runs git pull --rebase && git add . && git commit -m 'Quick fix' && git push in one command. Three seconds, and your work is shipped.

When your cognitive load is already maxed out on keeping tiny humans alive, every saved keystroke matters.

Why Aliases Matter More for Parent Developers

Typically, developers optimize for readability and best practices. Parent developers benefit from optimizing for speed and resumability. When your coding windows are measured in minutes and you have precious few more of those than functioning brain cells, every saved keystroke compounds.

The math is simple:

• Average parent coding session: 15 minutes

• Time spent on repetitive commands: 2-3 minutes

• Time saved with good aliases: 2-3 minutes

• Daily productivity increase: 15-20%

But here’s the real impact:

• 5 coding sessions × 3 minutes saved = 15 minutes weekly

• Over a month: 1 extra hour of deep work

• Over a year: 12+ hours = almost two full workdays of found time

More importantly, aliases reduce cognitive load. When you’re tired and distracted, muscle memory beats trying to remember command syntax. They also create rage-quit-proof workflows—when you’re interrupted mid-thought, one command saves your work before you sprint to handle whatever’s happening.

The Parent Developer Aliases for Every Situation

Before we dive in, here’s a quick power-user tip:

# Function alias for dynamic commit messages
alias gc='function _gc(){ git commit -m "$*"; }; _gc'

# Now you can type: gc Fixed the API timeout issue
# Instead of: git commit -m "Fixed the API timeout issue"

Now, the essentials—organized by the scenarios that actually happen in parent developer life. Copy these straight into your .zshrc or .bashrc.

1. Emergency Git Workflows

These are for when things break and you need to act fast:

# The golden trio - save your work instantly
alias save="git add . && git commit -m 'WIP: interrupted by life' && git push"
alias quickfix="git pull --rebase && git add . && git commit -m 'Quick fix' && git push"
alias backup="git add . && git commit -m 'Backup before trying something' && git push"

# When you return and can't remember what you were doing
alias last="git log --oneline -5"
alias status="git status && echo '---' && git log --oneline -3"
alias changes="git diff HEAD~1"

# Quick branch management
alias main="git checkout main && git pull"
alias newbranch="git checkout -b"
alias deletebranch="git branch -d"

# When you need to abandon ship quickly
alias abort="git reset --hard HEAD && git clean -fd"
alias unstage="git reset HEAD ."

Real scenario: API was returning 500s just as I heard “MAMA MAMA MAAA” from the monitor. Used backup to save current state, changed req.body.userId to req.body.user_id (why do we never standardize these?), hit quickfix, then to mom duties. When I came back some hours later, last showed me exactly where I’d left off.

2. Quick Project Switching

Parent developers juggle multiple projects in fragments:

# Navigate to common project directories
alias work="cd ~/work && ls"
alias personal="cd ~/personal-projects && ls"
alias blog="cd ~/blog && code . && hugo server -D"

# Quick environment setup
alias devup="docker-compose up -d && npm run dev"
alias devdown="docker-compose down && pkill -f 'node'"
alias fresh="rm -rf node_modules && npm install && npm run dev"

# Open common project combinations
alias workday="code ~/work/current-project && cd ~/work/current-project"
alias blogpost="cd ~/blog && hugo new content/posts/$(date +%Y-%m-%d)- && code ."

Parent-specific benefit: No time wasted navigating directories or remembering startup commands. blog opens your editor and starts the dev server in one command—crucial when you have exactly 12 minutes during snack time.

3. Development Environment Shortcuts

When you have 15 minutes to code, environment setup can’t take 5 of them:

# Server management
alias serve="python -m http.server 8000"
alias nodeserve="npx serve -s build -l 3000"
alias hugoserve="hugo server -D --bind 0.0.0.0 --port 1313"

# Testing shortcuts
alias test="npm test"
alias testwatch="npm test -- --watch"
alias testcoverage="npm test -- --coverage"

# Package management
alias ni="npm install"
alias nid="npm install --save-dev"
alias nrun="npm run"

# Quick file operations
alias ll="ls -la"
alias ..="cd .."
alias ...="cd ../.."

# Process management
alias ports="lsof -i -P -n | grep LISTEN"
alias killnode="pkill -f node"
alias killport="function _killport(){ lsof -ti:$1 | xargs kill -9; }; _killport"

4. Mobile & Remote Coding

For when you’re coding on iPad via SSH during Daniel Tiger:

# Ultra-short for thumb typing
alias m="git add . && git commit -m"  # usage: m "quick fix"
alias p="git push"
alias pl="git pull"
alias s="git status -s"
alias d="git diff"

# Codespaces/remote dev
alias remote="gh cs ssh"
alias cslist="gh cs list"
alias cscode="gh cs code"

# Quick file edits on mobile
alias v="vim"
alias n="nano"

These work great in GitHub Codespaces, Termius, or any SSH session.

5. Content Creation Workflows

For building in public while building humans:

# Blog post management
alias newpost="hugo new content/posts/$(date +%Y-%m-%d)-"
alias preview="hugo server -D --bind 0.0.0.0"
alias publish="git add . && git commit -m 'New post' && git push"

# Quick content ideas capture
alias idea="echo '$(date +%Y-%m-%d): ' >> ~/content-ideas.md && code ~/content-ideas.md"

Installation Guide for Busy Parents

Step 1: Back Up Your Current Setup

# Always backup first - parent developers can't afford to break their environment
cp ~/.bashrc ~/.bashrc.backup
cp ~/.zshrc ~/.zshrc.backup 2>/dev/null || echo "No zsh config found"

Step 2: Add Aliases Gradually

Start with just these three life-savers:

1. save - for instant work preservation

2. quickfix - for emergency deploys

3. last - for context recovery

Master these, then add more.

Step 3: Test in Low-Stakes Moments

Try them during a calm coding session before relying on them during naptime production emergencies.

Advanced Parent Developer Power Moves

Once comfortable with basics, these compound your efficiency:

# One-command pull request workflow
alias pr="git push && gh pr create --fill"

# Branch cleanup
alias cleanup-branches="git branch --merged | grep -v main | xargs -n 1 git branch -d"

# Update all your projects at once
alias update-all="find ~/projects -name '.git' -type d -execdir git pull \;"

Making Aliases Stick

Use Muscle Memory

The best aliases feel natural. save works because it’s obvious. qf for quickfix might be faster, but you’ll forget it exists.

Document Your Aliases

# List all your custom aliases
alias

Keep this output in your notes app for quick reference.

Troubleshooting

“Command not found” After Adding Aliases

# Reload your config without restarting terminal

source ~/.zshrc  # or ~/.bashrc

Git Aliases Conflicting

# Check existing git aliases

git config --list | grep alias

# Remove conflicts

git config --global --unset alias.save

The Compound Effect

These aliases don’t just save seconds—they reduce context-switching overhead. When you can execute complex workflows without thinking, you preserve mental energy for actual problem-solving.

After a month with these aliases, my typical 15-minute session:

• 30 seconds: Environment setup (was 3 minutes)

• 14 minutes: Actual coding and problem-solving

• 30 seconds: Save and cleanup

That’s 20% more coding time, which over a year adds up to two full weeks of additional productivity.

Your Next Step

Your time is fragmented. Your attention is split. Your coffee is cold. But your commands? Those can be lightning fast.

Start with three aliases today. Just three. By next week, you’ll wonder how you ever git add . && git commit -m 'message' && git push’d like a caveman.

Now if you’ll excuse me, someone just discovered they can flush toy cars down the toilet. Time to save and run.

Download: Want all these aliases in one file? Get the ready-to-install parent developer aliases collection that you can source directly into your shell configuration.

Next in the series: CLI tools designed for 15-minute coding windows—including AI-assisted context recovery and emergency deployment strategies.​​​​​​​​​​​​​​​​

“Build a tower,” he says.

My toddler is more interested in stacking them than lining them up, so I switch axis. “Big block, small block, big block…”

“I’m going to knock it over!” he announces.

“Okay, but first tell me if a big block or small block comes next.”

“Small block,” he says, and uses a small block to knock over the tower.

It’s progress.

Tricking Toddlers into Learning Programming Fundamentals

1. The Sock Sorting Algorithm

Post-laundry, dump all the socks on the floor. "Find all the truck socks!" He groups them. "Now find their friends!" He matches pairs.

We just taught classification and matching—core programming concepts—disguised as helping with chores.

2. Red Light, Green Light 2.0

Classic game, programmer twist. Green = walk, Red = stop. Then we add: "When I clap AND say green, you clap and walk!”

Congratulations, you just taught conditional logic. Next: "Two claps means go backwards!" Now we're teaching parameters.

3. The Toy Car Parking Lot

Line up cars by size. Now by color. Now red cars in front, everything else behind. He's learning sorting algorithms without knowing what an algorithm is.

Add a rule: "Emergency vehicles always go first!" That's priority queuing.

4. Snack Patterns

Goldfish, pretzel, goldfish, pretzel. "Can you continue the pattern?" Once he masters it: "What if we add a raisin?" Now it's goldfish, pretzel, raisin, goldfish, pretzel, raisin.

We just taught sequence expansion (although the raisins rarely last past a couple iterations).

Why This Actually Matters

These aren't cute games that vaguely relate to programming. They're teaching the exact thinking patterns he'll use whether he's prompting AI or (unlikely) writing actual code:

• Pattern recognition: The basis of all debugging

• Sequential thinking: How programs execute

• Conditional logic: If this, then that

• Classification: Grouping similar things

• Algorithm design: Steps to solve a problem

Your Turn

Talk out loud about any pattern you see. Cars parked on the street. Tree, bush, tree, bush along the sidewalk.

Give your kid the opportunity to match: “Can you put this fork in the drawer with the other forks?”

Tonight at dinner, make a pattern with food and ask your kid to describe it. The yummier, the better!

Subscribe now

What pattern games do you play? Reply and tell me—I'm always looking for new ways to sneak programming logic into playtime.

“If I eat meatball, then I can have more blueberries?”

Conditional statements come naturally at mealtimes. He doesn’t know it yet, but he’s programming me.

The Daily Algorithms

Every toddler negotiation follows programming logic:

The Basic If-Then

“If I put on my shoes, then we go outside?”

Classic conditional. Input (shoes) leads to output (park). He’s learning cause and effect aren’t just natural laws—they’re negotiable parameters.

The AND Operator

“If I brush teeth AND pick up toys, then two stories?”

Multiple conditions! He’s combining requirements.

“If I lay down AND be quiet AND close my eyes, then another story?”

That’s a three-condition function.

The OR Logic

“I wear the dinosaur shirt OR the truck shirt?”

He’s presenting options, understanding that either input produces the desired output (getting dressed). Then he levels up: “If dinosaur shirt, then green pants. If truck shirt, then blue pants.”

Different inputs, different outputs. That’s programming.

The Edge Cases

My favorite is when he finds the bugs in our parent logic:

Me: “If you don’t eat your fish, then you can’t have more crackers.”

Him: doesn’t eat fish

Him: “I don’t want more crackers. I want melon.”

He found the loophole. Our conditional didn’t account for his ability to reject the entire premise. That’s debugging.

Or this one:

Me: “If you eat your fish, then you can have melon.”

Him: takes one bite of fish

Him: “May I have melon now, please.”

One bite of fish for a bowl of melon? That’s optimization.

Why This Matters

These aren’t cute moments that vaguely relate to programming. This IS programming. He’s learning:

• Conditional logic: If X then Y

• Boolean operators: AND, OR, NOT

• Variables: Different inputs produce different outputs

• Edge cases: What happens when assumptions break

• Debugging: Finding flaws in logic

• Optimization: Maximum reward for minimum effort

Every negotiation is a program he’s writing in real-time.

The Magic Question

When he negotiates, I’ve started asking: “What’s your if-then?”

“If I drink water, then we go outside.”

“If I get dressed, then we play GCompris.”

“If I lay down, then Mama sings Twinkle Twinkle Little Star.”

He’s getting explicit about his logic. He’s learning that clear conditions lead to predictable outcomes.

Your Turn

Tomorrow, when your toddler starts negotiating, listen for the logic:

• What conditions are they setting?

• What operators are they using?

• Where are the edge cases?

Talk through each point (in toddler terms) and make them explicit. Then try this: “Okay, if we do that, then what do you want to happen?”

Watch them think. Watch them structure their argument. Watch them debug their own logic when it doesn’t work.

They’re not just negotiating. They’re programming.

When we teach them to think in if-thens, we're teaching them to think clearly about cause and effect, actions and consequences, effort and reward. That's not just coding. That's life.

Subscribe now

This morning: "If I hug, then Mama is happy.” Yes, buddy. That program runs perfectly every time. What's your favorite toddler if-then that just melts you?

We skipped the "kid-friendly" stuff and went straight to real tools. Turns out, toddlers are vastly underestimated! They don't need training wheels, just guidance and motivation.

The Entire Setup (Yes, Really)

Step 1: Install VS Code (3 minutes)

Download Visual Studio Code. That's it. The same editor I used at work now serves as my toddler's creation platform. Don't overthink it—kids don't care about themes or extensions.

Step 2: Add Cline Extension (2 minutes)

Search "Cline" in VS Code extensions. Click install. This is the AI assistant that turns natural language into code. No configuration needed beyond adding your API key.

Step 3: Make It Toddler-Friendly (5 minutes)

• Bump the font size to 20 (Command+Plus a few times)

• Hide the sidebar (they don't need it)

• Full-screen the window (fewer distractions)

• Create a folder with their name on the desktop and open it in VS Code

Done. Your toddler can now build software.

The Secret: It's Not About the Tools

Here's what I didn't do:

• Install a "kid-friendly" IDE

• Set up Scratch or Blockly

• Create special shortcuts

• Baby-proof anything

Why? Because the complexity isn't in the tools—it's in the syntax. Remove the syntax (thanks, AI), and suddenly VS Code is as simple as any toy. (Well, you might have to help them type.)

The First Session

Open VS Code. Open Cline. Say: "Tell the computer what you want to make."

That's your entire onboarding.

My son's latest request: "Make a green car website for kids."

I typed exactly that. A few minutes later, it existed. No configuration. No setup. No "let's learn about variables first."

What About Safety?

Fair question. Here's my approach:

• I'm always present (it's a together activity)

• The API has spending limits

• We use a separate user account on the computer

• Generated games run locally in the browser

If you wanted to be extra, extra cautious, you could use a devcontainer to isolate Cline's coding environment. (For these details, see my post on API keys and safety) But honestly? The biggest safety feature is that he can't type yet. I'm the gateway, which means natural moderation.

Skip the Kids' Stuff

Scratch teaches drag-and-drop coding. ScratchJr simplifies it further with picture blocks. But they’re still teaching syntax, just with pretty colors. We're teaching creation with real tools that will matter in industry for the next generation.

Your toddler doesn't need a special "learning environment." They need:

1. A way to express ideas (their voice)

2. Something to turn ideas into reality (AI)

3. A place to see it happen (VS Code)

That's it. Ten minutes to set up. A childhood full of creation ahead.

Tonight's Homework

Stop researching "best coding apps for kids." Instead, install VS Code and Cline. Tomorrow, ask your kid what they want to make.

Then make it.

You'll be amazed at what happens when you stop teaching them to code and start helping them build.

Subscribe now

Stuck on setup? Reply and I'll help you out! Let’s get your kids building together.