We have mapped a toy problem to every day that has a lecture. The toy problems are chosen to match the days content to make the lecture go smoother and clarify challenging topics and teach new code tools.

We used to give the students 15 minutes or so to work on the problem alone but we found for the students who are struggling it ended up being wasted time for them and caused frustration more than anything. For these students we recommend starting right at 9 and going through the problem solving steps with them to help them learn how to think through the problems. Make sure to read and get familiar with the problem solving/trouble shooting steps below.

With the students who don't struggle with the toy problems they can just work on their own and try out the challenge mode associated with each problem.

• Monday: none
• Tuesday: 45 Minute Fizz Buzz With '8 step Walk through'
• Wednesday: Broken - Swap Case
• Thursday: Broken - Array's and Reference(In prep for setState/immutability)
• Friday: None

• Monday: This and Context(In prep for props/binding(Teaching notes in file))
• Tuesday: Bob Ross Family Tree (in prep for axios)
• Wednesday: Array cardio
• Thursday: Skip Toy problem in favor of showing how to connect react and node.
• Friday: None

• Monday: None
• Tuesday: Cart - class setup/Remove From Cart
• Wednesday: Cart - Calculate Total
• Thursday: Broken - Vowel Counter
• Friday: None

• Monday: Object.Assign(In prep for Redux)
• Tuesday: Cart - Add to Cart/Update Quantity
• Wednesday: HTML Facebook Post
• Thursday: Broken - Largest Even
• Friday: None

• Monday: HTML Adobe(In prep for Media Queries)
• Tuesday: Letter Frequency
• Wednesday: Async Await
• Thursday: Wire frame project planning for all day review
• Friday: None

• Monday: Randomize Array
• Tuesday: Primes Summed
• Wednesday: Ransom Note
• Thursday: Lowest Common Denominator
• Friday: Competency day

• Monday: Fibonacci Recursion
• Tuesday: Does It Contain
• Wednesday: Interview Prep
• Thursday: Interview Prep
• Friday: Competency day

Below are steps that should be used for teaching how to solve toy problems. It is vitally important to use this on every toy problem you do from scratch. This teaches them how to break down a toy problem and identify its parts. This is also the exact same steps that should be followed when doing white board problems, Make sure the students know that! Help them to see the value in being clear with your communication and planning. Some steps seem to be not worth while but if a student is struggling with toy problems you should be able to help them see that their problem has to do with one of the steps.

// Step 1: Clarify - Understand the question

// Step 2: Create multiple sample data

// Step 3: Solve your Sample Data

// Step 4: Break down the problem into its smallest pieces and how you solve the mini the problems.

// Step 5: Pseudo Code

// Step 6: Code

Every one of these problems is "finished" but does not work. With each one you can solve it by only modifying existing lines (make sure to communicate this to the students), there is no need to write more lines of code. The purpose of this is to teach the students how to troubleshoot and develop debugging skills/mindset. A trouble shooting mindset is more like a way of life than just a coding idea. These troubleshooting steps are universal and apply to any subject.

Typically the process starts at the Observation step. You may observe, "my code does not work" and that is a viable and helpful observation. From there you need to ask questions. Questions like, what does this line really do? One of the hardest things to do is learning to question your own assumptions, and even harder is realizing you are making assumptions. The goal from here is to get confirmations of your assumptions but performing experiments that will give you hard evidence to either prove or disprove your theories.

If all you do for these problems is solve the problems you will finish in about 5 minutes. But that is not the point of the problem. It is to teach the students how to perform tests. You should make it clear to the students that you don't want fixes, you want theory's, and how to we can test those theories.

1. Observation

2. Question your assumptions

3. Form Hypothesis

4. Experiment

5. Analysis

6. Conclusion

The HTML has a few sites drawn with boxes around them progressing through how to build a layout and more importantly how to think in terms of boxes and sections. If you use this I would stress that they should really just use divs and not worry about the actual content but more the layout and how to position things.

The idea of this one was to try and spend multiple days spread over a few weeks where they built something that felt more real and usable. Also this would help for when students want to build a cart and now you could have them pull up their toy problems for a starting point.