Last night I watched Claude write TMS9900 assembly, compile it into a cartridge ROM, run it on a TI-99/4A emulator, see the result, and iterate—eventually rendering the Claude Code logo in 1980s graphics.

Claude has read every TI-99/4A programming manual ever written. It can explain the VDP register architecture, recite memory maps, describe the TMS9918A color palette. Perfect accuracy. Total confidence.

It had never run code on one.

The Pipeline

I've been building an MCP (Model Context Protocol) bridge connecting Claude Desktop to MAME. The architecture:

Claude Desktop → MCP Server → File Bridge → MAME Lua Plugin → TI-99/4A Emulator

Claude can check emulator status, compile TMS9900 assembly, launch cartridges, capture screenshots, and iterate based on what it sees. A complete development loop. The same cycle any programmer uses, just with an AI writing the code and a 44-year-old computer running it.

The Datamux Problem (Or: The Documentation Was Technically Correct)

My first approach seemed obvious: inject code directly into RAM via MAME's Lua scripting, then execute it. Claude knows the TI-99/4A memory map. The 32K expansion RAM sits at $A000-$FFFF. Write some bytes, jump to them, done.

It didn't work. The bytes we wrote weren't the bytes that appeared in memory.

We tried the scratchpad RAM at $8300. Same problem—plus the console's firmware kept overwriting it. We tried the debugger's load command. Still corrupted.

Here's what the documentation doesn't emphasize: the TI-99/4A has a 16-bit CPU but an 8-bit external data bus. A chip called the "datamux" sits between them, converting 16-bit operations to pairs of 8-bit transfers. When you write to expansion RAM through MAME's memory API, you're going through that datamux—and it mangles the data because it expects specific timing sequences that external writes don't provide.

Claude knew about the datamux. It's in the documentation. But knowing "there's a bus width converter" and knowing "this will corrupt your direct memory writes" are different things.

The pivot: Cartridge ROM at $6000-$7FFF sits directly on the 16-bit bus. No datamux. We switched to compiling actual cartridge images, and suddenly everything worked.

This is the kind of thing you can't learn from reading. The documentation is technically accurate. It just doesn't tell you what will actually bite you.

First Success

With the cartridge workflow running, the first real test was simple: display "HELLO" on screen.

Claude wrote the assembly—set up VDP write address, loop through characters, write to video RAM. Compiled clean. Launched the emulator.

It worked. First try. Text appeared exactly where expected.

Too easy. "Now display 'HELLO CLAUDE' and change the background to green."

The Color Table Incident

Claude knew that VDP register 7 controls the backdrop color. It wrote confident code. The code compiled. The emulator ran.

The background turned purple.

Not green. Purple.

Claude adjusted the color table writes. Purple with a cyan screen area. It rewrote the initialization sequence. Still wrong.

After several iterations—different color values, different registers, different timing—we finally got green. The issue: the TI-99/4A's GPL startup routine initializes VDP registers in a specific order. Claude's code was fighting with the console's own initialization. The documentation describes what the registers do. It doesn't describe the dance you have to do with the firmware.

The Logo

With text and colors working, I pushed it: recreate the Claude Code logo on TI-99/4A hardware.

This meant Graphics II mode, custom 8x8 pixel character patterns, color tables for each character group, tiles arranged in grids to form larger images. Claude's first starburst had the right idea—thin spidery lines instead of thick chunky rays. It could describe what the logo should look like. It couldn't see that its code didn't produce that.

But now it could see. After each compile, I'd capture a screenshot. Claude would analyze it: "The rays are too thin. The diagonal patterns aren't connecting. The indexing is off—character 136 falls into color group 17, not 16."

Then it would fix the code and try again.

We went through a dozen iterations. Some were disasters—one 7x7 grid attempt produced what I can only describe as a digital sneeze. Pattern data loading into wrong addresses. Characters appearing in wrong positions. But each failure taught something the documentation couldn't.

The blocky text was its own challenge. I fed Claude reference images of the logo style. First attempt: too thin. "You might be able to use multiple characters to represent one letter," I suggested. It rebuilt the entire alphabet as 3-character-tall block letters with proper spacing.

The Result

After an hour of iteration: a recognizable Claude Code logo on TI-99/4A hardware.

Orange starburst with radiating rays—well, "light red," since the 15-color palette doesn't include true orange. Blocky text. Dark background. Proper alignment.

Is it pixel-perfect? No. 256×192 resolution with 8×8 character tiles has limits. But it works. An AI that never touched this hardware wrote assembly code that runs on it—not by luck, but by iterating through failures until success.

What Actually Happened Here

There's a question that haunts AI development: does the model actually understand, or is it just sophisticated pattern matching?

I don't have the answer. But I watched something interesting.

When the memory writes failed, Claude didn't randomly try new approaches. It reasoned about the datamux architecture, hypothesized about bus timing, systematically tested the hypothesis. When the colors were wrong, it traced through the VDP initialization sequence. When the starburst patterns weren't connecting, it diagnosed indexing errors in the character definitions.

