Eccles & Toad home ~ blog ~ perl ~ projects ~ employ me
You are here: home > blog > 2007

Blogs 2007

(RSS)

2007/12/19 - Send-a-Test Launched

I've just launched http://www.send-a-test.com/. This is a site that should make sending out pre-interview tests much easier. It takes care of getting the test to the candidate, timing them whilst they do it and then storing their answers when they are done.

As with most things I did this to scratch an itch.

Recently I was being recruited - which means that your CV goes onto lots of websites and you get lots of calls. Often once the recruiter has checked that you are right for the job they'll want to send you a test to check that you know what you're doing.

This is where the pain would start. Their problem is that they want to time how long it takes for you to do the test, understandably. To do this they email it to you, you start work straight away, do the test and email back the answers. Compare the times on the two emails and you have how long it took to do the test.

This is great, as long as you can start your test during the recruiter's office hours, which if you already have a job you almost certainly can't. It also wastes time with all the arranging of times, and follow up calls to check that you've received the test by email etc.

The solution was simple - create a website that the recruiter saves the test on. When they want someone to do the test they tell the site and it sends an email to the candidate with a link in. The candidate follows the link and gets all the instructions they need for the test, and when they are ready they download the test file to start. When done they upload the answers and the timer stops.

And that is exactly what http://www.send-a-test.com/ does - enjoy!

2007/01/26 - Know your market

Right - I'm sitting on the bus in traffic and to my right is a father and his three young children. As a bus in traffic is deadly dull they are playing a game where one person says a list of words and then someone else makes up a story that has all the words in it.

So the father says: "canoe, tea cup, fire extinguisher, astronaut and the biggest thing in the world".

Before the little boy has even started talking I came up with: "There is an astronaut orbiting the biggest thing in the world who wants to relax so he makes some tea with water from a fire extinguisher, pours it into his favorite tea cup and day dreams about his canoe".

Feeling quite smug that I had completed the task quickly and accurately I was curious to see if the boy would do as well. Needless to say he thrashed me.

His story started off promisingly with an astronaut who was hungry. He decided to eat the biggest thing in the world. Having eaten this he then went to drink some juice, but couldn't find a glass and so used his tea cup instead. At the end it turns out that all of this happens in his canoe. He forgot about the fire extinguisher, but fixed that by being attacked by a fire breathing dragon.

The whole story was delivered with hand waving, facial expressions, giggles and lots of heckling from the others.

The reason he thrashed me was that they went on playing the game, whereas my contribution would have been so breathtakingly boring that it would have been the last round and children would have sat in silence contemplating the misery that is the daily commute.

The aim of the game was not to use all the words in as few words as possible. It was to keep the others entertained. He did that.

2007/01/24 - Build code like you would pack a garage.

At my current job I am frustrated at how the code is being built. In order to explain it I came up with this analogy about packing a garage:

Say you have a big pile of stuff that you need to store. You rent a garage and start to fill it, putting things on the floor and stacking other things on top where they fit best. Eventually you have filled the garage with all the stuff and you close the door. Everything just fits so there is no wasted space. Job done.

The other way to do it would be to rent slightly bigger garage and install some proper storage shelves. You'd also get some boxes and marker pens and go through all the stuff and sort it into the right boxes: CD's in one, winter clothes in another. You put similar things near each other - like all the suitcases could be one one shelf. After a while everything is in and you close the door. Job done.

So one method is faster and cheaper, and both achieve the same objective which is to get stuff into the garage. Obviously the 'stuff it in' method is better.

Truth be told the 'stuff it in' method is better for filling the garage, and if that is all you want to do then fine. However if you ever want to get to anything in the garage you will realise that it was a mistake.

You have several problems to deal with. Firstly you can't find anything because there is no order and you have forgotten where you put things. Related things are not stored together so finding the ski boots does not get you closer to the skis. Also once you find something you can't get it out with out disturbing everything else. Finally because everything is so packed in you can't see it all so you can't be sure that there isn't a box at the back getting crushed.

Needless to say this is not the case with a properly stacked garage. Everything is on a shelf so it is easy to get to. Related things are collected in well labeled boxes so they are easy to find. When you find the necessary box you can pull it out without worrying about anything else falling down.

Bringing this back to code you can probably see the parallels. The 'stuff' that needs to go in the garage are the features of your code. Poorly written code is not well organized. All the functional code was just packed in as and when it was needed so it is not possible to easily find anything. Related bits of code end up in different files. There is lots of 'action at a distance' and plenty of side effects. Fixing or changing one bit of code can cause another to fail, seemingly for no reason, and this failure way not be obvious for some time.

Another parallel is that a tidy garage stays tidy because anything out of place looks messy and wrong. However once there is a little mess more mess quickly builds up and you start to lose the benefits of a tidy garage.

Code goes downhill in the same way. Regardless of how hard you try to keep it tidy if there is someone on your team who litters then it starts to bring everything down. Soon you stop being a coder and start being a cleaner. Or you leave it too long and suddenly you realise that it is all a big mess, that the best way to fix it is to take everything out, sort through it and put it back in again. But if a messy garage is not seen as a problem then the cleanup will not last, and you are wasting your time.

If you find yourself in this position I hope this analogy helps you.