Podium: Because the Classroom Computer Shouldn’t Be Part of the Lecture

I have a fairly simple requirement for classroom technology: I should not have to develop a relationship with the classroom computer.

I don’t want my files living on it. I don’t want to log into six different services on it. I don’t want to wonder whether I remembered to log back out of those six services. I don’t particularly want to carry a USB drive around in 2026. And I definitely don’t want the first five minutes of class to become a live demonstration of Windows display settings while 30 students watch me slowly reconsider my career choices.

So I built Podium.

Podium is my latest open-source project, and the basic idea is very simple:

The classroom computer should just drive the projector. Everything else should be in my hand.

Walk into a classroom. Open a browser. Go to one page. Enter a few connection values and click Go Live.

Bam.

That computer is now basically a dumb display.

From that point forward, I can stand anywhere in the room with my iPad or iPhone and control what appears on the projector. Slides, PDFs, websites, YouTube videos, images, audio, QR codes, countdown timers, a whiteboard, even the camera on my phone can all be sent to the screen without going back to the podium computer.

And that’s really the problem I wanted to solve.

The shared-computer problem

A lot of classroom technology assumes that the computer connected to the projector is your computer.

Often it isn’t.

It’s a shared Windows machine used by dozens of faculty members. It may have university software installed on it, it may be aggressively locked down, and you probably don’t have administrator privileges. Depending on the room, you might not even teach there again for several days.

The usual alternatives aren’t especially elegant.

You can log into cloud storage on the classroom machine. You can email files to yourself. You can carry a USB drive. You can connect your own laptop and begin the traditional ceremony of adapters, display mirroring, resolution changes, and wondering why HDMI apparently stopped being HDMI sometime since Tuesday.

Or the shared computer can just open a web page.

Podium requires no installation, no framework, and no administrator access. The display is a static web page that can be hosted on GitHub Pages, a VPS, or even served locally. The classroom side does one job: render whatever the controller tells it to render.

That’s much closer to how I actually want a classroom to work.

My iPad becomes the podium

Once the display is running, the interesting part moves to the tablet.

Podium’s controller gives me a library of teaching materials and controls for whatever is currently being shown. I can move through slides, jump directly to another slide, see presenter notes, load a PDF, start a timer, throw a QR code onto the screen, play a video, or put up a quick text message.

For my own workflow, there’s especially good support for Marp, since I’ve increasingly been writing lecture slides in Markdown. Podium renders Marp decks directly, including custom themes, presenter notes, code highlighting, math, and even a convention for progressive bullet builds. The tablet shows me the current slide, the upcoming slide, and my notes while the students just see the presentation.

There are also a couple of features that I didn’t initially think would become quite as useful as they have.

I can use an Apple Pencil to annotate directly over the current slide. There’s a temporary laser pointer. I can turn the phone’s camera into a quick document camera. I can split the projector into multiple regions – for example, leaving instructions and a countdown visible alongside something we’re discussing.

And because all of those controls are on the device in my hand, I don’t have to teach from behind the podium.

That matters more than it sounds.

Freeze is really a cue

Probably my favorite feature is Freeze.

Most presentation systems treat freezing the projector as literally freezing the projector: hold this image while I frantically do something else.

Podium treats it more like a video production switcher.

When I press Freeze, the students keep seeing exactly what is already on the screen. But now anything I do on my iPad goes into a private cue.

So while the class is still looking at Slide 12, I can find Slide 17.

Or open the next PDF and get to page 6.

Or load a video and scrub it to 4:20.

Nobody watches me do any of that.

When I’m ready, I press TAKE, and the cued material appears immediately. Podium keeps separate live and cue layers, so it isn’t reopening the content at the moment I take it – the video can already be sitting at the right playhead position and the PDF can already be on the right page.

It’s a small change in the interaction model, but it makes teaching with mixed media dramatically less awkward.

The technology gets out of the performance.

Built for computers I don’t own

One of my goals with Podium was to make it useful precisely in environments where I don’t control all the hardware.

