I stumbled upon an awesome new YouTube channel for programmers - Worst Practices. Specifically, Worst Practices in Software Development. The tagline is "we've all heard enough about everyone's best practices in software development, we're here to talk about … worst practices." I've written about "best practices" for teaching before - I don't believe in them - I believe in practices that are good under certain circumstances. Maybe in the majority of circumstances but there's no silver bullet.

So, last post I talked about the technical interview and unquestionably students at elite private schools have yet another leg up on the other folk. Today, let's look at the core subject of those interviews and what I think should be emphasized in class. I want to be clear - I'm only talking about in class here. There are many things that can be done at public institutions like Hunter to help better prepare students for tech careers.

It's been a while since I last wrote up a specific lesson idea so when my friend Garth asked about recursion ideas I thought I'd write this one up. This is a unit I used to teach in my intro class at Stuy using Racket (nee Scheme) but I coded up a quick and dirty Python version. Recursion is a polarizing topic. Some people love it, others hate it. I'm sure the usual suspects of intro recursion problems doesn't help.

Day 3 ended up being a quick one. That is, as long as your language supports set operations. You can do it without set operations but it's easier if you've got them. Part 1 Input is a file of text where each line is an input. You have to read each line, split it in half and then find the common letter between the left and right halves and then apply their scoring rules on that letter.

It's Advent of Code season again. Every day a new two part programming challenge and once again I'm taking part. At least until grading and other end of term obligations end up eating my lunch. I wasn't planning on writing anything up but the first two days looked like nice problems for CS1 or even CS0 students and since my friend Steve was writing up his take, I thought I'd at least comment on the first two.

Last time, I wrote about frustrations in trying to motivate myself to learn ocaml. I could see the strong points but given that I've been using Clojure now for a while, it didn't really hold any value added for me in my current situation. Next, I thought I'd explore Rust. On the non-functional style, my go to languages have always been Python for scripting and small things and C professionally.

The semesters back up in full swing again - teaching 2 undergrad classes in person - CS0 in Python and CS1 in C++ along with my teacher certification class - Ethics via Zoom. Grand total of about 125 students. An error came up in the CS0 class the other day that reminded me how tough it is not only to prepare students to deal with all the things that can go wrong when learning to program but even for a teacher to realize what's going on.

Like most CS educators I'm a regular reader of Alfred Thompson's blog. Alfred's latest post is spot on but there was a line in it and a particular Twitter response that reminded me that we so often forget a big reason why people learn to code. Alfred mentions, as did that Tweet about coding to solve problems. What problem are you trying to solve. This is the mainstream push - programming helps you solve problems.

Tomorrow, or more practically, tonight at Midnight, Eric Wastl will once again launch the Advent of Code. As I've written before, it's a month long event where each day a new programming problem is released. The problems range in difficulty and complexity. Some are very approachable to beginners and some are crazy challenging. I've written a bunch about AOC in past years: Solve A to Solve B Data structures and Hidden Complexity Tools can shape- how we think 2019 day 1 2019 day 2 2019 day 3 2019 day 4 2019 day 8 2019 day 8 addendum and a few more not listed.

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.