This was part of my early cloud and infrastructure learning journey. I’m keeping it here as a reference.
Coming from a Materials Engineering background, I frequently hit coding challenges without a clear starting point — not because the problems were technically beyond me, but because I didn’t have a method for approaching them.
Here are three frameworks that helped.
1. The Mathematical Method
From How to Solve It by G. Polya:
- Understand the problem — What are you actually being asked? Restate it in your own words.
- Find the connection between the data and the unknown — What information do you have? What’s missing? Is there a related problem you’ve solved before?
- Execute — Carry out the plan.
- Review — Check the result. Does it make sense? Could you have done it differently?
This sounds obvious. It becomes valuable when you’re stuck — the discipline of forcing yourself to articulate what you don’t know before reaching for a solution.
2. Turning Problems into Code
From Exercises for Programmers by Brian P. Hogan:
- Understand the problem
- Discover Inputs, Processes, and Outputs — What goes in? What transformation happens? What comes out?
- Drive design with tests — Write the check before the code
- Write the algorithm in pseudocode — English first, then translate
- Write the code
The most useful step here is pseudocode. Writing the logic in plain language before touching a programming language catches structural problems early, when they’re cheap to fix.
3. When Coding: Debugging
German Cocca’s debugging guide at FreeCodeCamp covers this well. The short version:
- Reproduce the problem with the smallest possible input
- Read the error message carefully (the answer is often right there)
- Add logging to isolate where behaviour diverges from expectation
- Verify assumptions — the thing you’re most sure about is often wrong
- Check the obvious first: typos, wrong variable names, off-by-one
The Through-Line
All three methods share the same first step: understand the problem before trying to solve it.
The temptation — especially early on — is to start coding immediately. The problem looks familiar. You’ve seen something like it before. But a few minutes of deliberate framing (what are my inputs? what is the expected output? where specifically does the behaviour break down?) almost always produces a faster solution than jumping straight in.
References
- Exercises for Programmers: 57 Challenges to Develop Your Coding Skills — Brian P. Hogan (Chapter 1)
- How to Solve It — G. Polya
- 3D Game Programming for Kids: Create Interactive Worlds with JavaScript — Chris Storm (Chapter 2)