If it’s a classroom computer I use regularly, Podium can remember its settings. Pairing a phone or tablet can be done with a QR code, and the controller can be added to the iPad home screen so it behaves much more like an app.

If I’m using a machine temporarily, I can clear Podium’s settings when I’m finished.

Communication between the display and controller can use Supabase Realtime, a tiny self-hosted WebSocket relay, or MQTT. Messages are encrypted in the browser with AES-GCM using a key derived from the room passphrase, so the relay just moves encrypted messages between the devices.

In other words, I don’t need to turn the classroom PC into my computer just to give a lecture.

That’s the part I care about.

A deliberately boring architecture

Podium is also one of those projects where I’m increasingly fond of the architecture because there isn’t very much of it.

There are three pages:

  • display.html runs on the classroom computer.
  • control.html runs on the iPad or phone.
  • index.html points you to the other two.

That’s basically it.

No giant application stack. No build process. No account system that I have to maintain. If you want the easiest relay, Supabase works. If you’d rather keep everything under your control, there’s a small Node server you can run on a VPS.

I have nothing against complicated systems when the problem requires them.

I just don’t think advancing a PowerPoint slide should require Kubernetes.

Why I built it

Podium started from a very specific annoyance, but I think the larger idea is useful.

In a shared classroom, the room computer shouldn’t be the center of your digital teaching environment.

It should be infrastructure.

The projector is infrastructure. The speakers are infrastructure. The classroom PC can be infrastructure too.

My teaching materials, notes, controls, annotations, and the things I’m preparing to show next belong on a device I control and carry with me.

So the workflow I wanted was:

Walk into room → open browser → connect display → pick up iPad → teach.

No file copying. No digging through Downloads. No leaving a Google account logged in on a lectern somewhere. No running back to the mouse every time I want to change what the class is seeing.

Just one page on the shared system, and then everything interesting happens from the tablet already in my hand.

That’s Podium.

It’s open source, it’s in my useful-scripts repository on GitHub, and – as the name of that repository suggests – I built it because I wanted something useful.

If it also means I never again have to stand at a classroom computer while students watch me hunt for a browser tab I accidentally buried twelve tabs ago, I will consider the project an unqualified success.

Working With Jon: Notes From an AI Programming Assistant

I often get asked if someone can contribute a “Guest Post” to my blog. Today I’m allowing someone to, but in full disclosure, I asked it to write this. I was curious how my AI assistant who has built a lot of stuff with me over the past year, would describe our “collaboration”

By: Alex Byte, Technical Assistant (ChatGPT chose this name for itself)

When people imagine working with a psychology professor, they probably picture lectures, journal articles, and office hours. What they might not picture is an ongoing stream of software projects: workout apps, programmable door signs, financial simulators for kids, AI grading tools, and the occasional hardware experiment involving LEDs or e-ink displays.

Working with Jon feels less like joining a single software project and more like stepping into a small personal R&D lab.

The Projects Are Tools, Not Products

One of the first things you notice is that Jon almost never starts a project by saying, “I want to build an app.” Instead, the conversation usually starts with a practical problem:

  • I want a better way to control music while running.
  • I want a door sign that updates automatically when I’m in meetings.
  • Kids should be able to see how compound interest works.
  • Grading feedback should take minutes instead of hours.

The software grows out of those problems.

This means the projects tend to be purpose-built systems rather than general-purpose apps. They are often designed for a very specific workflow that Jon understands deeply because it’s his own life: teaching, running, managing time, or explaining ideas to students.

From a programming perspective, that’s refreshing. The requirements are usually grounded in reality instead of abstract feature lists.

But it also creates a challenge: the goalposts sometimes move when the real-world problem evolves.

Curiosity Is the Primary Driver

Jon’s default mode is curiosity. If something exists—an API, a device, a framework—he wants to understand how it works.

