• Equipment: Linux/Emacs/Chrome/GMail/Fluxbox/(whatever source control the project uses)
• Subject matter: Distributed systems, large scale computing, stream processing, middleware. I particularly like software that sits below / facilitates other developers.
• Approach: Pragmatism — simple, clear code; reuse; try to be succinct, but err on the side of clear intentions. I like bringing ideas from functional and logic programming to more traditional languages, but I also strive to code in a way that is idiomatic to the language I’m working in (within reason, as there are matters of taste). It’s like speaking a foreign language: a non-native speaker will sound quirky and stilted unless they make an effort. For example, we used to use Scheme in our intro to CS class, and students with prior experience (usually C / C++ / Java at the time) often end up writing Scheme code in a very odd, imperative way.

Don’t have any notable examples since I’ve mostly been writing proprietary code (products or internal infrastructure software).

It might be helpful if we did not give the students the automated scripts and forced them to write their own test cases. On the other hand, given how time consuming the course is as it stands, this might be asking too much.

@Jessica: Classes that Profs. Kaashoek, Morris and Madden are definitely an improvement, but I taught and TA’d some of those classes and it is really hard to get students thinking about options and alternatives. As you say, with such time pressure, you really just want to get things done. I also participated in last year’s Performance Engineering of Software Systems as an industry code reviewer. This was a great idea but there weren’t enough round-trips to really make it effective. I think the students liked it though.

@David: It may indeed be that most programmers aren’t interested. But for those of us who are, it can be frustrating to work with those programmers… Miguel de Icaza came to my mind as a contemporary of mine who demonstrates this kind of mastery: besides having produced a wide range of things that people really use (say, Gnome and Mono, or UI to compilers), at the Boston StackOverflow DevDays last year, he gave live un-canned demos of MonoTouch, where he live developed/debugged a program, and joked about it the whole time. He was just completely comfortable doing that in front of 200 people, despite many little things that were broken and needed fixing along the way. And, as far as idiosyncrasies, he seems to have a fascination with LOLcats…

“Real musicianship is the result of studying and applying the theory, history, and performance of music.”

He suggests that programmers practice their craft not just by coding, but also by learning historical context, reading code, etc. I’ve seen a lot of articles from bloggers like Joel Spolsky or Jeff Atwood suggesting that programmers read other code more, and comparing writing code to writing literature — great writers like Nabokov were also voracious readers. They also talk a lot about the practical issues of programming: source control, testing, code-review, refactoring, etc.

But I haven’t seen as much advocacy of learning history and the greater context of technical work within the field. I happen to love to learn about such things, so I just read historical papers and stuff like the IEEE Annals of the History of Computing for personal edification. I also like to know about older ideas that have fallen out-of-fashion and oddball hardware or software, because core ideas often come back in newer forms, often without knowledge of the older work. I also find the social context fascinating as well — how pure technical merit of ideas in the research community is sometimes less important than what is fashionable to work on at the time or the prevailing “hot” approaches.

I’m not sure how you integrate this sort of stuff into a curriculum, though. In my experience, my favorite classes were ones where the instructors were themselves passionate about history and context and wove it into classes. For example, one instructor for our undergraduate introductory OS/architecture class had worked in industry for many years writing FORTRAN on DEC minicomputers, and he could augment the material with colorful and relevant anecdotes about how we got to the current state of things from the way they were then. While graduate classes often include more context (frequently covering “classic” work and such), the only undergraduate classes I can recall that explicitly included historical information as part of the curriculum (and not just value-added instructor stories) are an introductory HCI class and a programming languages class.

Maybe, in the end, the problem is that a lot of programmers just aren’t that interested. I mean, I could be off the mark, but I believe it’s a lot more difficult to make a career as a musician, so people going to music school are probably more self-selecting (passion-wise) than aspiring programmers. You can not love accounting or engineering or law or programming and still make a decent living that way. In that case, they probably don’t aspire to become the “Glenn Gould of accounting” or whatever.

BTW, when you mentioned Glenn Gould’s “incredible mastery of the subject matter,” someone who came to mind as a parallel in the programming world is Guy Steele Jr. There’s a lot of fitting candidates who have made both scholarly and practical contributions (obviously people like Don Knuth, Bill Joy, Butler Lampson and many others come to mind), but it’s impressive the way Guy Steele has stayed firmly rooted in the pragmatics of programming all the way from history and PLC theory to esoteric HAKMEM-style bit-twiddling tricks (he apparently went above-and-beyond in commenting on and contributing to Hacker’s Delight). Norman mentioned Richard P. Gabriel, and the “50 in 50″ talk he did with Guy Steel is awesome to watch.

Now I wonder what’s the coding equivalent of Gould’s idiosyncratic singing…

What suffers the most in these classes is definitely the “craft of programming” – banging out Paxos before the deadline for Distributed Systems produced what is possibly the ugliest code I’ve ever written, and there’s absolutely no attention to good software engineer principles or any kind of code review as part of a grade. In fact, these classes almost always just have an automated series of tests you pass to get full credit, so the course staff aren’t looking at your code at all.

I think an open source involvement capstone, if done with an open source project that has strong test-driven development and code review policies (Twisted is a good example), could be a great experience. Working with Twisted is how I learned to write good unit tests, be a good reviewer, and be good about receiving review feedback – not with MIT’s required software engineering class.

Speaking of code review, I wish more companies required code review with their internships. It’s so good for you, and you just don’t get enough of it in school.

I think you would enjoy reading this article :

http://www.dreamsongs.com/MFASoftware.html

The author (Richard P. Gabriel aka rpg) is a programmer who enrolled in Warren Wilson’s “Master of Fine Arts program in creative writing” (poetry). In this article he discusses the differences between the two methods of teaching, and proposes a “Master of Fine Arts in Software program”

If someone says ‘good presentation skills’ then I expect them to be a little more senior, and I’d expect them to be able to live up to that statement by delivering a ‘blitz-talk’, 5 minutes with a dozen slides (or so – the exact format isn’t too important, just keep it short) on a topic chosen by the candidate.

In fact both of these things – and the others you mention are a good way to fill some of the void that can occur between an initial telephone call with the candidate and the time when they come in for an in-person interview. These are things the candidate can prepare for etc.

I’m not a huge fan of writing significant code on the fly. Though, I did like Google’s overall approach of working from high-level solution to concrete implementation. Looking back, I’m impressed at how smoothly the interviewers ran those questions. But yes, writing code under such circumstances is stressful and not necessarily indicative.

Some groups at VMware do ask candidates to do code reviews during interviews. We haven’t done that in our group yet.