Author Archives: dhruvtapasvi

Presentation Skills Workshop

A skill often overlooked – but no less important – in the field of Computer Science is presentation. Apple’s keynotes, along with those of other major tech and gaming companies, compete with the year’s most highly awaited speeches. A new startup needs funding, and for that its founders need to be able to pitch their ideas. And even the typical professional or academic will present several papers or projects, often in situations where persuading the audience to believe in their idea has direct and significant consequences. So when the time comes, you need to be able to present effectively, which is why Dr Rice gave us a talk aiming to teach us this crucial skill.

Following annual tradition, we began by dissecting the “How (not) to give a presentation” video published by Neil Dodgson, a former member of the Computer Lab. Apart from more obvious issues such as a lack of preparation, absence of a script, and crazy transition animations and sounds, we were encouraged to pick up on the more subtle mistakes Dodgson (intentionally) makes. By the end, everyone knew the pitfalls to absolutely avoid.

People say that the best way to learn to present well is to practise. But you don’t always have someone at hand to listen repeatedly to your presentations, and if you don’t know what to look for in a good presentation, you can’t even practise usefully by yourself. Therefore, it’s very helpful to give feedback to others; by running critical eye over others’ work, you learn how to evaluate your own. The word “feedback” alone is quite nebulous, so Dr Rice suggests that we make use of a structure: we should comment on script (verbal content), slides (visual content), verbal delivery and body language.

To conclude the talk, Dr Rice covered a few tips to maximise the persuasive appeal of a presentation. Group things in threes. The first 30 seconds are paramount. Appear motivated.

And finally, make your ending snappy and memorable.


16/11/2016: Talk by Alex Chan

This week, Alex Chan was invited to give us a talk about Colossus, a British code-breaking machine from World War II. The former Queens’ student noted three remarkable facts about the Colossus: that it was created to decrypt a machine the British know nothing about; that it was created in such a short time frame; and that despite being a huge advance in computing at the time, it had almost no impact on the history of the modern computer.

Alex began with a brief description of the cipher that the Colossus was eventually built to crack, and the machine that was used to implement it. The folk at Bletchley Park knew none of this to begin with, and deduced it entirely by studying the intercepted messages — an incredible feat! Eventually, the team at Bletchley figured how how to decrypt the messages, but unfortunately the process was too slow. To speed this up, they built successively faster and more reliable machines, requiring less and less human input, and this resulted in the construction of the Colossus. This machine could translate any message in about 5 hours, and provided the British war effort with crucial intelligence in time for the D-Day landings in 1944.

In total, there were 10 Colossi at Bletchley Park. What made this collection special is that together, these machines were the first to be Turing complete — a key benchmark in measuring how powerful a computer is. Unfortunately, this achievement was buried deep under the veil of secrecy that covered all that transpired in Bletchley Park, which is why the Colossus did not make its rightful contribution to the field of computing. The talk concluded with a quick summary of the the timeline and how incredible it was that Colossus came around to be.

Apart from finding about a fascinating topic in the history of Computer Science, we also learned plenty from Alex’s polished presentation and delivery. Thank you for a wonderful talk!

Easter Revision Planning: 2016

In a departure from the previous theme, we focused this week on Easter revision. Eduard collected everyone’s plans and classified them as either focusing on when to revise, or what to revise. Some of us were chosen to present our plans to everyone else. Here’s the selection of the more memorable moments from the presentations.

When, Middle Level of Detail:  Ben

Ben planned to do eight hours of work per day… on his dissertation alone. Not to mention revision for his final year exams and a three-day rowing trip. While he sketched out a rough work schedule – in sufficient detail to identify daily targets – he retained enough freedom to juggle sessions around as necessary.

When, High Level of Detail: Andy

Andy planned in great detail each hour of his day, segmenting it into blocks of exactly 1 hour 35 minutes. Andy’s plan should ensure that he stays on track, and can just run on autopilot from this stage onwards.

Image: Andy’s incredibly detailed plan.

Screen Shot 2016-03-11 at 13.45.54.png

When, Low Level of Detail: Alex no. 1

Alex started off by asserting that he was a great “believer in freedom”, and so it’s no surprise that his plan left plenty of room for improvisation. This should allow him to vary his schedule on a day-to-day basis, as per his mood.

What: Alex no. 2

Everyone was dazzled by his three page plan written in LaTeX — until he mentioned that “none of this is the actual plan.” Fortunately, he did seem to have a good alternative plan, relying heavily on tripos questions (“Java questions are jolly useful”) to revise. This is a good strategy to get to understand the style of tripos questions and cover the material at the same time.

Image: An extract from Alex’s plan written in LaTeX.

Screen Shot 2016-03-11 at 13.42.13

What: Henry

Henry emphasised the importance of taking a break, planning in a week of gliding. Cambridge can be lot of hard work, and it’s vital to take some time off to be able to focus fully during term-time.

What: Radu

Radu used fancy fitting algorithms to slot his study sessions into his timetable. Wisely, he prioritised the courses he needed by assigning them the most number of sessions. The Part II dissertation was also once more a running theme.

How it can all go wrong: Eduard

To finish off, Eduard gave a demonstration of how a plan can go wrong, even for the best of us. Overall, the message was “be honest with yourself,” and keep a realistic set of goals in mind while revising over Easter.

Image: Eduard’s example (of what not to do) plan, including travel to Japan, FIFA, meeting with friends, and a worryingly small amount of time to work on his project.

Screen Shot 2016-03-11 at 13.43.07.png