My youngest came to me and said,

“Let’s build a game, Dad.”

And in under two hours, we had a game built and published for others to enjoy. This blog post goes through the experience and points out some of the reasons that helped us pull it off.

It’s important to know that I try to spend one-on-one time with each of my kids doing whatever they want to do. Sometimes that’s just playing games. Sometimes it’s building something. This time, he wanted to build a game. It’s a request all of my kids have asked me to do at one point or another. They’ve seen me create games from a VR Jurassic Park adventure to small web games. So of course, they wanted to join in!

Before AI, this usually meant spending most of the time on scaffolding. Picking an editor. Finding assets. Wiring things together just to get to the point where you can even start thinking about the game itself. The lesson often ended up being that game development is hard, which is true, but it didn’t do much to spark imagination. Oftentimes, they’d lose interest before we could get to the game mechanics, or we’d wind up prototyping something in Scratch only for it to disappoint when they wanted to take it to the next level.

That part has changed. AI has made it easier, especially with low-code tooling that can lower the barrier to focusing on logic, game mechanics, etc, instead of scaffolding and keeping the kids engaged.

Lowering the Barrier Without Lowering the Bar

My youngest already had a clear direction. His older sister had instilled a love of FNaF-style “survive the night” games, and he wanted to build something in that vein, but make it his own.

We started on his phone using Gemini. Not coding yet, just breaking the idea down:

• What does “survive the night” mean?

• What ends the game?

• What does the player actually do?

Once we had a solid description of the core components, we had Gemini generate a playable version directly in Canvas. It was surprisingly good. Good enough that we knew we were onto something.

That early win matters. Keeping his excitement high meant he’d be more likely to make it through some of the harder parts I knew were coming, and it kept the focus on ideas instead of tooling.

Iteration (and a Real Failure)

As we added features, we eventually asked it to build a settings menu for a custom night.

Instead, it overwrote the project with a blank game.

This was almost a catastrophe, but that led to a useful lesson… We’d hit the context window limit. He didn’t know that to him his game was just gone… No amount of prompting was going to recover that version. So we adjusted.

Knowing the basics of the game now we were able to reprompt a new chat and recreate it. Once we got to a stable point, we then moved the project into AI Studio, where we could manage the codebase more intentionally.

From there, the process became very familiar:

• Make a change

• Playtest

• Find bugs

• Decide what mattered for MVP and what didn’t

My son made most of those decisions. He’d play, find something that didn’t feel right, and we’d talk through whether it was worth fixing now or saving for later. When he wanted to add a feature, I’d ask if it was necessary for the game to work.

The conversations with him was the real value, he was so excited to add features but very pragmatic about not taking on too much at a time. It was pretty cool to be a part of.

Teaching the Agile Way (Without Calling It That)

At no point did we talk about “Agile,” but we practiced it the entire time:

• Start with a core idea

• Break it into small, achievable pieces

• Build just enough to test

• Iterate based on what actually happens

• Ship when it’s playable, not perfect

This is the same way I approach professional work. The difference is that AI removed enough friction to let my nine-year-old stay engaged the whole time.

A good example of this was the custom night.

Me, not knowing about FNaF, had to ask him what things we should customize, what that meant to the game and if we needed to or not. His reasoning was sound.

“It’s in the main game dad (Sarcasm implied)… also it will give people a way to test the settings”

So we added it!

Shipping It

Once the game felt solid, he asked the best possible question:

“Hey dad, can we publish this so my friends can play it?”

Of course we could. So I pushed the project to GitHub and then began using Antigravity to add the bits we’d need to host it on GitHub Pages. Mainly, this was a workflow for publishing the built project to a branch, setting up a devcontainer so we could dev on any machine. I also took the opertunity to add some mobile optimizations we didn’t worry about in the core build.

And Night Shift was published! https://night-shift.magician.dev

After it was live, he tried it out on all of our devices :) so we had some bugs to fix from that and then he wanted to add some easter eggs (Tell me if you find them)

So yeah, from idea to published game took about two hours… That’s right, TWO HOURS!

TWO HOURS

Is the game perfect? No.

Does it have:

• a gameplay loop

• working interfaces for mobile and desktop

• audio (some are directly from code!)

• level progression

• and a concept entirely driven by a nine-year-old

Yes… Yes it does and it’s out there ready to be played by his friends.

More importantly, he’ll always know that we built something together and shipped it. That matters far more than polish.

AI didn’t replace the work. It reduced the barrier to entry enough that the work could stay focused on creativity, iteration, and learning.