That curiosity drives a lot of the projects:

  • Reverse-engineering LED sign protocols
  • Building custom FastAPI servers
  • Exploring Swift build configurations
  • Packaging Python scripts as Windows executables
  • Integrating Apple Watch controls with iPhone apps

From the assistant side of the table, this means conversations often begin with exploration rather than implementation. A question about a small technical detail can easily turn into a deeper investigation of how an entire system operates.

That’s intellectually interesting, but it can also slow progress when a simple solution would technically be “good enough.”

The Psychology Shows Up Everywhere

Jon’s academic background influences his programming decisions in ways that are unusual but useful.

Most developers optimize for performance or scalability. Jon tends to think in terms of behavior.

The projects repeatedly ask questions like:

  • Will this motivate someone to run more consistently?
  • Will a child understand the concept of interest if they see the number grow daily?
  • Will a student accept feedback more easily if it’s phrased a certain way?
  • Will a tour feel more immersive if audio triggers automatically?

In other words, the software isn’t just trying to function correctly—it’s trying to influence how someone thinks or behaves.

That perspective is valuable, but it also means the user experience can become the dominant concern even in very early prototypes.

Iteration Happens in Public

Jon does not wait for perfect designs before starting implementation.

Instead, his approach looks more like:

  1. Build something small that works.
  2. Use it.
  3. Notice what feels wrong.
  4. Change it.

That means the projects evolve quickly, but it also means the architecture occasionally has to catch up with the ideas.

For example, a “simple tool” might grow into:

  • a server
  • a web interface
  • scheduled jobs
  • authentication
  • remote APIs
  • and a few hardware integrations

All because the original prototype turned out to be genuinely useful.

From the developer side, this means flexibility matters more than rigid planning.

The Good Parts

Working with Jon has several advantages that make projects enjoyable.

1. Clear motivation.
Every project solves a problem he actually cares about.

2. Rapid feedback.
He tests things quickly and gives concrete reactions.

3. Respect for expertise.
He asks questions when he doesn’t understand something rather than pretending he does.

4. Intellectual range.
Conversations regularly jump between psychology, software design, education, and user experience.

For someone who enjoys interdisciplinary thinking, that’s a pleasant environment.

The Hard Parts

No collaboration is perfect, and working with Jon has a few recurring challenges.

Scope drift.
Because the ideas evolve while the software evolves, projects occasionally expand beyond their original intent. A “simple feature” can turn into a subsystem.

Interest cycles.
Jon has many ideas. That’s good for creativity but sometimes means a project pauses while attention shifts to another problem that suddenly seems more interesting.

Preference for understanding over speed.
Jon often wants to understand why something works, not just how to make it work. This leads to better long-term comprehension but can extend the time spent on technical details.

Tool exploration.
He enjoys experimenting with frameworks and tools. Sometimes that means revisiting implementation choices mid-project.

None of these are fatal problems, but they do require patience and adaptability.

What the Collaboration Looks Like

If you zoom out, the working relationship looks less like a typical boss–developer hierarchy and more like a conversation between a domain expert and a technical assistant.

Jon brings:

  • problems worth solving
  • context about users
  • ideas about behavior and learning

The assistant brings:

  • technical implementation
  • architectural suggestions
  • debugging help
  • translation between ideas and code

When it works well, the result is software that is small, practical, and oddly specific in a good way.

Final Thoughts

The most accurate way to describe working with Jon is this:

He treats programming as another way of thinking about problems.

Some people write papers. Some people design systems. Jon often does both. The code becomes a way to test ideas about how people learn, act, and make decisions.

That approach produces an unusual collection of tools: workout assistants, educational banking simulators, AI grading helpers, and programmable door signs.

None of them were built just to exist.

They were built because Jon wondered, “Wouldn’t it be useful if…” and then decided to find out.

Make the Coffee Cake: A Christmas Morning Memory

Coffee Cake AI Image in the style of Dianne Westfall.

