Meetings Schmeetings

I hate meetings. I gather that this opinion amongst academics isn't exactly unique. However, at least my expectations for all meetings are at rock bottom so I can only be pleasantly surprised if a meeting actually exceeds expectations.

Yesterday's meeting had its plus and minus points. One minus point was that one of the topics of conversation was completely unintelligible to me. They were speaking English alright, and they weren't using any big words or technobabble or jargon or multiple acronyms that would have obfuscated the conversation. No, the problem was that I mentally failed to register the first sentence of this conversation, which was unfortunately the sole provider of clues as to the topic of conversation. I sat and listened, and could not make head or tail of what they were talking about. They were talking entirely in generalities, and it was very irritating! (We computing types don't like vagueness.)

It got so surreal, they managed to carry this vague conversation on for so long, I started recording some of the actual phrases used:

"taking that message and trying to do something with it"
"make sure that we meet their requirements"
"alert to it all and aware of its importance"

It carried on for so long that I got nervous, in case the chap who started the conversation was going to ask "So what do you think on this issue, Lossy?". Fortunately he didn't and my ignorance was preserved.

One of the plus points of the meeting was that I didn't leave the meeting with too many issues I had to take action on, only a couple of emails to send. In conversation with a friend who works in industry, I was astonished to learn that in the modern programming industry, meetings are not for acquiring greater workloads. Meetings in industry are for turning up to, and assigning work to be done to people who aren't there.

What a splendid idea! At academic meetings, there are often people absent (with the infinitely re-usable excuse "I've got teaching then"), and people only really attend them out of a sense of duty (because otherwise nothing would get agreed upon) or because they've got some issue they want to push. You can't assign much in the way of work to people not at the meeting because you generally don't know what they've got in the way of workload committments, and so you can only really assign things in absentia if you know full well that specific task is the job of the absent person and no other. Thus it is the people who selflessly attend the meetings who come away with various tasks to do.

It's a wonder we have so many meetings...

Blood Pressure Rising

Edited extract from an email sent to one of my students:

"If you've misplaced your copy of the handbook for students then I suggest that you look at the following web page
http://compdept.uni.uk/handbook.htm
(username: astudent password: pass123 )"

I included the password for the web page, because even though all students have been emailed the password already, that email was rather a while ago. Students are apt to forget that they've been sent a password, or they haven't yet developed the ability to save old emails and search them. What did I get back in response from the student? The following:

"...i tried to use the link you supplied but i cannot access this without a password"

*(&@$%£"!!!!

Resit Results

Resit exams were pretty dire this year.

One student thought that a "if" statement was an example of a static data structure. This is like someone thinking that making a decision is an example of a storage space (say, a bookshelf).

The same student also thought that a "while" statement was an example of a dynamic data structure. This is like thinking doing something repeatedly is an example of an flexible storage space (like an extendible bookcase).

Another student, when asked to "draw a graph" of some adjacency lists, instead wrote out an adjacency matrix. Yes, "draw" did indeed instruct the student to draw a picture. What did I get? I got a table of zeroes and ones (which is what an adjacency matrix looks like).

These are very basic concepts that they got wrong. It is not surprising that nobody passed the resit exams. In other words, we got it right the first time.

Systems Programmers

Let's have a change from ranting about problem students and instead rant about people who program the central university computer systems. Every university has such programmers: they do a very vital job maintaining various computer systems that allow students and staff to access university information, like timetables, course information, exam results, that sort of thing. The computer systems typically allow access via web pages, or from using software that everyone has access to.

I'm sure there are a lot of people who program these systems who do a very good job, and most of the work they do is unsung, because the rest of us in the university only notice when the systems go wrong. But sometimes, it can be very frustrating trying to communicate with some of the systems programmers and you feel like you are banging your head against a brick wall, because they just fob you off with excuses or give nonsensical replies to your queries and suggestions.

This is particularly frustrating on the occasions when you, as a computing lecturer, do know what you are talking about: often you are treated as if you are not a computer specialist and know no more than the average office worker. Don't get me wrong - I realise that they know about the internal workings of their systems and I don't, and in some areas of computing they probably do have a lot more practical knowledge than I do. I don't have this lofty ivory tower opinion of "I'm right and they are wrong", but I do get frustrated when their responses are unreasonable.

One sort of unreasonability I find is a view that is too programmer-centric and not enough user-centred. Time and time I see this in my students, too. When practising their programming skills they are much more concerned as programmers with what's easy to program, and when producing some software, they will value the easy-to-program route over the better-for-the-user route, even when a primary focus of the software is supposed to be that it's easy to use.

Yesterday I indulged in a mutual rant with a colleague about how unreasonable some of the systems programmers at our university can be. My current biggest pet hate is about how they structure the information in such a way that it takes much longer to get to it than it should. They have put all the information that I don't want to get to in an fast-to-access place, and all the information that I use 80% of time in a slow-to-access place. With all the accesses I make, this soon adds up.

I'm sure I'm not the only one, I found out my colleague yesterday thinks exactly the same thing, and I'll bet most of my colleagues find the same thing. Not only that, it's very easy to program a solution. You'd think it would be a clear-cut case, because the solution is easy to implement, quick to implement, and fixing this can improve access times without disadvantaging anything else. But have they done it since I asked them about it a year ago? Have they cocoa.

See, they have let-outs. The university computer system programmer's standard excuses:

• "That's just your opinion."
  No matter how much objectivity and fact there might be in my comment/request, they try and paint it as my subjective opinion. They try to imply that just because it might make my life easier it wouldn't necessarily make it any easier for anyone else in the university. Thus they dodge the issue, because I'm only one person pointing out the problem, rather than coming to them with a lengthy petition signed in blood by all the lecturers I can find.
• "It's too difficult/time-consuming to implement"
  Another standard let-out is that it's too difficult to implement, with the implication being because I don't understand their programs, then I don't know how difficult it is to implement, so therefore I'm in no position to say otherwise. It is true that I don't know the inner workings of their programming, but it's still irritating, particularly when I give them a concrete suggestion of an easy way to implement it, and they don't address my suggestion, either by saying why that's not possible or by explaining why it's more difficult than it sounds.
• "It's not possible because of ..."
  Standard fatuous reason, usually bringing in some other factor, some reason which you can't prove false. Typically with a reason like this you later discover that their reason can't possibly be right because they did something later on which contradicted it.
• "We have too much else to do."
  Again, I'm in no position to know whether this is true or not. However I believe them. They probably do have a lot to do on their plate. Which is why I try and provide constructive helpful suggestions which could help speed things up.
• "We'll put it on the list of things to do."
  The ultimate condemnation. That's like the in-tray which doubles as a rubbish bin, yes? When a year has gone by and still nothing's been done, somehow I don't believe you put it on a list of things to alter like you said you'd do.

Why do I somehow believe that they just think I'm a troublesome ignorant user who would just make their life easier if I never made suggestions to them? (And no, I do not bombard them with suggestions, we are talking about maybe two issues per year here.) Why can't there be a culture of welcoming constructive polite suggestions as ways to improve even better their systems?

Wish me luck when I try again to see whether they will do something about this issue of access speed...