How Solving Real Problems Changed the Way I Code

For the first few years of programming, I was an academic coder. I solved the problem in front of me, passed the test, moved on. Real-world coding taught me something different: the problem in front of you is almost never the actual problem. Understanding the real problem is most of the work.

Academic Coding: Solve the Problem Given

In college and on LeetCode, problems are presented cleanly. Here is an array. Find the two numbers that sum to the target. Input format: guaranteed valid. Edge cases: mentioned in the problem statement. Test cases: provided.

This environment optimizes for algorithmic thinking. That's genuinely valuable. But it creates a dangerous habit: accepting the problem statement as given, rather than interrogating whether you understand the problem at all.

The Booking System Lesson

My first real-world project was the booking system for Raghavendra Swami Mutt. When I first heard the brief — "we need a booking system" — my instinct was to jump to database schema and API routes.

Instead, I spent a full day just watching. Watching staff receive calls. Watching them write in registers. Watching them send WhatsApp confirmations manually. Watching the chaos of double-bookings and missed messages.

What I saw wasn't a "booking system problem." It was a communication bottleneck problem. The booking was the symptom. The root cause: information about availability wasn't accessible without calling a person, and confirmation required a human to manually send a message.

This understanding changed everything. The most important feature wasn't a beautiful booking form — it was automatic WhatsApp confirmation on booking completion. That one automation eliminated 70% of the staff workload.

"Real-world problems always have a user behind them. The problem they state is what bothers them. The problem you need to solve is what's actually blocking them."

The RIS Application Lesson

When I built the Radiology Information System for medical imaging workflows, the stated problem was "we need to manage patient imaging data." But the real problem, after talking to actual users, was: radiologists were spending 40% of their time on administrative tasks instead of reading images.

This reframing drove every design decision. The most important thing to build was not a comprehensive patient database — it was the fastest possible path from "patient arrives" to "radiologist sees images." Every screen, every button, every workflow was designed around eliminating friction for that specific journey.

The Idyllic Services Lesson

At Idyllic Services, the stated problem was "our AI pipeline is slow and expensive." Token reduction and throughput.

The real problem: the pipeline architecture had grown organically without anyone questioning the fundamental assumptions. We were sending full context windows when we needed 1% of them. We were making synchronous calls when we could be async. We were routing with brittle if-else chains when a supervisor agent could handle routing dynamically.

Understanding the real problem led to ~99% token reduction and ~10× throughput improvement. Solving the stated problem — "make the API calls faster" — would have yielded maybe a 20% improvement.

How This Changed How I Write Code

Real-world problem solving changed my coding habits in concrete, specific ways:

• I talk to users before I design anything. The user's words contain the real requirements, even when they can't articulate them technically.
• I start with the bottleneck, not the prettiest part. The biggest improvement always comes from fixing the constraint, not polishing non-constraints.
• I build the simplest thing that solves the real problem. Not the most elegant system. The one that eliminates the actual pain.
• I measure results, not features. Did manual work drop by 90%? Did throughput increase 10×? Those numbers are the product. The code is the means.
• I resist the urge to over-engineer. The mutt needed a booking system, not a microservices platform. The clinic needed a RIS app, not a distributed database.

The Mental Model Shift

The shift from academic to real-world coding is ultimately a shift in what you think your job is. Academic coding: your job is to solve the algorithm. Real-world coding: your job is to understand what success looks like for the person with the problem, then find the simplest path to that success.

That mental model change — from "solve what's given" to "understand what's actually needed" — is the most important thing I've learned from building real software for real people. It changed not just how I code, but how I think.