Build the Tool, Don't Find the Tool
A student in my neuroscience class blinked. A lot. That's not remarkable in itself, we all blink. What was remarkable was the question that followed: How many times do we blink in a minute? And does it change when we're focused?
In the past, I would have Googled "blink counter app," scrolled through the App Store, found something close, settled for something mediocre, and moved on. Instead, I built one. Right there. During class. An app that counts blinks, times them, and gives students real data to analyze.
This is the shift I can't stop thinking about.
The Problem-Solver's Instinct
We've spent years training ourselves, and our students, to be tool finders. Need a timer? Find one. Need a quiz platform? Compare five. Need a simulation? Hope someone built one. The entire edtech ecosystem is built on the assumption that teachers are consumers of tools built by someone else.
But what happens when you can build the tool yourself? When the distance between "I have a problem" and "I have a solution" collapses to minutes instead of months?
Building apps to solve problems rather than looking for tools to solve problems is very metal. Solving your own problems through invention just might be the next AI-powered critical thinking.
My own app, Spark Learning Inquiry Studio, is an example of this. I had a problem: inquiry-based lesson design is powerful but hard to structure, hard to present, hard to share. No tool existed that thought the way I think about the 5E learning cycle. So I built one. And it continues to evolve because it's mine, it solves my problems.
Students as Builders
Here's where it gets exciting: students can do this too. Not hypothetically. Right now.
Jacob, a student in my Design for Social Good class, needed a way to test assistive technology connections for the Xbox Adaptive Controller. There's no app for that. So he built one: an Arduino-based testing interface that solves a real problem for real users. He didn't find a tool. He became the toolmaker.
This is what I mean by "app slop" used for good, quick, purpose-built applications that solve specific problems. They don't need to be polished. They don't need to scale. They need to work.
The Classroom as Laboratory
This week I used a Slinky to get my neuroscience students thinking about perception and time delay. A simple warm-up in Spark Learning, watch the Slinky drop, notice the delay between what you see and what you feel, and wrestle with why. In chemistry, we used Jenga blocks to model the molecular instability of nitrogen triiodide. The tower wobbles. You hold your breath. Then it collapses, just like the compound.
These aren't tech moments. They're inquiry moments. The Slinky and the Jenga tower are tools I built into a learning cycle using the same app I built to solve my own problem. The technology isn't the point. The thinking is the point. The technology just makes the thinking visible, shareable, and structured.
The Question
Here's what I keep coming back to: What's a problem you have? Not a tool you need, a problem. And what would happen if you, or your students, just... built the solution?
I think we're entering an era where the ability to identify a problem and invent a solution is more valuable than the ability to find and evaluate existing tools. That's a different kind of critical thinking. And AI makes it accessible to everyone, not just developers.
Something to sit with this weekend., Ramsey
Resources
- Spark Learning Inquiry Studio, Inquiry-based instructional design
- Jacob's Arduino Assistive Tech App, Student-built problem solving
Cycles of Learning, Ramsey Musallam cyclesoflearning.com