Monday, October 29, 2012

Why teach?

After some years when I was not doing so much teaching - I was on research leave and before that head of school - I'm back in the thick of it, and really enjoying it. Why is that? The main reason is that it's great to see people learning new things, particularly when it's stuff that's unfamiliar … logic at master's level, or the "professional context" for first years.

Unlike the old joke about the lecture being the mechanism for getting the notes from the lecturer's note pad to the student's without passing through either of their brains, I'm impressed at the interaction going on. Particularly in our new first year course we're trying to turn things into more of a conversation - either directly or using technology (google forms/spreadsheet) - and we're having some success. OK, not everyone is involved all the time, and there have been some tech hiccups, but we're getting there. 

Teaching can be a solitary activity, but often the best courses are ones where there's a team of teachers. The first year course is coming from a team of four: two at each campus, and the collaboration makes us more imaginative and daring than we would have been on our own.

I'm learning a lot, too, from students and colleagues. Now I know how to explain the constraints on the implication introduction rule: give a "proof" which breaks them, and so demonstrate precisely what the constraints embody, and why they are there. Thanks to a suggestion from one of our CO334 students, I also now know that using "data validation" in a google spreadsheet will give us much more useful data in interactive estimation exercises.

Teaching something new is the way to learn new things yourself, and to ask new questions: what are the relationships between contract law and software specification? why is resolution not complete? Both are things to find out more about. 

So, it's fun, and as it's the largest part of what the University of Kent is here for, that's a good thing for everyone!




Sunday, October 28, 2012

Lawyers and software engineers

I'm preparing a lecture about computing and the law, and using as a resource the encyclopaedic Computer Law (7th ed.), C. Reed (ed.) OUP, 2011. It's accessible and clear, even for a non-lawyer,  but this quote from one section on contracts (section 1.1.2.2) took me aback:
“Many IT projects fail precisely because the parties do not exercise sufficient
care to ensure that the supplier’s and the customer’s expectations match. Ensuring
that these do … is the key role of the legal adviser in the contract process.”
While I guess that is a key role for the legal adviser, I wonder how much she can manage to achieve this, in the absence of having strong technical skills. She can certainly ensure that the process is sound: terminology is agreed, all relevant points are discussed one by one, and so on, but when it comes to a discussion of technical issues like feasibility, efficiency, scalability etc. it's not clear that a legal adviser alone can deliver what's needed. Maybe I'm missing the point, but don't we need software engineers (or other technical experts) to be part of the conversation too?

Saturday, October 27, 2012

Links to make you think

In the first year course People and Computers I am tweeting (with hashtag #co334) one topic a day … usually a link to something else on the web.

In this course we're trying to give students studying computer science some context to what they're doing by looking at the history of computing, how we communicate ideas, how to estimate solutions to problems when the full data isn't there, as well as looking at more traditional LSEPIs such as computing and the law, intellectual property, privacy and so on.

Here are the tweets so far, in chronological order:

First week

Second week

Third week

Fourth week

Fifth week