[Workshop] Problem Solving Workshop

[moneyinthesky]

Workshop Request

What is the title of your workshop

Problem Solving Workshop

What are the key topics that will be covered in the workshop?

• Clarify what we mean by "problem solving"
• Setting expectations that we all struggle with problem solving at first (coursework, CodeWars, Codility, etc.)
• How do we get better at problem solving
• Common problem solving techniques and how they apply to a real example

What knowledge does the trainee need before starting?

Due to the examples we might use in the workshop, some initial JavaScript knowledge would be beneficial. Specifically, I would suggest trainees are already familiar with the concepts covered in the JS1 module of the syllabus (variables, conditionals, loops, arrays).

What are the topics that will not be covered in the workshop?

The details of any specific coding constructs or coding environment should probably not be covered in the workshop. I would go as far as suggesting we don't use laptops in the workshop either. The idea is to focus on the problem solving aspects of software development, before writing any code in an IDE.

Any other notes?

More potential content (including a breakdown of some common problem solving techniques) in the attached slides: Problem Solving.pdf

First exercise used to introduce some common problem solving techniques to the group as a whole:

Write a function to return the longest word in a given array.

Second exercise, which can be done in smaller groups of trainees with whiteboards (or paper and pencil, if no whiteboards are available).

Imagine you are a teacher and your students have taken a test. The tests are marked with one of the following grades: A+, A, B, C, 
D, or F.
- You want to get the average score of the class as a number. For this, you can assume A+ is worth 100, A is 90, B is 80, C is 70, D is 60 and F is 50.
- Write a function which,
    - given an array of grades (which are either A+, A, B, C, D, or F)
    - returns the average score of the class as a numbe

Completion

When completed the lesson plan, slides and exercises should be added to the Workshop section of the Syllabus

[40thieves]

Capturing some notes from the discussion on Slack.

There was general agreement that problem-solving is a topic that we should include more of and that this was a useful starting point.

I managed to come along to the trial session that @moneyinthesky arranged for LDN10, and I thought it was great. I made some notes:

• Talking with the trainees, I tried to emphasise how problem solving is actually the “interesting bit” of development: we see so many trainees get caught up in syntax that they can’t move forward with a problem
• It’s not in the slides but @moneyinthesky pointed out that interviews are nearly all variations of this problem, so another area that I think we could emphasise
• I’d never really thought about it like this, but breaking down problems necessarily requires some knowledge of code, otherwise you wouldn’t know where to stop. One of the examples I discussed with trainees is getting the denominator for calculating the average: through knowledge of the code we could stop at .length. Not sure how useful an observation this is, but I found it interesting nonetheless

---

As I see it, there's a couple of things we need to decide to move it forward:

• Where could we fit this content into our existing modules structure?
  • Do we think it could fit into our plans for restructuring the JS modules?
• What format should it take? (I.e. re-write out of the dreaded slides 🙀)
• Who is interested in taking this on? (It seemed like @SallyMcGrath & @illicitonion were interested. I'd be interested in helping where I can)

[SallyMcGrath]

I think that I've figured out how to make sense of flipped classroom, movable workshops, and a more flexible syllabus structure. Will demo next Syllabus

[SallyMcGrath]

Secondly, "I’d never really thought about it like this, but breaking down problems necessarily requires some knowledge of code, otherwise you wouldn’t know where to stop. One of the examples I discussed with trainees is getting the denominator for calculating the average: through knowledge of the code we could stop at .length. Not sure how useful an observation this is, but I found it interesting nonetheless"

A very useful observation. I offer another one: it's not necessary to know the code, but to know there is something to know. When learning a new language, don't you endlessly google "loop over list in go" or "rust remainder how" ? Occasionally you discover there is no way to do that in the language, but mostly you do. The richer your programming knowledge is, the better those questions will get, but knowing to ask the question is the important step.

[illicitonion]

One skill I feel like we don't currently teach at all, which may be useful to factor in: Solving a sub-problem outside of our main problem, then applying the insights gained to the problem.

For instance, if I'm trying to work out how to align things in a certain way in CSS, I'll typically make an empty file, add just elements, and work out how to align just the two elements in isolation, and then once I've worked out how to express that, fold it into the actual project I'm working on. Or if I'm trying to work out how to perform some numerical transformation, or use a new library, I'll typically write a small standalone program or function to experiment with, and then once I've worked out the details, apply that to my actual project.

In contrast, something I see a lot in CYF trainees is that code only ever gets added, and so we end up with hundreds of CSS rules many of which are unused or only work when sequenced with other rules which aren't an essential part of the solution but happen to be relied on. And also, that the act of working out the correct solution may be obfuscated by some other bug or confounding code which means that even though the right solution was worked out, it didn't happen to work in a larger project.

I'm not sure how to demonstrate and get people to practice "separate out a sub-problem" as a strategy, but it feels like it falls under the problem solving / breaking down problems heading...

[40thieves]

I think that I've figured out how to make sense of flipped classroom, movable workshops, and a more flexible syllabus structure. Will demo next Syllabus

I look forward to this :)

It feels like we've noted some useful tactics on breaking down problems:

1. Break down problems until you know how to solve them already
2. Try to solve sub-problems in isolation

Are there any more? This does seem like an area we could focus our teaching on.