I feel blessed and fortunate that my journey in computer science began with the classic How to Solve It by Computer by R.G. Dromey (1982), a book inspired by another timeless masterpiece, How to Solve It by George Pólya (1945). Back then, as an innocent college fresher, I had no idea how profoundly these books would shape the way I think and approach problems.
When people talk about computer science, software development, or programming, the term "problem-solving" often comes up. If you've been in this world for a while, you've probably heard advice like, "You need to be a good problem solver to become a good software engineer."
But the million-dollar question is how once become a good problem solver in the first place?
A naive answer would be "just solve a lot of problems". But there is more to it.
Taking a leaf from Pólya's classic How to Solve It, he outlines four timeless principles for approaching any problem:
- Understand the problem.
- Devise a plan.
- Carry out the plan.
- Look back. Reflect on your work and ask, how could it be better?
These principles from 1945 (more than 80 years ago) still stand tall and are more relevant than ever.
The first principle ("Understand the problem") is where the real crux lies, and it's exactly where most people in software engineering go wrong.
Let's take a hypothetical scenario at your workplace. There's a complex problem that needs to be solved. One person tackles it with an innovative but complicated solution and manages to fix it. Another person approaches it differently, by simplifying the problem itself and solving that simpler version with a trivial solution.
Now, who do you think will get the limelight? Which one will go viral on social media? Which one will rack up views on YouTube?
Unfortunately, it's the first person. The other quietly moves on to their next problem.
As an industry, we celebrate complexity and even take pride in building tools to manage it. But is that really what we're paid for?
The primary objective of any software is to make its users' lives simpler and easier. And the primary role of a software developer is to build such software and helping their organization become profitable and grow in a sustainable way.
By celebrating and popularizing the tools we use, we're missing an important piece of the puzzle. Our customers pay us to solve their problems and that's what ultimately becomes our salary.
We should take pride in the problems we solve and celebrate the success of our customers.
By taking an "AI-first" mindset, we're doing the reverse. We fall into the "solution-first trap", starting with a tool and then retrofitting a problem to fit it. A few years ago, it was "blockchain-first." Before that, "microservices-first." As an innovation, I agree, AI is far more powerful and useful than blockchain or microservices ever were. But that's not the point. The real question is do we even need it in the first place to solve the problem at hand?
We've started optimizing for the technology rather than the outcome. People want to look innovative, not necessarily be effective.
Simple problems get over-engineered and fundamentals like user understanding and domain logic often take a back seat.
By choosing to go AI-first, people are choosing the tool first and then looking at the problem to solve rather than picking the problem first.
Going AI-first is like a painter obsessing over buying the most expensive brush before deciding what to paint. True artists start with a vision, not a tool. The brush just brings that vision to life.
What really bothered me and eventually triggered me to write this post, is the wrong signal we're sending to the next generation of software developers. We're creating an environment that's biased towards using tools rather than encouraging thinking.
I'm not worried about AI replacing coding. I'm worried about AI replacing thinking.
Dromey and Pólya taught us to think first and compute later. AI-first reverses that order. When you start with AI, you start with an answer in search of a question. True innovation doesn't come from the tool; it comes from the clarity with which you define the problem.
If we can help the next generation rediscover what Dromey and Pólya taught us, to think first and compute later, the future of software will be in good hands.
