Mike Hewner's Homepage

This is a publication of the study I worked on when I was a visiting professor at the Indian Institute of Technology Bombay in the summer of 2014. I had a lot of fun and the opportunity to interview some super smart students who had chosen CS in a much different environment than I did. I think it’s fair to say that if I was born in India, I never would have been a CS major.

Much of the existing work on student experiences in the CS major focuses on CS in American and European contexts. This paper explores the experience of CS students who — due to India’s unusual educational system, joined CS with very little knowledge about CS outside of its reputation. The study was a grounded–theory based interview study based on 20 students at 2 tiers of schools in India. Results suggest that although students generally enjoyed the CS content of their courses, they had a great deal of concern about the lack of freedom in professional programming. This is surprising considering the highly positive view of CS jobs is what initially seems to attract students to the major. We contrast this with educational findings in other contexts and discuss the educational implications of the result.

You can get the full PDF here.

Special thanks to my co-author Shitanshu Mishra who is presenting this paper at ICER.

(Contains 1 attachments.)

I’m a big believer in practice when it comes to learning programming techniques. Although this seems obvious, it tends to go against the grain for most developer/teachers (like me) who love cool projects. What’s the best way to learn (say) scheduling? Write a scheduler! Our students did write a scheduler in OS, but they probably spend 90% of their time dealing with weird C mistakes and about 10% actually thinking about scheduling. More importantly, they only wrote 1 scheduling algorithm. If you really care, they have to write 10 scheduling algorithms. I didn’t care that much about them being able to code schedulers, but I did care about them being able to use semaphores. So I needed a bunch of tiny semaphore assignments. I’m sure I’m not the first teacher to do so, but I couldn’t find ones online when I looked.

So here’s a bunch of small problems that use semaphores. Some of these I used as 2 semaphore homework assignments, some of these I used as semaphore exam questions. If I were to try and arrange them easy-to-hard, it would be: threeAndTwo, abcd, hammerAndSaw, littleRedHen, balloon, printerQueue, producerConsumer, pair. Solutions are available too, if you email me.

Thanks to Ian Ludden who write littleRedHen and balloon for me. Also, a shout out to Allen B. Downey who’s awesome free book The Little Book of Semaphores is maybe the best treatment of the topic I’ve seen. I would love to go through that entire book in my class, but there’s not enough time in the current incarnation.

If you have any problems of your own, please send them my way! My students could use the practice!

(Contains 10 attachments.)

This spring I decided to try something I’ve been mulling over for a long time – a 1-credit course in GIT. 1-credit CSSE classes at Rose tend to be minor affairs…generally just for student fun and not affecting graduation. Of course, we already use git in many classes at Rose-Hulman, but you usually can’t cover anything in more detail than basic checking-in, checking-out, and conflict resolution.

10 classes was a bit on the longish side…I think you definitely could have done the topics in 7ish-classes if you wanted to compress, and the curriculum will always tighten with time. I do think that it’s wishful thinking to expect students to be good at git with just a lecture or two and some sort of highly structured tutorial.

The design of the course also was a challenge. Lecturing about command line tools is not usually effective – you have to use it to get good. I toyed with the idea of making a series of broken repo states that the students would have to fix/debug, but decided it would be too much work (if anybody would like to help me by make a library of 45 or so….feel free to get in contact with me, I still think that could be good). What I decided on was lectures, supplemented by a textbook (Git Pro), followed by weekly programming assignments were students had to write scripts that used git commands (and parsed the output). This was a course for moderately senior students who had used the basics of git and could pick up a new scripting language easily.

Git homework assignments:

• Plumbing 1 – grep for strings in particular trees (apparently git grep does this automatically but no matter)
• Plumbing 2 – make a commit history from a series of SHAs
• Reset and Stash – 3 little scripts involving the commands
• Merging – automatically merge two branches in a crude way
• Rebase – rebase but show what commits change shas
• History Rewriting – a simple interactive rebase and a use of filter branch
• Branches and Push/Pull – pull all local branches to a remote
• .gitconfig – write your own gitconfig

(solutions are available if you email me)

Overall, I thought it worked pretty well. I’d like to maybe refine a few of the assignments and maybe get some more in class activities. I’d even like to do an “exam” – probably not for student credit, but just so I can assess how well this is all working.

The students also generally seemed to enjoy the class (well, I had a few drop out because they didn’t want to do the homework, but that didn’t stress me out particularly much). I’ll know a little more when student evals come back in a few weeks.

My complete lecture notes are here, if you’d like to use them for something.

Anything I missed that you would cover in your 1-credit git class? Any great ideas for assignments (they should be easy to code, and exercise the commands under question well)? Comments welcome!

