Skip to content

Instantly share code, notes, and snippets.

@stolenegg
Last active September 10, 2018 20:44
Show Gist options
  • Save stolenegg/9f5557b1dde7cdeca562db282e35e95b to your computer and use it in GitHub Desktop.
Save stolenegg/9f5557b1dde7cdeca562db282e35e95b to your computer and use it in GitHub Desktop.
Contractor musings

Contracting: Thoughts from a decade on in the game

Prompted by some recent chats with current and former colleagues, I thought I'd share some musings on life as an IT Contractor* after nearly 11 years in the business. It's something of a stream-of-consciousness but I've tried to summarise it into three main points:

1. Know your financial worth, but be flexible

Knowing what to charge is probably the hardest part of being a freelancer or contractor, particularly when starting out. So how much should you charge? Perhaps unsurprisingly, the answer is 'it depends', which I can best illustrate by an early example from my own career:

In 2007 I left my last full-time job paying a modest 'developer' salary (~£20k/annum at the time). The lure of contracting is often seen as chasing the 'big bucks', but my first contract was with my former boss who had moved on to found a (now very successful) startup and offered me a contractor role at roughly the same money I was on. This was actually a mutually beneficial arrangement: They got a cheap (£100/day) contractor who they knew and trusted, I got my first freelance gig for a steady few months which allowed me to establish my business with minimal financial risk - win-win.

At the same time I was on a retainer at my old company providing handover and support for their bespoke systems. The rate? £500/day for one day per month with some on-call support, plus £250/day thereafter for ad-hoc work which I quoted for in small blocks.

So that's three different rates for essentially the same skill-set, in the same market conditions, but crucially all represented fair value for the parties involved. Incidentally, had I not taken the £100/day role I wouldn’t have made the contacts I have built up and who offer me work to this day, and for that I remain massively grateful.

2. Beware IR35, but don't sweat the small stuff

The spectre of IR35 has loomed large over the contracting sector for 20 years and is probably best summarised as a massive clusterfuck (sorry) on the part of Her Majesty’s Revenue and Customs. It could be a whole series of articles in itself. The goalposts are constantly moving but the main thing to realise is almost no-one really understands it, especially big companies who just want to assign everyone a payroll number.

It can be a constant headache, particularly if you're working on a client site with a mixed team†. Working ‘outside’ IR35 you just need to do your due diligence: Make sure your contracts and working practices are aligned, get some professional advice, get the correct insurances, and stick to your guns when it comes to Supervision, Direction and Control. This actually has many upsides if, like me, you hate corporate bullshit. You really don't need to go to that 'team meeting' if it's nothing to do with your project!

That said, be pragmatic and pick your battles. If it takes three minutes of your life to do some "mandatory online employee fire safety training" (OMG it says 'employee', IR35 klaxon!) then you know what, just do it if helps someone you work with get HR off their back or meet their bonus target (yes, companies really do stuff like that).

3. Be humble, be tactful, and be positive

Working with different clients in different environments you very quickly understand that office politics is very much A Thing. Just don't get involved; it really is that simple. Don't offer opinions on staff members, hires, policies or decisions - anything that's not your professional, contractual duty to have an opinion on. If something is part of your remit (such as a code review) then be constructive, offer the benefit of your experience and suggest ways to improve. Engineers are an egotistical bunch so you can only offer your advice - ultimately it's up to the client to make their own mistakes.

A corollary of this is, don't criticize those who have gone before you. Software systems are complex beasts and like everything else, a product of circumstances. A past design or implementation decision may not make sense to the casual observer, but it was usually made for good reason.

I recently returned to a previous client I had done some development work for about five years previously, and overheard some their newly-hired engineers loudly bemoaning some code they came across in the 'legacy' system. Of course, unbeknownst to them I was one of the authors... as were the Engineering Manager and Head of Technology now several pay grades above them. I didn't say anything despite really wanting to point out that the code in question had been running perfectly fine in production for five years supporting a several-hundred-million-pound business. I like to think a curious 'git blame' at some point may have prompted a change of attitude.

One further thing that I regret not making more effort with in the past: Always, ALWAYS be nice to reception, security and cleaning staff - people you don’t necessarily work with directly or 'have' to interact with. They are almost invariably good people who know many interesting things and can open doors (in every sense). There is no hierarchy you need to observe when you’re your own boss, but you’re not the boss of anyone else either. Just the way life should be, and just how I like it :-D

* I actually dislike the term IT Contractor, more accurately I'm a software engineer, but that term seems poorly understood outside of the industry

† Agile software projects are very often delivered by 'mixed' teams comprising client staff, contractors, third-party vendor reps, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment