Say hello to the Three Headed Programmer

I’m playing with some ideas for the introduction to an update of the C# Yellow Book. I don’t want people to end up thinking that a developer writes programs. I think a good one does a lot more than that:

The Three Headed Programmer

I like to think of a developer as having three heads. I think that to be a good developer you should be capable of wearing any of these heads, although you will probably be better with one head or another. If you are working in a team, you might find that team members gravitate towards one particular head, but everybody should know what the heads do. The heads are:

The "Find out what is wanted" head

This head is friendly, approachable, and constructive, but not above asking hard questions about what should really happen or why something is being done the way it is. This head is good at writing things down and then showing them to people to make sure that everyone agrees what is being made. It has a twin - the "This is what I'm going to build" head which is used when you are making something for yourself.

When you first start programming you don’t use this head very much because the things that you do are set out as exercises for you to have a go it. However, if you can get good with this head it will vastly improve your usefulness as a developer.

The "Make something that works" head

This head is good with technology. It can take the problem definition from the first head and build a solution using software and hardware. Making it work might involve creating an overall design, breaking things into components and then making each component in turn. For a large development this head might have to assemble and manage a team of people. Testing will form a big part of the process; this head is very keen to be able to prove that it has made something that works. This is the head that most people think developers wear all the time. I think it is the hardest head to learn to use because when you are learning program it is very difficult to know where to start when confronted with a problem and asked to make something that provides a solution.

The "Make it good" head

This head is a bit of a worrier. You might think it comes into play once the "Make something that works" head has finished but this is not quite how it works. This is a head that you pop on every now and then to look at how things are going. It's the one that asks the hard questions when finding out what is wanted. It's also the head that looks at a solution and worries about things like reliability (are there things that can go wrong), security (can the system be successfully attacked), scalability (what happens if we get lots of users) and business (can we be sure we are going to get paid for all this). This head really wants to make something good, but it also has a sense of perspective and is happy to negotiate what "good enough" means, as long is that is written down and everyone agrees about it.

In a team the heads can turn into different roles for team members. Whatever happens I think it is really useful if a developer stops every now and then and thinks “I wonder what my other heads would think of this?”.

Compile early and compile often

I’ve been writing a big and complicated program for a while. I’m not sure if it is supposed to be big and complicated, it just seems to be turning out that way. And one of the things I’ve remembered from my days of doing this kind of thing is “compile early and compile often”. If you wait a while before hitting the compile button you can sometimes get so many errors that it can take you a while to figure out. Modern editors are quite good at spotting coding mistakes as you write, but there is nothing like letting the compiler take a proper look at your code.

I’ve been hitting compile every time I’ve written a few lines. That way, if I get an error I don’t have to look through much text. I do this even though I’ve no intention of running the program at that stage. It’s just that when I’ve done a bit that I think should compile it is worth getting the proper opinion on the matter.

When I was teaching programming we used to get people come in with 500 line programs that didn’t compile and they weren’t sure why. They’d written all the code down and then hit compile and were surprised by the number of errors they got. I used to tell them that a good way to start would be with an empty program that compiles and then add the statements a small amount at a time, compiling at each stage.

Take a look at Jupyter

If I was still teaching a programming course (those were the days) I’d be taking a very long, hard, look at Jupyter. It’s a web based active notebook where the pages can contain text, images, programs and outputs from programs. You can write your code into blocks on the page, hit run and see the output. And you do this inside your browser.

I’ve had a go with Python and JavaScript and they just work. You can also use C# as well. It would make it possible to create an interactive text book which contained code and output that readers could play with in the text. You can also use it to create interactive labs in other things too. We’re working on some curriculum for experiments with particle sensors and I’m going to take a look at how we could use Jupyter to do this.

Talking Air Quality at South Hunsley school

David got in touch a while back. Would I like to talk to his students at South Hunsley school? Would I? Oh yes. So today it was into the bag with the Air Quality Sensor Top Hat and a few other goodies and then off back to school. They were a great bunch of folks. And they were even polite enough to laugh at my first (and only) joke. I was talking about air quality, hardware, self promotion and whatnot. I said at the time I’d put some useful links onto my blog (always a good way to drive traffic). Here they are.

To find out about the Arduino and get the software you can go here.

To make yourself poorer buying things from China you can go here. You can get cheap Arduino Uno devices, along with a whole bunch of other hardware.

If you want to buy one of the tiny LoRa enabled devices with a screen search for “Heltec LoRa”. The devices are sold in pairs for some reason, make sure you get the ones which are marked as 868Mhz.

You can also get the tiny cheap WiFi devices here, search for “Lolin D1 mini”.

If you want to get an air quality sensor you can get one of the good ones by searching for “SDS011”. If you want to measure temperature, pressure and humidity, search for “BME280”.

If you want some fun coloured leds search for “WS2812” followed by “ring”, “strip” or “panel”. These are dead easy to interface to any of the devices I’ve mentioned above. But make sure you get hold of a properly beefy power supply if you are driving more than 12 or so to full brightness.

