Symphonious

Some time ago, Jeff Atwood posed the question: How Should We Teach Computer Science? In the article, he laments the fact that formal education doesn't teach students about deployment issues or source control:

 And yet, as Greg notes, existing software engineering textbooks give this crucial topic only cursory treatment. Along the same lines, a few weeks ago, a younger coworker noted to me in passing that he never learned anything about source control in any of his computer science classes. How could that be? Source control is the very bedrock of software engineering.

While I agree that any good software engineer needs to know about source control and deployment, I think it's unreasonable to expect that formal education is going to teach students everything they need to know. What universities are good at or at least should be good at, is teaching people to learn. The actual content they learn isn't anywhere near as important as developing the skills to go out and learn things for yourself. There's simply no way that students can come out of university knowing everything they're ever going to need to know in their jobs, so they need to learn to learn. That's why Jeff's suggestion that computer science should be taught in conditions as close to reality as possible is the wrong way to look at it:

Today's computer science students should develop software under conditions as close as possible to the real world, or the best available approximation thereof. Every line of code should be written under source control at all times. This is not negotiable. When it's time to deploy the code, try deploying to a commercial shared web host, and discovering everything that entails. If it's an executable, create a standalone installer package that users have to download, install, and then have some mechanism to file bug reports when they inevitably can't get it to work. Students should personally follow up on each bug filed for the software they've written.

This kind of experience is a critical part of student's education, but it's not the only important part. Getting a solid grounding in all the abstract theory, the history of computers and a range of different types of programming languages - even if they're almost never used in the real world. If education is just trying to simulate the real world, we'd be better off just canceling all the CS courses and letting people learn on the job. What's missing in the IT industry is the understanding that providing education is a partnership between educational institutions and the industry. Neither can provide the education new software engineers need alone. That's why most software engineer jobs require or at least prefer a CS degree.

Universities should focus on providing the theoretical knowledge that underpins computer science and teaching students how to learn for themselves. Industry should provide internships and partner with universities to give students experience working in real teams on real projects. A simulated development environment will never be as successful as a real one and on the job training will never give students enough of the technical underpinnings to master their craft.

That's why Ephox got involved with Griffith Uni last year to bring in a team in their final year project where they developed real software for us in a real environment - complete with source control and deployment. That's why we prefer hiring people who are quick learners and passionate about technology even if they don't have all the knowledge or experience yet. That's why we go out to university events and make contact with universities (and schools) to help bring more of the real world into their education and to help make them the best possible software engineers.

Computer science education is a partnership - what have you done lately to hold up your part in that partnership?

Here's a tip for all those intrepid conference organizers - in certain situations when there really is no point in scheduling a session. To help identify these here are some key warning signs:

• The session is from 7am to 8am
  • Double points if breakfast is also 7am to 8am.
  • Triple points if the session is in a different hotel to breakfast.
• It's the last day of the conference
  • Double points if the conference party is the night before
• The session isn't listed in the handy access program guide
  • Triple points if it also isn't listed in the full program guide

If the session meets any of these warning signs you probably should just cancel it. If, as was the case with my BoF at Lotusphere, the session meets all the criteria the facilitator probably should just not bother turning up. Security was certainly surprised when I did.

Fortunately, a fellow Aussie from Dr. Notes, did turn up and we had a good chat before calling it quits early to get some extra packing time. If you happen to need training in Lotus software, give them a yell - I'd recommend them just on the fact that he was committed enough to turn up to such a poorly scheduled session.

My previous post, Atom is the New JCR, sparked some interesting conversations, firstly from Lars Trieloff via private e-mail (with a option of spilling over into a pub if we ever wind up in the same town…) and now from Dan Diephouse. Both Lars and Dan made a really good point - that JCR needs to find ways to work together well.

I completely agree that JCR isn’t very worthwhile as something that will break down content silos. It does have value as an API to work with data though. Atom is quite limited in the granularity it can work with data (which coincidentally is one of the reasons Web3S exists as well). And you still need to store your data somewhere.

This pretty much matches the distinction I see - Atom is great for providing an API to your content and letting anyone use it, JCR is great for having a standardized set of facilities for actually storing and manipulating the data. In other words, Atom is the API, JCR is the method of implementation.

I think the improvements need to be made in working out how Atom maps to JCR and making that easier and it sounds like work is already being done on that from Dan's generic JCR content store for Abdera to Lars' concept of Atom support in Sling.

It seems I'll be heading to Boston in June to speak at the Web Content 2008 conference. The full session details are available, but the brief version is that I'll be talking about making people important in web content management systems instead of just focussing on content and control. By letting the people who create content actually show through in the system and improve the personal connections, people work together a lot more and are more inclined to actually use the system.

It's certainly not a bad list of names to be among.

So if I build a social network on Ning I can add forums which are kind of cool except that noone actually knows that new stuff has been posted and don't bother checking back in. It doesn't seem to matter what options you provide - RSS feeds, offers to email notifications of new threads etc - people drift away from forums very quickly once their question has been answered. On the other hand, mailing lists tend to be harder to get people to use in the first place because you have to subscribe, but then they tend to stick around longer because they've already subscribed. If in that time you manage to teach them a few things they didn't know they needed to know they hang around permanently and the community grows.

Coming back to Ning, it has lots of cool features and user management etc etc etc, but it doesn't seem to have any kind of mailing list at all. Ideally I'd like the forums to also have a mailing list option but if not, is it possible to just have a mailing list so people can join a group and they're automatically added to the mailing list? I can even host the mailing list software myself but it would need to be kept in sync.

It goes without saying that whatever solution I come up with would be clearly labelled as subscribing to a mailing list etc etc etc - it's not an attempt to fool people into opting into e-mail. All done in good faith and with all the nasty little details to be thought out in full before implementation, but right now I'm brainstorming.