This is the second of three planned posts. What wasn’t planned was the two and a half year gap (!) between the first post (https://tpg.me.uk/2014/11/11/megatech-and-minitech-part-1/) and this one. In the very unlikely event that you have been waiting with bated breath for this follow-up, I can only apologise.
Don’t be too quick to dismiss ideas at this stage. We’ve discussed this already but, in my opinion at least, here are some final year project issues that you might think about.
1) Don’t take on too much. This is an undergrad project and so you don’t need to do something brand new. Applying existing knowledge to a new situation or taking a slightly different approach is fine. And, anyway, you will make your project unique just by being you and approaching things in the way that you do (something that nobody else can do).
2) Don’t think that you have to solve everything (also see point 1). You might finish your project with more questions that you started with, but that’s okay. Questions often result from reflection, which is a high level activity.
3) Make sure that there is some existing research in the area, otherwise it’s going to be difficult to find background information that you can build on (also see point 1).
4) We’re in a technical department, so there’s an expectation that you will produce something technical as part of your final year project. BUT, and this is definitely with capitals B, U and T, the technical artefact (‘thing’) should generate an academic discussion. Making the most impressive ‘thing’ does not necessarily make the best project. I’d say that a decent ‘thing’ that is built upon background research, generates data and allows you to discuss and reflect on that data is much better.
5) Projects that involve some kind of comparison seem to work well. So, for example, two ways of doing the same thing, or running the same tests before and after some kind of change has been made. Comparisons can generate different results, conflicting results, surprising results. This gives lots of room for analysis, discussion and reflection.
6) Start with the smallest number of tests that you think will be needed to generate the data you need (see also point 1). Personally speaking, given the choice between two projects, I prefer the less ambitious and complete project to the project that could have been amazing if only the student had another six months to finish it (see also points 1, 2 and 4).
7) Don’t take on too much (see also point 1). Joking aside, I can’t emphasis this enough. Start with an achievable plan. If you find that you have finished a first draft with two months to spare then you might look at adding some extra content.
8) Make sure that the project interests you. The project needs a sustained effort over two semesters, possibly longer if you put some work in over the summer holidays. This should be point number one, but I can’t face renumbering everything else.
Hope this helps
For the first time since my very early thirties, when a lack of ID stopped me from buying a bottle of wine in a supermarket (quite a flattering experience, if I’m honest), someone has refused to sell me something. Continue reading
Just before Christmas an order of 20 or so Raspberry Pi 3 kits arrived at work and I had spent some time clipping boards into cases and inserting Micro SD cards. Nothing out of the ordinary. As I completed each kit I stacked the boxes into a pyramid of sorts. Job done, I sat back and admired the construction. Continue reading
(This post has nothing to do with the Motorola 6809 microprocessor and everything to do with how inspiration sometimes comes from the strangest places.)
I can still vividly remember my first lecture as an undergraduate computing student. Monday morning. 9 o’clock. Programming 1A. C++. Within the first five minutes we’re being talked to about data types. I can remember some dazed expressions and confused discussions at the end of the lecture. Not to mention the confused discussions 12 months later when, as a second year computer networking student, some of my classmates were still dragging Programming 1A and 1B resits behind them like a ball and chain.
Fast forward a little over a decade to January 2014 and I’m teaching second year networking students. Second year students dragging a familiar ball and chain. It might be a Java shaped inconvenience now, rather than C++, but it’s still first year programming baggage that the students could do without carrying. Bring things to the present day and I find myself team teaching foundation students the Fundamentals of Programming. The niggling mantra running through my mind? “Please don’t let this be their ball and chain. Please don’t let this be their ball and chain. Please don’t let…”
But what’s the best way to prevent this from becoming the miserable outcome? I’m not sure. I’m more certain that there isn’t a magical solution to this. For me the issue extends far beyond the choice of programming language or the object oriented versus procedural debate. In the past week I’ve seen the panic that can set in when students are faced with a programming challenge. Enthusiastic, intelligent students staring at a blank screen, gripped by fear and not knowing where to start.
This lack of knowing where to start seems important. With some of the students there seems to be an assumption that, because it’s a programming module, the answer lies in the development environment. But this is an environment that forces students to contort their thinking into strange syntax. Syntax which must pass muster with the most pedantic entity they’ll ever have to deal with. Creativity thwarted by semi-colons and the right shape of bracket. Constraint by the bucket load.
We’re using the Arduino for Fundamentals of Programming. At least this offers the chance to bring the abstract world of programming languages into a more meaningful, physical, real space. Wires, LEDs, buttons, noisy things. Making gadgets. Tinkering. Most of the students seem to like it. But eventually the students need the code to drive the gadget and at this point we’re back to the blank screen problem. We’re back to the syntax.
I acknowledge that, at some point, the students need to understand the language and be able to properly construct code. If they can’t do that then eventually they’re going to have problems. Just like my issues with French grammar and tenses back in the day. But if the abstract concepts of programming are presented through equally abstract examples then it seems doomed to end in misery for a sizable chunk of the students. As a student, demonstrating my competency with C++ by creating a program to check whether a series of cylindrical and cuboid boxes would or would not fit inside each other wasn’t a problem, but I can see why it was unfathomable for many others.
So, as far as my input into Fundamentals of Programming goes, I’m trying to keep it as real as possible. Which is hard, because we’re still asking the students to make things that many probably wouldn’t otherwise make, using a programming language that many probably wouldn’t otherwise touch with a barge pole. I’m hoping that having time away from the computers proves to be a good strategy. We’re blessed with a classroom which provides a space for this kind of breakout activity. So this is the first week when I’m going to present students with a group activity where they unpick a real world device, think about how it works and map out the steps of a program to control it. The examples aren’t particularly thrilling (think traffic lights and lifts) but they are immediately identifiable and familiar. Hopefully, because the problem is clear, the students can focus on the activities needed to solve it. With a nod to Problem Based Learning, they’ll need to ask questions and they won’t have all the information they need.
My goal is to bring the tasks of identifying requirements and planning program functionality and structure into the students’ comfort zone. Then, hopefully, with a clear plan to work to and an end product they can visualise, the prospect of satisfying the pedantic syntax monster won’t seem quite as daunting.
This afternoon I read through a collection of abstracts for a conference. It was a very mixed set of abstracts. For the purposes of this post I’ll split them into “hard science” abstracts and “not hard science” abstracts.
Some of the “hard science” abstracts were talking about immensely technical and specialised subjects and yet I still found them more readable and understandable than some of the “not hard science” abstracts. It reminded me of my comment on this post.
So why did I find the “hard science” abstracts, on the whole, more approachable?
Maybe I have a “scientific brain” that can’t cope with more complexity than “works or doesn’t work”, “yes or no”, “on or off”. I won’t rule this out.
Maybe it’s the nature of the subject matter. With the “hard science” abstracts it didn’t feel like anybody was trying to be clever. The results of their work would tell the story and provide the mechanism for any ego boosting that the author(s) may or may not be looking for.
Maybe it’s easier to talk about subjects that provide repeatable experiments that deal in certainty. In <insert conditions> you will always get < insert result>. When you stray into anything involving the social sciences or anything involving people do things inevitably become less certain? Does this encourage the application of mindw&nkery?
There could be a model in this.