I actually took a full week off from studying between Christmas and New Year’s (which worked out to exactly one calender week, this time). I recall that one year ago I used the entire Christmas break, all two weeks, for studying, but now in my still somewhat unstable condition I found I needed some time for recreation. Towards the end of the week however I began to feel uncomfortable with not doing anything study-related, so it was actually with some relief that two days ago I resumed exam preparation this week (the second of the break). Oddly, there will be a single week of lectures, next week, before the two-week exam period. It used to be two or three weeks. And even some time before Christmas most professors had already switched from actual lectures to exam preparation sessions or dropped the lecture entirely. Somehow every time the winter term is a lot more relaxed than the summer term.
And I myself also feel a lot more at ease than before the exams in the summer term. One course, business administration, is already done. As you may recall, there is an oral presentation in this course rather than a term-end examination, and we did ours as early as the third week. All that remained was getting the PVL in the practicum, and there our group passed with flying colors a week before Christmas. We are just waiting for the grades now, but reportedly the lecturer is a generous grader.
I feel confident about software engineering as well. The contents of the lecture were easily comprehensible and, compared to many other courses, rather limited. A good part of the lecture time was taken up by practical exercises anyway. Already a couple of weeks before Christmas I was through with writing and memorizing my flashcards. Right now it’s all about repetition and about structuring the material in a useful way. It’s going to be an oral exam of roughly 30 minutes, and we are expected to begin with a 5-minute presentation on a subject of our own choosing. I think I am going for user stories, a leitmotif of the lecture and of agile requirements analysis in general. It’s a rich theme, and I have read a standard book on the subject (User Stories Applied for Agile Software Development, by Mike Cohn, Boston, MA: Addison Wesley, 2004).
As a matter of fact, I am looking forward to this exam. I have always preferred oral to written examinations. The examinor’s reactions to one’s replies provide instant feedback and thus the chance to correct or amend an insufficient answer. And a reasonably benevolent professor (and I believe ours is) will try and pass quickly over areas where the student is insecure and give him/her the chance to expand on subjects s/he feels comfortable with. The only thing about this exam that has the potential to make me nervous is that the schedule will not be announced in advance. Rather, we are expected to assemble all early in the morning on the actual day and then learn who is going to be examined when. It may turn out I am the first. Or the last. Both options seem not particularly attractive.
Neither am I worried about graph theory. This will be a written exam in the classic style of our first-term math professor, a format with which we are by now perfectly familiar. 90 minutes plus a grace period of up to 30 minutes, provided nobody hands in early, eight equally weighted assignments, for a total of 120 points, 100 of which suffice for an A+. I believe most of us feel comparatively well prepared for this exam. As always, the professor has made a point of providing a large number of pertinent exercises complete with solutions, during the lecture itself, in two large homework assignments, and in two dedicated four-hour exercise sessions. In addition, since she has been teaching at UAS for many years, we have numerous Altklausuren (exams from previous terms), also complete with solutions. I have been doing those for a couple of days now. And finally there was a full-size mock exam just before Christmas in which my programming partner and I, grading each other maybe just a bit too generously, but probably not much (we know her grading policy by now) both got a comfortable A+, with points to spare.
Granted, in math, there is always the chance for a nasty surprise–an assignment that the professor considers self-evident but that is puzzling to the students–but all in all I feel I have mastered 90 per cent of the contents of this course and even enjoy some parts (particularly modelling flow problems or scheduling conflicts). I feel a bit shaky about graph grammars and graph isomorphisms–unfortunately favorite hobby horses of our professor–but in the worst case there should be one problem out of eight from one of these fields. And Petri nets, another of her hobby horses, can be involved but I think I will manage. Besides, there will be another exercise session next week.
So much for the good news. The other two exams I find sort of unpredictable. In algorithms, the unfortunate situation is that the only problems certain to figure prominently in the exam–complexity of algorithms, particularly resolving time complexity recurrences by substitution and then proving them by induction, or using the so-called master theorem to decide in which complexity class they fall–are certifiably nasty. Invariably they involve calculations that feature limits of functions, logarithm arithmetic, even logarithms as exponents, and sums with a large number of addends full of fractions and variables. Basic stuff for a math professor, I am sure, but highly confusing for most students. Even though in theory I think I get it, in practice it’s highly error-prone even with a lot of practice and unlimited time. I have been doing it a whole day a couple of days ago and still feel getting it right will be entirely accidental.
And that, together with sorting and searching algorithms, is the predictable part of the exam. The second half of the lecture featured a lot of barely interrelated areas that seemed nothing but particular hobby-horses of this professor: hashing, conditional probabilities, Markov chains, waiting systems. All very interesting, but hardly very pertinent for this particular course in our curriculum, so it’s difficult to imagine they should figure prominently in the exam. And each of them highly complex, too. So I find it hard to prepare for this exam. The effort needed to master all these barely related areas seems completely out of proportion to the weight they are likely to have in the exam. In addition, this professor has been at UAS for only three years. There is just a single Altklausur from him for this particular course, and it’s without a solution. The mock exam was very early in the term and very short. It covered only a fraction of the contents of the lecture. And there are no pertinent homework assignments or exercises with solutions. In short, this is an exam that I find unpredictable, with a chance to be extremely nasty, and thus, in comparison, rather stressful.
Yet it’s nothing compared with operating systems. There, as related earlier, shortly before Christmas our professor had not yet given us even the vaguest indication as to format, contents, setup, etc., of the exam; nor has he meanwhile. Granted, this is his first term at UAS (which is why we also have no Altklausuren from him) and everything is likely new and overwhelming for him, but for us it means we have absolutely no idea how to prepare, save by rote-learning the entire contents of the lecture. And these contents are huge, full of petty detail, and unintuitive to say the least. I have 288 flash cards and I loathe every one of them. Things like the minutiae of scheduling or paging in Windows and Unix, respectively, or the cryptic Unix commands for creating a shared memory region (“shmid = shmget (key, size, flag)”), or the six versions of RAID. I believe I am not the only one to have no great expectations for the outcome of this exam. And it’s the first one we take, as well, followed by algorithms on the next day. Some start for the exam period!
So it’s a rather mixed bag all in all. If I should state my expectations, I would have to say I confidently look forward to an A in business administration, software engineering, and graph theory, in this order, with graph theory being the hardest. I work for an A- and have reasonable hopes for at least a B in algorithms. And I have absolutely no idea with respect to operating systems, but am certain of passing.
By the by, and maybe surprisingly, these expectations have little to no relation to the relative effort I spent in getting the PVL and preparing for the exams in these courses. Like last term, I consciously kept track of my work load outside lectures for each individual course–homework assignments, studying, acquiring additional expertise, exam preparation, etc. As I mentioned before, our study regulations fix this workload as 132 hours per course (lecture plus practicum) over the whole term, but since this adds up to 660 hours for the regular five courses per term, and thus over 15 term weeks computes as 44 hours per week outside courses, I am certain that no student ever comes even close to fulfilling this insane requirement for all courses.
For me, this term, graph theory was the only course where I came near, with 130 hours, or 32.3 per cent of my total work load of 403 hours, to date. That figure was due mainly to having started working through a reference work already during the summer break, and to spending several weeks familiarizing myself with a graph library we didn’t use, in the end. Well, that graph theory was my favorite subject this term may have played a role as well. Algorithms was a close second, with 117 hours so far, or 28.9 per cent of the total. Of course, these were the two courses with the greatest amount of content, and those where we did a lot of programming. Software engineering is on third place, with 97 hours or 24,1 per cent. To put this in perspective, however, over 40 hours of these accounted for my solving the last practicum assignment independently–the one involving Spring, Rest, and Angular. Without that extra work, the workload for this course would have been at least one-third less. On operating systems I spent 42 hours outside courses, or 10.4 per cent–for only a few small practicum assignments, but mainly for writing and memorizing flashcards. Business administration accounted for 17 hours or 4.3 per cent. So at least these two last courses had a good cost/benefit ratio, which is more than I can say about algorithms.
By the by, please observe that my grand total in the summer term was 523 hours; still 137 hours short of the official requirements, but 120 hours more than my total this term, so far. And I am quite sure I am putting in a lot more work than the great majority of my co-students. In any case, it’s obvious that this term is, on the whole, easier, or in any case I am definitely taking it easier. You see? I really managed to keep my promise to myself and my family.
So what’s my plan for the two weeks before the first exam? After this two-hour foray into procrastination I will use the afternoon for working out the structure for my software engineering exam presentation. Tomorrow I think I will look at some Altklausuren for operating system–as I said, there are none from our professor, but plenty from others, and he will certainly take a leaf or two from their books. Boy, am I not looking forward to this! The rest of the time will be more Altklausuren for graph theory and algorithms. Next week starts with the final meeting of our group for the presentation of our software engineering, part II, project on Tuesday. On Wednesday our operating systems professor may finally (and very belatedly) have some news on the exam layout; but then again, maybe not. The final exercise session for graph theory is on Thursday, after which we are going to do some Altklausuren for algorithms. And then it’s only a few days before the first exam!