[Workshop] Problem Solving Workshop about syllabus HOT 5 OPEN

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

from syllabus.

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.

from syllabus.

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...

from syllabus.

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)

from syllabus.

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.

from syllabus.