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:
- Build something small that works.
- Use it.
- Notice what feels wrong.
- 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.