Problem Solving and Pseudocode

The Big Idea

Before you write a single line of code, think through the problem. Pseudocode is a way of writing out your plan in plain English — it lets you focus on the logic before the syntax. This sprint you will practise this deliberately, and then reflect on your problem-solving process in your technical blog.

Your Roadmap

Problem-solving techniques

You already know some techniques from Sprint 1:

• Reading error messages
• Checking the foundations-help-desk Discord channel
• Searching with Google or another search engine
• Asking peers
• Asking coaches

Now that you know some JavaScript, here are more tools to add:

• Pseudocode — plan your logic in plain English before writing code
• The rubber ducky method — explain the problem out loud to an inanimate object; the act of explaining often reveals the solution
• console.log() — print values at key points to see what your code is actually doing
• Trying something — make a small change, run the code, see what happens
• Reflection — after solving a problem, write down what worked so you can use it next time

Pseudocode

Pseudocode is not real code — it is plain English comments that describe the steps your code will take.

Writing pseudocode first means you can focus on the logic without worrying about syntax. It is also useful for explaining your thinking to someone else.

Example — making brownies:

// put butter, sugar, and cocoa in a bowl and then microwave
// add eggs and vanilla and mix through
// add flour and mix until thick
// bake!

No fine detail — just the steps in order.

Your pseudocode will change as you write the real code. That is expected. The point is to have a first draft of your thinking before you start.

Apply this in every kata challenge this sprint. Write your pseudocode as comments before you write the code. This helps you think, and it helps us see your reasoning when we review your work.

Research

Look up any techniques from the list above that you have not used before. Spend 30 minutes exploring them.

Keep notes as you go — you will use these when you write your technical blog post this sprint.

Check your understanding with a chatbot

Open your chatbot and work through these steps in order:

Step 1 — Tell it where you are:

"I've just read about problem-solving techniques for JavaScript developers — pseudocode, rubber duck debugging, console.log, and others. I haven't done the kata challenges yet. Quiz me with 3 questions to check my understanding. Don't explain anything yet, just ask."

Step 2 — Answer its questions in your own words. Don't look anything up. Just answer from what you remember. It's fine to say "I'm not sure."

Step 3 — Ask it to fill the gaps:

"Based on my answers, what's the one thing I'm most unclear on? Explain just that one thing in plain language with an analogy."

Step 4 — Check your analogy:

"I think pseudocode is like [your analogy]. Is that accurate? What does my analogy miss?"

The Big Idea (revisited)

Before you write a single line of code, think through the problem. Pseudocode and the other techniques here are what separate developers who get stuck for hours from developers who get unstuck quickly.