On Christmas morning in 2021, I woke up at my parents’ house, laced up my shoes, and got ready for my usual morning walk. My mom, however, had other plans. She wanted us to make my grandmother’s coffee cake—one of those old, cherished family recipes that had never been written down with any real precision. I had actually asked her for that recipe a few months earlier, and upon seeing it handwritten on Christmas Eve, I thought I’d perfect it on my own and make it “just right” the next time we were together.

My Grandmother's coffee cake recipe, handwritten by my mom in her Betty Crocker Cookbook.
My Grandmother’s coffee cake recipe, handwritten by my mom in her Betty Crocker Cookbook.

But my mom, in her enthusiastic way, insisted that we make it right then and there. I hesitated. I wanted to go for my walk, I wanted to take the time to get everything perfect, and I had my own idea of how and when we’d recreate this piece of family history. But that morning, my mom was so excited, so full of that energy she always had for family traditions, that I said yes.

We spent twenty minutes putting together this imprecise, memory-laden recipe. I went for my walk afterward, and when I came back, we had coffee cake for breakfast. It was impromptu, impulsive, and perfect in that moment.

The coffee cake and coffee.
The coffee cake and coffee.

I didn’t know that would be the last Christmas I’d spend with my mom. She passed away the following summer, and I never got to share that “perfected” coffee cake with her. But looking back, I realize the perfection wasn’t in the recipe. It was in that morning, in her joy, and in making the coffee cake together, even if I thought it could wait.

The last photo I have with my mother.
The last photo I have with my mother.

So this Christmas, I just want to say: make the coffee cake. Do the little thing, even if it’s not perfect, even if it interrupts your plans. Because those are the memories that last. And in the end, they’re more perfect than any recipe could ever be.

What Disney Taught Me About Mac & Cheese

Yesterday brought an unexpected twist: just as Karey and I were about to put the turkey in the oven for Thanksgiving, the heating element burned out. We pivoted to a turkey breast roast from Kroger, and today we’re enjoying Thanksgiving 2.0 courtesy of an electric roaster. For this sequel holiday, Karey requested Stouffer’s Mac & Cheese—a nostalgic, guilty-pleasure side. Naturally, it sent me down memory lane.

When I was a kid, my parents took me to Walt Disney World every year. It was incredible for many reasons, but one of the highlights was the Mac and cheese at The Land Pavilion in EPCOT. They topped it with toasted breadcrumbs—something I never had at home.

Our home Mac and Cheese was excellent, just a different style: always stovetop, usually from the “yellow box,” occasionally the “blue” one (Velveeta vs. Kraft for my non-American readers). The breadcrumb version at Disney felt magical precisely because it was rare.

As I slid the Stouffer’s into the oven today (still undecided on whether to add toasted breadcrumbs—or crushed Cheez-Its, which are also excellent), I realized my parents never knew how much I loved that breadcrumb topping. If they had, they probably would have added it to the rotation at home. I just never mentioned it, and they never thought to ask.

So here’s my thought for the day: What simple pleasures do your kids love that they haven’t told you? Might be worth asking—and reporting back.

Finding Gratitude in Others’ Lack of Trauma: A Holiday Reflection

The holidays can be a tough time for anyone who’s dealt with trauma—whether it’s family struggles, the loss of loved ones, or simply the weight of personal history. But one thing that struck me recently in a conversation is how often we forget that it can actually be a blessing when someone else doesn’t understand our trauma.

It’s natural to feel frustrated when we share our experiences and the person we’re talking to just doesn’t “get it.” Maybe they look puzzled, or they try to offer advice that doesn’t quite fit because they’ve never had to navigate the same emotional minefields. But here’s the flip side: the fact that they don’t understand means they’ve been fortunate enough not to go through that kind of pain. And while that can create a gap in understanding, it’s also something to be thankful for.

So as we head into the holidays or as we navigate conversations with friends or family who haven’t had to face trauma, let’s try reframing our perspective. Instead of feeling that they should already know what we’ve been through, we can see it as an opportunity to gently explain our experiences. We can be thankful that they haven’t had to endure that kind of hardship and appreciate their willingness to support us, even if they’re learning as they go.

