“The hardest thing about learning how to code is learning how to think computationally”, Matt Bawn later told me as the workshop progressed. Indeed, Graham Etherington of the Di Palma Group pointed out the same thing, that the hardest part is “getting used to writing in pure logic.”
Matt further explained that “you have to extract the bits you need to program from your problem and then visualise all the steps it takes to get there.”
“That’s where the creativity comes in, though. There will be many different ways to code, it’s open to interpretation.”
Matt pointed out that there is good code and bad code, and that this can lead to variance in the results that you see. Ben White of the Anthony Hall Group said that, often, the hardest thing about learning to code, “is other people’s code”.
Ben Ward of the Clavijo Group told me to “accept the bugs will happen to you, and nothing but care and time will cure them,” while Paul Fretter, Head of CiS, agreed, when he told me the hardest thing is “knowing when to blame the OS, the function, or the library you’re using… and when to admit the problem is in your own code.”
Nicola Soranzo of the Davey Group said that the hardest thing then is “debugging, i.e. how to find what’s wrong in your program!”
Another aspect is what you’re working with. Year in Industry student Will Glynn said that “computers don’t ‘think’ the same way humans do,” while PhD student Calum Raine agreed, telling us that “the hardest thing is learning how to intelligently think with complete unintelligence. The computer is very fast but entirely stupid and needs to be meticulously spoonfed.”
Ryan Joynson, another postdoc in the Anthony Hall Group, rounded us off with some sound advice, when he said, “no matter what you’ve learnt, there’s probably a faster way to do what you’ve done.”