red-library.com

Something struck me today whilst reading a tweet from a developer I consider to be on top of their game. They had an issue with a framework doing something unexpected and annoying, and after hours of trying to get around it, eventually they had to get a solution. They posted a tweet asking if anyone knew the solution as they suspected it would just be something really simple which they didn’t know.

Helpfully someone responded and pointed them in the right direction, but only then did this developer actually bother to look at the documentation themselves. The solution was simple and was fully documented – so why not check it out first to alleviate all that bother?

While this is a good example of the value of Twitter, I can’t help but feel that the documentation should always be your first port of call. I don’t ask someone until I’ve checked out the documentation for myself. Chances are the docs will have the answer, along with a whole lot of other info which could really help you out. At least that is what I find!

So, next time you have a problem – look it up! Chances are you’ll get more than you asked for.

Sanity. Its an important thing. It stops you shouting at passing cars in the street or smothering yourself in ice cream before hurling yourself down a supermarket aisle. That is why jQuery is so important to me – I value my sanity. Also, Tesco value their stock of Ben & Jerry’s.

1. Cross-browser differences with JavaScript can be largely eliminated. No need to re-code that bit of animation so it works in IE 6 as well as Firefox 3.5, jQuery will handle it all for you. Don’t get me started on the ‘for…in’ construct and how ‘.each()’ saves the day every time.
2. Everything you want to do is even more simple than you can believe. What used to take over a dozen lines of code can usually be expressed in one line.
3. Chaining. It may rile some programmers up, but when you can chain function calls together on a single object, you end up with cleaner, more readable and more semantic code.
4. Plug-ins. There are so many of them around now that just about anything you want to do has already been done at least once. Sure, the jQuery site could use some improvements when it comes to searching the docs or plugin database, but it is all there for you.
5. Light weight. In comparison to MooTools, jQuery is quite hefty. But when you compare it to nearly every other JavaScript framework out there, you will see that when minified, the library is small enough to justify its addition to your code base. Every byte transmitted and processed delays the user seeing your website, so you have to balance the good against the bad!

These are my reasons, what are yours?

I was thinking about how each and every programmer likes to play around with things for no real reason other than for the fun of it. Little scripts which help you do a job maybe, or just something to pass the time (like playing with a new web API). Some people do it more than others – after all, if you code all day then maybe you wont feel like doing it all night too!

The question is, though, what do you hack with? Which languages do you like to use, which tools and so on. I was thinking about this since by day I’m usually a web programmer, dealing with stuff like PHP, Perl and even VB or C# on occasion. However, when I’m working on stuff for myself, I tend to use Python. If I’m feeling adventurous I may dabble in a bit of C or C++!

Tools are a different matter, though. Usually a text editor is enough when you’re quickly hacking together some code – the extra weight of a fully-fledged IDE can get in the way and make things a bit harder. How about you?

Lastly, which systems do you use? I have a pretty powerful desktop PC at home, but I also have a netbook. Usually it is the netbook which I will do my hacking on, while watching a DVD or listening to some music. I don’t know about you, but after sitting in an big office chair all day in front of monitors and a desktop whirring away beneath my desk, I kind of appreciate the freedom and ease of use of a small laptop!

Now I’ll throw the question out to all of you – what do you use?

We’ve all been there. You turn up to an interview for a job, where most of your work will be in [insert programming language here]. There is a code test. You think to yourself, “I damn well hope I remember enough!”. Then it either turns in to either a cakewalk or something approximating Dante’s Inferno.

Are code tests actually worth it? In my eyes, all they do is separate those who have got through to the interview by blagging and/or winging it from those who genuinely know the language. They don’t really test a candidate’s coding ability, all it shows is how fast they can write a solution to a problem, however simple or complex it is.

You can see I think ‘no’ is the right answer here. Well, you’d be kind of right. I have seen so many code tests which would make even the most experienced developer cringe at first glance which are really quite simple, and others which appear to be easy but will get you escorted off the premises quicker than you can say “exponential time algorithm”.

The real question is what do you value from your development team. Do you value a quick solution to a problem you already know the answer to? Or do you value someone who can look at a problem, decompose it into its component chunks and attack it in a methodical way, whilst maybe knowing nothing about the libraries they may need to use or the techniques which are common for such a problem? I would take the second any day – development is rarely a one-size-fits-all business. Sure, you may have done task X for many clients, but I bet their infrastructure, systems and background varied enough to make the code look (and act) completely different from case to case.

Maybe I’m barking up the wrong tree here, but when you’re asking a prospective employee if they can write a quicksort algorithm in Java within 30 minutes all you are doing is replicating their university days. Quicksort implementations are ten-a-penny, and matter not in the real world (since you’d use a tried-and-tested library function anyway). In this business, it is the unknown which causes the problems, not the things which have been done by every programmer at least once in their life.

In short, code tests are a double edged sword. You’re ensuring that your interviewee actually knows what they claim to know, and that they can work under a certain amount of pressure. However, you could write off that new university graduate who lives for development just because they couldn’t implement an arbitrary algorithm within a time frame. In real life, you would give that person access to all the source material they could ever need and they would get the job done, improving their abilities. All you’re doing in the interview is testing if they remember that 9am Data Structures and Algorithms class they took in their first year at university.

After all, isn’t it all about improvement on the job?