I’ve not had a problem buying from China. In over 50 orders I’ve only had one not turn up, and I’ve only had a couple of broken devices.

You can find my Air Quality stuff on GitHub here. That has drivers for the hardware that you can buy and there are also circuit diagrams and box designs.

Digital Teaching - Final Week

Today was the last day of my teaching on the Mechatronics course. Thanks for being a great audience folks. I really hope you’ve learned something useful.

You can find the notes for the session here.

You can find the little circuit simulator that I used here.

Digital Teaching Week 2

If you;re on my Digital Technology course today you can find the slide decks here. If you’re not on this course, then don’t bother looking.

Digital Teaching Week 1

I had a great time teaching some digital stuff today. I said at the time that I’d put the slides and stuff up on the internets, and here it is.

I also mentioned some links to useful Karnaugh Map videos, they are here:

Robot Projects at Hull

Steven did a project which involved getting swarms of robots to push a box around. This is a picture of a swarm of robots pushing a box around. I think we can call that a win. Unfortunately I haven't got any pictures of the Jousting Robots that Jason made, but he does have a video where one of them crashed into the other one and broke it, which I think also counts as a win.

Exams as an aid to learning

[Click through the picture for the full 360 degree lecture experience]

Sometimes I get asked about exam technique. What's the best way to deal with an exam? What should I do to prepare? My advice is quite simple; try to get yourself into a situation where you know the answers to the exam questions. 

Today we had our revision lecture for our First Year Programming module. I went through all the questions from last year and didn't quite give the answers as such. I was more interested in charting a path that will get you to the answer from first principles. I'm quite calculating about this. I'll try really hard to give some solid hooks that you can remember, and will start you off to the answer. 

Compostition? That's a car number plate. Throw away the numberplate and the numbers go away too. 

Agregation? That's a football team. If we disband the football team we don't kill all the players. 

I feel a bit guilty about saying "and the way to remember the triangle on a class diagram is to think of granddad dying", but I was trying to get people to think about inheritance....

The aim of all this is to make exams useful for teaching, as well as our assessment mechanism. In a week or two's time I'll find out if it worked. 

Marking time

We were back in the department, marking today. We are using the latest version of my Magic Marking program, which now has a search so that you can easily find the student you want to mark. It automatically opens the student submission, builds the marking spreadsheet and puts everything in the right place for returning to the students when the marking is complete. I saw some really nice great too, which was nice. 

Computer Science Course in "Actually Useful Shock Horror"

James came to see us today, which was rather nice. We got to talking and the subject turned to the gulf between studies and real life, and how to narrow it.

One of the things that we try to do in Hull is to tell people useful stuff that will they can use to get by in life as a developer. A problem that we have is that people think that the only use for the stuff that we are telling them is in exams and assignments to get a good mark.  This is a good thing as far as it goes. And of course you should do this. We have to do the grading thing to ensure that the learning outcomes for our courses have been met.

But we really, really want people to carry those skills into the next (and indeed every) thing that they do going forwards. We're trying to start you building skills that will carry you through your professional career. I don't think you can ever say you've learnt something like programming because, if you do it properly, you are continuously learning. And you should never stop. 

The good news for me is that we do get a few folks who go out into the big wide world, and come back and say "You know, that stuff you taught us turned out to be quite useful".

Who'd have thought?

Anyhoo, James is very keen to come back and do some Rather Useful Seminars on what you can do as a student to build on what you're taught, which is great.  Stay tuned. 

Cross Country Ski Race is Coming

This is not an assignment about graphic design - obviously...

Kevin and I are just putting the finishing touches to the assignment for Programming 2 for this year. We always set two different scenarios, one a game and the other a line of business app. For the game we are doing "Cross Country Ski Race". For the line of business app we are doing "Cross Country Ski Race Manager". Almost like we have planned it. 

.it might not be one about UI design either..

For the game, players have to steer their player down an increasingly tortuous ski run, avoiding the deadly, and somewhat improbable, "horizontal avalanche" that seems to have erupted. Fortunately an explosion at a nearby cheese mine has left their path littered with life giving cheese which they can use to recover their strength. 

For the manager application they have to track competitors, generate reports and produce a fully tested solution. Should be fun. 

Jupiter and Static Class Members

I put some of my lectures up on YouTube last week and it was great to get a comment on one of them. Kostas was wondering why I spend so much time explaining how static works, and even dragging the Planet Jupiter into the explanation, when a memory diagram would do the job much more efficiently. 

Well, yes and no.

The problem with diagrams like these is that people think that they just have to learn the diagram to pass the exam and therefore pass the course. But I don't want them to do that. I want them to know what "static" means, and when to use it in a program.

