“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.

*drip*
…pause…
*drip*
…pause…

I looked over at the sink.

*drip*

Nothing fell from the tap faucet (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.”

(more…)

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.

(more…)

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.

(more…)

As a non-statistician who every now and then has to understand statistical concepts as if they were second nature, illustrative examples are like gold dust to me. I thought I’d share a small yet extreme sample set that I devised to aid me in understanding the difference between the first statistical moment, the mean, and the similar yet potentially wildly contrasting median.

(more…)

What’s New? MUSIC was recently launched, so for those of you who’ve already read about the idea, architecture and technology stack, you can go straight to the post-launch results and conclusions. For everyone else though…

At the beginning of the year I posed a conundrum on Twitter. I wanted some way to make sure I never missed out on a new release by one of the many bands I like. In the end, I had to build it myself. This would be my first website ever after a professional lifetime of enterprise code and it started something that would take up a large part of my free time for the next 9 months. I created and launched the website What’s New? MUSIC. Here is my journey.

The tweet – which no-one replied to – that started it all

(more…)

At the beginning of the year I posed a conundrum on Twitter. I wanted some way to make sure I never missed out on a new release by one of the many bands I like. In the end, I had to build it myself. This would be my first website ever after a professional lifetime of enterprise code and it started something that would take up a large part of my free time for the next 9 months. I have created the website What’s New? MUSIC. Here is my journey.

The tweet – which no-one replied to – that started it all

(more…)

Dynamic Languages Strike Back – Steve Yegge

A blaze of nepotism from my sister saw me land my first paid contracting gig back in 1998. The company was technologically naïve and it was pure HTML/CSS. The start to a potentially exciting story perhaps, but alas, the summer ended and I went back to finish the last two years of my undergraduate degree in computer science and – after a brief stint in academia – I ended up as a salaried server and desktop-side coder for some big global software companies.

A year or so ago I might still have stood alongside Stanford graduates and asked Steve Yegge, “Yeah, what is it with all these unnecessary languages?” But more than just being blinkered against things like Scheme, I was part of the big machinery in the corporate software development world, busily building large, complex codebases that will likely be supported by legacy specialists in years to come – today’s version of the COBOL programmer of the 1980s.

But though I left the office today with three instances of Visual Studio open, three C# solutions that co-operate to produce some of the DLLs required for one of my companies’ products, I’m definitely not the same programmer I was a year ago.

(more…)

I have failed. Earlier this spring when I rejoined the world of the working I pledged to continue the blog I started over a year ago but with, naturally, a less demanding post frequency. But even my plan to produce one per month seems to have slipped by for the month of September.

I have excuses around a few packed social weeks, but I suppose ultimately it comes down to a matter of priorities. I’ve been working on my projects but not at the required pace. There are a couple of ways to look at this. I could view it as I described above: failure. I have goals I want to keep to and I didn’t put in enough effort after realising my initial estimates were off.

Or I could view it as a minor hindrance. Things didn’t go quite as I’d hoped but it’s no real disaster, the posts and my projects will be released a little later than initially hoped but I’d rather that than miss out on weddings, visits from friends and The Fringe.

(more…)

It’s that exciting time of year again. I know, I know, London 2012 and all that but who really wants to watch amateur archers and beginner judo students when the English Premier League is about to restart?

For those who weren’t here last year, I announced in an overly technical way an area of artificial intelligence called constraint programming. Never mind all that though: here is an Excel spreadsheet that will help you improve your Fantasy Football League team for the Official Premier League version.

EDIT: I’ve also added a Yahoo! version but beware, that problem has greatly skewed player prices – a bit of manual culling is needed to the high-priced players to get it to find a solution this century. The best value technique still finds solutions quickly but some formations work better than others.

(more…)