For over a year I have been writing vaguely of our “practical courses” or some wording to this effect on these pages without ever properly specifying what I meant by that. Meanwhile it appears there is actually an (American) English word, practicum, that is identical to the German word I was at a loss how to translate, save for the spelling (we Germanize it by trading the c’s for k’s), but that moreover seems to describe roughly the same concept as the German word does here at UAS. Which is useful, because for a German, Praktikum more often means what in English would be called an internship–working in your desired professional environment for a few weeks, or several months at best. Many study programs, particularly more technical ones, require students to do just that.
At UAS, the concept is different. Our practicums are an integral part of our study program and take place here at the university. Each and every course on the curriculum is accompanied by a corresponding practicum, supervised by the same professor working in tandem with a research assistant to improve the student to teacher ratio. At the start of the term, the participants of the lecture are divided into groups of roughly equal size, with the upper limit determined by the number of available workstations in a typical computer pool (usually eight, so that sixteen students working in pairs can be in each group). The practicum takes places three to six times per term (most often four times) for each group, with the dates staggered so the professor and assistant can attend all meetings. Naturally that staggering makes for some injustice, as the group that meets first usually has the shortest time to prepare the homework assignments, of which one is usually due in each meeting. Though over five lectures per term and in any case over several terms this injustice usually cancels itself out.
Some very rare courses, usually those rated as being purely theoretical, are accompanied not by a practicum but by a similar event called an Übung, literally “exercise,” the difference being that it takes place once a week for a shorter period of time. A practicum meets for up to four hours. We had Übungen in Math 101, CS 101, business administration, and automata theory, though in two of these courses they never actually met, the face-saving theory being that the “exercise” took place during the lecture itself. Everything else had a practicum.
Practicums (or is it practica?, my inner humanist wonders) can be quite different in many respects. The only things they invariably have in common is that attendance is compulsory and that you have to complete several homework assignments in order to get the crucial Prüfungsvorleistung (literally “examination prerequisite,” PVL in short), that means you are admitted to the exam that concludes the corresponding lecture. These homework assignments have ranged over three terms and about a dozen practicums from trivial to quite involved, but in any case, combined over five lectures they constitute the bulk of the workload per term. The lectures by our now third-time math professor invariably keep us busiest, with weekly homework assignments, some of them very complex. Though of course, whenever programming is involved (and now in the third term, the practicums require us to program in almost every case, whether that means visualizing graphs or implementing algorithms), there is hardly any natural limit to the time and effort one can invest in a solution. It just feels less stressful without the pressure of a weekly deadline. Which is why our group of four has capitalized upon the fact that our math professor has recently given us three of his weekly assignments in advance by splitting the workload over all three, with each one of us doing an assignment, or a part thereof, alone. In my case that meant implementing an abstract data type for a context-free formal grammar, complete with methods for bringing it into Chomsky normal form and using the Cocke-Younger-Kasami algorithm to decide whether a word is included in the language. That took me about three days combined and resulted in about 1,200 lines of code. But on the flip side, I am done with homework assignments for algorithms for the rest of the term.
In fact, though, this term so far I have invested about twice the time in the homework assignments for graph theory. This practicum meets only three times, and there were only three assignments too. But the first one required us to familiarize ourselves with a graph library of our own choosing, finding a way to read text files describing graphs into this library, which involved writing a parser and an internal data format, then implementing a shortest-path algorithm, and visualizing its traversal of the graph. All of this combined probably took my programming partner and me about 60 man hours, not the least because I first solved most of the assignment on my own in a library different from the one we eventually settled on. That resulted in my throwing away 600 lines of code and beginning nearly from scratch (I could re-use the parser). To be sure, what we finally came up with was top-notch, with the graph itself being observable and us being able to visualize the traversal in real-time. And once we had broken the ground, the subsequent homework assignments were insignificant in comparison. They involved writing random graph / network generators and implementing two path and two flow algorithms, respectively. Had I tried to understand the somewhat complex path reconstruction in the Floyd/Warshall algorithm first instead of after four unsuccessful days of trying to get a solution by trial and error, I would probably have completed the second assignment within a few hours.
Sometimes, unfortunately, understanding an assignment takes longer than actually solving it. Our algorithms professor has become rather notorious for giving us assignments that appear to be entirely experimental on his part. A few weeks ago, our study group spent a couple of days, for the four of us combined, to try to come to terms with the task of compressing text files of random binary strings (in other words, 128, or 1024, or even more ones and zeros). This simply cannot be done–there is no way to compress random data, for the very fact that it is random, i.e. has no structure that would lend itself to taking shortcuts. Yet the professor had been vaguely hinting at looking for an inner structure in the data, and this we tried to accomplish in vain. Turned out he had used a Markov chain to create the data, but with probabilities so close together that, well, the output was close to random. Next we had to use a Huffman tree to compress the same data (that, too, is unlikely to result in any meaningful compression, for the same reason), and weeks later we finally got to use a Huffman encoding on a less random Markov chain output. Any idea what I’m talking about? No? That’s my whole point. He had us groping in the dark for many days on an obscure question that in the end turned out to be nearly moot and of which even the remote connection to the subject of the lecture (conditional probabilities) bore little to no relation to the likely contents of the final exam. Since attending the practicum and successfully completing the assignments is to prove one eligible and reasonably proficient for taking the exam, homework that in no way relates to the exam is sort of pointless. Now in graph theory, too, this in an open question, since the practicum is, well, practical, whereas the exam will be theoretical. But at least there implementing algorithms in Java requires us to understand them, and thus can be considered a useful preperation for the exam where we will most likely have to show we can do them manually.
In most courses the connection between lecture, exam, and practicum is a great deal more obvious. Particularly in programming, where we did a practical examination, i.e. live programming, the programming assignments were a direct preparation for the eventual exam. Granted, there was this one monster project, the notorious media player that nearly ate me alive in the second term, and of which until the end our professor never made clear that he did not expect us to complete it. Even so, however, whenever you program anything you cannot but further your programming abilities, which, if not directly relevant to the exam, certainly increase your eventual market value as a developer.
The same can probably be said about the homework assignments in software engineering. The first two were more conceptual in nature; we practised writing user stories and everything else that relates to requirements (the analysis of what a software should be able to do). The third was much more practical: We were to familiarize ourselves with the Spring Java framework, with REST services (in the vaguest terms, getting data out of a Java object by way of URL queries from a web browser) and with persistence (saving object data to a database) using the Java Persistance API (JPA) and Hibernate (an Object Relational Mapping tool, i.e. a translation from an object-oriented programming language to a database). The fourth assignment, apparently, will add AngularJS, another framework for writing dynamic web pages, so completing the setup for a web-based, database-backed Java application.
Of course, all this is rather an overkill for the small example project we are currently working on, and for all but my programming partner the entire setup is extremely confusing, a veritable maze of classes, annotations, several pages of completely incomprehensible console output whenever you hit “save”, and a lot of sheer magic. I spent two entire weekends trying to get to grips with Spring and Angular and gave up. In fact, apparently it’s not really essential to understand what we are doing there right now, because we are being spoonfed the entire thing in small bits, with prepared runnable projects we can download and add our own logic by overwriting and amending some of the code. But I hate to do things I don’t understand. It always carries the risk of thinking you have mastered something when in fact all you have learned to do is to copy the boilerplate and adjust it to your needs. I believe it’s called cargo cult programming. But my real point is that these assignments, too, are only indirectly related to the eventual exam, which in any case will be oral and thus more about general understanding of design concepts than about actual programming skills.
In machine-oriented programming last term and in operating systems this term, our professors are from the technical CS study program. There, the homework assignments are called Versuche (experiments) and are highly technical and practical, particularly in machine-oriented programming where we even had to interface with hardware, a thought that makes every applied CS student shudder. Other than that, it was assembly language programming last term (which is of course as close to the bare metal as you can get, short of writing actual machine code) and small programs highlighting operating system concepts like semaphors this term. Fortunately in Java rather than in C, the language preferred by technical CS professors, it seems, for its opacity (unpronouncable six-consonant method names, with parameters framed by asterisks and ampersands to signify dealing with pointers) and its lack of any high-level language comforts like strings, automatic memory management, or garbage collection. In keeping with this preference, in our experience technical CS professors will always emphasize mastering technical detail over understanding general concepts. Well, to each his own. Seems to me there is a somewhat amused live-and-let-live relationship between their students and ours, with each side slightly shaking the head at the other’s strange interests and all of us united in our mild disdain of the business informatics students who allegedly learn accounting rather than programming!
In databases last term, the practicum involved developing an entity-relationship model for a webshop, then transferring it to a relational (database) model, implementing it (i.e. actually creating the tables in a SQL database and writing some sample data to it), and in the last meeting interacting, under time pressure, online with other groups to simulate an order-delivery chain. In this, we all failed signally, because our models were developed in isolation and no common interfaces were ever agreed on. In spite of this failure, our professor pronounced himself highly satisfied, because he said that was exactly the lesson we should take away. The most unusual assignment, however, is certainly in business economics, part II, this term. There the entire practicum group (13 people in our case) is called upon to develop a website for a consulting agency and present it in the last meeting. In spite of an elobarate mock hierarchy, in which each practicum group is subdivided into four task groups, one per subdivision of the business, each with a sub-project manager answering to a project manager in turn reporting to the professor, the entire thing is rather a farce. In our group, three people simply copied some impressive-sounding text fragments from the websites of actual consulting agencies (a matter of minutes), one is creating a mockup of the website (he may be the only guy in the group actually working for his grade), another couple of people do the talking, and the rest will get the Prüfungsvorleistung anyway.
In fact, business administration is the only practicum in which we are expected to work while attending. Oh well, in the courses run by professors from technical CS, they too to seem to be surprised that almost all of us have the assignments completely done when we get there, resulting in an instant rush to the blackboard where a list is kept of those groups ready to have their work reviewed and accepted. But that is what is expected of us in applied CS. The assignments are usually too big anyway to complete them within three and a half hours, so as a rule the practicum meeting is entirely reserved for the review of the solutions. The actual procedure for doing so is up to the professor. In graph theory, each time every group presents their entire solution before the class (using a video projector), which results in our looking at very similar pieces of code seven times in a row over several hours, which is tedious to say the least. Not to mention it’s hard to do justice to 500 to 1,500 lines of code within half an hour.
I preferred the practice of our programming professor, who reserved a couple of hours each meeting for having one or two groups present their solution at length, which a chance to discuss pertinent points in depth. Afterwards, he and the assistant split the work of briefly reviewing the work of the other groups. In machine-oriented programming and operating systems (the technical CS courses), there are no presentations at all. Rather, every group has its work reviewed individually before its workstation, often line for line, which means that it’s not uncommon for groups to wait for hours idly and then have to overstay, or come back in the next meeting (that of a different practicum group). In databases and software engineering, the same practice applies, but the review is much more superficial, so that it is usually complete with time to spare. Our math professor is in the habit of building mixed discussion groups where each person presents the solution of his/her own study group/programming pair, and a synthesis is then submitted to the professor for his review.
In any case, whatever the setup, the practicums are where the bulk of our study effort takes place, even though in terms of hours of attendance per week the lectures predominate. But attending the lectures is voluntary, and a lot of people prefer to study the contents from books or websites at their own pace, whereas the practicums are mandatory and you can’t take the exam without the PVL. To be sure, not all professors are very keen to actually keep track of attendance in the practicum. Our math professor, for instance, will make only a token effort to try and weed out very early those few evidently unfit for the exam, or unwilling to make the effort to prepare for it, then summarily give the PVL to everybody else. In fact, I think he doesn’t even monitor whether we complete the homework assignments. On the other hand, some professors take the PVL and thus the practicum very seriously. In machine-oriented programming, as you may recall, we even had mandatory tests, passing which was a precondition for the PVL, in addition to completed and accepted homework assignments. I suppose in the end it comes down to a matter of personal preference. In theory, getting the PVL should mean that you are not just eligible for taking the exam, but very likely to pass it. But some professors seem to be willing to let the students themselves be the judges of whether they are fit for the exam, whereas others take a more paternalistic approach.
Personally, I am not sure which model I prefer. Certainly I think a teacher has a responsibility to give her/his students reasonable feedback, including telling them when they are obviously unfit for something. On the other hand, I hate being patronized. And at least in those courses where the homework assignments in the practicum are at best indirectly relevant for the exam in the lecture, I think withholding the PVL should be reserved for those cases where students quite evidently make no effort at all. Which, unlikely as it may sound, happens not all that rarely. But that is a different story.