So what are the takeaways?

• AI removed the scaffolding overhead

• We focused on ideas instead of tools

• Iteration and playtesting happened early

• MVP decisions were intentional

• Shipping was part of the lesson, not the finish line

Do this with your kids!

If you’re a parent, teacher, or mentor, this is a moment worth recreating. You don’t need a full weekend or a deep background in game engines. Start with a simple idea, break it down, and build just enough to test.

And if you’re doing this for yourself, the same applies. AI is at its best when it helps you think and build, rather than trying to replace either.

Sometimes the most important thing you ship is the experience itself. My son has inundated me with idea lists and bug reports, so I’m pretty sure what we’ll be spending our next 1:1 time doing :)

As with many of the things I learn, I get just enough training to be dangerous and then use practical side projects to actually get my hands dirty. If you haven’t seen my interactive Christmas trees or the Pumpkin King, those are examples of how I use real-world problems to actually build with things I’m learning. If it’s a complete flop, I just move on to the next project. AI tooling is no different…

I’ve been working on a few side projects and trying to get my AI tooling workflow dialed in through them. One of those is MeshRx, a Rust-based utility for applying common fixes to 3D models. The side project itself isn’t the focus of this post, but the workflow behind how I developed it is.

It’s important to note that I have built many things in C++ but have only played with Rust. So this is a newer language to me. I also have extensive knowledge of 3D modeling and CAD software engineering, so I understand the processes that need to be applied to fix model issues.

It all starts with a conversation

It all started as a conversation with ChatGPT about the need for this kind of utility and examples of how meshes can be broken. I researched existing tools and open-source utilities, and coming off the success of mat2vert.magician.dev, I knew I wanted both an online repair tool and a macOS tool for bigger or more complex files. Bambu Studio and other slicers don’t have repair functionality built in, and it often leaves people searching for solutions. This was my niche.

Knowing this, ChatGPT and I picked the language and frameworks to accomplish our goals, then set out to break the project into phases that I could further chunk with speckit. ChatGPT already knows my coding style but we chatted through the important bits so it understood what I wanted out of each “Phase”… Small, testable steps to build a larger system.

After breaking down the project with ChatGPT, I had it output an agent_instruct file I could use to initialize the repo. This file is similar to .agent or .claude but is a format that I’ve come up with to describe the basic project architecture, coding styles, etc. Here’s a snippet from that output:

# agent_instruct.md — Mesh Repair Core (Rust)

## Context

You are building the **core geometry/repair engine** for a cross-platform mesh repair tool, written in **Rust**.

The long-term product has **three layers**:

1. **Core Rust library (this project, Phase 1)**
   - Rust crate providing robust mesh loading, repairing, and saving.
   - Exposes a clean, idiomatic Rust API for internal use.
   - Also exposes a small, C-compatible FFI API for use by other layers.

2. **WebAssembly frontend (Phase 2, separate package)**
   - Browser-only, privacy-preserving tool (no servers; all processing in the client).
   - Uses the Rust core compiled to **WebAssembly** (via `wasm-bindgen` / `wasm-pack`).

3. **macOS app (Phase 3, separate project)**
   - SwiftUI app for macOS (Intel + Apple Silicon).
   - Links against the Rust core as a `cdylib` / `staticlib` via C FFI.
   - Provides a friendly GUI for large or complex meshes.

You are currently responsible **only for Phase 1 (Core Rust crate + CLI + FFI hooks)**, but you must design the core so it can be safely reused by the WebAssembly and macOS projects without major refactors.

---
...
---
## Language, Tooling, and Dependencies

- Rust 2021 edition.
- Pure Rust where possible.
- Dependencies allowed (and should be reflected in `specs/001-core-implementation/spec.md` and contracts):
  - `clap` or `argh` for CLI
  - `thiserror` for error types
  - `log`/`env_logger`
  - `nalgebra` (optional, if needed)

Follow any additional dependency guidance or constraints defined in the spec files.

---

## Core Data Structures (Conceptual)

> **Canonical definitions are in** `specs/001-core-implementation/contracts/data-model.md`.  
> Use that file for exact field names, types, and visibility.

Conceptually, the core mesh types look like:
...

I keep this file at the root of the repo in a folder called .agent, and I’ve added that folder to the search paths for all my AI tooling. For example, I symlink .claude.md to this file, and I update the Copilot VS Code instructions so they look in .agent as well.

