programming

There are 8 posts tagged programming (this is page 1 of 1).

an afternoon with Don Knuth

It’s not often you get the chance to spend an afternoon with probably the most famous hacker/developer/computer scientist the world has ever seen. However, last week I got the chance to do just that when myself and three colleagues had the great fortune to spend some time with Don Knuth.

For the uninformed IT “professionals” that have never heard of Don Knuth this is the guy that brought to us the idea of analysis of algorithms and asymptotic notation (big-O notation), the Knuth-Morris-Pratt string searching algorithm, the Art of Computer Programming book series, the list goes on. However, he is not only an “algorithm’s guy”, he also developed the Tex typesetting system and the METAFONT language used to define vector fonts. So basically he is the most famous computing guy out there.

Knuth is a surprisingly easy guy to talk to. Sure, he can really lose you pretty quickly in a conversation, but he also has some great insights.

Our conversations tended to centre around stuff to do with algorithms. His next volume of the Art of Computer Programming will likely focus on constraint satisfaction problems and satisfiability problems – the former being something I worked on myself in the not to distant past. I asked what he thought was a good algorithm to teach people and he said he thought the biparite graph matching algorithm was a nice one in terms of beauty (he did mention another which escapes me now). Not everyone will find the algorithms stuff that interesting (you should!) but his view of beauty is maybe something more universal.

He also expressed a love for writing code, he said that when he gets up in the morning he thinks about writing code and misses it on days when he doesn’t get the chance. That is pretty cool by me and sits in stark contrast to many academics. I got the feeling that he wasn’t too keen on the “apps” developers as he called them. My guess is that his thoughts lie with more meaningful problems than fart apps – however people download them so who are we to say. Still, there was definitely some lamenting going on about the fact that people use software without ever trying to understand what the software is actually doing. That is, have at least a high-level view of the data structures and algorithms used that make the said piece of software useful. Having this kind of understanding allows you to select the right tools for the job. In my experience people that tend to have this knowledge and understanding are far better developers and is likely why Google, Microsoft, Facebook et al. try to attract developers with this kind of knowledge.

He was telling us that he watched The Social Network on the way over on the plane. He said he thought it was great how Mark Zuckerberg was also someone who just liked building stuff like him – this was something Zuckerberg said himself at Startup School 2010. What is even cooler is Mark Zuckerberg actually sent him a copy of the latest Art of Computer Programming book and asked him if he would sign it for him.

So Don Knuth himself will have long forgotten who I am but at least I will be able to recollect years down the line this encounter with a computing genius.

programming just isn’t that hard!

Programmers at times can take themselves, and their abilities, a little too seriously. The fact is that programming, in general, is just not that difficult. Sure, there are parts of it that are tricky but, at the risk of over generalising, the capabilities required by your run of the mill programmer are not that high. Are you sure I hear you say?

Well plucking figures right out the air I’d say that around 90% of applications involve a simple CRUD model. So what we are essentially doing is gathering data, processing data, and writing this data to the database. Two-thirds of this process is pretty simple, i.e. gathering the data and writing it to the database, this leaves the possibilities for hardness in the processing data phase.

Again in most situations the processing of data is pretty simple with no complex db manipulation or algorithmic mind games. Consider your typical web application for example. The processing of data is minimal, with little to no algorithmic work involved at all – I mean with Twitter there is literally nothing to do. Google on the other hand has lots to do: it has to make those search results shine. This is not to say that developing Twitter is simple, as the scaling issues will make your head hurt. However, scaling problems are only going to affect a very very small number of sites out there, but due to their ubiquity they are the ones we hear most about.

If all this programming nonsense is so easy then surely it’s difficult to make bad software?

Nope. The fact is that the only people who care what the code looks like are other developers. The code underneath could be shitter than an incredibly shitty shit and the end user wouldn’t know. As long as it carries out the task that they require the software to do, in a reasonably efficient and user friendly way, no one really cares. Oh apart from other developers.

