In the real world you're usually not building your own projects from scratch. Much more frequently you're working on a team and you and other players come and go over time. This is in stark contrast to most CS educational experiences where students typically complete relatively small assignments from beginning to end. One of my biggest fears way back when as I was about to graduate college was when I woke up one night in a cold sweath "oh crap - in a couple of weeks I'm going to have to actually produce good code.

As I said in my last post, day 8 would be a nice project or lesson in an APCS-A or college CS1 class. Another nice problem would be to write a program to generate an image in the format required by the question. Alternatively, a teacher doing day 8 with their classes might want to generate a bunch of images for the students to test their decoders on. I thought I'd write one to see how appropriate it would be for the students.

I spent most of last week up in Albany working on the NY State K12 CS Standards so fell a bit behind. I had to go back to complete day 5 but still haven't finished day 7 which builds on day 5 which in turn builds on day 2. I might not get to finishing 7 for a while but it looks like a good chance to play with core.

Day 4. Most of the day was spent working on the NY State CS standards to I didn't figure to have much time to work on the problem. Fortunately, I was able to knock out part 1 before work started and part 2 was a quick adjustment when I got back to it at the start of lunch. Once again, it was a problem with a few interesting teacher side aspects.

Today's problem dealt with intersecting paths. You start with two inputs, figure out the paths they represent and where they intersect and then find the intersection that correctly answers the question. For part 1 you have to find the intersection closest to the origin. From a teacher's point of view, the interesting part here is data representation. This problem deals with a two dimensional grid on which the paths live.

Day 2 of Advent of Code 2019 was also pretty straightforward and once again I wrote my solution in Clojure but in order to talk about this from a teacher's point of view, we'll look at a Python solution. At its core, this is a simulation problem - read the data into an array or list and write a program to run through the steps. At first I was hoping that the solution would consume the data - that is, once you read past an instruction you don't go back to it.

Like most programming challenges, Advent of Code ramps out from easier, more accessible problems to harder, more complex ones. As such, a number of the early challenges are great problems for early CS students. I thought that while I watched my NY Giants play valiantly in their attempt to get a high draft pick I'd talk about today's challenge from a teacher's point of view. The summary of part one is that you have a list of inputs (masses of components) and for each one you have to perform a calculation (how much fuel is needed).

With summer right around the corner I'm hoping to spend at least a little time on some personal coding projects. There are a few work related tools I'd love to develop and just some random areas of CS I'd like to explore. If I finish them, the work projects will be web based. I was thinking about using this as an opportunity to do a deeper dive into Clojure having used it for some experiments and competitions like Advent of Code but at the end of the day I decided not to.

What can I do to discourage my students from using the "break" statement? That was more or less the gist of the comment and it elicited some good responses. This time the conversation was on Facebook but I've seen this one and participated in it many times before. I never liked the question when presented as a "how can I stop them" one. I equally dislike when the offered advice is basically "never use break no matter what" or something similar.

We've all been there: Student: Teacher, I need help Teacher (comes over) Student (shows screen listing three bazillion errors) The student has just written pages of code and finally decided to try to run it only to end up with pages of errors. Error messages can at times be hard to read for beginners but to see and truth be told, they frequently don't even read them but over the years I've developed a practice that I've found helpful as a software developer and if students adopt the same practice it can save them a lot of time and effort.