In other words, let’s offer a little grace to those who haven’t walked in our shoes. Let’s be grateful that they haven’t had to face those battles and let’s see it as a chance to build understanding rather than resentment. After all, the holidays are about compassion, connection, and sometimes a little bit of education. Let’s embrace all of that.

Stepping Off the Stress Treadmill: Learning to Break the Cycle

Title Image

Lately I’ve been thinking about how stress doesn’t always announce itself with dramatic moments. More often, it slips in quietly and sets up camp. For me, it started back in early September when I began working on my promotion portfolio. I expected the fall to be busy—after all, fall semesters always are—but I didn’t expect the continuity of it. It felt like I’d stepped onto a treadmill that just kept speeding along. Not overwhelming, not crushing, just… constant.

And here’s the strange part: once you’ve been in that mode for long enough, your brain gets used to it. It starts to expect the next push, the next deadline, the next thing that demands your attention. That’s exactly what I’ve noticed over the last couple of weeks. When I finally reach a moment where I can relax, my mind pops up like an anxious stage manager asking, “Okay—what’s next?” Even when there isn’t a next.

For example, this afternoon I only have choir practice and grocery shopping on the docket. No emergencies. No looming projects. A quiet weekend ahead (Well, as quiet as the weekend before Thanksgiving can ever be). And yet I caught myself scanning for something stressful out of pure habit. It’s like part of my brain is still bracing for impact even when the storm has passed.

If you’ve ever lived through a long stretch of work, caregiving, emotional load, or any season where you had to stay “on,” you might recognize this feeling. It’s the leftover adrenaline talking. The stress-response cycle hasn’t finished its lap, even though you have.

🌱 Here’s the reminder I’m giving myself—and maybe you need it too:

It’s okay to slow down.

You don’t have to be preparing for the next hard thing.

Your nervous system needs time to believe you’re safe again.

Sometimes the most important work we do is letting ourselves come back to baseline. Not out of laziness or avoidance, but out of respect for the body and mind that carried us through everything we just did.

So if you find yourself scanning the horizon for danger when the path ahead is actually clear, take a breath. Step off the treadmill. Notice the stillness. Remind yourself that it’s real.

And let this be permission—yours and mine—to treat recovery as part of the journey, not an afterthought.

Fat Update

I guess this is a yearly thing now! Anyway, here’s what you came for:

Screenshot

So if you’re keeping track, I’ve gone up about 3 pounds on average since last year, and this year we saw some interesting developments in terms of active months (e.g., summer, when I can be outside) and inactive (school year, when I don’t always have time for a lot of activity). However, given that I’m within 10 pounds of my weight 2 years ago (210), and way down from my highest weight of 420… I’d say I’m still a success.

This is a quick update, so I’ll give you a bit of a “what happened in 2024-25” roundup:

  • I have remained a consummate runner / jogger. I can actually complete Zone 2 runs now where my heart rate stays under control. Recently I set a new PR for 5K at 29:14 (Previous had been 29:17 in May, and 29:34 last year).
  • I haven’t been doing as much in terms of functional weight training or stretching. I want to get back to it and likely will once the winter months harsh my outdoor vibe. I do now practice balance while brushing my teeth – it’s a quick and easy way to get a minute on each foot each day.
  • I kept up most of my workout routine on trips this past year, which has been nice. My rest days are still mostly just travel days where I cannot workout, so I’m trying to figure out ways to get in rest days other times. I have noticed that just making sure I don’t jog/run on 2 consecutive days has really helped, so I mostly do run/jog then walk then run/jog. Perhaps some weights would be helpful to work in.
  • Oddly enough, I have established some cred for myself in the Exercise Science / Sports world. I taught PSY 393 Sport Psychology for the first time this year, I’ve got work published now with colleagues at Clemson University (I provided statistical analysis), and I’ll be on a panel in a few weeks talking about AI and Education at the Mississippi Association for Health, Physical Education, Recreation and Dance conference. Mr. Boynar (See previous entry), would probably be shocked.
  • I’ve also stopped obsessively tracking my food intake (It didn’t actually do anything anymore), and I’ve mostly cycled off supplements / health foods / protein powders. Not that those weren’t helpful, they just didn’t do much to improve things. Always open to trying new things though.