Obviously nice structured code, that is easy to understand, free of bugs, and a maintenance dream is a good building block. However, it is by no means a guarantee that you are on to a winner. Marketing, user experience and coolness are all equally important, actually, they are probably much more important. I obviously can’t say for sure but I would imagine there are plenty of successful software products that are badly written but tick these boxes – maybe even most successful products, as they are free from the burden of the studious programmer.

So, essentially what I’m trying to say is that despite programming not being that difficult there are many other more important factors that contribute to the success of a software product. Many software products do their job, but the one that will be successful is the one that does it well.

All this is not to say that programming well is not important. On the contrary, it’s important to other developers who you work with and that is not to be underestimated. This is a topic for discussion another time though!

Finally, for those non-programmers out there, don’t start shouting “If it’s so simple why does it take so long”? Well just because something is easy it does mean there are not lots of easy things to do. I mean, hammering a nail into a piece of wood is pretty simple, right? But if I asked you to hammer 10 million nails into a bit of wood it would take you a long time. Remember this marketers and project managers.

the future of the humble programmer

Back in ancient times and right up until relatively recently (mid 1400s) scribes were used to copy important documents for kings, queens and other nobility.  It’s hard to imagine that most people couldn’t write back then, and I suspect (but can’t find any hard facts) that many many people still had difficulties writing until the beginning of the 1900s.

However, the job of a scribe became almost redundant overnight with the invention of moveable type. At this point we began to see a power shift, as documents were easily copied and translated, and distributed to the masses.  Obviously there was still the hurdle of learning to read, but now many important documents were available to more than just a handful of people – prior to this reading such documents was limited to the nobility and the clergy.

Moveable type was the most popular form of distributing documents and information right up to the modern day. However, with the advent of computers and the internet, this has changed for good.

Today we find less and less people reading books, but instead we mindfully overdose ourselves on blogs and social networking sites.  This information exchange only serves to benefit each and every one of us, as now we can observe opinions that are not dependent on the views of an editor whom we share little to nothing in common.

It’s easy to see how jobs have transformed over the centuries, once coveted jobs are now in the hands of “amateurs”; who to their credit provide content that is more pertinent to the interested party.  So where does this leave us as software developers?  How will our roles stand up with the future in mind?

If we think back to what I said earlier, about how not too long ago most people couldn’t even write, and consider that the computer was out of reach, both financially and physically, of most people, but now both these things are the norm in society.  So just as everyone learned to write, is everyone going to learn to program?

OK, you may be thinking that a field like mathematics has been around a long long time, and that not everyone is competent in even basic mathematics.  However, let’s face facts, a general programming task is nowhere near a difficult as even high-school level mathematics. That’s not to say there does not exist difficult computing tasks; in fact I’m hoping to convince you of the opposite.

Is it that crazy to think that one day people will program a computer in the same vein as we read and write English (insert your native tongue here)?  I don’t think so. Programming is not really that difficult (doing it well is as difficult as writing beautifully in English, and that has never stoped people writing, look at me). Just as blogs and the internet pulled down the barrier for each and every one of us to write and be heard, I feel it’s only a matter of time before programming computers becomes something more akin to what many will do in everyday life.

If we look closely the first steps are underway. People are using HTML, CSS and JavaScript as if they were everyday things.  They may be doing them under the veil of certain tools, but the “non-programmers” are programming.  They may not even know they are doing it, and the ability to make more complex applications is only going to get easier.

For example, consider writing a database application for an online bicycle shop using CakePHP (something I have experience of, hence the inclusion). You have to know almost nothing about using a database to create this application. OK, you may say that scaling and optimising these things takes a “professional”, but at the rate we are pushing the technology, this barrier may not be there on 5-10 years time – consider the cloud computing environments as a step in this direction.

What I’m not saying here is that all computing is easy. There are still problems that are difficult to solve and require much much more than simply following a fixed set of instructions. Indeed, this is the domain where us developers must start focusing.

There may be many readers out there that think this is all nonsense and that programming computers is always going to be an elite occupation. Just tell that to the scribes, journalists and the media presenters/organisations, whose occupations have either vanished or are suffering severe contraction. Many of these occupations never seen it coming (or refused to see it coming) and done nothing –  but just remember how quick this actually happened to each group. Do you want to be in the same position?