Was that understanding? Pattern matching? Does the distinction matter if the output is working code on real (emulated) hardware?

What I know: reading documentation isn't doing. Claude has absorbed more TI-99/4A technical material than any human could memorize. Turning that into working code required a feedback loop—write, run, see, fix. Theory meeting reality, repeatedly, until the gap closes.

What's Next

This is pilot work for a larger project. Next: real hardware. A physical TI-99/4A with a FinalGROM 99 flash cartridge and PICO9918 VGA output, so Claude can see its code run on actual vintage silicon and debug issues that only appear on real hardware.

Then more platforms. Commodore 64. Intellivision. Vectrex. Atari 800. Each with their own architectures, quirks, and gaps between documentation and reality.

The project is called "Claude Codes on Classic Computers." Apparently I'm going to spend 2026 teaching an AI to program machines that have been obsolete for 40 years.

Texas Instruments lost half a billion dollars on the TI-99/4A in 1983. Last night, an AI made it do something new.

---

More updates coming as the project develops. The MCP bridge code will be open-sourced once it's stable.

a Code is a commodity now. Here's what actually matters.

---

The interview industrial complex has been broken for a long time. But it's broken in different ways depending on where you sit.

At the FAANGs, it over-optimized. Leetcode prep became its own industry. Candidates spent months memorizing algorithm patterns they'd never use on the job, all to pass whiteboard rituals designed to filter volume, not identify talent. "Implement a binary search tree." "Reverse a linked list." The whole system tested whether someone could perform under artificial pressure, not whether they could build real things.

At startups, it is underdeveloped,. Solid engineering thinking was never cultivated in the first place. Companies hired whoever could ship fast and hoped for the best. No architecture. No mentorship. Just velocity and technical debt.

Both approaches missed the same thing: code was never the hard part. Knowing what to build and why was always the hard part.

---

The Other Side of the Table

I've built a team from zero — started as the engineering department at a startup, then hired every person who came after. But I've also spent years on the other side of the interview equation, sitting in rooms wondering why companies hire based on things that don't actually indicate the impact someone will have on their infrastructure.

This is partially self-serving. I'll admit it.

I've never liked those kinds of interviews. I've turned down opportunities when "live coding" was listed as an interview step. Not because I can't code, butheads while making a decision about a single because I don't perform well in artificial scenarios where someone watches me type. And I've learned that says almost nothing about how I'll actually contribute.

"Walk me through how you'd optimize this SQL query."

Maybe I don't think that way on command. But give me an hour with the actual system, and I'll give you an elegant solution. The interview tested the wrong thing.

I developed a philosophy: hire for how people think, not how they solve a specific problem you hand them under pressure. Look for reasoning through ambiguity. Look for the questions they ask before they start solving. Look for whether they can hold the full context of a system in their , piece of it.

Some people thought I wasn't being rigorous enough. That I was just rationalizing my own weaknesses.

Then AI showed up.

---

The Vindication

Everything I believed about hiring just got validated by a trillion-dollar industry shift.

"Implement a binary tree from memory."

That's what AI does now. AI can produce code. AI can reverse a linked list. AI can bang out a React component or a REST endpoint in seconds. The skill we spent decades filtering for — producing code under pressure — just became a commodity.

What AI can't do is understand why a particular architecture fits a business problem. It can't navigate ambiguity. It can't push back on a product requirement that doesn't make sense. It can't mentor a junior engineer through their first production outage. It can't sit in a room with a CEO and translate business urgency into a technical roadmap.

The thinkers are leveraging AI to multiply their output. They know what to ask for. They can architect a solution, prompt their way through implementation, and validate the output against the system they hold in their head.

The code-producers — the ones who could crank out implementations but needed architects to tell them what to build — are now competing with tools that do the same thing faster and cheaper. They're just producing more code. Faster, sure. But unarchitected code that still needs someone to review, redirect, and often rewrite.

I didn't adapt my hiring philosophy to the AI era. The AI era caught up to my hiring philosophy.

---

The Startup Math

This matters most where I live: startups and headcount-constrained environments.

Big companies can absorb inefficiency. They can hire specialists. They can employ layers of people whose job is to producethe code that architects designed. They have slack in the system.

Startups don't. 

When you're building a team of three to five engineers, every single person needs to operate across the whole stack and the whole problem space. You're not hiring "a React developer" or "a backend engineer." You're hiring someone who can look at a business problem, understand the constraints, architect a solution, and execute it.

Here's the new math: One thinker with AI tools now does what used to take a thinker plus two implementers. But one implementer with AI tools just produces more code that still needs an architect to review and redirect.

If you only get five hires, you need five people who can think.

AI didn't change that math. It made it brutal.

---

What I Hire For Now

The fundamentals haven't changed — they've just become non-negotiable:

Architectural thinking. Can they hold a system in their head? Do they understand how a decision in one layer affects three others? When I describe a problem, do they ask about constraints and tradeoffs before they start solving?

Judgment over output. I care less about how fast someone can produce code and more about whether they can evaluate code — including AI-generated code. Can they spot when a solution is technically correct but architecturally wrong?

