Archive for December, 2012

Should I train as a programmer or learn how to code?

Friday, December 7th, 2012

I live in London, I meet a lot of people, and when you meet people, the default questions always run through to "what do you do / do you like it?”. Increasingly in the last couple of years I’ve had people ask me if they think training as a programmer is a good idea, or how hard it is to get into the industry, and I always end up telling them more or less the same thing

“Do what you love”

Seems simple right? Either way, enough people have asked in enough different mediums that I thought it’d be interesting to share an exchange I had with a friend. She asked me if I thought that it would be an interesting career move worth following up on, and I ended up writing an essay, which I’ve anonymised below. There’s a little bit of my own personal bias’ for frameworks and languages in here (which I actually don’t think is all that important) but the message is consistent.

Without further ceremony…

Should I become a programmer?

First and foremost, I recommend working in programming and development. I absolutely love it, I love what I do and I don’t ever wake up feeling like I don’t want to go to work.

That’s the most important thing. There are loads of jobs, and different types of jobs in development, all of them suited to different types of people who are interested in different types of problems. There are obviously also some really shitty programming jobs (I’ve done two myself) and as such, I’ll be realistic and say that lots of jobs sit somewhere in between.

The day to day really depends on where you’re working and how much autonomy you have, but working in a good organisation, you’ll generally be working in small to medium size teams made up for developers, testers and business / product owners designing and building things. You’ll often work together with other programmers on the same computer to solve problems ("pairing") and generally, if the team is good, it’s a really enjoyable lifestyle.  Obviously the opposite also applies, and if your team is bad / colleagues are tedious you’ll end up with the same kind of irritation as in any other job.

For my part, I feel like I’m getting paid for play-time, I love solving weird and wonderful problems and I work with awesome people. It’s compounded by the fact that I found an amazing place to work that give me the freedom I need to build great things and I know there are other roles out there with a similar mentality and culture.

The industry as a whole is in the middle of a massive skills shortage. Frankly, the last ten years have been terrible for technology in universities in the UK. Tech isn’t cool, and the stigma of the "geeky" subject has kept people out. Those that stayed were often hit by the learning curve when they expected it to all be about playing games. That’s lead to two things really, a huge shortage of talent and people that a really interested, and a loud elite minority of people who are exceptional at what they do in industry. There are good and bad aspects to this but ultimately, there are always plenty of jobs in software going around, and the pay ranges from "reasonable" to "stupid money". People also tend to put a lot of value on passion and self motivation in industry (which will play into my thoughts on formal software courses in a moment).

I’ve been hiring a handful of programmers recently, and generally I have no feelings whatsoever about where they’ve come from or who certified them, all that’s bothered me is that they can code, and that they care about making things awesome. It sounds like a throw-away statement but enjoying and being interested in coding is worth more than any degree, both practically and in the hiring process. Of a team of around 15, I believe only handful have a degree, the rest are just great communicators and at least good programmers, and those two things matter most, actually in that order. It may sound trite, but in industry, being able to articulate yourself is just as important as raw ability, and I’d much rather hire someone who would ask for help solving a problem than spend 3 days struggling. In that respect, it’s much like any other team-based job, but it’s important. In my opinion, the only difference between a great coder earning 50k and a great coder earning 100k is communication, not credentials. The money often attracts people, then the job crushes them, because they just came for the cash.

