There are things we do in school and there are things we do in industry and they're not always the same. In school we might use a learning language or an IDE which gives additional support and at times even take away language features while at work you might you might make heavy use of continuous integration tools. On the other hand, sometimes we use the same things. Java is used in schools and in industry, StackOverflow consulted in both and many schools use professional IDEs like Eclipse.

A couple of weeks ago there were some discussions about students working on and in larger projects. Most CS educators think it's a good idea to expose students to large projects even if we don't all agree as to what the best time is. Regardless of when, figuring out a large project can be a bear and that's not just true for students. I saw this on my Tweetstream about onboarding software engineers:

I'm enjoying reading about Ria Galanos' new chapter on her blog. In her most recent post Ria briefly talks about the fact that very few professional developers start from scratch and most work in existing large code bases. She wonders why the College Board got rid of the APCS-A case study and talked about how it gave students an opportunity to work on a multi-file complex system. Over the past few years others have wondered if the College Board should bring it back.

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.

Last semester I wrote about how I was introducing my students to code review. I thought it worked pretty well and was anxious to try it again. Well, I did the lesson(s) again this past week and it looks like it's a keeper. The setup was pretty much the same with some hiccups due to using a new platform. Last semester I used plain GitHub public repos. This time, I've been using GitHub classroom which I like very much but I forgot that I made this assignment use private repos which turned out to be a hassle.

Sometimes professional practices don't work well in the classroom and sometimes they do. One professional practice that does work well is code review - reading and reflecting on other peoples code. I've had my students do code reviews in the past but this time I did things differently. Here's what I did and here's how it went Two weeks ago my students completed a lab. The lab involved reading in a poorly indented C++ program and spit out a properly indented one.

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.

One of the things I've heard for years from former students - both those looking for jobs and those looking to hire is that colleges don't really do a good job preparing students for careers in tech. Sure they teach the algorithms and the theory but ther are a lot of missing pieces, particularly on the practical end. I'm certainly not advocating turning CS programs into coding schools but there are many low cost opportunities to bring practical real world best practices in to the CS classroom.

There's so much to like in the shape drawing lessons I talked about in my refactoring post that I thought I'd share a little more here. It can be argued that the most important things for a program to do is work. The most clever, elegant, creative program is worthless if it doesn't produce the desired result. All too often, beginners and hot shot beginners in particular try to be too clever too early and get themselves into trouble.

A few weeks ago I wrote about introducing testing in CS classes, specifically using a testing framework. In that post I talked about the plan but now I can talk about the results. My class interleaves with Hunter's CSCI 13500 - Software Analysis and Design I class. One day each week, my students have complete a hands on lab focusing on whatever is being covered in the 13500 class. I decided to use one of those labs as a first foray into testing.