Do any of you remember that scene from “Pretty Woman”, when Richard Gere’s character Edward asks his ex-girlfriend Susan if she had spent more time talking to his secretary than to him? Her reply was, simply, “she was one of my bridesmaids”. Any time in a relationship of any kind that you don’t meet the needs of the people in the relationship, it’s going to cause problems. (Not all problems have to end with you scaling a ladder to patch up your relationship with Julia Roberts but there will be problems.) Now, before anyone is wondering (or my friends are worried), my marriage is still great, I’m talking about my professional relationship with my students.
While I’ve been critical of myself and my teaching this semester, where I’ve done a good job but not necessarily excelled across the board, I haven’t identified one of the greatest problems that has crept in – no-one in their right mind should be emulating what I laughingly refer to as my work ethic, time commitment or current pursuit of success. Right now, I am not a good role model for students. While I am still ethical, professional, knowledgable and I’m apparently doing a good job, I cannot present myself as a role model to my students because I am losing the time that I need to seize new opportunities, and to allow for the unrushed catch-up time with other people that is vital to doing a job such as mine and doing it well. At the moment, any student who comes to see me does so knowing that I will have 15-30 minutes, tops, and that I will then have to rush off, elsewhere, to go and do something else. It doesn’t matter when they come to see me – if I’m in at 7:30am it’s because the day is starting at 8. If I’m still there at 7pm at night it’s because I have to be in order to meet requirements for that day or the next. Let me give you an example from my lectures.
My Student Experience of Learning and Teaching results have come in and there have been a lot of warm and rewarding comments from my students, among a pleasing overall rating. But one of my students hit the nail on the head. “[Nick] always seems to have a lot to say and constantly looks at his watch. (I assume that it’s to keep within time constraints) the problem is that he feels like he’s rushing.”
Ouch. That’s far too true and, while only one student noted it, you bet every other student was watching me use my watch to check my time progress through a busy, informative but ultimately time constrained lecture and at least some of them thought “Hmm, I have a question but I don’t want to bother him.”
It’s my job to be bothered! It’s my job to answer questions! Right now, it’s pretty obvious that students are getting the vibe that I’m a good lecturer, I care about them, I’m working well to give them the right knowledge and they love the course that I built… but… they don’t want to bother me because I’m too busy. Because I look too busy.
Every student who comes to see does so in the one of the windows that I have in my day, often between meetings, my meetings back up on each other with monotonous regularity and, looking at my calendar for last, week, the total amount of time that was uncommitted prior to the week starting was…
Including the fact that Tuesday started at 7:30am and went until 6:15pm.
Please believe me when I say that I’m not boasting – I’m not proud of this, I think it’s the sign of poor scheduling and workaholism. This should be read as what it is, a sign that I have let my responsibilities pile up in a way that means that I am running the risk of becoming a stereotypically “grumpy old Professor”, who is too busy to see students.
So when you read all of this stuff about Time Banking and think “Well, I guess I can see some of his point – for assignments…” I’m trying to work out how I can take the primary goal of time banking – to make people think about their time commitments in a way that allows them to approximate a manageable uniformity of effort across time to achieve good results – and to work out how I can think about my own time in the same way. How do I adjust my boundaries in time and renegotiate while providing my own oracle and incentives for change? If I can crack that, then solving the student problem should have been made much easier.
How do I become the kind of person that I would want my students to be? Right now, it requires me to think about my commitments and my time, to treat my time as a scarce and precious commodity, but in a way that allows me to do all of the things I need to do in my job and all of the things that I love to do in my job, yet still have the time to sit around, grab a slow coffee, make a lunch booking with someone with less than a month’s notice and to get my breathing room back.
I have one of the best jobs in the world but the way I’m doing it is probably unsustainable and it’s not really in the spirit of the job that I want to do. It’s more than just me, too. I need to be seen to be approachable and to do that I have to actually be approachable, which means finding a way that makes me worthy of being a good overall role model again.
My wife sent me a link to this image, created by Alex Koplin and David Meiklejohn.
The message is (naively) simple – if you don’t like where you are, change something. This, of course, assumes that you have the capacity for change and the freedom to change. There are lots of times where this isn’t true but, in academia, we often have far more resources to hand to help people if they assess where they are going and don’t like the direction.
I talk a lot about process awareness – making students of what they are doing to ensure that they can identify the steps that they take and the impact that those steps have. My first-years have their first process awareness assignment to complete next week where I want them to look at their coding history in terms of difficulty and timeliness. What did they do that had a big impact on their chances of success? Being honest with themselves, were they lucky to get the work in on time? What I really want my students to understand is that they have to know enough about themselves and their capabilities that their work processes are:
- Predictable: They can estimate the time required to complete a task and the obstacles that they will encounter, and be reasonably accurate.
- Reconfigurable: They can take apart their process to add new elements for new skills and re-use elements in new workflows.
- Well-defined and understood: Above all, they know what they are doing, why they are doing it and can explain it to other people.
Looking back at the diagram above, the most important step is change something if you don’t like where you are. By introducing early process awareness, before we ramp up programming difficulty and complexity, I’m trying to make my students understand the building blocks that they are using and, with this fundamental understanding, I hope that this helps them to be able to see what they could change, or even that change could be possible, if they need to try a different approach to achieve success.
Remember MIKE and SWEDE? Even a good student, who can usually pull off good work in a short time, may eventually be swamped by the scale of all the work that they have to do – without understanding which of their workflow components have to be altered, they’re guessing. Measurement of what works first requires understanding the individual elements. This are early days and I don’t expect anyone to be fully process aware yet, but I like the diagram, as it reminds me of why I’m teaching my students about all of this in the first place – to enable them to be active participants in the educational process and have the agency for change and the knowledge to change constructively and productively.
I just finished reading Katrina’s post on students who are scared to interrupt us because we look so busy and it made a lot of sense. It’s certainly something I’ve struggled with and anyone who has come into my office in the past few months has seen that I am really trying to give everyone as much time as possible – but I’m obviously balancing a lot of things.
I’ve been toying with some new models for setting up my time for the day and something I’m finding that works is 70/10/10/10 time. I can lose up to 70% of my day with pre-scheduled appointments, lectures, tutes, meetings and things like that, but the remaining 30% is broken down like this:
- 10% time reserved for the unforeseen – things like the opportunity to put a proposal in to attend an important meeting in California, that lobbed onto my desk yesterday and needed about 3 hours of work to get to fruition – completed by this Friday. I seem to get things like this every day!
- 10% time reserved for me to do things like go to the bathroom, eat lunch and enjoy a coffee. I need time to get from point A to point B – and sitting the whole day hungry, thirsty or … anything else will not produce my best work.
- 10% time, reserved in my head and on my calendar, for students who drop in to ask questions or who send me e-mail with questions (or post them on the forum). I should be making time. Yes, I have drop-in times normally but my students have a range of timetables and, after all, I am here to help. If I’m genuinely busy and out of time then I may have to use this time as well, but setting aside this time will help me to think about my students.
I look at the blog as an example. Every day, I put aside 20-30 minutes to write a post and, every day, I think of things that help me, or look for things to share, or go and do some research on CS Ed, or write up something interesting. (Some days I manage all of this!) Putting time aside for something gives you the mental ability to think “Yes, this is important and I should do this.”
In the Thursday keynote, Professor Brooks discussed a couple of project approaches that he thought were useful, based on his extensive experience. Once again, if you’re not in ICT, don’t switch off – I’m sure that there’s something that you can use if you want to put projects into your courses. Long-term group projects are very challenging and, while you find them everywhere, that’s no guarantee that they’re being managed properly. I’ll introduce Professor Brooks points and then finish with a brief discussion on the use of projects in the curriculum.
Firstly, Brooks described a course that you might find in a computer architecture course. The key aspect of this project is that modern computer architecture is very complex and, in many ways, fully realistic general purpose machines are well beyond the scope of time and ability that we have until very late undergraduate study. Brooks works with a special-purpose unit but this drives other requirements, as we’ll see. Fred’s guidelines for this kind of project are:
- Have milestones with early delivery.
Students must provide a detailed application description which is the most precise statement that the students can manage. A precise guess is considered better here than a vague fact, because the explicit assumption can be questioned and corrected, where handwaving may leave holes in the specification that will need to be fixed later. Students should be aware of how sensitive the application is to each assumption – this allows people to invest effort accordingly. The special-purpose nature of the architecture that they’re constructing means that the application description has to be very, very accurate or you risk building the wrong machine.
Programming Manual (End of the first month as a draft)
Another early deliverable is a programming manual – for a piece of software that hasn’t been written yet. Students are encouraged to put something specific down because, even if it’s wrong, it encourages thought and an early precision of thought.
- Then the manual is intensely critiqued – students get the chance to re-do it.
- The actual project is then handed in well before the final days of semester.
- Once again the complete project goes through a very intense critique.
- Students get the chance to incorporate the changes from the critique. Students will pay attention to the critique because it is criticism on a live document where they can act to improve their performance.
The next project described is a classic Software Engineering project – team-based software production using strong SE principles. This is a typical project found in CS at the University level but is time-intensive to manage and easy to get wrong. Fred shared his ideas on how it could be done well, based on running it over 22 years since 1966. Here are his thoughts:
- You should have real projects for real clients.
Advertise on the web for software that can be achieved by 3-5 people during a single semester, which would be useful BUT (and it’s an important BUT) you can live without. There must be the possibility that the students can fail, which means that clients have to be ready to get nothing, after having invested meeting time throughout the project.
- Teams should be 3-5, ideally 4.
With 3 people you tend to get two against one. With five, things can get too diffuse in terms of role allocation. Four is, according to Fred, just right.
- There should be lots of project choices, to allow teams choice and they can provide a selection of those that they want.
- Teams must be allowed to fail.
Not every team will fail, or needs to fail, but students need to know that it’s possible.
- Roles should be separated.
Get clear role separations and stick to them. One will look after the schedule, using the pitchfork of motivation, obtaining resources and handling management one level up. One will be chief designer of technical content. Other jobs will be split out but it should be considered a full-time job.
- Get the client requirements and get them right.
The client generally doesn’t really know what they want. You need to talk to them and refine their requirements over time. Build a prototype because it allows someone to say “That’s not what I want!” Invest time early to get these requirements right!
- Meet the teams weekly.
Weekly coaching is labour intensive and is mostly made up of listening, coaching and offering suggestions – but it takes time. Meeting each week makes something happen each week. When a student explains – they are going to have to think.
- Early deliverable to clients, with feedback.
Deadlines make things happen.
- Get something (anything) running early.
The joy of getting anything running is a spur to further success. It boosts morale and increases effort. Whatever you build can be simple but it should have built-in stubs or points where the extension to complexity can easily occur . You don’t want to have to completely reengineer at every iteration!
- Make the students present publicly.
Software Engineers have to be able to communicate what they are doing, what they have done and what they are planning to do – to their bosses, to their clients, to their staff. It’s a vital skill in the industry.
- Final grade is composed of a Team Grade (relatively easy to assess) AND an Individual Grade (harder)
Don’t multiple one by the other! If effort has been expended, some sort of mark should result. The Team Grade can come from the documentation, the presentation and an assessment of functionality – time consuming but relatively easy. The Individual Grade has to be fair to everyone and either you or the group may give a false indication of a person’s value. Have an idea of how you think everyone is going and then compare that to the group’s impression – they’ll often be the same. Fred suggested giving everyone 10 points that they allocated to everyone ELSE in the group. In his experience, these tallies usually agreed with his impression – except on the rare occasion when he had been fooled by a “mighty fast talker”
This is a pretty demanding list. How do you do tasks for people at the risk of wasting their time for six months? If failure is possible, then failure is inevitable at some stage and it’s always going to hurt to some extent. A project is going to be a deep drilling exercise and, by its nature, cannot be the only thing that students do because they’ll miss out on essential breadth. But the above suggestions will help to make sure that, when the students do go drilling, they have a reasonable chance of striking oil.