Before I dive into those two links (which I just skim read), here are the things that *I* think make a *great* programmer

  • A strong understanding of Object oriented programming (
  • Having a mind that can deal with problems in levels of abstraction
  • A keen sense of breaking down problems into their smallest logical components
  • An average understanding of algebra
  • A strong understanding of logic and a grasp of arithmetic
  • Pragmatism in talking and mediating with people to come to decent compromises (most systems are a compromise of time / complexity / spec)
  • Understanding working in a team, pair programming and constructive criticism
  • Lack of an ego
  • Understanding tools that are used in the real world – using source control, using common development tools
  • A good sense of presentation and cleanliness in code, code is like writing, it must be clear and concise to be maintainable and understandable
  • A good understanding of the fundamentals of computing and how most computers and software hang together (regardless of programming language of frameworks, the root problems that everybody has to solve are all subject to similar constraints)
  • A good understanding of TDD and composition
  • Understanding the SOLID principles

My knowledge of university courses is almost a decade out of date (which is terrifying beyond belief) but my general opinion is that they don’t really prepare their graduates for actual jobs in programming, but they equip them with some of the fundamental skills which can be later used to make a good programmer. In a sense, it’s the long road, and a bit of a chicken and egg problem. Anecdotally, my degree spat out around 5-10 great programmers, a bunch of "technical business analysts" (people that understand the gist of software development but didn’t quite have the interest to do it, so ended up doing requirements capturing and project management), and a *lot* of help desk / support staff. You don’t want to end up on the help desk, it’s a special ring of purgatory reserved for people who hate every minute of their jobs.

I have two pieces of general advice for learning programming

  1. The university route will give you credentials to get through the door of your first job, no doubt. They teach some of the things that make a great programmer (OO principles, any course that teaches Java or C# will give you a solid foundation, algorithms still feature, though they’re less important now, and if they let you use significant external frameworks or SDKs that’s really experience that you’ll find useful) but when you take that first job, the gulf of things they didn’t teach (code quality, code structure, source control, development tools) will hit you like a truck. That said, it’s a tried and true way to get on the ladder and build up. The good thing about programming jobs is that you can generally move between them, and once you have 6 months to a year of commercial experience, your options open up a *lot*.
  2. Code. Code code code code code. Again, sounds like a joke, but the only way anyone ever became a great (or even good) programmer was to do a lot of it. Have pet projects, think of problems you’d like to solve. Write software for yourself, learn things that solve problems. The best bit about programming is the feeling that you can literally solve *any* problem that’s thrown at you. It’s so wonderfully enabling. Try and learn a few distinct different languages. You’ll find that after the first one, most of them are very similar, or at least solve similar problems. There are broad families of languages that will help you learn the best of different styles of programming. Really get into it, read lots of open source code, try work out how things work, join GitHub and spy on other peoples software as it’s built. It’s all built by mortals.

If you do both of those things, and don’t get bored or hate it, you’ll be a awesome developer and people will queue to hire you.

Now a few thoughts on frameworks and tools to learn…

Programming moves fast, really fast, there’s always new cool things, but the stuff I’d recommend learning and why (and in order of difficulty)

  1. HTML5 and CSS – This stuff is what all of the web is made of. It makes the world go round and you can find a thousand tutorials. Make a web page or two, get to grips with the basics
  2. C# – Very solid OO language, nice framework, good tools, nice way to get started. Really compatible with "the computer science" angle of algorithms and data structures and cleverness. Also great for web coding
  3. JavaScript – A programming language that you can run and test in a web browser, becoming more and more popular, use jQuery to make your HTML5 and CSS do cool things
  4. ASP.NET MVC – A web framework built on C# to let you build interactive websites. Popular in business and banking.
  5. Ruby on Rails – Very different in look and feel to C#. vibrant community of open source coders working on it, lots of newbie guides out there. Popular in start-ups.
  6. PHP – Lots of the web is built on it, it’s a horribly designed language, but there’s a lot of PHP code around.
  7. Git – This is a source control tool, it lets you "version" your code, it’s becoming the defacto standard.

If you use a Windows machine, the C# tooling is quite available, if you use a Mac, I’d suggest starting with Ruby on Rails. Once you’ve got over this hump, try out a functional language like Clojure or F#, for a different take on the same problems.

Books to read..

There are good books to get you started on anything, get you going on C#, it’s a good place to start if you want to learn "backend coding" and not just doing web pages.

I’d also recommend reading "Coders at work" maybe even before you try learn anything. It’s a really good page turner, an interview book, and you’ll get a feel for lots of different types of programming and the joy people find in it.

Clean code will teach you the stuff that universities should cover but they’re probably not smart enough to

Don’t make me think is the bible for learning how software should be built. Makes you see the world differently.

Easy Google Analytics Event Tracking–Do it by convention!

Wednesday, December 5th, 2012

For better or worse, we use a lot of Google Analytics event tracking at JustGiving, let me explain our workflow:

  • PM wants to track feature A
  • PM decides on track event categories and keywords
  • If a JavaScript file exists for that particular feature, we plumb in jQuery selectors and GA “_trackEvent” code
  • If not, we add a file, wire up the selectors, add the file to the bundling system, add the “_trackEvent” code

I’m not sure about you, but after you or your team have done that for say, 10-15 sub-features of a given feature, across several features, across several products, it’s obviously both a drag and a tedious, repetitive process. This kind of repetition sucks, especially for a simple problem, so we fixed it.

EasyEventTracking – a JavaScript “library”

Get the code: 

It feels slightly embarrassing to call this a library, so I won’t, but we built a little chunk of JavaScript, on top of jQuery, that uses conventions to “auto-track” events by subtly abusing css selectors.

There’s full documentation and source at the GitHub url above, but the simple overview is:

“Add a snippet of JavaScript to your footer, and auto-track events with the css class ‘track’, along with optional HTML5 data attribute overrides”

You need to add a tiny snippet after your usual GA tracking code that looks like this:

  <script type="text/javascript" src="src/EasyEventTracking.js"></script>
  <script type="text/javascript">
    var tracker = new EasyEventTracking(_gaq, function(trackEvent){
        console.log("Track event was fired: " + trackEvent);

And then the follow examples from the docs will ‘just work’:

<div class="track">
This will track when clicked.

<div class="track-mouseover">
This will track when moused over.

<div class="track" data-action="action!" data-category="category-here" data-label="label-here" data-value="my-val" data-non-interaction="true">
This overrides all available parameters using HTML5 data attributes.

That simple. As you can see above, you also get a nice little callback that you can use to “re-track” the event on your server, just in case you need that stuff in more than one place.

So stop! Don’t write event tracking code! It’s entirely tedious! Do it by convention!