Process and Framework

The Big Idea

Good developers do not just write code — they have a process for solving problems. This framework gives you a repeatable approach you can use from day one. Use it for every challenge, every sprint.


Your Roadmap

SectionTimeRequired?
The process10 min⚑ Required
The framework in detail10 min⚑ Required

The process

At the start of every learning activity, work through these steps:

  1. Start your timer
  2. Understand — get clear on what is being asked
  3. Plan — plan your approach before writing any code
  4. Divide — break the problem into small steps
  5. Attempt — write an initial solution
  6. Get unstuck — debug, reassess, research, or ask for help
  7. Refactor — improve your solution
  8. Reflect — capture what you learned
Problem-solving process flowchart

The framework in detail

0. Be intentional

At the start of each day, write down:

  • What are my goals today? e.g. "Complete the Git setup challenge"
  • What are my challenges today? e.g. "Stay inside the timebox"

Then: eliminate distractions, focus on one thing at a time, and plan short breaks.


1. Understand

Know precisely what is being asked before you start.

If you can explain the problem in plain English, you understand it. If you cannot, you do not — yet.

Write the problem down. Draw a diagram. Explain it out loud to yourself. Some developers use the Rubber Duck Method — explaining the problem to an inanimate object often reveals the solution.


2. Plan

Do not start coding until you have a plan.

Answer: "Given input X, what are the steps needed to return output Y?"

Write your steps in plain English or as comments in your code (pseudocode) before writing any logic.


3. Divide

Do not try to solve one big problem. Break it into sub-problems.

Solve the simplest sub-problem first. Then the next. Connect your sub-solutions — that is your full solution.

"If I could teach every beginning programmer one skill, it would be: reduce the problem." — V. Anton Spraul


4. Attempt

Start writing. Piece together what you have planned.


5. Stuck?

Take a five-minute reset before trying anything else. Then:

  • Debug — go step by step and find where the code stops doing what you expect
  • Reassess — step back and look at the problem from a different angle
  • Research — search for solutions to your specific sub-problem (not the whole thing)
  • Ask — your cohort, your chatbot, or your facilitator

Do not look for solutions to the whole problem. Only look for solutions to sub-problems — that is where the learning happens.


6. Refactor

Once your solution works, make it clear.

Good code is not just correct — it is readable. Short, descriptive names. No repeated logic. Another developer should be able to understand it without asking you.


7. Reflect

At the end of each day, write down:

  • Have I reached my goals for today? If yes, what did you do well? If no, what would you change tomorrow?
  • What have I learned today?

Reflection is what moves learning from short-term into long-term memory.


8. Practice

You will not become a strong problem-solver after one sprint. Solve many problems. The more you practice, the faster you start recognising patterns.


The Big Idea (revisited)

Every challenge you do in Foundations has the same shape: understand → plan → divide → attempt → get unstuck → refactor → reflect. Use this framework every time and it will become automatic.