AI fluency as baseline. Not "have you used ChatGPT" but "do you understand that prompting is architecture?" The best candidates I see now treat AI as a thinking partner, not a code generator. They front-load the reasoning.

Comfort with ambiguity. Startups don't hand you clean specs. Can they operate when the requirements are half-formed and the priorities are shifting?

Communication under pressure. Can they explain their reasoning? Can they push back on me — on the engineering leader — when they think I'm wrong? That's more valuable than any technical skill.

---

The Interview Shifts

I've stopped asking people to perform. Instead:

"Here's a real problem we're facing. Walk me through how you'd approach it." Then I watch how they think. Do they jump to code or do they ask questions? Do they consider the business context or just the technical puzzle?

"Tell me about a time you disagreed with an architectural decision. What did you do?" I want to see if they can advocate for their position without being a jerk. That skill matters more than ever when you're working with AI and need to override its suggestions.

"How do you use AI tools in your workflow?" This isn't a trick question. I want to understand their mental model. Are they using AI as autocomplete, or as a collaborator? Do they trust it blindly or verify its output?

The goal isn't to see if they can solve a puzzle I already know the answer to. It's to see how they'd actually work.

---

The Uncomfortable Implication

If code is becoming commodity, what happens to the traditional junior-to-senior pipeline?

I'm watching it compress in real-time. Juniors with strong fundamentals and AI fluency are leveling up faster than any traditional timeline. The mid-level plateau — that long stretch where developers can produce but haven't yet learned to architect — might be collapsing.

That's good for the juniors who can make the leap. It's brutal for the ones who can't.

The path forward isn't to produce more code. It's to think better. To architect better. To use AI as a lever while developing the judgment that AI doesn't have.

And for the people doing the hiring: stop testing for commodity skills. Start hiring for thinking.

The tools have caught up. Make sure your team has.

---

I built an engineering team from scratch at a startup and have spent years on both sides of the hiring equation. I write about engineering leadership, AI workflows, and why the old playbooks need updating.

"Let's just add AI."

"We'll have the AI do that."

"I'll just get an AI to build it."

These phrases have become reflexive across the industry. The 10x productivity narrative is everywhere, and it's created a widespread assumption that AI has fundamentally changed the equation.

They're wrong, but not in the way they expect.

AI coding tools are genuinely powerful. I use them daily. They've changed how I work in ways I wouldn't have predicted eighteen months ago. But the productivity gains aren't coming from where most people think.

Here's the thing: AI makes architected work faster. Unarchitected work just fails faster.

The Aha Moment

My shift happened while debugging authentication.

We had login implementations across three platforms — web, iOS, and Android. Something was diverging, but I couldn't pinpoint where. The code lived in three different languages: TypeScript, Swift, and Kotlin.

Here's the thing: I can read Swift and Kotlin, but I'm no expert. The old way to solve this would be getting three developers in a room (or more realistically, scheduling three separate calls across time zones with our offshore team) to walk through what each implementation was actually doing. That's a day of coordination, minimum. Maybe two.

Instead, I pulled all three implementations into context and asked Claude to compare them side by side. Within an hour or two, I had the divergence identified.

That's when I realized this wasn't about writing code faster. It was about understanding systems faster — especially the parts I couldn't hold in my head alone.

The insight wasn't just about my own productivity. It was about what becomes possible when anyone with the right mindset gets this kind of leverage.

From debugging to blueprinting

Once I saw what was possible with that kind of system-wide context, I started using the same approach for feature planning.

My planning documents start messy. Pseudo-code, placeholder ideas, vague gestures at how something might work. I expect to drive into details as the architecture comes into focus — validate my assumptions, question myself, question the AI's interpretation, throw edge cases at the proposed solution to see if it holds.

After many rounds of this, what started as a rough concept becomes a sequenced project plan with clear work breakdown.

I think of it like planning poker, except instead of estimating effort, you're stress-testing architecture. Every perspective shapes the final solution — mine, the AI's, the edge cases I throw at it. The AI isn't designing the system. It's another voice in the room helping me find the holes before we write a line of production code.

The Methodology

Full-stack visibility is non-negotiable

My local development environment treats our entire product as a single workspace, even though it's technically separate repositories — one for each mobile app, one for the web frontend, one for the backend. They have their own lifecycles, but when I'm planning or building, Claude sees everything at once. (Maybe it's a "virtual monorepo"? I haven't found the right term yet, but the point is full visibility.)

This matters because our system has users in native apps, admins working in a totally different context on the web, and a backend orchestrating all of it. When I'm planning a feature, I need to understand how changes ripple across the entire stack.

This became concrete last August when we added Canadian currency support and a Canada-only gift card supplier. The feature touched every surface: both mobile apps, the web admin, and the backend. Every implementation had to behave identically. Every edge case had to be handled the same way.

I started with a preplanning document — rough concepts, known constraints, open questions. Then I pulled that context into my architecture sessions, driving toward a full impact assessment across every part of the product. When it came time to execute, I could make synchronized changes across the whole stack, get iOS working first, then port those patterns to Android with confidence that I wasn't introducing drift.