If the file gets too long or too detailed, I split it into smaller pieces (project_arch, coding_guidelines, feature_xxx, etc.) and then reference those from the main agent_instruct file. I’ve found that most coding tools can pull in extra files as needed, and when instructions get long, they tend to follow smaller, more focused documents much better than one giant one.

So with my agent_instruct and basic repo initialized, I then set out to define the work to be done in the first phase.

Use SpecKit to really define the work to be done

From there, I used Speckit to further break down the initial phase (the Rust CLI). I used GitHub Copilot with Claude and Speckit to do this. Working through the plan, research, and tasking really helped me hone in on what we were trying to accomplish. Phase I was intentionally narrow: close holes in models naively through a Rust CLI. On the side, I had been requesting several files from various 3D printing Discords that I could use as tests… Having these and making sure the spec used those specific files ensured I had a good base for phase I.

The coding model would know explicitly what I wanted through the spec framework, it had extra guidance it could access through the agent_instruct file, and it had known bad files to test against. I was feeling pretty confident.

Up to this point, no actual code had been produced. It was just conversations with different LLMs at different scopes (high-level project overview vs. detailed spec definition). Now that I was confident in what we were building and confident that it was all documented it was time to let yet another model loose on the codebase.

Use a big model to do the heavy lifting

I’ve used Speckit implemented in Copilot, and while it does perform rather well, I’ve found that using Claude CLI or Codex (my go-to) is better at following the instructions and getting more of the generated code right the first time. I always have to go back to Copilot or smaller models for the more interactive troubleshooting that follows, but for the big swath of code gen, I’ll typically use Codex.

That being said I was recently in some lives with AI coders from around the world that was singing Gemini Pro 3’s coding capabilities and they had just released Antigravity so I decided to give Antigravity a try. I must say I’ve been pleasantly surprised… It was a bit of a curve to get devcontainers and other integration I come to expect by default in VS Code configured. But once that was done I found it to be a pretty decent IDE… it is essentially VSCode after all.

Its direct integration with VS Code actually made for some really fun experiences: presenting a plan in the main editor, taking over the terminal, managing the file system, even using checkboxes in the editor window and ticking them off as it went. I basically pointed it to the spec and agent_instruct and told it to complete phase I.

After a bit, Phase I was completed. There were bugs, and I iteratively swapped between Gemini Pro 3 and Copilot with Claude to resolve them. Having the sample models really helped here as I could test and load the output in Bambu Studio. But overall, the experience was smooth!

Yes, one more AI

Once I felt confident with the codebase, I submitted a PR and had Copilot review it. It found several things (unused imports, logic that would swallow errors, small edge cases) that were easy to address. In fact, it had auto-buttons to just address them there, but I again often opted to go back to Copilot and work iteratively through them until the PR was good.

As I actually got to playtest the CLI, I realized I needed to include some pipelines in so I added a phase for a CI/CD pipeline to have the WASM and CLI built as GitHub artifacts!

Next phase

As I was adding an additional phase, “Volumetric Repair.” I realized the agent forgot to update the WASM crate even though it had made breaking changes to the API. I had included it in the spec to check that the WASM crate built successfully, but in the end, it decided not to fix the crate and instead just document a breaking change… It was lazy. Even though I had play tested the CLI and saw it was working I overlooked the WASM build… This was caught in that CI/CD pipeline, even though I didn’t think to test the WASM locally during that iteration. So building that out early helped me detect issues I didn’t think to check.

I repeated the same methodology for the later phases and now have a working CLI (Linux/Mac/Windows) and WASM that can do basic repairs. I’ve even been able to help some people on Discord who had broken meshes that current solutions couldn’t fix!

So what?

If you’ve read this far, you might be thinking, “Great, it worked for you… so what?” I’d say the project itself is just an example of a workflow that’s been working for me, and I wanted to share it and hear input from others.

The main things that I’ve found helpful with AI tooling are:

• An initial conversation with an LLM can help solidify the idea and plan. Both for you and the coding tools.

• Create an overall guidance doc (agent_instruct) that all of the other coding tools can use as a basic reference for the project architecture, coding style, frameworks/languages, and general guardrails.

  • Use the initial conversation to help seed that document

• Get down into the nitty-gritty of each milestone with SpecKit and clearly define what you want to accomplish. Use your overall guidance doc as context when generating specs.

• Provide the test cases yourself or use real-world examples that can be tested.

• Use a large coding AI (Claude CLI, Codex, Gemini Pro 3) to actually implement the spec you defined.

  • Review the code yourself. Make sure the tools didn’t leave any unwanted or missed requirements.

  • Run the same commands and test cases. Don’t believe it ran all of those for you.

  • Make sure it updates the artifacts too.

  • Use Copilot or other small interactive models to troubleshoot.

