“So what is it you do?”

A bad enough question in a social situation where the answer “I’m a software engineer” causes your correspondent’s eyes to instantly glaze, but even worse when you’re talking in a technical environment, or job hunting.

The thing is, whatever it is I do, I’ve been doing it for just short of 20 years, and like most developers I’ve my own unique trajectory through my career. I’ve had 6 permanent roles and about 10 contract clients. Both the industry and the languages I’ve used have changed immensely during this time.

Trying to bundle that down into a snappy answer is nigh-impossible, hence this longer attempt to find one.

One way of starting might be to run through a few of the job titles I’ve had during this time:

Graduate Engineer, Software Engineer, Web Developer and Server Administrator, Contract Frontend Developer , Contract LAMP Developer, Technology Manager, Technical Manager, Technical Architect , Senior Contract Developer…

not to mention several contracts that didn’t come with a job title.

About all that’s clear from that though is that most technical job titles are pretty vague.

I could run through the technologies I’ve used, which always leads to an impressive jumble of alphabet soup:

PHP, Javascript, Perl, C, MySQL, Linux, Apache, nginx, MongoDB, Angular, Node.js, PHPUnit, Composer, Zend, Symfony, Doctrine, Git, Mercurial, Subversion, GitHub, Stash, Kiln, Jira, Trac, FogBugz, Jenkins, Docker, Quay.io, AWS, VMWare, VirtualBox, Bind, Postfix …

I could continue, but it mostly just illustrates a breadth of experience rather than a clear direction or theme.

So what do I do on a daily basis? Well, that varies between roles — I’ve worked as both a frontend and backend developer, and in roles with sysadmin responsibilities. I’ve worked as a Team Manager, team member and as a single developer. But there are some common themes in what I’ve done:

Anywhere I work, I try to ensure that the right tools and processes are in use, because this helps me to produce quality work in a low-stress environment. Beyond the simple belief that professionalism requires doing good work, I do this because:

— I only want to write any particular piece of code once

— I don’t want my code to fail on live systems

— I want to make sure my code is as readable and re-usable as possible

In other words I want to do a good day’s work 9–5 without having to continually break flow to fire-fight, and then go home and be able to concentrate on my family life in the knowledge that I’ve minimised the risk of anything failing out of hours. I want to have a low-stress, productive, even enjoyable environment both for myself and my team.

This means ensuring the presence of:

— A good code management, approval and release process

— Decent automated testing, run automatically on all changes without interrupting developer flow, with an expectation of zero failures.

— Common coding standards that ensure both that code is automatically familiar to all developers, and that automatic tools can be used to ensure code quality and consistency where manually-written tests might not reach

— Quality logging and monitoring tools to catch live issues and oddities early

— Powerful, complete and consistent development environments with tools like loggers and profilers available to all engineers without requiring significant setup or maintenance time

— Readable, accessible and complete documentation

I’ve found that, if you give developers the right tools, they write good code. If you give them tools, on the other hand, that are hard to operate or maintain, they won’t use them.

The target of my process design is always: “Make it easier for developers to write good code than bad code, without making the process a drag”.

I do this from a realisation years ago that in, for example, a team of five, spending 100% of my own time just “writing good code” could only ensure that 20% of the code was good. But by spending some of my time, as a Lead Developer, manager, or senior team member — on processes and mentoring, I could help ensure that almost all code produced was good — even if I was writing a bit less of it myself. Best of all, the payoff on that investment over time means you have less stress, higher quality code, and more time to devote to either further process improvement or more hands-on development.

This attitude to changing processes has earned some happy employers, clients and teams, but also some unofficial job titles that have never quite made it onto a business card, along the lines of “Troublemaker” and “Professional Nuisance”. As it happens I’m quite fond of these, as they’ve reflected the fact that I’m generally wiling to stick my oar in and make changes for the better, and won’t usually grant special dispensation to cut corners. Fortunately clients and colleagues tend to understand why this is, and generally accept even as they make the case for a shortcut that it may not be the best approach.

Of course, there’s a certain approach required in being a Troublemaker. You can’t just walk in and say “we’re doing it this way now”. There’s a phase in every job and contract where you have to work inside the existing system, understanding that particular team’s needs and producing the sort of code, advice and feedback that gains people’s respect; you can affect change either aggressively through force of will and then try and work through the resentment, or you can first prove to people that you know that you’re on about, can produce quality work, and that the changes you propose are in their best interest.

You generally have to prove, too, that you can work across and between teams, whether it’s getting approval for new servers and services, helping to build tools that traditionally fall more within a DevOps than pure developer mandate, or making a business case for commercial tools and services. You can’t generally do this work if you’re happy to sit in exactly the slot that people have conceptually made for you, you have to be a trusted connection between existing groups, and you have to show that you can provide enough support to ensure that new tools & systems won’t add to existing workloads.

Building up adequate trust and reputation to have space to be disruptive in this way can take time and feel difficult, but I’ve always found it the best approach for long-term success. I like to think this is borne out by the fact that, since I last left permanent employment over 4 years ago, every one of my clients has offered to extend my contract when it came up for renewal (although I’ve obviously not always taken up the offer).

I tend to refer to this sort of work as either Process Engineering or Synthesis (or simply “Problem Solving”); it’s not generally full-on DevOps, and it’s a bit more than run-of-the mill development. Suggestions for a concise description or title are welcome.

Apart from this “Synthesist” role, though, I’ve obviously done a lot of hands-on development over my career. In particular, I’ve done a lot of work on older code. Partly this reflects the fact that I’ve been doing this for a long time — I’m familiar with the technologies that were used a dozen years ago as well as those of today, and I’ve gained a deep understanding of the underlying grammar of development, of what works and how to bring older projects up to standard. Partly, too, it represents that fact that I’m just plain stubborn at working out how older systems work, and have thereby gained a good reputation as a “Code Archaeologist”.

This can, unfortunately, be a bit of a two-edged sword. A familiarity with a myriad of coding techniques means that you can generally pick up new technologies both rapidly and successfully, but a reputation of working well with older code can put off employers and clients looking for 18 months’ experience in “this year’s thing”; framework specialisation is often seen as the domain of those who have been developing for fewer years than the framework has been around, and I’ve complained before) as to how that limits flexibility. By definition, as a Synthesist, I have to be a jack of many trades, but that increases, rather than decreases, your ability to master new ones.

So what does this all add up to? Where am I at now?

As ever, looking towards the next role — but this one’s going to have to be outside London — having married last year and living in a London box-sized flat we’re looking to move to somewhere with more space and better access to outdoor activities. My wife’s American but right now that’s not somewhere we’d want to go. Canada would be a consideration but their points-based immigration system considers that you stop accumulating experience 6 years into your career and start losing points to age instead, so I’d need an approved job offer to get in. Dublin’s a temptation but the possibility of a hard Brexit and the loss of freedom of movement makes that uncertain in the long term. The most tempting locations in the UK now seem to lie somewhere between Bristol and Cardiff, but few places come close to London’s tech industry. Thoughts on the practicalities and availability of both permanent and contract roles in any of those locations would be greatly appreciated; drop a comment below or find me via twitter at @parsingphase.

Originally published at phase.org.