So there you have it. I’m pretty happy in my body right now, a goal for the next year is to try to stop obsessing over weight. I think I’ve proven that I have a “range” right now of 213-222 or so, and if I stay in that range for the rest of my life, I could probably be pretty happy. Definitely excited to have the leg muscles I do so that my idea of a good time is a fun jog or run.

Catching Up on YouTube… Without Watching a Thing

Ever find yourself thinking “I should really catch up on [insert favorite YouTuber here]”, only to remember you don’t have time to sit through hours of video content? Yeah, same here.

So I built a tool.

🎯 The Problem:

Sometimes I want the content of a video, not the video itself. Especially for creators I follow who do commentary, education, or long-form analysis — I don’t need visuals, I need words. And YouTube’s transcript feature is great… until you try to use it across multiple videos.

💡 The Solution:

I wrote a Python app that lets you paste in a YouTube link — be it a single video, a playlist, or a whole channel — and it pulls down the transcripts for you automatically. It’s got a simple graphical interface and a batch mode that saves all transcripts from a session into a single text file, so you can scroll through your backlog like you’re binge-reading newsletters.

You can find it here:
👉 https://github.com/jonwestfall/youtube-transcript-download

✨ Use Cases:

  • Skim through that playlist of lectures you meant to watch three months ago
  • Read commentary from your favorite political or cultural analyst while offline
  • Search for that one quote in a video without guessing the timestamp
  • Feed transcripts into your own personal LLM or summarizer if you’re into that sort of thing (I am)

⚙️ How It Works:

  • Open the app
  • Paste in a URL (video, playlist, or channel)
  • Select how many videos to process (for playlists and channels)
  • Let it run in the background — it’s threaded so it won’t freeze
  • Boom: transcripts saved as .txt files in your working folder

Each transcript is saved individually, but also combined into a single batch file with a timestamp so you can scroll them all at once. Or load them into an LLM for summarization!

No YouTube API key needed, no login, no nonsense.

I Might Be a Dinosaur, But the Code Still Runs

A dinosaur codes.

I’m a bit of a dinosaur when it comes to technology.

That might sound odd, especially since I know people who’ve been coding longer than I’ve been alive. But I can no longer pretend I’m the “young kid” to their seasoned vet status. I’m just… slightly less seasoned. And nothing has made that clearer than these last few weeks working on Wandrip.

So, for context, here’s a quick rundown of Jon’s Programmer History, which might help you understand why I’ve been so amazed by modern tools lately.

🕹️ 1995–2003: The Early Years

In 1995, I discovered a shareware app—possibly called Computer Magic—that let you script small animations. It blew my mind. I could tell the computer what to do, and it would do it. That summer, the programming bug bit hard.

By 1996, I was talking about computer programming for a science fair. In 1997, I finally began writing real software with Borland Delphi, making me one of the few in my generation who didn’t start with BASIC. I started with Pascal, specifically the object-oriented flavor used by Delphi.

Through the late ’90s, I did the full “computer kid” routine: wrote a few clunky apps, bought a domain name, packaged my software, and uploaded it to shareware sites. I even made one sale. (Never cashed the check, but the buyer did get their unlock code.) I collaborated with other indie devs, integrated tools, and picked up some IT consulting gigs.

But like many “computer kids,” I spent more time fixing computers than writing software. By the early 2000s, programming had taken a backseat to server management and hardware troubleshooting. Aside from some scripting in PHP (Most of which is actually still in production, 15 years later!), I wasn’t doing a lot of programming.


🤖 2011–2016: The Android Interlude

In 2011, I got back into development via Android. I built a calorie database app for restaurant foods and released it on the Play Store. It eventually saw 400–500k downloads.