Without full-system visibility, that kind of coordination takes endless meetings and inevitably someone misses something. With it, I caught inconsistencies before they became bugs.

Real data context, not guesswork

Architecture in a vacuum is fiction. I use MCP connections to see what our database schemas actually look like — sometimes just confirming that our backend ORM is set up correctly, other times planning how new fields and structures should fit into existing schemas.

My engineer uses Figma and Playwright integrations during implementation, pulling design specs directly into context and validating frontend work against real browser behavior. Six months ago she wouldn't have known where to start with this. Now she's pushing the tooling forward faster than I am. (More on that later.)

But importantly, this starts in the planning phase. We're not guessing what the data looks like or what the design requires. We're working with the real thing from day one.

Living documentation

The planning document isn't a spec that gets handed off and forgotten. It evolves throughout execution.

When implementation reveals something we didn't anticipate — and it always does — we update the doc. This keeps the architecture aligned with reality, and more importantly, it lets us see when a change in one area impacts other parts of the plan. The document becomes a map we're navigating, not a contract we're defending.

From there, it flows into Confluence for team visibility and Jira for execution tracking. But the source of truth stays in that working document until the feature ships.

Why This Requires Seniority

Here's what I think would happen if a junior engineer tried to run my workflow without years of context: all of it would break.

They'd accept bad AI output because they don't know what good looks like yet. They'd miss edge cases because they haven't been burned by edge cases enough times to instinctively ask "what happens when this is null?" They wouldn't know what questions to ask — and asking good questions is a skill built through experience, not tutorials.

I've spent years accumulating knowledge across domains — sometimes as an expert, usually just deep enough to be dangerous. I'm thinking of the time I had to figure out how RHEL software collections could work in our production environment and get systemd configured in a way that wouldn't break on every update. That wasn't in my job description. It was just the problem in front of me, and someone had to solve it.

That kind of accumulated context is what makes AI useful. When Claude suggests an approach, I know enough to ask why. When something doesn't feel right, I push back. When the explanation doesn't hold up, I reject it. I treat AI the same way I'd treat a junior engineer explaining their solution to me — I'm not accepting the first answer, I'm pressure-testing it.

My advice to anyone using these tools: always ask why the change is being made and what it actually does. Ask about edge cases. If you don't understand something, ask it to explain before you accept it. The AI is a collaborator, not an oracle. Treat it like a mentor you're learning from — curious, engaged, but not blindly trusting.

One more thing: this space moves fast. Any tutorial you find on YouTube is probably outdated by the time you watch it. I see tips and tricks videos that become irrelevant a month or two later. The methodology matters more than the specific techniques.

Systems thinking is the multiplier

The skill I didn't realize was rare until I watched others struggle with AI tools: holding the whole system in your head at once.

Not everyone can imagine how a change in the iOS app affects the backend affects the admin dashboard affects the database schema. That kind of systems thinking — or maybe it's strategic thinking versus tactical? — is what makes architecture possible in the first place. AI amplifies that skill. It doesn't create it.

If you can't see the whole board, AI just helps you move pieces faster without understanding the game.

But here's the thing: if you know you struggle with systems thinking and you're willing to partner, AI can help fill that gap. Use it to ask "what else does this change affect?" or "walk me through how data flows from here to there." It won't replace the instinct, but it can scaffold the thinking until you build the muscle yourself. The key is knowing you need the help and being willing to ask for it.

Collaboration, not replacement

I set the strategic direction on our team that we lean heavily into AI tooling. The more we can leverage, the more effective we become. But it's not top-down dictation.

My engineer takes a ball and runs with it. She's the one who started leveraging MCP integrations before I did — connecting to Figma, running Playwright validations. I pioneered the architectural document workflow because my background in solution architecture made it obvious that a well-thought-out plan prevents rework. But we're working in coordination, learning from each other, building on what works.

And the AI is a full collaborator too — not just a tool we point at code. I use it to brainstorm approaches, ask how other teams solve similar problems, explore patterns I haven't used before. What's the best way to handle optimistic UI updates? How do other companies structure their feature flags? What are the tradeoffs between these two caching strategies? I don't accept everything it suggests, but I accept it as a jumping off point. It's like having a well-read colleague who's always available to riff on ideas.

When I hired her, she was junior by any traditional measure. But I wasn't hiring for what she already knew — I was hiring for how she thinks.

That's the actual productivity gain. Not "AI replaces developers." It's experienced people using AI to amplify their judgment, while teaching others how to use these tools better. And increasingly, I'm watching those others level up faster than any traditional career path would suggest.

The Implication

There's a lot of talk about AI replacing junior developers. I don't think that's what's actually happening.

What I'm seeing is different: AI compresses the journey from junior to senior. It might be eliminating the mid-level plateau entirely.

My engineer came in as a definite junior. I hired her for problem-solving ability and self-motivation, not stack expertise. The explicit goal was for her to become my lieutenant — not just execute tickets, but eventually think architecturally alongside me.