• Play-test the output, ensure that the tool produced what you wanted

  • Hold back some test cases for your own use to ensure the solution wasn’t hyper-optimized for the test cases.

• Use PR’s as a final check with Copilot reviewing the entire codebase.

• Build CI/CD pipelines early that will alert you of missing or failed items.

• You are part of the process… Every process. Make sure the tool works for you.

These are just general guidlines that I use in my flow and I’d love to hear from you how you are utilizing these tools and what processes work for you! Hit me up on my socials to engage.

if you would like to try out MeshRx it’s now available at https://meshrx.magician.dev/, Mac app coming soon.

“What Simpsons character would you be?”

We tossed around a few guesses, laughing about whether I was more of a Homer or a Ned, and then I flipped the question back at him. That’s when the lightbulb went off… I remembered how we’d used ChatGPT 3.5 in the past to create a fun little RPG together, where he gave input and the AI spun a story around it. We had a merry adventure beating an orc, tricking a wizard, and eventually saving the day. Why not see if it could figure out what Simpsons character we would be?

This time, with GPT-4o, I uploaded a photo of him and asked it to turn him into a Simpsons character. Not only did it create a fantastic cartoon version of him in that signature yellow hue, it gave him a name, a personality, a backstory. He instantly transformed into Milo Munchman, a snack-loving, big-hearted troublemaker with a squirrel sidekick “Nutters” and a knack for vending machine mischief.

And then, as these things often do in our house, it spiraled… in the best way possible.

We brought in the rest of the family:

• Abe Munchman, the quiet, bearded engineer dad who keeps the Springfield Power Plant from imploding (from the basement, of course).

• Marge Munchman, the loving, detail-oriented homemaker and holiday party queen.

• Lisa Munchman, Milo’s fiercely loyal older sister with a pink-shirt-wearing soft armor philosophy.

• Bart and Burt, the lovable goofball older brothers who specialize in breaking things creatively.

• Mimi Munchman, the grandma with a purse full of wisdom and snacks.

• Maw Maw, the homesteading, plaid-clad matriarch who can outbuild, outbake, and outwit just about anyone.

• And Auntie Grace, the galaxy-hoodie-wearing cosmic crafter and aunt every kid dreams of.

We had a blast watching each image pop into existence, complete with Christmas hats, personality quirks, and in some cases, galactic glitter! The backstories were sometimes eerily spot-on and sometimes hilariously off, but always perfect. We laughed, we built out a fictional universe, and honestly, we made a memory that’ll stick with us for a long while.

What started with a question turned into a full-blown family portrait, Springfield style.

Want to Do It Yourself?

If you’re curious to try this out with your own family (or just want to see yourself as a Simpson), here’s how we did it:

1. Upload a photo to GPT-4o.

2. Ask it to turn the person into a Simpsons character.

3. Request a backstory… and maybe a catchphrase for good measure.

4. Keep going. Add relatives, pets, friends, and create your own little Springfield.

I love utilizing AI to help me spark play, fuel creativity, and bring the family together in unexpected, delightful ways. When kids own the adventure, it’s just different, seeing their creations come to life… Today we brought springfield to us and I wouldn’t trade it for all the Duff Beer in the world!

The features

As you set out to build anything you need to understand the core features and this was no different, I started with the need for a timer. I wanted my son to sit on the potty for 10 minutes and he was anxious, playing games, running in and out, I was frustrated. But then I tried setting a timer in the clock for 10 minutes and telling him to sit until the timer went off… IT WORKED! but having to set my phone in there with the timer while he just played on his wasn’t the best. If I just had something that could hold his attention for the 10 minutes then I would be perfect. So I incorporated little games, and again it worked! So with this success in hand I had an idea in mind.

Let’s build a custom app that at it’s core had a timer function with little mini-games or activities that could hold a kid’s attention for 10 minutes. I’ve seen similar things like Colgate’s Hum toothbrush for kids we even used it with our kids and they loved the challenge and virtual gifts. So I set out to make something similar. But let’s not forget the adults, they will be the reason the kid uses the app so we’ll need an incentive for them… Apple Health! What if we could track the success rate and offer suggestions for potty training!

After confirming all of this with ChatGPT I came up with the following list of features:

