What will you write today?

Problem Solver Extraordinaire

First, you have to be an effective problem solver. This is an important place to start since programming is problem-solving.

Although there are many ways to solve a problem, there are a few parts of the process that stand out to me. Programmers who are also great problem solvers distill a problem to its essence, to identify their overall aim and begin a problem with purpose. Then, they break each problem into small, manageable parts — attacking each part in turn, and sometimes in visual terms by drawing a picture to make it “real world.”
The process is harder than it sounds. When I started to program, I hit a wall: like many others, I never learned how to problem solve in school; it’s a skill that’s not readily taught. I was given a problem set in math class and just dove in, which is what I did when I started to program. Unsurprisingly, I was spinning my wheels unnecessarily and hitting roadblocks on the simplest of problems.

Understanding the problem may seem obvious, but the obvious is easily overlooked. On more than one occasion, I’ve poured hours into a problem only to realize much later that I missed a small, but critical detail in the problem statement. Writing out problem details slows me down mentally, and helps me think through exactly what I need to do, which is half of the battle.
From there, I make a plan, which is another of Polya’s suggestions. It makes sense. I write an outline before I write an article. An artist sketches the painting before working on the painting itself. A builder uses drawings and blueprints to build a house. It’s no different with programming. Instead of rushing into doing it, I need to start by thinking about what I’m setting out to do and make a plan of attack.

There are many ways to go about this. Sometimes I outline the steps I need to take in numerical order: first, do this, secondly, do that. Other times I make the problem visual. When I was learning about for loops, I pulled out a handful of almonds and physically iterated through the pile. It’s a silly example, but it helped me think through the problem.
I’ll also draw pictures or diagrams. For a recursive problem, I’ll draw a diagram of what’s happening on each recursive call until I hit the base case. Almost always, however, I find a way to simplify the problem to make it more manageable and to help me spot a pattern. Above all, the aim for me is to enter a problem with purpose, and maintain that sense of purpose throughout.

References (Example)

[1] <name>, '<title>' (online, <year>) <link>.
[2] BULB, 'Write to Earn. Read to Earn' (online, 2022) <https://www.bulbapp.io/>