So this summer, I’m working on a interesting pilot project with the folks at Rose-Hulman Ventures (http://www.rhventures.org/). Basically, I’ll be acting as technical lead for a group of Rose-Hulman students working on programming contract work. So in the morning, I’ll be basically a professional programmer/mentor and in the afternoon I’ll be teaching a course for the students.

I just finished the first set of technical interviews for the students and we made offers this week. I’m actually really impressed with how the students did…I used a modified version of my old SDE interview script from my Amazon days and I was really impressed by how well the students did. Honestly, I’m not sure they’ll need all that much mentoring on my part to be productive.

Only downside: we’d ideally like at least one more contract-work software development project for the students to work on. You’d have to pay…but because of some grants we’ve got from Rose-Hulman the cost is very reasonable. Plus, you get the software and a chance to interact with some great students who presumably could be recruited for internships or full-time in future years. Plus, I’ll be on the programming team too, if that carries any weight.

If you’ve got any projects you think would be a good fit (or know someone who would) let me know! (all my contact info is here)

This summer I had a fun opportunity to program in a space I’ve never really explored before: medical data analysis. The company was Indigo Bioautomation. They build cloud-based software for analyzing mass spectrometer data. Here’s a pretty good introduction if you’re curious:

Despite medical tech’s reputation for somewhat old-school and slow software approaches, Indigo definitely feels like a startup. They are using new technology: TokoMX, a heavily modified ruby-on-rails stack, Backbone.js, etc. They also have an agile in-house process pretty similar to other places I’ve worked.

One thing that was different though: automated testing. The Indigo guys are totally on board and have tons of automated tests for everything. It’s a different mindset: I definitely had to be reminded to write more tests several times during my tenure. There’s a lot of good, but also some bad – in particular, long test runtimes (like 5+ minutes) are a huge problem there despite a lot of careful design work to optimize. And of course bugs still slip through in various places…though they definitely tended to be more obscure and less “this feature doesn’t even sort of work” like I’ve seen elsewhere. My views on automated testing have definitely become a lot more nuanced – and I’m constantly thinking of ways I want to revise what we talk about in the SE curriculum to reflect that.

Indigo really let me explore their system. I worked on a big command line tool, in their Java-based rules engine, writing MongoDB queries, front-end javascript, and lots of ruby coding both on webservers and services. The opportunity to get down-and-dirty with ruby was particularly fun: I really think I see now how it differs from python in actual practice.

Overall I learned plenty and I think Indigo is happy with what I produced for them. I’m missing my students and looking forward to being back at Rose in a few weeks though.

So CSSE375 is a Rose-Hulman course focused on refactoring (course notes here). As a result, I like to have the students make changes to existing open source projects. This gives them a little experience with codebases of a realistic size, and it makes the assignments feel a little more authentic.

I generally like Java projects that can be made to build automatically in Eclipse. Not by any means a deal breaker but Java is the language they know best so it lets me focus on the concepts easiest. Eclipse is not really a requirement but it has to build really easily because otherwise I end up debugging 45 different weirdo build problems.

Here’s a few that have worked for me:

• Argo UML – a really big project which is great (although it makes submissions a pain). A UML editor with some very weird use of objects in places. Here’s the assignment I used – and here’s the eclipse workspace source I used in case you don’t want to check it out yourself. The force based aspect of the assignment is maybe too fussy an algorithm…if I had to do it again I might do something a little simpler.
• Cleansheets – a great java spreadsheet that is quite reasonably designed. Builds very easily. The assignment I used was this one but I’ve since released the solution so I wouldn’t go reusing it on anything important. But I would use it again on another assignment.
• jFTP – this one’s codebase has a LOT of duplication in it…great if you want to pratice some refactoring techniques. Here’s the assignment I used and I modified the codebase slightly to make testing harder and make the project build easily in Eclipse.
• BORG – another large codebase, in this case a calendaring program. Unfortunately, annoying to build because students must install the lombok library. Here’s an assignment I did using it anyway.

If you’re looking for a more straightforward refactoring assignment, here’s what I started my students with – Calender Parse Part 1 & Part 2.

This winter I taught a course called Programming Language Paradigms. This is a language-oriented course where students learn several interesting programming languages and discuss the various features of these languages. The goal is to learn the various paradigms of programming through actually using the languages to solve the kinds of problems that they are well suited for (you can see the complete notes for the course, if you’re interested). One of the consequences of this was that I had to develop a lot of assignments in each of the languages. Of course, I didn’t develop them from scratch – I dug around and bummed what I could from courses I found online. But there’s not as many assignments out there as there used to be, partly because I think many college courses now use Moodle and so are automatically walled off. But I figured at the very least I could contribute a few.

Prolog Assignments

Prolog turned out to be a great language to start with – absolutely different than what they had seen before, and fun to solve the problems.

1. Maze Problem simple pathfinding, first assignment in prolog. Main thing is that it’s designed to force to you encounter infinite prolog loops earily.
2. Word Find a program that generates all possible “word finds” for a list of words. Main thing is that it forces you to carefully manage unbound variables.
3. Grade NLP final prolog project. In practice, it was a bit too open ended – lots of folks didn’t end up doing anything too cool. I think next time I’ll do a more traditional sentence structure NLP, plus more hints for how to structure the code. I think if I were to do it again I’d follow this assignment more closely.

Erlang Assignments

Erlang was maybe the least well-loved of the assignments, but I think that may be more due to the complexity of managing multithreaded programming.

1. List Problems first functional-ish language so needed to give them some practice with iterators.
2. Simple Communication in class activity where students practiced setting up multiple processes and communicating
3. Merge sort a multi-process merge sort. Students don’t actually have to implement merging or sorting, but the communication is tricky. This one has some basic unit tests.
4. Paxos final project, implementing the paxos algorithm in erlang. Includes some serious unit testing. But this assignment was probably too hard – I think I might do the raft algorithm next time which supposed to be simplier.

Elm Assignments

Elm was liked by folks who enjoyed making games, less liked by others.

1. Circle following mouse simple but gets the idea of signals across
2. Line drawing adds in the state signal
3. Spacewar more complex state, getting ready for the final project
4. Scrolling Video game the assignment itself seemed to work pretty well. Nobody asked to do something different than the scroller.

Other in-class activities

1. Lua/C integration activity
2. An in class thing about making monads I did with Haskell

I have solutions for many of these assignments as well (excluding the really open-ended ones) – as long as you’re a professor or something similar. Email me.

I’m in India, but there’s some downtime and I’ve been using it to play a with a toy project – a Settlers of Catan game built in the pure FRP web language Elm. Well, perhaps “game” is to strong of a word for what I’ve done thus far – lets say Settlers of Catan GUI.

I really liked using a boardgame to try out Elm. It’s a fun thing to try BUT the mechanics of the game itself force you to confront real problems. The examples on the very nice elm website are cool, but once I tried to actually engage with a data model more complex than just a few coordinates, things got pretty crazy.

One thing I can say is that the mechanics of FRP really encourage you to come up with a can GUI/model seperation. I eventually came up with this idea of hoverable stuff – which in theory the model can communicate to the GUI all the board objects that can be manipulated, then the GUI itself does the highlighting, then when the user clicks the selected object is communiated back to the model – which adjusts its internal state and then gets re-rendered. Not bad.

Some of the other stuff is not so fun. Some of is just book keeping – variables are not mutable, so when the state needs to be updated you can’t just update it. Instead you need to return a fully new model object, based on the old model object but with the variable changed. But when your model actually is complex, this is very annoying – the value you need to change is one variable in a record in a dictionary in the overall model. So you need a function that takes a record and returns a new record, a function that takes a dictionary and returns a new dictionary, and a function that takes a model and returns a new model. Also, if you have dictionaries of various keys and values, these functions are not easily reusable – although maybe you could do something with type parameterization somehow.

Other stuff is more than annoyance. Every function must be pure, so random numbers are hard. In elm, you need a random “signal”. But unfortunately, signals don’t have values at initialization time – they only exist when your program is actually “running” (i.e. a very funky pure functional transformation of input signals to GUI signals). So if your board arranged randomly – prepare for some serious sadness. I did figure out a way around it, but it was anything but pretty.

Anyways, I had some fun with elm. I’m not sure if I am actually going to complete the catan game – most of the rest of it seems unlikely to teach me new stuff and board games have a lot of complexity. But I did learn a lot, and I think I may ask students to build a (much smaller project) in elm as part of an upcoming programming language course I’ll be teaching in the winter.

(Contains 1 attachments.)

So the second main part of my dissertation research was accepted into ICER 2014! Here’s a pre-publication version if you’re interested.

Students in most CS curricula have to make a wide variety of educational decisions including what courses to take. Frequently, they must make these decisions based on a very limited knowledge of the content of the topics they are choosing between. In this paper, I describe a theory of CS undergraduate course choices, based on 37 qualitative interviews with students and student advisors, analyzed with grounded theory. Most students did not have specific educational goals in CS and, as long as their classes were enjoyable, tended to assume that any course required by the curriculum had useful content (even if they could not articulate way). Particularly enjoyable or frustrating courses caused them to make long term course/specialization decisions and use a more strategic goal–oriented approach.

After focusing on teaching and research for the last few years, I wanted to get back to the swing of things and write some real code. Lucky for me, my good friend Ben twisted a few arms and got me a summer job with his team at Groupon (lest you doubt Groupon’s hiring practices…yes there were some technical interviews in there too). I worked on the Breadcrumb Pro team. Our app looked like this:

It’s a restaurant point-of-sale application – the system restaurants use to enter in everybody’s orders, track employee hours, generate reports, etc. This is part of Groupon’s big plans to . From a technical side, we’re talking a 100% classic client server app – iOS on the frontend, python on the back.

I had a great time and was pretty productive. I was initially worried three months might not be enough ramp-up time for me to be of value to my team. Within a month I coding fast and signing up for high priority stories just like everybody. It actually sort of helped that I was not particularly familiar with either iOS or python…I took stories on both sides and that really help me understand the overall architecture. Especially on the fast development cycles we were on, there wasn’t a heck of a lot of spec design. So oftentimes a single story would require a change all the way from the DB to the frontend – just understanding every layer and changing it was way easier than attempting to coordinate a hand off.

I think I’ll definitely give my students even more practice with understanding big systems – maybe even toss in one or two multilingual codebases. At the very least I managed to get a few more war stories to tell them about. By then end of it, both me and Ben were wondering why summer internships at other companies wasn’t standard practice for professional software engineers.

Of course, even though I had a great time at Groupon, I’m still very much looking forward to teaching again in a few weeks.