• Core

  • A timer system with notifications to help both parent and kid keep a schedule

  • A way to track success or attempt and graph that for the parents over time

  • Interactive “Busy” activities to keep a child occupied during each attempt

  • Virtual rewards to keep the child engaged and positive

  • A compelling theme to excite

  • COPPA compliance (Minimal data collection, Parent Opt-In)

• Optional

  • Parent dashboard with better than Apple health diagrams and training tips

  • Hydration and Hygiene tracking (Could help)

  • Overall mission tracking (set an end goal)

  • Parent data sharing (in a COPPA-compliant way)

  • Add-ons like character expansions, mission expansions, themes, etc.

Free or Paid

This is another area where ChatGPT helped, I needed to do market research on how many users I would potentially have and how to monetize the app, mainly just to cover the cost of me developing it and any little bit I can make to make my personal dev fee smaller :)

The market research showed that a $.99 app would cover the cost of development since the app is likely to have high churn. Kids only potty train once, and the app is not likely to be of use past that. For those who need it longer, having in-app purchases for things like hydration or hygiene will help extend past the potty training phase. But all in all it’s a one time throw away purchase.

All of the freemium models would require some kind of advertising or hinder the functionality of the app by having to gate features so a one time purchase with the possibility of in-app purchases made sense.

So What’s the Theme?

Potty Heroes is an amalgamation of several of my kids’ favorite TV shows. Paw Patrol, Wonder Pets, and similar franchises where teamwork, engaging characters, and fun missions are at the heart of the experience. Each Potty Hero is designed to represent an essential aspect of the potty training journey, ensuring the app is not only helpful but also highly relatable to toddlers and young kids.

The characters are inspired by popular emojis, giving them a universal appeal and an instant sense of familiarity. From Captain Flush, the brave leader who embodies confidence and courage, to Splashy the Soap, the bubbly hygiene expert, each character adds its own charm and expertise. The goal was to make the heroes not only educational but also fun, creating a cast that kids would eagerly interact with.

I used a combination of image generation, editing, and 3d model generation and animation tools to create the characters… or at least enough to continue for now.

Let’s get coding

I wanted to start fleshing out the interface and some of the initial work to get a sense of how hard this was going to be. I was pleasantly surprised that it’s come together so well and I was able to get more work done than I thought I would.

I was able to get the 3d model integrated with an animation and create a screen for consent.

I was also able to stub out a “Heros Dashboard” and get all of the access flow integrated!

What Should I Include in the Next Update

That’s it for now, my next thing to tackle is to build the first game and timer and then notifications.

For those unfamiliar, Inktober is a yearly challenge where artists create ink drawings based on daily prompts. It’s an awesome way to flex those creative muscles and maybe learn some new skills along the way. Over the years, I’ve used Inktober to dive into new creative mediums, from digital sculpting in Nomad to AI-generated art. This year, I’m exploring the exciting world of HueForge 3D (@hueforge).

HueForge is like a digital canvas for 3D printing. Imagine painting with filaments instead of inks. Sounds crazy, right? I’m working on a monster series inspired by Misfit Printing (@MisfitPrinting) Halloween portrait wall. I’ll be crafting and printing a unique monster every other day until I complete the wall.

Intrigued? Check out the first creation in the Huetober series—Drac!

Pretty impressive, right? I’ve even posted the model on Makerworld and Thangs, and you can download it to print yourself!

Creating these multi-layered prints is a fun process. I’ll share a quick breakdown to get you started:

1. Image Creation: First, I combine AI-generated art from Midjourney with some Photoshop magic to craft a spooky image of the classic monster.

2. HueForge Prep: I import the image into HueForge.

3. Layer Creation and Filament Assignment: This is the coolest part. I use HueForge to create the layers for the 3D print, and adjust the color scheme and settings for each filament… I want to make sure the right components POP!

Once that’s done, I export the model into Bambu Studio (HueForge includes a handy describe file with all the color change information). And now, here's where the real magic happens. Take a look at this brief tutorial from @neokoiprints:

The describe file tells me where to add the different filament stops. I've created this file so you can print this on any 3D printing machine. You don’t need to have a fancy AMS system or anything like that. Just follow the color change instructions, swap out the filaments, and voilà!

So, go ahead and make your own Huetober creation. Share your creations with me, and stay tuned for the next monster in the series. You can view all of my Monsters as I create them at my linktree.

I hope you have a spooktacular season!

This little fella is still in its early stages, but it's already showing some serious promise. As you can see in the video below, the prototype features a cheerful smiley face displayed on a small, circular screen. It's about the size of a…well, I’ve helpfully included a can of Coke and a banana for scale. You get the idea.

