In defence of job hopping

(don’t be like Tim)

As a primer for why I think you should consider becoming a feckless, shifty, good-for-nothin’ job hopper, I offer the following cautionary tale.

I retrained as a software developer after a fledgling career in market research. Read more about it here.

My first job after my computer science masters was on a graduate scheme at a medium sized software consultancy, in a small university town, far away from the hustle and bustle of London.

I was excited to get started on my journey as a developer, and make up for lost time.

One of the reasons I opted to work for this consultancy was the shimmering promise of being able to work on many different projects, across different sectors and tech stacks, and to learn from the best.

The first few weeks were great. We were given in depth training in modern software engineering practices: automated testing, git, project management, scrum and agile, architecture and programming fundamentals. It was a dream.

Unfortunately, directly after this, I was tasked, along with a cohort of a dozen or so grads, with manually testing a true waterfall, death march disaster project.

There was an entire floor of staff dedicated to servicing this heaving, under-budgeted and over-sold behemoth, and after a few weeks of genuinely useful learning about the domain of the project, and gaining an understanding of the application, it became clear that any skills we learnt were not going to transfer into other programming roles.

At this point (and this will become a recurring theme), I began to panic.

I had abandoned a career which I had started to gain traction in, in order to become a software developer, and now I was faced with the prospect of leaving the job after a few years, with nothing but an in depth knowledge of a poorly written application to my name.

I was going to end up having spent 12 months at university and all of my money, as well as take a sizeable pay cut, to gain the professional experience that a high school leaver could get as a manual QA tester.

Three months later, I was still doing manual testing, and rapidly losing my mind.

Meet Tim

Around this time, while I was pulling my hair out and questioning all of my life decisions, I noticed Tim.

Tim did not share my concerns.

He joined as a grad and had already been at the company for a few years.

He had a PHD in a whizzy sounding hard science, and was clearly a clever guy.

However, he did zero programming; absolutely none.

What is more he didn’t seem to want to, despite his job role being ‘Software Engineer’.

He had been working on the death march project from the start, and was quite content to puzzle over spreadsheets and Word documents, doing the job of an entry level QA.

In some ways, this slightly zen attitude seemed admirable.

He also really did know how to do the job of a manual QA well.

However, there was a problem.

At the consultancy, Software Engineers (and Tim was a Software Engineer) were graded into bands.

As grads, we were band 1 Software Engineers.

As he had been at the company for a while, Tim had moved up a few bands.

These bands were partly used to decide on salary, but were also, crucially, used to dictate the price to hire us out to other companies for.

If a new project was being commissioned, the bid might include something like ‘two level 1 SEs and a level 3 SE’.

The point being, that a client expected a return for their money in the form of hard technical skills.

Tim, as you may recall did not have these technical skills.

After a few more months, Tim ended up being hired out to another project, as a Software Engineer level 4 or whatever he was at that stage.

Hurray! I was happy for him and also very jealous.

He came in with a big book on Java and sat poring through it at his desk, clearly determined to make sure he was up to the challenge.

Plot twist: Tim got fired.

That’s right, it turns out if you don’t acquire valuable skills that people want to pay for, the market will not reward you, and might even punish you, regardless of how good you are at your job.

Tim’s Java book remained on his old desk after he was gone, and made me shudder every time I walked past it.

What I did next

I ended up leaving the company very shortly afterwards, for a job at a tiny startup, with an even lower salary, in London, but where I would be able to get as much experience as possible in as short a period of time as possible.

I was at the consultancy for only six months, and was seriously worried about the effect that leaving so soon would have on my long term career prospects, but the gnawing horror about what had happened to Tim was enough to motivate me to hit the ejector switch.

This move turned out to be a good decision, and I stayed at the startup for a year and a half, inhaling knowledge and responsibility at a rapid rate, until I ultimately left for another job with almost double the salary, in order to be able to afford both rent and Tesco meal deals.

Since then I have essentially framed every career decision in terms of the experience it will give me, and whether that experience is something that the market will reward.

This greedy accumulation of experience gives me options, and has allowed me to be far more open at work when things aren’t working, and ultimately to not take any unnecessary shit, as I know that I can fall back on my skill set to find more work.

This feels great.

This tactic works particularly well in this industry because there is both a rampant demand for software professionals, and an under supply of good ones.

This means it is comparatively easy to stand out from the pack, assuming that you dedicate conscious effort to improving yourself in areas that the market rewards.

But this is immoral!?! What about the companies you’ve left in your wake

Somewhat… but I don’t think as much as you might think.

As I see it, software development is highly transactional in nature.

You pay me money, I build you a thing. You pay me more money, I maintain the thing I built, or the thing someone else built.

This lends itself very well to project based work, and has parallels in the building trade.

Building and engineering rely heavily on contracting work out to individuals and companies, who then build, or design the thing, take their money and move onto another project.

Framed in these terms, the idea that you would spend x number of years getting embroiled in a company mission, and supporting their long term goals at the expense of your own development seems misguided, and actually not beneficial to either of you.

I have always endeavoured to leave projects and companies in a better state than I found them.

As I specialise in one area of development currently (frontend), and one specific technology (Angular), I can join a company and be up and running in around a week. The training cost to them is very limited.

I always aim to deliver defined pieces of work to any company I’ve worked at, and have made sure to hand over what I’ve done to the rest of the team when I leave, including documenting anything I’ve done.

Recruitment costs aside (which have more than once not ended up being paid as I have left during my probation period), I don’t believe that my impact on any of the companies I’ve worked at has been negative.

I could be tragically misguided, but I believe that the way I have left companies means that I could go back to any of them if I really wanted to.

Why not just become a contractor then ya bum!

Fair point.

That’s actually what I’m going to do when my current job is finished in August.

Feel free to check back in a few months to see how that goes for me 🙂

If I’m honest, I am once again shitting myself.

Leave a Reply

Your email address will not be published. Required fields are marked *