PopQuiz! Three Cans, a Forest Fire, and a CSV: How We Practise Lateral Thinking
Weekly pop quizzes — odd, off-topic, five minutes long — turned into a lightweight ritual that sharpened our architecture discussions and team participation.
Hey folks 👋 I'm Corey Jasinski, a Staff Developer at Jane.
Why Practise Thinking?
As senior engineers and staff developers, we spend a lot of time solving problems. But most of our day-to-day work happens inside constraints — a ticket, a defined scope, a roadmap, a deadline. That structure is necessary. But it narrows how we think.
Lateral thinking — connecting unrelated concepts, questioning assumptions, reframing ambiguity — is a skill. And like any skill, it needs deliberate practice. The problem is we rarely practise it on purpose.
So I started running pop quizzes. Not tests. Not gotchas. Just prompts.
Pop Quiz #1: Three Cans
I dropped a photo of three ginger ale cans into our team chat and asked:
How do these three cans relate back to our AI conversation the other day? What learning lesson can we take away and apply to our projects?

Same image. Same question. Completely different answers.
Some people focused on label orientation. Others noticed the cans were already opened. Some fixated on the number three, while others talked about perspective and framing. The "correct" answer didn't matter — what mattered was how differently everyone interpreted the same input.
That sparked a bigger realization: if we all see three cans differently, imagine how differently we interpret a product requirement.
That conversation led to a lightweight team norm: before starting a ticket, do a quick-check with someone else. Run your approach past another brain — not for approval, but for perspective. It's reduced rework, improved architectural discussions, and surfaced assumptions earlier.
All from three cans.
Pop Quiz #2: Nonograms and Software
Next one:
How do the skills in solving a Nonogram puzzle apply to solving software problems?

A Nonogram is a grid puzzle where you fill cells based on numeric clues, without knowing the final picture at the start. The parallels were immediate: you eliminate what can't be true, work iteratively, validate assumptions against constraints, and make progress by marking what is out of scope.
One insight that stuck with me: defining what we are not solving is just as important as defining what we are solving. In a Nonogram, empty squares are progress. In software, saying "this is intentionally not part of this solution" is clarity.
Since then, refinement conversations have gotten sharper. We're more explicit about scope boundaries, architectural trade-offs are clearer, and UX discussions are more deliberate. We're narrowing the grid together instead of colouring randomly.
Pop Quiz #3: Forest Fires and Learning AI
Then I posted an image of a forest fire simulation and asked:
How do forest fires relate to us learning about AI?

At first glance? No connection. But the conversation moved into power laws, thresholds, and system criticality.
Learning AI feels slow. You experiment, read docs, try prompts, fail, tweak. Nothing happens. Then suddenly — something clicks. Forest fires don't grow linearly; they hit a tipping point and accelerate. So does capability.
That discussion reframed how we approached learning. Instead of expecting steady visible progress, we embraced experimentation and sharing small learnings in chat. The energy shifted from "I need to be good at this" to "Let's spark things together." That confidence has shown up in planning sessions — people are more willing to propose bold ideas, challenge assumptions, and explore alternatives.
Pop Quiz #4: CSVs, LLMs, and Architecture
This one was more technical:
We have a CSV. We want to interact with it via an LLM — filter, group, aggregate. What’s your architecture? What’s the user flow?
This forced us to separate what the LLM interprets from what a tool executes deterministically, where validation lives, and how the user experiences the system. We debated whether the model should load the whole spreadsheet, whether the LLM or the tool should own sorting and filtering, what needed guardrails, and what was probabilistic versus deterministic.
It was architecture rehearsal without a live fire. Later, when real AI projects came up, the team already had shared vocabulary around tool delegation, context limits, and system boundaries. The pop quiz gave us architectural muscle memory.
The Lateral Thinking Workshop (The Messy One)
At some point, we took this further. We ran a Lateral Thinking Workshop on a giant Miro board.

The goal wasn't to solve a ticket — it was to generate far out metaphors. We asked things like: how is prompt engineering like teaching a kid basketball? How is model variability like a vending machine? How is long AI context like driving longer distances and increasing the probability of failure?
The board got messy. Wild analogies, half-baked diagrams, strange connections. It was chaotic, and that was the point. The exercise forced everyone to reach for something they already understood, find structural parallels, and use metaphor to explain something abstract or intangible.
Something interesting happened after that workshop. In real ticket discussions, people started naturally saying things like "this feels like the vending machine problem" or "are we accidentally driving longer and increasing failure probability?" Metaphors became shared shorthand, and communication improved — not because we wrote a perfect document, but because we practised explaining complex systems in human terms.
The value wasn't the Miro board. The value was the exercise.
What Actually Changed?
Here's what surprised me. These small exercises increased participation in refinement, improved architectural discussions, elevated UX conversations, boosted confidence in idea sharing, and encouraged healthy challenge across the team. Because the quizzes were playful and low-stakes, people practised speaking up — and that confidence carried into real planning.
Developers aren't just picking up tickets anymore. They're engaging earlier — brainstorming, questioning assumptions, shaping direction. They're owning the whole solution.
Why This Matters for Staff and Senior Engineers
As Staff Developers and Team Leads, we influence systems. But we also influence how people think. You don't always need a new process or framework to shift culture. Sometimes you need a weird question, a safe space, a shared laugh, and five minutes of lateral stretch.
Thinking is trainable. Culture is built in micro-moments.
If You Want to Try This
Start small. Post one thoughtful, slightly odd prompt per week, make it explicitly low-stakes, highlight different interpretations, and connect insights back to real work. You don't need slides, you don't need approval, and you don't need a perfect outcome. Just a question that makes people tilt their heads a little.
Final Thoughts
These pop quizzes started as experiments and turned into a lightweight learning framework for practising lateral thinking, improving communication, and building shared ownership. And honestly? They're fun.
If you're a Staff Developer or Team Lead looking to strengthen architectural thinking and team culture at the same time, try something small and strange. You might be surprised what catches fire.
Thanks for reading. If you've run similar experiments — or have a great pop quiz idea — I'd genuinely love to hear about it. And if you're interested in working somewhere that values learning in public and building thoughtfully together, come check out Jane.