What's really neat is the touch interface I'm developing. A simple touch elicits a reaction from our smiley friend, and a swipe down reveals a settings menu where I can tweak things like volume. There's something undeniably satisfying about interacting with something so small and seeing it respond in real-time.

A Glimpse into the Future (and the Settings Menu)

While the software is still a work in progress, the goal is to create a pin that can answer your questions, provide information, and maybe even offer a bit of witty banter. Imagine having a miniature AI assistant right there on your lapel, ready to assist at a moment's notice! The possibilities are endless, and I’m having a blast exploring them.

Now, without further ado, here’s the video demonstrating the AI pin prototype's character display and touch testing:

As you can see, the touch responsiveness is pretty snappy, and the character animations are starting to come to life. I’m continually tweaking the settings, working on the AI integration, and brainstorming new features. Stay tuned for more updates as this project evolves! Let me know what you think in the comments—I always love hearing your ideas.

Over the years I’ve tried dozens of ways to cook turkeys from brining to frying. Here are just a few:

Bacon wrapped Breaded and fried Smoked

My favorite of all the methods is spoiler injected and smoked. Our feast has grown enough that we need two turkeys now and a with a mix of kids and adults we wanted to have different selections for each.

I started the tradition of Dr. Jekyll and Mr. Hyde about four years ago on a single bird. Each breast taking on the different roles of the characters.

Dr. Jekyll is sweet and savory, injected with a garlic honey butter and smothered with a pepper blend. Mr. Hyde is hot and spicy, injected with Datil honey, Buffalo sauce, and butter usually rubbed with red hot dry rub.

Once injected and rubbed they are smoked at 225°f until the inner thigh reads 180°f. I use a blend of fruit tree and pecan wood for the smoke. I started out with an electric masterbuilt smoker but as the size of the turkeys grew so did my needs for a large smoker. This Pitboss Lockhart has served me well the last few years and offers the nerdy things I need like wifi control.

Now, I’m a stickler for traditions and this one is here to stay. You know a tradition has taken hold when you tell your kids you might try something different this year and they go “Oh my god dad, we have to have Dr. Jekyll and Mr. Hyde!”

check out this years video

I hope you and your families are creating traditions that last and if you decide to try the Dr. Jekyll and Mr. Hyde turkey shoot me a picture on any of my socials.

Happy thanksgiving DB

A few days ago I watched Adam Savage’s reply to one of his patreon’s question:

“Do you ever lament that you’re a generalist when it comes to maker skills, instead of devoting all of your mind and resources at becoming a master at one particular thing? I know I do.” ~Jason Cz

If you haven’t seen the video go watch it. Adam does a great job discussing why he’s proud to be a generalist. Go ahead, I’ll wait.

Amazing right? This video as well as this post from a fellow maker touched me so much that I thought I would tell my story in becoming a generalist in the hope that it might help others deal with some of the anxiety or missteps I had. My general answer would be YES of course I struggled with that. After all our entire society is geared for mastery of a skill. After reading this I hope that if you are a generalist you’ll embrace it or if you are someone mentoring a generalist you can help them see why they might not be satisfied with mastering a single skill. This is by far the longest blog post I’ve written and I plan to develop the individual stories into something more but for now, here’s my story.

Looking back I was always curious. In my youth, my quest for understanding often manifested to others as destructive behavior. I had no qualms destroying something to understand how it worked. I didn’t mean to destroy it but I lacked the skills to understand how to put it back together. It wasn’t until later that I realized that people reacted better when I tried to fix things. I found that tearing apart a broken thing could reveal how it worked along with the added benefit that it didn’t upset people as bad. My grandfather would often say

“If it can be fixed he’ll fix it. But if it can’t… it will be so broken no one else could attempt to fix it”

I was lucky to grow up where I did. There were always parts to scavenge and my neighborhood seemed to have an endless supply of broken bicycles and lawnmowers. Much to the chagrin of my mother, I would collect these items behind our trailer and then put them together to create frankenbikes or lawnmowers that were probably nowhere near safe to operate. But this outlet allowed me to scratch the itch and learn about the components of complex systems. I answered questions like why were spark plugs not interchangeable and how brakes worked. This led me to be the local fix-it kid for bikes and lawnmowers and I was hooked.

