Reading Garth Flint's end of year post and Alfred Thompson's follow up had me thinking about a couple of things.

One was spurred when Garth wrote "They also have to figure out the math before they code." This made me think about all the details we sometimes take for for granted. Things that are hard for our students that we just know. It's frequently math that we might find trivial but it could also be much simpler things.

When I write Java code I have a snippet that provides most of my main boilerplate. For a beginner, just typing in all the details and getting them right might be a chore. Heck, even typing is something we take for granted. Beginners who can type have a distinct advantage. They can focus on the code rather than on the keys. That boilerplate code might take ten minutes of typing alone and that's not adding in any typos or understanding errors.

I don't have anything to add here that I didn't address in earlier posts and Garth's post has some great points so if you haven't read it yet, I recommend you take the few minutes to do so.

The other thoughts were spurred from this part of Garth's post:

did only two of the six assignments myself. With the others I saw the solution so did not code them up. I should have coded them up just so I could answer questions better for the students.

Alfred expounded on this in his post and there was a good twitter conversation around it as well.

As a general rule as teachers we should have solved the problems before we assign them and not just theoretically be able to solve them. Actually writing up the solutions can also clue us in on some of the difficulties that our students might face. Particularly if we really try to look at the assignment using our student's eyes.

Neal Plotnick tweeted:

The lack of experience with coding for Ts combined with canned, cloud based curricula has allowed classrooms to be created with Ts pushing assignments out and relying on automated grades. I don’t have a CS degree but I made sure to code my python assignments first.

— neil plotnick (@NeilPlotnick) June 8, 2019

And this is a real concern for me. I get it - we're building a plane while flying it and that places teachers in situations where they have to learn on the fly and at times they'll have to assign problems before they have solutions. Long term, however, this is a big problem and I suspect it's not going to go away.

On the other side of the coin though are times when it's best not to have a solution before the class. Sure, if you're teaching a merge sort or doing a unit on inheritance you probably should have your ownb written solutions but there are a whole bunch of topics which lend themselves to doing things on the fly:

• debugging
• software engineering practices
• how to approach "random" problems
• practical "programming" techniques

can all benefit from an on the fly lesson.

Coding or teaching on the fly, when used appropriately allows the teacher to model best practices in real situations. Of course this is difficult to truly replicate if you teach the same class again later in the day or if you revisit the class next year but it can be a valuable tool. When you get a bug - a real bug not a planted one in your code, you can really model techniques to solve the problem and you can involve the class in finding that solution.

This can all be pretty scary. You can end up going down the wrong path and never finish building whatever you're building but overall it can be a very valuable experience for the students.

The other consideration is that you can teach a great lesson this way but it would probably get a low rating on Danielson or whateve nonsense rubric your district uses for teacher evaluation.

None of this is to say that you don't want to prepare. Most of the time I'll have solutions worked out or if not, I'll have written similar solutions countless times before but that said, there's sometimes value in exploring in the wild or as one of my early supervisors put it "calling an audible."