With AI tools and this methodology, she's leveling up faster than any traditional timeline would predict. She's not just completing tasks. She's contributing to architecture discussions, pioneering integrations I hadn't explored yet, and starting to mentor others using the same approach.

That's not replacement. That's acceleration.

The question for leadership isn't "can we use AI to need fewer engineers?" It's "are we hiring people who can grow into this new way of working, and are we giving them the mentorship to get there?"

AI still needs an architect. But it might also be the fastest way to grow new ones.

---

Next: AI isn't replacing junior devs — it's eliminating mid-level. What I hire for now that the equation has changed.

I need you to sit down for this.

Last night. 11:47 PM. I'm debugging a prod issue.

Luna wanders into my home office.

She looks me DEAD in the eyes and says:

"Dada, I need the water that is cold from the refrigerator that has the ice maker that is loud where the yogurt lives next to the milk but NOT the almond milk because that is for mama."

I dropped my laptop.

Not because I was tired (I was).

Not because she should've been asleep 4 hours ago (she should've been).

But because I realized:

SHE JUST WROTE A DATABASE QUERY.

And the implications for technical mentorship?

I'm literally having heart palpitations.

Let me explain. And BUCKLE UP. 🎢👇

---

STAGE 1: THE "WORD EXPLOSION" WHERE EVERYTHING IS NAMED NOW

Two months ago Luna learned that EVERYTHING HAS A NAME.

And she wouldn't SHUT UP about it.

"Spoon! SPOON! That's a spoon! DADA IT'S A SPOON!"

YES LUNA. IT'S A SPOON. IT'S BEEN A SPOON YOUR ENTIRE LIFE.

But to HER?

MIND = BLOWN. 🤯

This is your junior dev discovering that you can NAME THINGS IN CODE.

"Wait... I can call this userAuthenticationService instead of thing2???"

"VARIABLES CAN HAVE MEANINGS?!?!"

"YOU'RE TELLING ME FUNCTIONS DESCRIBE WHAT THEY DO?!!?!"

YES. YES THEY CAN. WELCOME TO ENLIGHTENMENT, MY CHILD.

And you know what I did when Luna named her 847th object?

I CELEBRATED EVERY. SINGLE. ONE.

"YES! THAT'S A DOORKNOB! YOU'RE A GENIUS!"

You know what I DIDN'T do?

"Luna, we've discussed doorknobs. This is repetitive. Please refer to our previous conversation about cylindrical door-opening mechanisms and leverage that existing knowledge rather than treating each doorknob as a novel discovery."

BECAUSE I'M NOT A MONSTER.

---