Fast-forwarding a bit to around the third grade. I started to attribute my thirst for acquiring new skills to my ADHD as my teachers would often tell me I had it and would penalize me for not paying attention in class. I often had a book on another subject open pouring over RAM jet architecture or space travel instead of focusing on mastering cursive. They would eventually convince my mother to have me tested, diagnosed, and drugged. However, Ritalin just exacerbated the issue. It would give me huge bursts of energy that I would pour into fracturing my learning even more. This ultimately led to me understanding that the underlying reason wasn’t ADHD but rather that I bored easily. Looking back today I can say that I drew pleasure from unlocking a new understanding, being able to conceptualize the new learning and apply it. After I had a grasp on how something worked I was not interested in the minutia of perfect execution. This went on until the fifth grade when I was taken off of Ritalin. I remember the teacher's words that convinced us.

While it may appear that he is not paying attention in class or completing his homework David shows an aptitude for the subject matter and aced his finals which clearly shows his ability to multitask. ~ Fifth-grade teacher

I still thought of myself as a failure and coming off of Ritalin had its side effects, not to mention teenage issues. But as I progressed in middle and junior high I brought on a new title of “Nerd” I was actually really happy with this. Being a nerd also helped me understand that I was an introvert and while I did get a rush from being able to help others understand a subject I got a bigger rush from just unlocking new knowledge. The libraries at my school were extensive and my favorite subjects were Japanese and robotics. Not because I was intrigued by either subject but because the teachers allowed me to explore other avenues of the subject. I learned HTML in robotics from a fellow student and applied it to the Japanese class to help the teacher make flashcards as an example. I was also introduced to an encyclopedia set (the internet was still young) and OMG you could catch me at any time of the day exploring a new subject. These experiences launched me into becoming what I am today but they were also where I had the most challenge. Bullying and home life lead me to quit school in the 10th grade, move to another state, and become emancipated.

It was honestly the best decision for me. I wouldn’t recommend it as a first course for anyone but having a change in life like that really makes you evaluate yourself, what you’ve become, and who you want to be. I still had the support of my grandparents so I wasn’t truly alone but they structured the experience so I would have to figure things out for myself. I lived in a camper near their home but separated by a creek for example. I had to pay for utilities and rent, etc. I spent a lot of time outside of work just deep in thought to answer the aforementioned questions and it really helped me understand what I wanted to do. I hadn’t grasped and wouldn’t grasp that what truly drove me was learning but computers and programming, really electronics in general brought me a ton of joy. I didn’t really like to play games on the computer but the internet brought a ton of knowledge directly to me. I spent many many sleepless nights just going down one research rabbit hole after another. Much like the frankenbikes of my youth I was able to build computers and understand software configurations. I remember reading every page in a series named the bible. it had everything you would ever want to know about a subject in huge books. For example, there was one on HTML called The HTML Bible that had every tag in the current spec. So, of course, I became known in my town as the computer guy. I had to work in areas like retail, construction, call centers, etc. because I lacked the degree and confidence to even apply for jobs related to my passion, so it remained a passion for some time. Often times I would work a full 8–12 hour shift and then go making house calls to fix people's computers just to scratch that itch to solve problems. I didn’t care about the money and oftentimes didn’t charge opting to just eat dinner with the people who I helped.

It wasn’t until I landed an actual job at a software development company that I really understood my potential. I was hired to help the owner with customer support but her husband saw the potential in me to become more. He noticed that I would try to break the application, write scripts for it, and push bugs to the software devs. He then made me realize that I could make things virtually and that in doing so it was just as satisfying as building a computer.

So of course this propelled me along a trajectory of becoming a software developer but also landed me in jobs dealing with PC building or systems administration in my early career. Keeping up with the latest and greatest in these fields now became my primary focus and things were changing so rapidly that it satisfied that need to learn and everyone was interested in my opinion of new tech since I kept up to date so it helped accelerate both my career and personal comfort with being an SME. Yes a new label, SME (Subject Matter Expert).

I also didn’t like being called a Windows or a Mac person. I like Linux just as much and when mobile phones started to be a thing I wanted to use all of the operating systems I could. I remember being called a dual platformer and later a cross platformer, eventually I would settle with platform-agnostic but it wasn’t because I had specific tasks to perform on an individual operating system. There were tasks more suited to one over the other at the time it was the thrill of being able to learn about them all and then apply it. When someone would visit the build room and ask to recover something I could save thousands of dollars by recovering the file(s) myself booting into Linux and using some of the advanced command-line tools available there. This was valuable both for my company and me as it showed I had capabilities beyond my current role.

It wasn’t until I was introduced to an Arduino that I really called myself a maker and even then it wasn’t until I discovered that I could communicate with them to create mashups like:

