Update: Fixed the etherboot wiki link.

I attended the Google Summer of Code Mentor Summit this past weekend on behalf of PostgreSQL. We met at the Google campus in Mountain View.

This event was an unconference and so, none of the sessions were determined in advance.

Some of the highlights were:

• Leslie Hawthorn and Chris DiBona went into some detail with the whole group about the selection process for GSOC. This session made me feel as though PostgreSQL had relatively good chances for being accepted again next year. Google, however, does not pre-announce projects/products, so there is no sure thing about our (or any other project’s) involvement.
• I met MusicBrainz guys and was pleased to receive many bars of chocolate they requested to be distributed to SFPUG and PDXPUG members as thanks for making an great database.
• Attended three sessions concerning recruitment and retention of students. This is a topic that many people were interested in, but that few people feel they have a proper strategy for.

I also led a session on recruitment and retention of students to open source projects. Some of the ideas that came out of that and the related sessions were:

• Determine what makes you personally need to be part of Postgres (joy of learning, scratching a technical itch, making a tool for your job, fame). Find out which of those things your student also needs or wants and try to give that or help your student achieve that thing.
• Have a clearly defined method for students to keep journals. Several projects simply used MediaWiki and templates.
• Use git (or other distributed revision control), and have students commit early and often to a branch that mentors have access to.
• The Etherboot project has a great system: http://etherboot.org/wiki/soc/2008/start
• Hold weekly meetings over IRC. These can be brief, but help get students accustomed to your project’s culture and way of doing things.
• Ask the student: “are you on track?”, ask the mentor: “do you think the student is on track?” on a weekly basis
• If you want students to stick around, find incremental responsibilities to assign that are driven by their enthusiasm.
• Interview on the phone all your students ahead of time, not just the ones you think might be a problem.
• Require a phone number on the application for the student.
• Require a secondary contact so that if the student “disappears” there’s a backup person to contact. (and contact that person BEFORE SoC starts)

I made good connections with members of Git, Parrot, WorldForge, Ruby and many other community leaders. I was particularly impressed by the ideas and stories from the current Debian project leader, Steve McIntyre and Gentoo council member Donnie Berkholz. Donnie recommended some books about recruitment that I plan to read and review in the next few weeks.

The issue of mailing list moderation and the number of people required to keep mailing lists functioning properly came up frequently. If you know a moderator for a Postgres mailing list, please consider thanking them for doing a very tedious, extremely important and often thankless job.

I also spent some time discussing with Leslie Hawthorn and Cat Allman how to increase the total number of women mentors and students next year. Leslie and I shared some ideas and I offered to help implement them next year. One thing the crowd asked for was explicit training on how to recruit and manage female students. Realistically, this information will apply to all students, and I hope this training helps us recruit more students overall.

I thought the conference went quite well. I hope PostgreSQL is accepted next year, and that one of our mentors is able to attend this conference. And, if you go, be sure to register for the hotel early, and stay at the Wild Palms.

Related posts:

1. GSoC Mentor Summit and the new mentor’s manual
2. October is a month of many conferences
3. Report from SCaLE 7x

Software Engineering and the Cause of the CS Enrollment Crisis

I propose that our current undergraduate computer science programs are designed to produce coders for software engineers.

Yeah. This is so true! I immediately thought of Shelley Powers’ comments about what we should do with computer science curriculum:

Break up the computer science programs, split the participants into specialized fields within other disciplines, and stop spending all our time on talking about Ruby and how cool it is.

(btw, I don’t mind talking about how cool Ruby is.)

So much of programming for a business is finding solutions for real-world problems. And you need to do that cost effectively. There’s a lot of “value engineering” in there, rather than perfection. And for me, I think there’s often way too much emphasis on correctness for correctness sake, in education and in the user group circles.

Here’s another choice quote:

It seems to me that the cause of the student’s disdain for “programming” and for the decline in CS enrollment lies there. As civil engineers need armies of construction workers to build their designs, and as mechanical engineers use armies of factory workers to produce their designs, so do software engineers use armies of programmers or coders, people who are explicitly not software engineers, to produce their designs. Few students go to college to become construction or factory workers. Why should it be surprising, then, that few Western students want to go to college to be the Information Age equivalent workers?

and a final point about creativity:

Computer scientists do not need to write good, clean code. Science is about critical and creative thinking. Have you ever read the actual source code for great programs like Sketchpad, or Eliza, or Smalltalk, or APL 360? The code that I have seen produced by computational scientists and engineers tends to be short, without comments, and is hard to read. In general, code that is about great ideas is not typically neat and clean. Instead, the code for the great programs and for solving scientific problems is brilliant. Coders for software engineers need to write factory-quality software. Brilliant code can be factory-quality. It does not have to be though. Those are independent factors.

Hell yes! I feel like so much of my computer science classes sucked the fun out of computers. The most fun I ever had in class was showing people how to use makefiles in the lab. By which I mean, not fun.

Fun was tracking down the exploits and then the crackers who broke into our servers, getting all the evidence together and talking to the FBI. And after that, learning about ways to monitor the system that wouldn’t be detected by intruders, but would immediately tell us someone just managed to get elevated system privs. That was engaging. I did that work as a junior in college, but a first year CS student. And I learned something I’ll never forget about operating system privileges and system administration (thanks, Steve).

What about the third term of my Intro to CS class? Or my software development class? I was bored. I did the homework as fast as I could to get back to my real job.

Related posts:

1. Women in Open Source: a focus group in March
2. Comments on “So What?”
3. moving on from experiencing to changing the structure