I use Jupiter as a context because it might stick in the memory. It turns out that the planet puts out a lot of radio static and that static on the radio is kind of like an echo of the big bang. So it has always been here. Just like static members of a class. They don't need instances to exist. As long as the class exists, the static members exist. So you can use static methods to perform tasks without needing to make an instance (for example data validation) and you can use static properties to hold values that need to be stored once only for the class. 

My idea is that folks can go from Jupiter, to static, to always here, to methods and properties and they'll have a handle on what it all means and how to use it. Which I think is better than a diagram.

Programming 2 Stealth Videos

I've started recording some of the first year lectures as screencasts, Just to see how it turns out. I joked with the class that I'd only tell the people that came to the lectures where the videos are, but this is probably not very helpful. Anyhoo, you can find the first one here and I've set up a channel here for the rest.  They're a bit rough and ready, being recorded straight from the Surface using Camtasia and the built in microphone, but they might be of interest to C# students at Hull. 

I'll keep posting them for the rest of this semester. The only slight snag for me is that it takes around four hours to render each captured session so I've got to create a workflow that I can use to do this. 

Final Year Project Interim Demonstrations

The department is trying something new this year. Each of our Final Year project students is being asked to give an interim demonstration of their project to their second supervisor at around the project mid-point. The students see a lot of their first supervisor, but they don't usually see the second supervisor until later in the project, when they are involved in the final viva and the assessment.

This year I'm getting to see all the projects for which I'm second supervisor. I wasn't convinced at the start, what with the nightmare of fitting a whole new bunch of meetings into an already crowded diary, but I must admit it has been really useful. I've seen some really great work, and some that could be made great by a strong focus on the important elements.

When considering things like this I'm much more impressed by an "end to end" demonstration of a working system with "n" features than a half-way demonstration of a system with "n*2" features. If you are making a game, it should be playable all the way to the end, with a high score table and a chance to play again. If you are making a product you should be able to  run through an entire scenario of whatever transactional behaviours the product provides. If you are performing research you should have the theory, the things you are going to do to prove/disprove the theory and some outcomes to look at which drive the conclusions. And it is worth trimming the scope so that you can achieve this.  

Writers have this thing where they talk about "killing your favourite children" which means that they have to discard a great piece of text out because it doesn't actually add anything to the work. The text might be funny, or poignant or interesting - but if it doesn't fit the context it has to go.

During the meetings we were encouraging students to take a look at their projects and do something similar. This isn't to say that they should not get credit for work that doesn't end up in the finished deliverable. My advice is to write these up in the report and then document the process by which you decide to leave them out in order to focus on the core of the work. In fact, I reckon that getting a handle on your project and dropping features that will make you fail is actually strong evidence of real professional ability. And in real life you can always save these for version 2.0 anyway. 

Printing Green Cheese for 100% Students

I've been giving awards for the best performance in First Year labs and exams. Last week I gave awards to the top five or so exam scores. When it came to the practical work I had a bit of a problem, what with ten students getting 100% in the work - which is awesome by the way folks. 

Anyhoo, it means that Una the 3D printer has been busy for a large chunk of today dropping out perfectly formed pieces of green cheese for next Monday's lecture....

Going bananas with passwords

We had our big First Year exam this morning. Around 250 students took the exam at the same time. Thanks to Septa, Amadou, Kevin, Nicholas, Xinhui and David for helping to run the affair. 

Before the exam I carefully wrote a briefing document and made sure that everyone knew the username and password to unlock the test. Bearing in mind the Yellow Book theme this year I thought a username of "bananas" and a password of "custard" would work well. 

Thing is, that's not what I typed in the briefing document. I missed the s off bananas, and so people were tying to start the exam with a single banana. Which didn't work. Fortunately I'd also put my phone number in the briefing document, so as soon as the exam started my phone lit up with folks ringing through from the exam locations around camps. We sorted out the problem in double quick time and everyone was able to get on and answer the 50 questions. 

Meanwhile....

... at a secret rocket and cheese production facility in the North of England....

... I'm making special "Space Cheese Mining" marker awards for all the folks who helped out with the First Year marking this year. I'm going to give them to Kevin, David, Phininder, John, Bailin and Brian to say thanks for their assistance in giving all of our students a great assessment experience and some splendid feedback. Guys, I'll have them for you for Monday.

Why I do my job

For me, there's nothing quite like marking a nice looking, well structured piece of code, giving  a good grade  and then asking the student "So, when did you start programming?" and then having them tell you that they started in September this year. 

What is Assessment For?

At this time of year we do a lot of assessment of our students. This week I'm going to be spending the best part of four days in the lab with a bunch of my colleagues, pointing at bits of code written by students and asking "What does this do?". Great fun.

You might think that we do the assessment so that we can give the students grades. True enough, but to me the assessment is more important than that. We also want to have a framework in which we can talk to each student about the programs they have written, and how to make them better. The marking scheme provides lots of hooks we can use to hang discussions about good program design, documentation and testing. 

By the end of each marking session the student will have a number and hopefully they'll have learnt a bit more about software development. Which is kind of the plan.