That I could conceptualize things and then make them real. I had often built things and even worked in construction but up until this moment I classified myself incorrectly as a hacker. My explanation was that I could take disparate systems and join them together to create new things that they weren’t intended for. Like creating a Youtube clone in SharePoint using Adobe’s media manager. Hacker seemed to fit and it was cool so I ran with it. Like much of my experience I often knew enough about the systems I worked with to build things with them. to make a square peg fit in a round hole. It’s what drove my passion to solve tough problems.

All along the way, I had great mentors that saw my curiosity and eagerness to learn and helped me. My general knowledge of multiple systems, languages, techniques, etc drove me to be involved with many high profile, tough technical challenges like being on the team that solved antenna gate or helping create new computer vision techniques for landing drones.

By some miracle or happenchance, this culminated in me getting to work full time on projects with companies like Verizon and Disney. It was here that my maker abilities were tested, broken, and reforged. From software development to rapid prototyping with 3d printing. I was able to take a problem, conceptualize a solution, and then not only build a prototype for it but also refine it into production and influence many lives. I was solely responsible for the outcomes of my ideas and this is where I truly became a generalist. Before it was a passion, a hobby, a way to scratch an itch. Now it was putting food on the table.

It wasn’t until I stepped away from this role that I realized I had no understanding of time management. Most of my work up until this allowed my passion to run rampant but were structured enough to step in when I would take on too much or put up a framework for me to limit my commitment. A lot of this was due to the mentors I had but also just how the enterprises were structured.

Being introduced to Agile which I thought at first was simply kanban was another life-altering educational experience. Never before had I understood how to create time estimates and back them up with experience and apply focus and structure to the problems I was trying to solve. While agile itself was yet another skill to learn it has become way more useful in life than I ever thought possible. I still don’t know all the ins and outs of Agile but it has allowed me even with a base understanding to change the way I structure problems and time management.

While learning agile I was forced to specialize in a certain language and thought about going all-in on the software developer route. I could see myself adopting a discipline for a specific way of software development and focusing on deep-diving into a single ecosystem. After having to keep up with all of the new trends for all of the different languages, frameworks, plugins, architectures, etc. I was tired. Not from information overload but learning things that I’d never get to apply. It was frustrating, infuriating, and caused me to get a second job and third job. I was not longer getting to scratch that itch so I was looking for places to do so. It was great at first but after overcommitting and underperforming I could see the cycle starting again. So I had to figure out how to scratch that itch without taking on additional commitments. Finally, I found the right balance between the two, and something amazing happened. My work once again took notice of my peculiar talents and carved out a position that fits my needs perfectly. They understood that being able to rapidly learn and apply new knowledge was perfect for blazing the path forward. Uncovering and conquering technical unknowns were essential to leap frogging in the market and of course, failing along the way is necessary for discovery.

Now, today I have an understanding of what I love to do and that is taking on problems that others either can’t or haven’t solved and applying the culmination of my learnings to solve them. Most of the time this uncovers a new gap in my knowledge and begins a new learning journey. Being in this mindset all the time still sets me up to have to rapidly learn new skills all the time and I couldn’t be happier for it. I have found though that software isn’t enough to scratch my itch completely anymore and that’s why I also love being a maker. I’ve found that pursuing making fun things in my spare time and learning new techniques like joinery has really put me in my happy place.

So as you can see becoming a generalist is a journey just like becoming a master at any particular subject. You have to put just as much time and effort into it as mastering any particular skill. This is why I don’t like the phrase “Jack of all trades, master of none”. The difference is that generalists are masters. While the external skills may be varied in both the level of knowledge and application of a specific skill, generalists are masters at rapid learning, conceptualizing, and applying that learning.

I can however in floating this term with friends and family see that even generalist might not be the best term for this. Much like the term hacker, it has a negative connotation that you aren’t a master at anything. It’s hard to change people’s minds around a term's definition as I’ve found out with both the term hacker and drone (I still call what most people call drones quadcopters). I hope to learn or develop a term one day that describes my skill as a skill of acquiring skills but until then generalist it is.

So as you look at my journey and map it to your own as a hacker, SME, multi-disciplinary engineer, maker, or generalist I have three thoughts to leave you with. 1. Understanding that you don’t know everything about something is key to letting others help you understand more about everything. 2. Learn how to learn on your own. Mentors and other resources are a byproduct of learning how to learn. 3. Find an application for your knowledge. You haven't truly learned a subject until you’ve applied it. Even if it’s conceptualizing the application.

Thanks DB