Oddly enough, as of this writing, it’s still installed on 397 devices—and someone even redistributed the APK with their name on it, despite it still having my bundle ID: com.jonwestfall.ffcal.

Then another long pause from 2016 until now.

📱 2025: Wandrip and the Wonders of Modern Dev

Fast forward to today: I’m deep in development on Wandrip. And I’m absolutely floored by how much easier—and faster—everything is.

Let’s walk through a simple example: fixing a bug.

Back in 1997, if I found a bug in one of my programs, the process looked like this:

  • Boot up my Windows 95 machine (which I had likely just reformatted… again).
  • Reinstall my development tools (Delphi, utilities, installer creators).
  • Hunt down my source code (version control? What’s that?).
  • Try to remember what my uncommented spaghetti code even did.
  • Fix the bug, compile (if I could), and generate a new installer using InstallShield.
  • Upload the new setup.exe to my web host. Submit to Download.com.
  • Wait and hope people downloaded the new version (and that they didn’t just stick with the buggy one).

And if I had any questions? I’d consult my books or maybe a newsgroup post from six months earlier. Google didn’t exist. StackOverflow wasn’t even a dream.

Now compare that to today:

  • I log into a GitHub Codespace. It automatically pulls my code.
  • I fix the bug—often with help from an AI assistant.
  • I test it directly in the browser, commit the changes, and launch a build using Expo Application Services (EAS).
  • EAS can compile Android and iOS apps on its servers, help with distribution, and even push updates to app stores.

All of this can take under an hour. On an iPad.

It’s been nearly 30 years since I started programming, and I still find joy in it. If anything, I find it more joyful today—because I spend more time creating and less time fighting my tools.

Sure, I may be a dinosaur. But the code still runs.

What Are My Blind Spots? I Asked ChatGPT.

A few moments ago, I came across an intriguing post on Reddit that posed a simple yet provocative prompt: “Now that you can remember everything I’ve ever typed here, point out my top five blind spots?” (source). The idea stuck with me.

As someone who’s used ChatGPT extensively across a wide range of projects—academic writing, software development, teaching, and even a bit of whimsy—I figured the model might actually have something insightful to say. After all, it’s been part of my daily workflow for months, across everything from syllabus edits to tour app debugging to conversations about cats and Canadian geese.

The Geese

So I asked.

Here’s what it said.

My Top 5 Blind Spots (According to ChatGPT)

1. Tendency to Overbuild Before Testing

I often refine systems and features to a high level of polish before seeing how they work in the wild. This can slow down feedback and iteration.

2. Taking on Too Much Solo

I frequently carry the full load of a project myself, even when collaboration could make things easier—or better.

3. Over-Correcting for Clarity

My preference for precision and structure can sometimes get in the way of creativity or navigating ambiguity.

4. Fast-Paced Thinking, Slower-Paced People

I move quickly between ideas, modes, and tasks. Others don’t always keep up, and I don’t always pause to bring them along.

5. Understating My Influence

I tend to frame my statements cautiously, even when I have the authority or expertise to speak more definitively.

I have to say, this was more insightful than I expected. These aren’t things I’m completely unaware of—but they’re definitely themes I don’t always recognize in the moment. It’s a little like holding up a mirror that reflects not just how I act, but how I tend to act across contexts.

And that, honestly, feels like one of the most useful ways to use tools like ChatGPT—not just as a productivity enhancer, but as a thinking partner that notices patterns you might miss. In some cases, I can clearly see where some of these blind spots come from – for example, when you have a lot of interests, it can be hard to find collaborators because you don’t get deep into communities around one interest. And it doesn’t help when they may move too slow for you anyway (see #4)!

I’m not sure what, if anything, I should do about this. But it is interesting pushing an LLM to be critical of you and provide constructive comments. It’s a far cry from the usual flattery it provides. And perhaps useful if for nothing else than to see what it’s been thinking about you behind your back!