The journey of learning about Computer Science will start by revisiting a simple lesson first encountered by most as a toddler: how to count. Indeed, it’s such an easy skill it’s hard to remember a time when you didn’t know how to do it. But one of the commonly known facts about computers is that everything is done in ones and zeros ie. binary. Just what does that mean though and how is any of this relevant to humans? Well, to understand how a computer works, you have to be able to work things out like they do. The first step is learning to count like them.
Earlier this year I helped out a random Hacker News commenter. This was covered in a recent blog post where I discussed the trade off between being an expert or a generalist. Realising my GitHub repository was littered with short, generalist introductions and experiments, I concluded that I should add the complex NP-complete constraint solver I had been working on for the past few years – an area in which I had some expertise.
At least, I thought that was the conclusion.
I feel embarrassed to mention this to people but I’m writing a book. It sounds just as pretentious aloud as it does written in text before your eyes.
Being an author isn’t something I ever thought I’d do and I’m not saying now that I’ll definitely see it to the end and publish a book. However, computer science is a subject dear to my heart and I feel constantly aggrieved by how misunderstood and misreported the discipline is by the media, programmers and everyone inbetween (see my complaint with University Challenge). Ultimately, I want to write an accessible book that explains computer science from the very basics, the most fundamental principles. I want everyone to know that computer science has nothing to do with technology and everything to do with, well, I’m about to explain exactly what…
So this is the first in a series of blog posts that will take excerpts from chapters I’m slowly working on from time to time. Feel free to chime in with comments and criticism about my metaphors, explanations, facts i.e. bug reports extremely welcome.
Tags: CompSci in Plain English | Comments Off
It’s that time of year again. Here is the updated Excel Spreadsheet for helping you choose a great Fantasy Football team that obeys all the team, position and budgetary constraints.
Education is changing in a big way. Whether you’re still in the education system or someday going to have children who will, it’s of prime importance you learn just how it’s going to change.
“My Name is Karl, Ich Bin Expert”
I don’t quote Karl Hungus lightly. When I began this blog back in the summer of 2011 it was because I thought I’d let my programming skills go rusty. I wasn’t starting projects and I hadn’t learned any significantly different technology or tools for a few years. Life Beyond Fife existed as a dumping ground for random ideas, quick trials and elaborate “Hello world!” examples.
But I’m not a twenty-three year old entrepreneur living in The Bay trying to get a startup off the ground. However cool it is to launch a micro t1 Amazon EC2 instance with a Node.js module using Heroku (yes, I’m doing Coursera‘s Startup Engineering class) I’m a C# programmer, and an experienced one at that. Recruitment agents don’t get in touch because I’ve tinkered with Iron Python, but because I have years of full development life-cycle experience on the Windows .Net framework. All my interviews begin with, “What’s the difference between a reference and a value type?” and end with “Explain the garbage collection process in .Net” or “How do you create an extension method?” etc.
Does trying out every new technology whim damage the focus needed to pick something and be an expert in it?
“Where is that drip coming from?”
Recently while in the staff kitchen, waiting a few minutes for my mug of tea to properly infuse – yes, I am that British – my absent minded thoughts were distracted by a repeating sound.
I looked over at the sink.
Nothing fell from the
tapfaucet (Ok, I’m British but most of my readers are American). So where is it coming from, I thought? I turned around and moved within the space of the kitchen trying to get a more localised area of where the source sound originated.
It almost certainly seemed to be emanating from the corner where the sink was, but I checked underneath the faucet and it was bone dry. I looked up to the ceiling and there was nothing. Puzzled, I stared intently at the plug hole.
Bingo! There was a build up of water in the complex plug hole that was dripping internally into the drain’s U-bend.
And I felt a wave of relief, picked up my perfectly brewed tea and left the kitchen.
Evolution and Metacognition
But then a thought struck me. If I hadn’t found the source of the noise so easily would I still be in the kitchen now futily searching? Or would I have left with the mystery preying on my mind?
The knowledge of where that sound, that drip, was coming from is completely useless. I could gain absolutely no advantage from knowing its location yet I was compelled to find out and felt satisfied when successful.
Humans have evolved to be curious. Indeed, our desire to know and understand has been instrumental in making us the most dominant species in the world. The greatest trick we learned though is that of meta-reasoning. Not only do we know we have an insatiably curious nature, we understand why.
Control Your Curiosity
So often as programmers we want to solve problems and understand technologies. We thrive on it and it helps us be more effective practitioners of software development. But just as frequently we’re figuratively walking around the kitchen trying to work out where the sound is coming from.
You worked out when that process was getting launched, how to setup a database reporting layer to see the order of server requests, constructed a complex event log filter to see when your app started paging. And after you understood everything you felt better because that’s how we’ve evolved.
Next time you find yourself attacking a problem with gusto because you want to find the answer to something, ask yourself, “Why do I need to know this?” “What would happen if I never found the answer to this problem?” If your answers are, “I don’t really need to, I suppose.” and “It would annoy me.” you have a different problem to address.
Rounding out your existing knowledge and gaining a better understanding of complex systems can be beneficial undertakings. But there is limited time in the world and when your curiosity is driving, it’s picking things on autopilot – not the most pressing or valuable problem. You need to fight evolution. You need to tell yourself that while your body wants you to spend time and energy finding the answer, the answer is of no use to you.
Walk away from the problem and do something more productive. I recommend making a cup of tea.
So often when faced with a programming task, you never truly solve the required problem from scratch. To be completely pedantic you’re not writing processor instructions or even assembler but rather high level programming commands that are compiled or interpreted depending on your language choice. But with more and more tools available today to make the job easier, a lot of the necessary knowledge and skills aren’t so much about how to programmatically break down and solve problems – it’s just as much about knowing how to use all the tools out there.
I love it when I’ve developed with a new technology enough so I “get it”. That feeling is fantastic when it clicks and you understand what it’s there for, how it should be used etc. And like my recent lightbulb moment with jQuery it feels great, but unless you continue to use your skills it’s easy to forget everything you learned. That’s why I keep a good track of my sourcecode when I’m done – something even easier to do these days with GitHub and Gists – because it’s the first port of call when I need to revisit a platform I’m not an expert in.
But how far back is it sensible to go? When should we say, that was interesting and fun but it’s no longer the right way to solve a problem – I should drop that code and learn a new way of doing things if the same problem occurs again. And where does the trade-off sit between performing a task once in a sub-optimal fashion and knowing the best practice method to solve the task multiple times?
This idea came to the fore for me recently when I was presented with a real life problem that I thought I might be able to solve with some coding… but it involved resurrecting Java 1.2 code I wrote as a 19 year old undergraduate student. Read on and make a mental note of when you would have put the keyboard down and said, “No, that’s crazy.”
Recently at work I was confronted by a problem requiring data persistance outside of a database – in this case, a saved parameter project file. Though I’m a convert to the purity and ease of use of JSON, in the land of Enterprise coding, XML is still very much king. Visual Studio provides many tools for not just dealing with XML files but also XSD files: a schema for describing a valid XML source file.
Both while at work in creating configuration files, and at home in parsing Amazon’s RESTful API results returned in XML data, I’ve written code to deserialise XML objects into data structures. I find this is the easiest way to get at the information contained therein – much nicer than, say, searching XDocument objects for the correctly named child at just the right sub-element.
I deemed this be the last time I’d ever hunt around for code reminding me how to do it again. I’d turn my serialisation and deserialisation class into a library and put it on GitHub and also make my first ever NuGet package.
Perhaps the one constant in becoming an expert in any particular craft is to do it regularly – preferably daily. For some disciplines e.g. skydiving and marathon running, this is prohibitive by being expensive or physically extreme. There are countless other more attainable skills, however, that demand only our time.
The purpose of this blog – for me at least – is to provide a place for thoughts on software development in practice and the implementation of ideas. So often it becomes the natural place to trial a new technology but at the heart of every technology is the idea that it was created to solve a problem. If my problem is, “I want to find a way to use technology X”, then I have failed before I have even begun.
Behind every implementation there should be a problem, and if we as coders aren’t solving genuine ones, we quickly become obsolete and left behind. More vital than the technology choices we make, are the problems we choose to solve. Therefore, it’s essential to make sure the muscle that comes up with ideas is getting some exercise every now and then.
With this in mind, a friend and I decided to embark on a joint training regime by coming up with one idea for a problem with a tech solution, every day for a month. Here’s how we got on.