some thoughts on pair programming

In the last couple of days I have had a chance to do a little bit of pair programming.  In the past I have found myself being a touch sceptical of it all, but predictably I hadn’t actually done much.  So here are some thoughts from my recent experience.

Firstly, I must admit it was only half pair programming, in the sense that I was only an observer and not a driver.

I would say that my biggest concern with pair programming is I found it hard to believe that there would not be a drop in overall productivity with two people concentrating on the same task.  However, I’m beginning to think that, counter intuitively, this may not be the case, but it also depends on the task.

For example, when two people have a completely different skill sets and both skill sets are required for the job.  In my case, I knew literally nothing about the programming language we were developing in.  However, I had a fair amount of knowledge with regards to the “API” we were coding to (fair amount meaning I wrote it!).  As a result of this I knew what we were trying to achieve but just not how to achieve it.  In this situation the pair programming seem to go very well and I would suspect that the functionality was added to the code twice as fast as it would have been if any one of us had to do it alone. 

So what are the other benefits?  You generally always learn something when pairing up –   even if you have more experience than the other person.  For me, I learned that you could place a hash (#) in front of the number to specify the ascii value for a character, for example, #9 is a tab character.  This had passed me by for some reason, I mean I knew in HTML you could do stuff like &#33 to obtain an !, but I had just never thought about what it meant.  Now I understand!  You also get the benefits of seeing how someone else thinks, and you can learn a lot from that.  You might also gain “tips” for navigating the environment or valuable tools being used.

There are some downsides too.  When I was doing it the last couple of days I never noticed too many, but I can certainly imagine thinks like different personalities, strong opinions, and reluctance to participate, affecting things quite drastically. Here are a few that I think may annoy the driver, but as I wasn’t driving I don’t really know for sure.

First, as a navigator you sometimes notice tiny things like misspelt names, missed semi-colons, etc, and at the start I pointed these out pretty quickly.  However, I then thought to myself, maybe the person has noticed these things and was going to go back and change them when they finished typing the line.  So I just tried to stop myself interrupting too much – as I suspect someone who constantly points things out can get pretty annoying.  I also had to stop myself preaching my coding habits that don’t make a difference to functionality, that was harder though, as I pretty much have an opinion on just about everything 🙂 .  As for navigating, I’m sure someone that completely ignored your suggestions and coded away regardless would be extremely annoying.

I’m not sure that pair programming is THE definitive development strategy.  I’m certain that someone sitting over you while you are writing some form of input parser in which you are just running through the motions is almost pointless.  Also, when you have to think really hard about something, whether it be debugging a hard problem or some complex algorithm, someone interjecting all the time would be extremely off-putting.

So to sum up: pair programming definitely has advantages and with some careful planning it can be used to improve a projects quality, cost and time to launch.

some top tips to piss off your colleagues

Every day you stumble into work and go about your daily routine.   You’re reasonably sure that you’re a model work colleague and everyone likes you.  But this is pretty boring right?  So from this day forward you decide to make other people’s life a misery.  Here are a few handy tips guaranteed to help you with this.

(A short note: in case confusion ensues the tone of this article is meant to be somewhat tongue-in-cheek! And please let me know of any annoyances that I may have missed in the comments 🙂 )

  1. Constantly receive incoming phone calls: to be honest it doesn’t even have to be constant, just enough to make it appear constant to those sitting around you. I have no real problems with people talking around me or even playing music out loud (as long as it’s not all the time), but the torture of constantly hearing a one-sided conversation is exasperating.  For maximum effect, I suggest you have a really bad ringtone, and make outgoing calls with regular frequency as well. 
  2. Take that chicken curry back to your desk so everyone can smell it at lunchtime: I can’t work out whether this is the thing that annoys me most. There is nothing worse than sitting down to do some work and some dude slaps his lunch down on the table 2 feet away. OK, eating certain things at your desk is fine, but there are others that should just be outright banned, and it doesn’t take a genius to figure out if you are eating one of those things. Or maybe it does! My suggestion to obtain the maximum effect with this one is to leave it sitting on your desk for a bit to “cool down” prior to eating it.
  3. Constantly ask people the same questions (or make the same mistakes): I know this one affects more than just me – I will elaborate. Imagine sitting next to someone who constantly asks you the same questions about how to do something. OK, at first they were new and you answered with glee, but it’s been two years since this person started in the job and they still ask you how to the most simple tasks (like how do you build the software). Not only that but when you tell them they always experience a problem, the same problem, and ask you why it’s not working. This is guaranteed to make people start muttering under your breath at you as soon as their name leaves your mouth. Note: This works best if you don’t say their name too loud at first and just lightly let it drift off your lips. This will give the “pink panther effect” where they will gradually think they are going insane.  Those who cannot learn from history are doomed to repeat it.
  4. Find out the names of new buzz technologies, then constantly suggest the inclusion of such things in your app, especially if they are not relevant: remember you don’t need to know what the new technology does or the advantages/disadvantages of it – in fact it’s better that you don’t understand what they are, this heightens the effect. For example, say you want to use AJAX in your legacy desktop COBOL application. To make this even more powerful don’t listen to people when they try to tell you that it’s not relevant, just state “it is” and then bring it up again in the next meeting.
  5. If you’re a manager, have favourites: this is just soooo cool to do if you are a manager.  There is literally no better way to piss off those people who are not on your favourites list.  If you want people to really talk about you, this is the one to go for.  For added value, place all those that you don’t really like in a maintenance team, fixing all those pesky bugs that your favourites create.
  6. If you’re not a manager, and your manager has a favourites list, try to be on it:  everyone hates a brown nose and this will easily get you straight to number one spot of your colleagues diatribe without a shadow of a doubt.  For this to be especially effective you have to be on that list because you know nothing, but are not going to let that get in the way of your career.  Once you are on it though, try to do things that you know will annoy other people, but your boss will let you away with because you are his favourite, e.g. show up late for stuff.
  7. Keep meetings running on longer than they should: if you think a meeting is nearing its conclusion, try and extend it for at least another 30 minutes – you can do so by going over the same points that were discussed in the previous hour of the meeting.
  8. If you’re a manager, send programmers on courses they will really really hate: one course that will probably do the trick is communication skills.  Ensure that the course has lots of role playing, and drops the average programmer waaaaaay out their comfort zone. To really rub it in, make them write a report about it when they get back.  Then when they give you the report, make it obvious that you are never going to read it anyway.
  9. Make people feel completely uncomfortable if they have to ask you a question: the key to this is to make them feel STUPID.  Some possible tips with this are to sigh loudly when they get to your desk; don’t make eye contact when they speak to you, just keep typing and looking at your screen while talking to them; speak to them as condescendingly as possible, phrases such as “it’s obvious!” and “everyone knows that!”, normally hit the mark; and finally show disdain toward any ideas they come up with.  Also, never finish the conversation by confirming that they have actually understood what you have just said, just sit in silence and see how long it takes for them to realise the conversation is over.  Essentially you are trying to be as unapproachable as possible.
  10. Occupy other people’s space: just start to gradually leave pieces of paper and books on the person’s desk next to you.  Don’t limit it to objects though, try to put yourself in their space as well.  Leaving empty mouldy coffee cups, and half eaten food will likely yield a reaction, just don’t let this stop you.

the secrets to obtaining a happy programmer

The ideal working environment for a programmer is an topic which has received considerable attention. What we (programmers) normally idolise after are, amongst other things, (multiple) large monitors, Herman Miller Aeron chairs, private offices, break-out rooms, and, of course, the best tools for the job. Joel Spolsky, the Godfather of programmer satisfaction, went even further and gave us the Joel Test for assessing a prospective employer. However, are the above all that it takes for programming nirvana? Probably not.

First up, I would love to experience an environment where each and every one of the things mentioned above was in place. However, in my career so far, I have yet to work in an environment where these things have been par for the course, and maybe I would be content with such a work environment. I’m pretty sure I wouldn’t though. Not because these things aren’t good but there is a vital ingredient that can make these things irrelevant.

So what is this ingredient? Well it’s FUN, or lack of it. Yes a fun workplace! I’m sure there will be those out there that think work isn’t supposed to be fun, well ask yourself why. Fun doesn’t necessarily mean that no work gets done – the contrary in fact. It’s a place where like minds can sit and create and innovate about things they find interesting. Now here is our first problem.

Essentially fun is the environment combined with the people. However, all too often we find ourselves in an environment where the people are not like minded. What surprises me most is that in an office full of software developers only a handful (or less) may be genuinely interested in software development. I’m not sure if I have just worked in the wrong places – however friends have confirmed a similar problem. It’s not simply that you couldn’t sit and talk to certain individuals about software development, it’s that you pretty much had difficulty talking about anything. It was often like talking to a baked potato.

For me this not just a job, software is one of my top three interests (along with music and cycling, for those who are nosey 😉 ). Wouldn’t it be nice if an employer could respect this – I’m not saying they all don’t, but most don’t, it makes it easy to see why Google attach such an importance to their culture.

All this is not to say that I think we should all be the same, it may be the case that you have to turn good people away because they simply don’t fit your culture. I think the culture is that important. This has been shown in the past by the likes of Richard Branson whose music empire started by providing an environment (in essence a community) where both the employee and consumer found it fun to gather in his record shops. Certain universities have also found this valuable over the years.

So essential we can have all the goodies we like, but unless we are working with people that are Smart and Gets Thing Done (or preferably Done and Gets Things Smart), and fit our culture, then maybe we are never going to reach our programming nirvana.

7 ways to write beautiful code

I’ve noticed that the developer and designer community appear to be obsessed with lists. Is this for a reason that I have somehow missed? For example, over at dZone, 2 out of the top 3 most popular articles are lists: 15 CSS Tricks That Must be Learned and 10 Dirty Little Web Development Tricks – incidentally I liked both articles so I seem to have this obsession myself. OK this is not that many but hey I’ve seen loads of lists elsewhere. Anyway, I thought I would embrace this culture to feed my own addiction and I have detailed 7 (I was only going to do 5, and 6 was out as it’s not prime 😉 ) ways to write beautiful code.

First things first here, I’m talking about pure aesthetics, nothing else. As I have said previously, good code starts by being something other people find easy to read. In fact, Jeff Attwood had a blog post comparing coding to writing citing several sources. I urge you to take a look.

Anyway on to my list.

  1. Return from if statements as quickly as possible.

    For example, consider the following JavaScript function, this just looks horrific:

    1
2
3
4
5
6
7
8
9
10
11
12
13

    function findShape(flags, point, attribute, list) {
    if(!findShapePoints(flags, point, attribute)) {
        if(!doFindShapePoints(flags, point, attribute)) {
            if(!findInShape(flags, point, attribute)) {
                if(!findFromGuide(flags,point) {
                    if(list.count() > 0 && flags == 1) {
                          doSomething();
                    }
                }
            }
       }
    }   
 }

    Instead we can change the above to the following:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

    function findShape(flags, point, attribute, list) {
    if(findShapePoints(flags, point, attribute)) {
        return;
    }
 
    if(doFindShapePoints(flags, point, attribute)) {
        return;
    }
 
    if(findInShape(flags, point, attribute)) { 
        return;
    }
 
    if(findFromGuide(flags,point) {
        return;
    }
 
    if (!(list.count() > 0 && flags == 1)) {
        return;
    }
 
    doSomething();
 
}

    You probably wouldn’t even want a function like the second one, too much going on (see point 7), but it illustrates exiting as soon as you can from an if statement. The same can be said about avoiding unnecessary else statements.

  2. Don’t use an if statement when all you simply want to do is return the boolean from the condition of the if.

    Once again an example will better illustrate:

    1
2
3
4
5
6
7
8

    function isStringEmpty(str){
    if(str === "") { 
        return true;
    }
    else {
        return false;
    }
}

    Just remove the if statement completely:

    1
2
3

    function isStringEmpty(str){
    return (str === "");
}
  3. Please use whitespace it’s free!

    You wouldn’t believe the amount of people that just don’t use whitespace – you would think there was a tax associated with using it. Again another example and I hesitate to say this but this is from real live code (as was the first example), all I have done is change the programming language and some function names – to protect the guilty:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

    function getSomeAngle() {
    // Some code here then
    radAngle1 = Math.atan(slope(center, point1));
    radAngle2 = Math.atan(slope(center, point2));
    firstAngle = getStartAngle(radAngle1, point1, center);
    secondAngle = getStartAngle(radAngle2, point2, center);
    radAngle1 = degreesToRadians(firstAngle);
    radAngle2 = degreesToRadians(secondAngle);
    baseRadius = distance(point, center);
    radius = baseRadius + (lines * y);
    p1["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]);
    p1["y"] = roundValue(radius * Math.sin(radAngle1) + center["y"]);
    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
    // Now some more code
}

    I mean I won’t bother putting an example of how it should be – it should just be sooo bloody obvious. That said, I see code like this ALL the time and so certain people do not find it that easy to judge how to use whitespace. Screw it, for them I will inject some whitespace into the example and it’s shown below.

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

    function getSomeAngle() {
    // Some code here then
    radAngle1 = Math.atan(slope(center, point1));
    radAngle2 = Math.atan(slope(center, point2));
 
    firstAngle = getStartAngle(radAngle1, point1, center);
    secondAngle = getStartAngle(radAngle2, point2, center);
 
    radAngle1 = degreesToRadians(firstAngle);
    radAngle2 = degreesToRadians(secondAngle);
 
    baseRadius = distance(point, center);
    radius = baseRadius + (lines * y);
 
    p1["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]);
    p1["y"] = roundValue(radius * Math.sin(radAngle1) + center["y"]);
 
    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
    // Now some more code
}
  4. Don’t have useless comments:

    This one can get quite irritating. Don’t point out the obvious in comments. In the example below everyone can see that we’re getting the students id, there is no need to point it out.

    1
2
3
4
5
6
7
8
9
10
11
12
13

    function existsStudent(id, list) {
    for(i = 0; i < list.length; i++) {
       student = list[i];
 
       // Get the student's id
       thisId = student.getId();
 
       if(thisId === id) {
           return true;
       }
    }
    return false;   
}
  5. Don’t leave code that has been commented out in the source file, delete it.

    If you are using version control, which hopefully you are – if not why not! – then you can always get that code back easily by reverting to a previous version. There is nothing more off putting when looking through code and seeing a large commented out block of code. Something like below or even a large comment block within a function itself.

    1
2
3
4
5
6

    //function thisReallyHandyFunction() {
//      someMagic();
//      someMoreMagic();
//      magicNumber = evenMoreMagic();
//      return magicNumber;
//}
  6. Don’t have overly long lines.

    There is nothing worse than when you look at code that has lines that go on forever – especially with sample code on the internet. The number of times I see this and go ahhhhhhhhhh (I’ll switch to Java for this, as generics makes this particularly easy to do):

    1
2
3
4
5
6

    public static EnumMap<Category, IntPair> getGroupCategoryDistribution(EnumMap<Category, Integer> sizes, int groups) {
        EnumMap<Category, IntPair> categoryGroupCounts = new EnumMap<Category,IntPair>(Category.class);
 
        for(Category cat : Category.values()) {
            categoryGroupCounts.put(cat, getCategoryDistribution(sizes.get(cat), groups));
        }

    I’m not suggesting the 70 characters width that you had to stick to on old Unix terminals but a sensible limit like say 120 characters makes things a little easier. Obviously if you are putting sample code on the internet and you have it within a fixed width container, make it easier for people to read by actually having it fit in the container.

  7. Don’t have too many lines within a function/method.

    Believe it or not a few years ago now an old work colleague exclaimed that Visual C++ was “shit” as it didn’t allow you to have a method with more than 10,000 lines. I kid you not – well ok I can’t remember the exact number of lines but it was huge. I still see this time and time again where a function/method is at least 50 lines long. Can anyone tell me this is easy to follow? Not only that but it normally forms part of an if statement that you can never find the enclosing block because you are scrolling. To me anything over 30-35 lines is pretty hard to follow and requires scrolling. My recommendation is if it’s more than 10-15 lines consider splitting it up.

This is by no means an exhaustive list and I could have gone on longer – in fact my abolish the switch statement motto would have been number 8 if I had not already mentioned it before. However, it has to end somewhere but feel free to state your own annoyances and maybe I can update the post with some more.

Over and out.

programmer rehab

Faced with the task of learning a new programming language (and its associated libraries) I was left considering what is the best way to do this effectively. I will now describe what I do, and by no means am I advocating its use, be aware of the hidden dangers that lie with it.

My first port of call is normally to try and see if some book on Amazon is the overwhelming favourite of the masses and purchase it. I must admit though, I often get the book, flick through it, and then probably ignore just about everything in it. I do however normally remember the name of the book and the author and when someone asks me if there is a book I recommend I spout this information to them. So the moral of this is probably never to ask me to recommend a book as I’m probably grossly misinformed about what is actually in it.

Anyway, in the first week of learning the language I will try to map the syntax of the language to concepts I know, i.e. object-orientation. This probably presents the first problem: what if the language is not really object-oriented? My solution, make it object-oriented 🙂 This can prove tiresome in certain languages, and JavaScript in particular. However I’m not one for letting this type of hurdle get in the way, and tend to find a way to do this (with JavaScript this was the module pattern described by Douglas Crockford). By the second week I’m normally getting pissed off with my lack of understanding of the language’s features. I think this in part stems from the fact that my style of coding appears to be a copy-paste based system. What I mean by this is that quite often at the start I won’t even bother learning how to say define a class – I will find it out once then just copy-paste the class definition in from another class and change the name. A similar process is then used for other language features (I must point out I’m not copy-pasting the code itself though, that’s just waaay too 80’s). So those first couple of classes and library calls can be like kicking smoking the crack pipe.

After this initial push though, it tends to get easier, I replace the crack induced cold turkey with a slightly more sociable nicotine based habit, but experience constant irritation at the need to stand out in the cold street whenever I want to spark up in public. At this stage I try to abstract most things away from the language itself and think more about how I can isolate change. In other words I tend to have the thought process where I ask myself, if someone asked me to change a requirement, how can I do it with just a change to one line; oh and preferably that one line I would have to change is at the top of the file so I don’t have to search through everything to find it. My motto is that not everyone cares enough to want to learn how something works and is happy if the process is simple and easy. Me, I prefer to waste a mountain of time trying to figure out every detail of how the code fits together – I really need to give up that pursuit, rehab or something. So at this point I start to trace into every language feature, not happy with it just working – tantamount to starting chain smoking. If I get through this stage then I will normally stick with the language, many however have fallen by the wayside after two weeks. More so learning specific frameworks though, as you start thinking “God I could do this far easier if I was writing ALL the code myself”. Remember if you get these thoughts they are normally bullshit though, try to ignore them, as you ARE wrong, you just don’t know it. It’s your mind trying to trick you out of a little hard work. All you will be is a hopeless quiter!

So only after I’ve kicked the crack pipe by weeding myself on to ciggies, and then developed a massive chain smoking habit, do I get the moment of enlightenment where I dump the ciggies and tag myself clean of any irritants (well apart from all those people who tell you that you have learned the wrong language, who all should go get a life). At this point I still occasionally use my copy-paste system described above but it’s becoming easier.

As I said at the beginning of this post I’m not sure this is the best way to go about this process. The main problem that I see is that I don’t learn all the language specific features (maybe this is a good thing). In most languages I work with a standard set of ideas that I apply to the specific language. This always leaves me thinking I could get more out of the language if I only pushed the boundaries a little further. For example, I always think that I’m not quite getting as much out of things like closures, lamdas, etc. I use these things but the way people rave about them I feel there must be more to it.

So that’s it. It usually takes me about a month or so to get comfortable with the language. I then use the language exclusively for around six months and then, for whatever reason, have to shift back to an old favourite which I have forgot how to use. So I dust down the crack pipe and seek out the Rizlas and start all over again……