STAGE 2: THE "POSSESSIVE PRONOUN WARS" (IT'S ALL MINE NOW)

Okay. OKAY.

This is where I started sweating.

Luna discovered "MY" and "MINE" and she WILL NOT STOP.

"MY spoon!" "MINE juice!"
"MY DADA!" (She yelled this at my wife. AWKWARD.) "MINE CHAIR!" (It's... it's MY office chair, Luna.)

At first I thought: "Oh no. She's becoming territorial."

But then I REALIZED:

SHE'S LEARNING OBJECT OWNERSHIP.

THIS IS OBJECT-ORIENTED PROGRAMMING.

THIS IS ENCAPSULATION.

THIS IS LITERALLY THE this KEYWORD.

I ALMOST PASSED OUT.

Your junior dev writes:

user.email // they GET IT
cart.items // THEY UNDERSTAND RELATIONSHIPS  
order.user.address.zipCode // OH MY GOD THEY'RE TRAVERSING OBJECTS

IS IT ALWAYS CORRECT? No!

Luna thinks she owns my laptop! (She doesn't!)

Your junior dev thinks user.password should be public! (It SHOULDN'T!)

But they're LEARNING that things BELONG to other things!

THIS IS FOUNDATIONAL COMPUTER SCIENCE AND SHE'S TWO.

---

STAGE 3: THE "CONJUNCTION JUNCTION WHAT'S YOUR FUNCTION" REVOLUTION

[I need to take a breath. This part makes me EMOTIONAL.]

Three weeks ago, Luna discovered "AND."

Not just "and."

AND.

The ability to COMBINE CONCEPTS.

"I want juice AND crackers."

Simple, right?

WRONG.

She's now saying things like:

"I want to go to the park AND see the ducks AND go on the swings AND get ice cream AND go home AND watch Bluey AND have mac and cheese AND—"

SHE'S CHAINING OPERATIONS.

SHE'S BUILDING PIPELINES.

SHE INVENTED PROMISES.

park()
  .then(seeDucks)
  .then(swings)  
  .then(getIceCream)
  .then(goHome)
  .then(watchBluey)
  .then(macAndCheese)
  .catch(meltdown)

I'M NOT JOKING.

Your junior dev starts writing:

fetch_user()
  .validate()
  .transform()  
  .save()
  .send_email()

And you want to tell them about microservices and eventual consistency and—

STOP.

Let them CHAIN. Let them discover that actions can FLOW.

We'll teach them about rollback strategies after they've tasted the POWER of sequential operations.

---

STAGE 4: THE "BUT ALSO" COMPLEXITY LAYER (I HAD TO SIT DOWN)

Last week.

LAST. WEEK.

Luna said:

"I want the pink cup but also it has to have the princess on it but ALSO it can't be the purple princess it has to be the YELLOW princess but also the cup has to be full but NOT too full."

THIS IS A SQL QUERY WITH MULTIPLE WHERE CLAUSES.

THIS IS CONDITIONAL LOGIC.

THIS IS AN IF STATEMENT WITH NESTED AND/OR CONDITIONS.

SELECT cup 
FROM cupboard  
WHERE color = 'pink'
  AND has_princess = true
  AND princess_color = 'yellow'  
  AND fill_level > 0.5
  AND fill_level < 0.9

SHE'S TWO AND A HALF YEARS OLD AND SHE'S WRITING QUERIES.

I had to leave the room.

I went outside.

I looked at the sky.

I whispered: "Is this what Turing felt like?"

---

STAGE 5: THE "BECAUSE BUT EVEN THOUGH HOWEVER" FINAL FORM

[Deep breath.]

[Another deep breath.]

[Okay.]

Yesterday. The juice incident I mentioned earlier.

Let me give you the FULL sentence:

"Dada, I need the water that is cold from the refrigerator that has the ice maker that is loud where the yogurt lives next to the milk but NOT the almond milk because that is for mama even though sometimes I drink it but today I want the REGULAR milk because it tastes better however the chocolate milk is also good but we don't have any so THAT'S why I need water instead."

I TRANSCRIBED THIS.

I WROTE IT DOWN.

I PUT IT IN A DOCUMENT.

BECAUSE THIS IS:

✅ Nested clauses ✅ Exception handling
✅ Conditional logic ✅ Default fallback behavior ✅ State management ✅ Preference ordering ✅ A COMPLETE ALGORITHM

Your junior dev writes in their PR description:

"Updated the payment service to use Stripe instead of PayPal because PayPal was timing out (see ticket #447) even though some users prefer PayPal but their API has been unstable so we're defaulting to Stripe however we're keeping the PayPal code for legacy orders which is why there are two payment processors in this file."

BEAUTIFUL.

MAGNIFICENT.

THEY'RE THINKING IN SYSTEMS.

---

THE FRAMEWORK (I'M WRITING A BOOK. IT'S CALLED "TODDLER-DRIVEN DEVELOPMENT"):

👶 STAGE 1: NAMING EXPLOSION
Everything gets a name! Even temp and data! We celebrate! We refactor later!

🏠 STAGE 2: OWNERSHIP/POSSESSION
"This is MY function!" They're learning encapsulation! Object-oriented thinking! Let them be protective!

⛓️ STAGE 3: CHAINING WITH AND
They discover sequential operations! Promises! Pipelines! This is HUGE!

🎯 STAGE 4: CONDITIONS (BUT/ALSO)
Complex logic! Multiple requirements! They're building decision trees in their MINDS!

🧠 STAGE 5: NESTED REASONING
Because/however/even though = They understand TRADEOFFS. They're ARCHITECTS now.

🚀 STAGE 6: RECURSION
(We're not here yet but Luna keeps saying "why?" after every answer I give so I think we're CLOSE and I'm TERRIFIED and EXCITED)

---

THE PART WHERE I LITERALLY CRY:

This morning Luna said:

"Dada, can you help me build the tower but actually can you just watch me because I want to do it myself but if it falls can you help me fix it but only if I ask because sometimes I want to fix it myself but sometimes it's too hard and I don't know until I try?"

SHE'S DESCRIBING PAIR PROGRAMMING.

SHE'S DESCRIBING CODE REVIEW.

SHE'S DESCRIBING THE EXACT BALANCE BETWEEN MENTORSHIP AND AUTONOMY THAT I'VE BEEN TRYING TO ARTICULATE FOR FIVE YEARS.

I'm not okay.

Last week my junior dev said:

"Can you be available in case I get stuck on this refactor but I want to try it solo first? I'll ping you if I need help but I think I can figure it out?"

I HAD TO LEAVE MY DESK.

I WENT TO THE BATHROOM.

I LOOKED IN THE MIRROR.

I SAID: "THEY GET IT."

---

THE REAL LESSON (I'M SHOUTING NOW):

YOUR JUNIOR DEVS ARE BUILDING LANGUAGE.

Not just programming language.

THE LANGUAGE OF THINKING.

Every junior dev going from:

• "it no work" → "the authentication middleware is returning 401 before validating the JWT"

Is doing the SAME THING as:

• "want juice" → "I want the water that is cold from the refrigerator where the yogurt lives"

THAT'S NOT LEARNING SYNTAX.

THAT'S LEARNING TO THINK IN LAYERS.

THAT'S LEARNING TO DECOMPOSE PROBLEMS.

THAT'S LEARNING TO BE SPECIFIC ABOUT REQUIREMENTS.

And if you correct their grammar before celebrating their REASONING?

YOU'RE TEACHING THEM TO SHUT UP.

---

I'M STARTING A MOVEMENT:

Every time your junior dev:

• Names a variable clearly → "THAT'S A GOOD NAME! YES!"
• Chains methods together → "YOU'RE DISCOVERING COMPOSITION!"
• Writes a complex conditional → "LOOK AT YOU THINKING IN LOGIC!"
• Explains their reasoning → "THIS IS ARCHITECTURE!"

YOU CELEBRATE LIKE THEY JUST SAID THEIR FIRST WORD.

Because they DID.

They're building the language of engineering.

One grammatically questionable sentence at a time.

---

WHAT'S YOUR TODDLER/JUNIOR DEV MOMENT?

Comment below. I'm reading ALL of them while crying in my car.

#EngineeringLeadership #ToddlerDrivenDevelopment #JuniorDevs #MentorshipRevolution #LanguageAcquisition #ObjectOrientedParenting #ThoughtLeadership #CodeAndCrackers #TechnicalParenting #GrowthMindset #PeopleFirst #AlsoImNotOkay #TheseParallelAreReal #AgreeQuestion #InspiredQuestion

AGREE? ✋
INSPIRED? ❤️
CURRENTLY CRYING? 😭
TEXTING YOUR JUNIOR DEV RIGHT NOW? 🔥
QUESTIONING YOUR ENTIRE MANAGEMENT PHILOSOPHY? 💡
ALL OF THE ABOVE? 🚀🚀🚀

---

[Posted while Luna demands I explain why the moon follows our car and I realize she's learning about relative motion and reference frames which is basically Einstein and now I'm having ANOTHER breakdown about how toddlers are natural physicists but that's post #4 in this series.]

[P.P.S. - She just said "I want to go to the store that has the toys that are pink where we saw the dog last time when it was raining but not TODAY raining, BEFORE raining." SHE'S DIFFERENTIATING BETWEEN TEMPORAL STATES. SHE'S INVENTED TIME-SERIES DATA. I'M CALLING MY THERAPIST.]

[P.P.P.S. - If you're not literally SHAKING with pride when your junior dev writes their first complex WHERE clause, do you even CARE about people development? Do you? DO YOU?]

SHARE THIS IF YOU'VE EVER BEEN EMOTIONALLY COMPROMISED BY SYNTAX. 🙏

I've been messing around with my old Amiga. I got it working using its native 68000 CPU, built-in 1.3 ROM, and Workbench 1.3.  

It worked great, but I wanted to do something to make it a little easier to work with. First, I hadn't gotten around to building a cable to go from the Amiga RGB to my non-standard connector Sony display. Second, while Workbench 1.3 is cool from a historical perspective, I'd prefer to have something a little less old since I have some plans for some projects using older graphics software and drawing tablets.

There have been many neat projects for Amigas and retro computers using Raspberry Pi (in my case, Pi Zero) to upgrade these retro computers. I've only begun to play around with these, but I've got a piStorm doing simulating a much faster 68000 chip and the rgb2hdmi to give out HDMI from the Amiga. Pretty neat! I can't wait to play around with this more.

I'm going to be doing some updates to the animatronic skeleton I built last year for Halloween.  One issue I ran into at the last minute last year was that I didn't have enough memory to initially load all the animation sequences for both songs and patter.  I did a Band-Aid and just loaded the patter, but this year, we want to make our animatronic sing, so I will be doing some updates to load in the animation files on demand to accomplish this.  Additionally, we'll be doing less hands-on running of the animation sequences,. There will be a jukebox mode so the skeleton can run without intervention.

Here's the status of last year's code.  I'll rework this repo to clean up and remove unused options.

https://github.com/darthmario/halloween23-skelleton

The lack of process and QA, which could allow something like this to go out, is surprising. I've agreed with many of the takes that question why this was a global rollout and not a staged rollout where issues could be found and the "blast radius" would be smaller, though still disruptive.  It's easy to conclude that this is also a Microsoft issue.  That may also be true, but take this comment:

Do note that while the focus is on Windows, Linux machines can run CrowdStrike software too, and I’ve heard from Linux kernel engineers who happen to also administer large numbers of Linux servers that they’re seeing a huge spike in Linux kernel panics… Caused by CrowdStrike, which is installed on a lot more Linux servers than you might think. So while Windows is currently the focus of the story, the problems are far more widespread than just Windows.

I don't know many Linux admins that closely at present, but I'd be curious if this were the case.

Hoping for the best with this.  My wife and I are big alamo fans and go there for pretty much all our movie going these days.

Sony Pictures Entertainment has acquired the popular movie theater chain Alamo Drafthouse Cinema, the two companies announced on Wednesday.I hope for the best with this. My wife and I are big Alamo fans and go there for pretty much all our moviegoing

To get the most from GitHub Copilot as your Drupal coding sidekick, know its strengths and limits. Its AI can spit out boilerplate code, but it's no replacement for developer know-how. 

The opening sentence really sums up my experience with AI coding tools and autocompletions.  They are defnitely pretty handy, but much like AI text and images they can spit out utter nonsense too.

I'm going to do a whole post / video on this at some point, but for now, just going to place this here. Along with this link for a vintage article describing exactly the same thing. 

From some amiga bbs:

> How did you do it?  I mean, connect your Amiga 1200 to your Sony
> KV25-XBR?  Nobody I've spoken with at any computer store or Sony dealer has
> any idea where to get a cable to connect a computer to the 34-pin RGB port
> on my Sony.  I even called Sony customer service, and those folks are real
> polite but even THEY don't have a clue.

I went to a Sony Service Center back in 1985 and purchased the
"KV-25XBR/RM-724/APM-X3U Service Manual".  It has schematics and lists
two options for the RGB MULTI INPUT:

  1) The PX-34 RGB multi connector plugs into the back of the TV.
     It has to be soldered on to the end of a cable that brings RGB
     data to the TV.

  2) The SMK-0001 cable has a PX-34 at one end and a "microcomputer
     connector" at the other.  (From the drawing, it is not obvious
     whether this is a DB-9 or some other style of connector.  The
     microcomputer in the diagram looks more like a TI-99 than an IBM-PC.)

The PX-34 was listed for more than $30, and there was no guarentee that the
SMK-0001 had the connectors I needed.  So I built my own.

I purchased a standard 34-pin connector with flat ribbon cable from a
computer store, and wired up a box that has an Amiga-compatible 9-pin
video connector, 6 RCA phono jacks (red green blue sync left right), and
2 switches.  One switch selects sync-on-green versus separate sync, the
other enables TV audio while in RGB mode.  The Amiga has a 23-pin video
connector, so I had to use either a DB-23 to DB-9 cable, or use a
genlock (which uses a 9-pin output connector).

9-pin Video connector (used by A2002 and A1084 monitors, AmiGen genlock):
  01 = Sync ground	06 = no connection
  02 = RGB ground	07 = combined Sync
  03 = Red		08 = no connection
  04 = Green		09 = no connection
  05 = Blue
	07+01 go to a black RCA jack labeled "Sync"
	03+02 go to a red   RCA jack labeled "Red"
	04+02 go to a green RCA jack labeled "Green"
	05+02 go to a blue  RCA jack labeled "Blue"

On a 23-pin Video connector, 03=Red, 04=Green, 05=Blue, 10=Csync, and
16-20 are all ground.  Do not use 11=Hsync or 12=Vsync in this case.
(On the 9-pin male to 9-pin female cable I was using, I took some wire
cutters to pins 06, 08 and 09, since their signals confused my A2002
monitor.)

I planned on adding a second DB-9 for CGA (TTL) monitor, but never got
around to it.  The original IBM PC used 1=GND, 2=unused, 3=RED, 4=GREEN,
5=BLUE, 6=INTENSITY, 7=unused, 8=H-SYNC, 9=V-SYNC.

34-pin RGB connector:
  01 = +5V		18 = no connection
  02 = +5V		19 = no connection
  03 = ground		20 = Audio, Right
  04 = ground		21 = Mode Switch (digital RGB vs analog RGB)
  05 = Remote Ctl gnd	22 = no connection
  06 = Composite gnd	23 = Video (composite)
  07 = Audio ground	24 = Audio, Left
  08 = Red ground	25 = Red
  09 = Green ground	26 = Green
  10 = Blue ground	27 = Blue
  11 = Ground		28 = no connection
  12 = Blank ground	29 = Blanking
  13 = Hsync ground	30 = H-sync
  14 = no connection	31 = V-sync
  15 = Vsync ground	32 = no connection
  16 = Ground		33 = RGB vs Normal
  17 = no connection	34 = Audio Select (+5v enables audio)

01+34 go to a SPST switch (to enable audio while in RGB mode)
20+03 go to a red RCA jack labeled "Right"
24+07 go to a white RCA jack labeled "Left"
25+08, 26+09, 27+10 go to the Red, Green, Blue jacks (and Amiga connector)
13 goes to the Sync jack ground, 30 goes to a SPDT switch, which connects
it to either the Sync jack (separate) or the Green jack (sync-on-green)

The phono jacks are useable by a "GIGI" (DEC VK100 terminal with BASIC).
The 9-pin connector is useable by an Amiga 23-pin to 9-pin cable, or
by the 9-pin output of an AmiGen genlock.

See also the "Sci.Electronics.Repair FAQ on Pinouts" 
http://www.repairfaq.org/REPAIR/F_Pinouts3.html#PINOUTS_015
for "Sony RGB Multi Input (found on KV-25XBR TV's).

Links to other documents:

 *) http://www.hut.fi/Misc/Electronics/circuits/vga2tv/ for details
	on converting VGA video (15 pin) to NTSC (CGA, 9 pin).

 *) http://home.att.net/~billhudson/rybyrgb.pdf has a component (YPrPb)
	to RGB converter.

 *) http://elm-chan.org/works/yuv2rgb/report.html - look for "Circuit Diagram
	3 (Simplified Lv.2) BG part is omitted (Sync on RGB)".

-- 
Joe Smith  <js-cgi@inwap.com>  CA license plate: "POPJ P,"  36-bits forever!
Humorous disclaimer: "My Amiga 3000 speaks for me."    http://www.inwap.com/