Spring 2018

# March 26

## where we are

• You've all turned in your piglatin work, and I will have grades and comments on that soon. (I've spent too much of the break sick.)
• Please turn before Thursday a description of your exploration of an open project : what happened, what worked, what didn't.

## where we're going

... is what we'll discuss today.

### possibility 1 : tron

Battle it out with your own robots in a tourney ...

### possibility 3 : programming styles

object oriented, functional, paranoid, monolithic, code golf, and many others ...

## asides

• are well specified and known to be completable
• start from a blank slate
• produce relatively short programs
• once complete and accepted, will never be run or looked at again
• are required to work individually Whereas in a real software engineering department:
• goals will be to some extent vague and fluid, may be contradictory => requiring negotiation skills with PM, customers etc.
• you will nearly always be adding to an existing project => requiring ability to read code and perform archaeology
• programs end up huge => requiring schemes for better organisation, modularisation etc
• have a long life and a maintenance overhead => requires design for adaptability
• are required to collaborate => requiring use of a VCS, not having complete freedom to choose tools, techniques like CI and branching for managing incomplete vs complete work fragments. "
"It's a little trite but the best thing college taught me was how to read critically and
teach myself as needed. The second best thing was providing plentiful examples of good
pedagogy (I went to a teaching college, not a research U.) which turned into models for how I try to mentor.
[...]
It's funny how much I hated group projects as an undergrad, but how in some ways they
were the best preparation: How do you still get things done when everyone has different
ideas, varying levels of competency, available time, and motivation?
"

https://cs.marlboro.college /cours /spring2018 /workshop /notes /mar26