Career & Meta on PHP Boy Scout

The campsite was never the point

Thu, 18 Jun 2026 00:00:00 +0000

I named myself, professionally, after a rule about litter.

The Boy Scout Rule is the one every camp drills into you: leave the campsite cleaner than you found it. Robert Baden-Powell’s version, in the last message he left for Scouts to be found among his papers after he died, was tidier and bigger: “try and leave this world a little better than you found it”. But the campsite is where a child first meets it. Ten years ago I stood up at a conference in a Scout uniform and argued that the same rule runs a codebase: leave the code better than you found it, every time you touch it. I still think I was right. I’ve just spent the decade since learning that the rule is bigger, and a good deal harder, than the tidy version I was selling then.

A clarification I owe you up front: I’m not an active Scout any more. I was one as a boy and again as an adult leader, and a few years ago I stepped back to put my energy elsewhere. The uniform’s in a box. The creed isn’t… And that, I’ve come to think, is the only real test of whether a thing was ever a value or just a rule someone was checking up on. A rule you follow while the warden’s watching is a rule. One you keep after you’ve handed back the woggle is a value. The campsite taught me the rule. Twenty-odd years of work taught me it was a value, and what that costs.

It’s the same rule, at every size

The thing people get wrong about the Boy Scout Rule is thinking it’s small. They file it next to “tidy your desk”, a nicety for when you’ve got a spare minute.

It isn’t small, and it isn’t about size at all. It scales from a single function to an entire company without changing shape, because the load-bearing part was never the litter or the lines of code. It’s the intention: that you leave a place in better order than you found it, on purpose, as a matter of course. Pick up one crisp packet on the way to the bus and the field is measurably better for the next troop. Fix one silently-failing lint rule on your way through a file and the codebase is measurably better for the next engineer. The act is trivial. The habit, held by enough people, is how a whole environment stops degrading and starts improving, quietly, without anyone running a project to do it. A campsite, a codebase, a team, a company: same rule, same intention, bigger blast radius.

Anyone can pick up litter; a leader buys a vacuum

Where it stops being a personal virtue and becomes a job is the moment you’re responsible for more than your own hands.

One scout picking up one crisp packet leaves the field a little better. But I can’t follow forty engineers around pointing at litter, and I wouldn’t want to. So the work of leadership is to stop relying on individual heroics and put a vacuum on the whole campsite: the standards that make the tidy thing the default, the automation that catches the mess before a human has to, the CI gate that won’t let the litter on the bus in the first place. On the teams I’ve run it became a mantra, that every project ticket you pick up, you also pick up something small alongside it, a CVE bump, a failed check, a confusing name. None of those was anyone’s job. All of them made the system better to work in, easier to understand, less prone to bite someone at three in the morning.

And here’s the part that surprised me, because I’d assumed the hard bit was getting people to care. It wasn’t. The scarce resource isn’t willingness, it’s confidence. Engineers see the litter. What they lack, under a deadline and the pressure coming from every direction, is the permission to bend down and pick it up, the belief that thirty minutes spent on something nobody asked for won’t be the thing they’re hauled up for. Giving people that permission, and meaning it, and backing them when they take it, turned out to be most of the job.

Then get on the bus

If I stopped there you’d have a poster, and posters are how good ideas turn into sanctimony. So here is the limit, because a rule without judgement is just yak-shaving in a woggle.

Every camp has the over-keen scout who is still deep in the bushes hunting for one last sweet wrapper while the rest of the troop has loaded the bus and the engine’s running. That scout hasn’t understood the rule better than everyone else, they’ve understood it worse. They already have a bagful; the field is already better than they found it; and now the right thing, the thing the rule is actually in service of, is to get on the bus so forty people get home. The litter stopped being the point a while ago.

It’s identical with engineers. Chasing the next improvement is a good instinct right up until it costs the team the thing that actually mattered, the release, the commitment, the colleague waiting on you. It’s a team sport, and the rule only works in the hands of a team player. I have, more than once, had to tell a good engineer to stop making something better and ship it, which feels like contradicting everything above and isn’t. Knowing when “better” is done, when the bag is full enough and it’s time to drive home, is not a betrayal of the rule. It’s the adult version of it.

The campsite was never the point

Which brings me to the thing it took me far too long to say out loud. The code is the easy half. The campsite was never the point.

“Leave it better than you found it” applies, most of all and most lastingly, to people. Every engineer I’ve helped pick up a new tool, every junior I’ve talked through a design they were afraid of, every review I treated as teaching rather than gatekeeping, that is the rule, far more than any lint fix. Code I improve decays; entropy comes for it eventually. A person I help to grow carries that forward into work I’ll never see, and teaches it to people I’ll never meet. If you want the rule to actually compound, you stop applying it to the codebase and start applying it to the people who’ll outlast your codebase. The campsite is just where you practise.

The scout who doesn’t get it

And then, occasionally, there’s the one who doesn’t get it. The scout, or the engineer, who won’t pick up the litter, who treats the whole idea as someone else’s fuss, who hands the messy work to the next person without a second thought.

Our industry has a reflexive answer to that person: route around them, manage them out, label them and move on. I’ve never been able to make that answer sit right, and I’ve stopped trying to. That person isn’t flawed. They’re not a write-off and they don’t deserve to be quietly frozen out. Far more often they’ve simply never been shown why it matters, or they’re carrying something that’s left them no room to care this week. What they need is the least scalable thing I have: time, patience, and the assumption of good faith. The same thing, now I think about it, that somebody once spent on a younger me before the rule stuck.

That’s the hardest application of the whole thing, and the one no standard and no amount of automation will ever do for you. You can put a vacuum on a campsite. You cannot automate the slow, human work of helping a person understand why they’d want to leave a place better than they found it, and that it’s worth doing for the rest of their life, long after anyone’s checking, long after the uniform’s in a box.

I stepped back from Scouting, and I kept the rule, because once upon a time someone gave me the patience to understand it rather than just obey it. Ten years on from standing up in that uniform, I’m clearer than I’ve ever been about what the badge was really for. Not the campsite. Never the campsite. The least I can do with the rule that named me is pass it on the way it was passed to me, one person at a time, and then have the good sense to get on the bus.

Why I still write code

Wed, 10 Jun 2026 00:00:00 +0000

By any sensible reading of an org chart, I have no business being in this file. I’m a Head of Software Engineering. My calendar reckons I should be in a room somewhere talking about headcount and roadmaps. Instead it’s late, everyone sensible has logged off, and I’m three retries deep into a release that refuses to tag itself, muttering at a Rust workspace I built with my own hands.

So why am I here? I’ve been asking myself a version of that question for about twenty-five years, and I think I’ve finally got an answer. It’s just not a flattering one.

I’m a builder, and that isn’t really a choice

Strip away the job titles and I’m a builder. I like to make things, I like to solve problems, I like to learn how something works by taking it apart and putting it back together slightly differently. That urge predates every role I’ve ever held and it has survived all of them. In jobs where I wasn’t allowed to scratch it, I went and built in the open instead, which is a polite way of saying open source has spent years absorbing energy my day job wouldn’t take.

I’ll go further, because being coy about it helps no one: it’s closer to an addiction than a hobby. I don’t fully switch off. The current outlet, when I’m not in a terminal, is converting a campervan, which is just software engineering with worse error messages and a real risk of electrocution. The shape of the thing changes. The compulsion doesn’t.

Underneath the building there’s a less charming engine, and I might as well name it: a fairly grim case of impostor syndrome. I wrote about it years ago when I stopped calling myself “Dev in Charge”, and a decade on it hasn’t gone anywhere. The only thing that ever quiets the anxiety is staying genuinely good at the thing, and staying good at the thing means using it. I’m a firm believer in use it or lose it. People say technical skill is like riding a bike, you never forget. Maybe. But step away for a few years and when you climb back on, someone’s bolted a jet engine to the frame and moved the pedals. The bike doesn’t wait for you.

What it actually buys

Here’s the part that justifies the indulgence, because on its own “I enjoy it” isn’t a reason to stay technical as a leader, it’s a reason to have a hobby.

The load-bearing belief is simple, and it’s the one line I’d carve into the desk: I will never ask an engineer to do something I’m not willing to do myself. Everything good about staying hands-on flows from that. Because I’m still in the work, I can give my engineers proper support, the right tools and a clear path, rather than guessing at what they need from a slide. I can steer them through a genuinely hard technical call instead of nodding along. I can sniff out a duff estimate, mine or theirs, because I know what the work actually costs. And I can hold them to account with a straight face, because the accountability runs both ways. They answer to me for what they ship, and they get to hold me to account for what I contribute. That second half is the bit a lot of technical leaders quietly drop, and it’s the half that earns you the right to the first.

The bill, and who paid it

I’d be selling you a fairy tale if I stopped there, so here’s the cost, and some of it is steep.

The obvious one is burnout. I’ve been there more than once over the years, and it’s the single biggest reason I now pitch myself deliberately as a Technical Leader rather than an Engineering Manager. I can do the manager stuff, the HR and the planning and the project-management bollocks, and after enough years in the role I do it well, because it demanded that I did. But competence isn’t appetite. Given the choice I’ll take a technical problem or a bit of mentoring over running the process around either, every time, and spending your days on work you’re good at but don’t much enjoy is its own slow road back to the wall. Sticking to my strengths isn’t ego, and it isn’t an admission I can’t do the rest. It’s self-preservation, learned the hard way.

The steeper bill came due at home. When my kids were small I poured my own time into pushing my skills and chasing the next rung, even starting my own agency. Between that and the burnout, I missed big chunks of their early years, and that is one of the real regrets of my life. I’m not going to dress it up or hide it behind a lesson. It was my decision, I made it, and I own it. I’m immensely proud of the people they’ve grown into, and since their mum and I separated I’ve put everything I have into giving them a stable home, the builder instinct quietly turning into a nest-building one, which is the better use of it. I put this here, plainly, because if you’re reading this with a young family asleep upstairs, I’d sooner you heard it from someone who got the balance wrong than learn it the way I did. The code will still be there next year. They won’t be five next year.

And there’s a smaller, daily cost that I still haven’t fully mastered: knowing when to put the keyboard down. A builder who can’t stop building is exactly the person who becomes the bottleneck, disappears down a rabbit hole, or hoards the interesting problem that would have stretched someone on the team. Stepping back to let them solve it, when every instinct I have is screaming to just fix the bloody thing, is genuinely one of the hardest skills I’ve had to learn, and some days it still feels like walking a knife edge. Open source is a big part of how I manage that. It’s a release valve, somewhere I can let the compulsion run with no brakes on, precisely so I’m not stealing the meaty work off the people I’m meant to be growing.

Does it still count when the robot types?

Fair challenge, given the year. I build solo now with an AI pair, to the point where it’s changed how I branch and release. So when a model writes a good chunk of the actual characters, am I still “writing the code”?

I think I’m doing it more than ever, and I’m certainly learning faster. My typing is genuinely terrible, a quarter-century of practice and still mostly thumbs, so being freed from being the typist is no loss at all. What’s left when you take the keystrokes away is the part that was always the point: reading, reviewing, judging, steering. I can review more code, faster, than I ever could when I was the one hammering it out, and I can run several projects at once by pointing my judgement at each in turn. That is leadership work and engineering work at the same time, which is rather the whole thesis.

It did not come free, mind. I was elbow-deep in AI and ML long before GPT made it fashionable, and I’ve seen the messy version up close. Getting to the point where the tools are good enough and I’ve built the guardrails and habits that make them safe took a long time and a lot of getting it wrong. Owning the judgement when the machine does the typing is harder than it sounds, not easier. The typing was never the hard bit.

What I’d actually put my name to

Not that every leader should write code. Plenty of excellent ones don’t, and they’re brilliant at the parts of the job I’m middling at. The narrower, truer claim is the only one worth making: I lead better when I stay in the work, because it’s the only way I know to support, steer and be held to account without faking any of it, and because I meant that line about never asking for what I won’t do myself.

Staying technical isn’t the job. It’s the thing that lets me do the job honestly. I’m a builder who learned, slowly and at a price I’d rather have not paid, how to keep building without it costing the people around me what it once cost the people closest to me. That’s the balance I’m still working at. I suspect I always will be.

Technical CV writing is still hard, and now a robot reads it first

Fri, 22 May 2026 00:00:00 +0000

Seven years ago I wrote a post called Technical CV writing is hard, pulled my own CV apart, and explained every choice in it. I even bragged that it converted to a first interview about eighty per cent of the time, then added “watch me now jinx myself for the future”. Reader, I jinxed myself. I’m back on the market, the same CV that served me for two decades went out into the world, and what came back was a sort of stunned silence. Not even rejections. Just nothing.

The CV that suddenly stopped working

The thing about that silence is how specific it was. Some applications behaved exactly as they always had: a human read the CV, liked it or didn’t, and replied like a person. Others went into a void. And the void had a pattern to it. It was the bigger, more process-heavy outfits, the ones you’d bet good money have an Applicant Tracking System and an “AI-assisted screening” line item in some HR budget.

That’s when the penny dropped. My CV wasn’t failing to impress anyone. It wasn’t reaching anyone. The first thing reading it wasn’t a person at all.

The reader changed, and I hadn’t noticed

I’ve made this exact point on this blog before, only about software: half your users don’t have eyes. A CLI tool’s output has two audiences, the human at the terminal and the script parsing the output, and they want completely different things. It turns out a CV is now precisely the same. It has two readers, and the first one is a machine.

A human recruiter reads a CV the way I designed mine to be read: narrative, personality, a sense of the person. An ATS or an AI screen does nothing of the sort. It parses for structure, for keyword density, for recency, for numbers it can latch onto. My CV was a beautifully tailored sales pitch aimed squarely at a human who, increasingly, never gets to see it, because a parser in front of them scored it and quietly binned it first.

Everything that made it a good human document was, to the machine, either invisible or actively confusing.

So I asked an AI what the AI hated

There’s an irony here I’m choosing to enjoy rather than resent. The way I worked out what the filters object to was to sit down with Gemini, hand it my CV, and ask it to read the thing the way a recruitment AI would and tell me where it tripped. Using one AI to get past another. Fight fire with fire.

The one instruction I was firm about, and I’ll come back to it, was that the CV had to stay recognisably me. I wasn’t asking Gemini to launder my career into something generic and machine-shaped. I was asking it to help me keep as much of my own voice and judgement as possible, while making the thing easier for an AI to approve and a human to enjoy. There’s a practical edge to that, too: the screening tools are increasingly tuned to spot the patterns of generated text and weight them down, so a CV that reads as though a model wrote it can trip the very filter you were trying to please, quite apart from leaving the human at the end of it cold.

With that ground rule set, the hurdles it surfaced were genuinely illuminating, and a bit humbling given I’d written a whole confident blog post about how to do this.

The skills tables are worse than useless. My CV led with two lovely tables: Management Skills and Technical Skills, each with a level and years of experience. Clean and scannable for a human. To a lot of parsers, a table is a trap: they flatten it into a jumble and lose the structure entirely. Worse, listing “20+ years” against nearly everything triggers what I can only call the recency trap. Modern screening looks for skills that show up in your recent job descriptions, not in a header table. A language sitting in my skills table but not in my last two roles reads as stale or unverified, no matter how many years I claimed next to it. Gemini put it plainly: “if a tool sees Golang in a top table but doesn’t see it explicitly mentioned in your last two job descriptions, it assumes the skill is stale or unverified.”

“I have a passion for what I do” is noise. My opening profile statement, which I was rather proud of, is exactly the sort of thing a screening tool discards wholesale. As Gemini noted, these tools “completely ignore subjective self-assessments … because they cannot be measured or verified.” It wants a dense, factual summary full of the nouns it’s searching for, right at the top.

My numbers thin out the further back you go. My recent roles are full of the data these tools love: a 75% reduction in deployment times, three thousand-odd Kubernetes clusters, a GitLab instance with four hundred thousand repositories. My older roles, written years ago in a more narrative style, are all “oversaw the delivery of solutions” with not a metric in sight. The machine reads that as a career that got vaguer over time, which is the opposite of true.

Four pages is at least two too many. Parsers weight the first page or two most heavily. My education and the foundational stuff sat on pages three and four, where the algorithm barely bothers to look.

It couldn’t work out what I am. This was the sharp one. With “pre-sales”, “client management” and “Managing Director” sitting next to deep technical keywords, the classifier genuinely can’t decide whether I’m a commercial manager who used to code or a hands-on engineer who drifted into management. As Gemini described it: “the algorithm gets confused … It struggles to classify you: Are you a commercial manager who used to code, or a hands-on techie who got pushed into management?” So it does the safe thing and matches me to neither.

What I’m actually changing

Knowing the hurdles, here’s what the rebuild looks like. This is the part I want to be useful, so it’s concrete.

The tables are gone. In their place is a “Core Expertise” section, plain text the parser can read, grouped so my leadership sits next to my technical stack. And I’ve done the thing 2019-me was too much of a show-off to do: tiered it honestly. Instead of “Expert+” against everything, there’s a primary tier of what I actually do day to day, a proficient tier I can deploy without blinking, and a frank “familiar, not current” tier for the languages I last touched in anger a decade ago. That honesty isn’t just decency. A wall of “expert at everything” reads as noise to a machine and as bluster to a human, and I’d been doing both.

The subjective profile is replaced with a keyword-rich professional summary that says, in the first two lines, exactly what I am and at what scale.

The keywords that mattered have been woven down into the recent role bullets, so the parser sees them where it trusts them. And I’ve reframed the people-management and pre-sales language toward technical enablement and architectural advisory, because what I’m actually chasing is the technical-leader sweet spot: the person who owns the architecture and mentors the engineers, without the HR admin and the sales pitches. The CV now points at that, deliberately, so the classifier stops dithering.

There’s also a more personal beat in here. A previous employer handed me a role with a “VP” title, sold to me as exactly the technical-leadership job I’d been chasing. It wasn’t. The title turned out to be a pay-grade bracket rather than a description of the work, the work itself was hands-on firefighting with little of the leadership or empowerment I’d been promised, and I moved on within a few months. To a screening AI, that pairing is doubly awkward. A “VP” title files me as a meeting-heavy executive and rules me out of the hands-on Principal and Lead roles I actually want, and a sub-six-month stint trips the flight-risk flag that some trackers quietly score you down for. So the fix is to stop letting the inflated label do the talking: describe the functional reality of the work, retitle it to the technical track it actually was, and let the scale of what I wrestled with speak instead of the job title. Titles, it turns out, are for the pay band. The bullets are for the truth.

Keeping myself in it

Back to that ground rule. Every one of these changes is in service of getting past the machine to the human behind it, and neither reader is well served by a CV with the person scrubbed out of it. The screen, increasingly, is trained to notice generic generated phrasing and mark it down; the human, always, would rather read something with a pulse. So the keywords go in, the structure gets fixed, the metrics come forward, and the voice stays mine. No “results-driven synergistic leveraging of cross-functional paradigms” that nobody would ever say out loud. That was the whole point of doing it this way: let the AI help reshape the structure a parser cares about, while the words stay mine, so what comes out is easier for a machine to approve, easier for a human to enjoy, and still unmistakably written by me. Optimising for the filter and sounding like myself turned out not to be in conflict at all.

I genuinely don’t know if this works yet

Here’s the part that makes this a post and not a victory lap. I don’t know if any of this lands. The old CV converted at around eighty per cent, on my own possibly-generous reckoning, right up until it abruptly didn’t. The new one is going out now, into the same market and the same filters that were stonewalling me a fortnight ago.

So this is a promise as much as a post. I’m going to keep count, the way I should have all along, and come back with the actual numbers: did reshaping my CV for a reader with no eyes genuinely move the needle, or did I just make it uglier and learn nothing? Either way you’ll get the truth, because a follow-up that only reports good news isn’t worth writing. Watch this space, and if you’re sending CVs into the same silence, maybe try reading yours the way a machine would first. It’s a deeply odd exercise, and I suspect it’s now an essential one.

Moving this blog off Jekyll

Thu, 21 May 2026 00:00:00 +0000

The blog you’re reading used to be a Jekyll site on GitHub Pages, built on the lovely beautiful-jekyll theme. It isn’t any more: it’s Hugo now, published to GitLab Pages. The hosting move rode along with go-tool-base leaving GitHub for GitLab, but dropping Jekyll for Hugo was its own decision, and the more interesting one. Most of the migration was painless. Two bits were not, and they’re the two bits worth writing down.

Why leave Jekyll

Jekyll hadn’t done anything wrong, exactly. beautiful-jekyll is a genuinely nice theme and the site worked fine for years. But it had started to show its age. It hadn’t seen much improvement in a long while, and keeping it building meant staying on older versions of Ruby. Ruby is a perfectly good language, just never one I’ve much enjoyed living in, and I could feel one of those fork-it-and-drag-it-up-to-date afternoons coming, the kind I’d done before and didn’t fancy repeating.

So rather than patch up what I had, I asked the more interesting question: what else is out there? It came down to a shortlist of two, Astro and Hugo. Hugo won, fairly narrowly. Partly I just liked more of its out-of-the-box themes. And partly because it’s written in Go: one portable binary, no toolchain to wrangle, the sort of thing an engineer can drop onto any machine and run without a second thought.

The day every image on the blog tripled

The first proper snag was about where images live. Hugo would happily have let me keep Jekyll’s arrangement, one big /assets/images/ folder with every post linking into it by absolute path. But I’d picked the Stack theme, and Stack leans towards page bundles: each post is a directory, and the post’s own images sit right next to its index.md, referenced by plain relative name. The cover image becomes a resource of the post rather than a file in a shared bucket.

That’s a better model, and I decided to commit to it. Getting there, I managed to make a proper mess. The migration copied the old assets/images across, and Hugo’s static/ directory wanted a copy too, and then I started moving covers into the bundles, and at one humbling point a count turned up every image existing three times: once in assets/images, once under static/, and once in a bundle. A blog with a hundred-odd images had become a blog with three hundred-odd, most of them duplicates nobody referenced.

The fix was to go all the way to the bundle model: move each post’s images into its own directory, rewrite the references from absolute /assets/images/x.png paths to bare x.png, and delete the two shared piles entirely. Once the images lived with the posts, there was exactly one copy of each and the path was obvious. But for an afternoon the repository was a hall of mirrors, and the lesson was to pick the new tool’s model and go all the way to it, rather than carrying the old one alongside it and ending up with both.

The “extended” image that wasn’t new enough

The second one cost me the most time, and it’s the most transferable, so it gets the most words.

Hugo comes in two flavours, ordinary and extended, and the Stack theme needs extended because it compiles SCSS. So I reached for an off-the-shelf extended Hugo container image, wired it into the pipeline, and watched the build fail with an error about a template function the theme was calling that simply didn’t seem to exist.

I spent far too long suspecting the theme, my config, my content. The actual culprit was a version. The image I’d grabbed was a couple of minor releases behind, and Stack v4 uses .Site.Language.Locale, a Hugo feature that only landed in 0.157. The image was older than that, so the function genuinely wasn’t there, and the error was telling me the literal truth in a way I wasn’t ready to hear. “Extended” had told me the flavour was right and lulled me into not checking the version, which was the thing that actually mattered.

The fix was to pin a specific, recent extended image rather than trusting a floating “extended” tag to be new enough. The pipeline now runs on a pinned hugomods/hugo:debian-git-0.161.1, comfortably past the 0.157 the theme needs, and the build that had been failing on a missing function went green the moment the version was right. A theme has a minimum Hugo version the same way any dependency has a minimum, and “extended” is a feature flag, not a version number.

What it comes down to

Moving this blog from Jekyll to Hugo, and from GitHub Pages to GitLab Pages on the way, was mostly a pleasant afternoon, with two frustrations worth sharing. Commit fully to your theme’s page-bundle model rather than dragging Jekyll’s shared-assets layout along beside it, or you’ll briefly own three copies of every image. And pin your Hugo version explicitly, because a theme needs a recent enough Hugo, and the “extended” label tells you nothing at all about whether yours is.

If the site renders for you now, both got sorted. If it doesn’t, well, you’re reading this in a text editor, and I’ve some more debugging to do.

Technical CV writing is hard

Wed, 15 May 2019 00:00:00 +0000

Recruiting people is effing hard!

That’s all… I’ll get back to reading through CVs now and let you get on with your day!

Medicines Discovery Catapult is, at the time of writing, recruiting Software Engineers, and as “Head of” it falls to me to start filtering through the CVs that land in my inbox. But what a mess! I get all sorts, from 1-page masterpieces that look amazing and all glossy, but tell me nothing about the individual to 10 pages of war and peace that have so much in it spanning 20 years of experience that 70% is actually completely irrelevant to the job they have applied for.

So now I get to say that this is what the perfect portrait of a CV should look like… I’m sorry to disappoint but I don’t think there is such a thing as a “perfect” CV. It’s far too subjective and open to interpretation. Instead, I’m gonna rip apart my own CV and explain why I chose to write it like I have and justify reasons why I would expect to see similar things on the CVs I am forced to read.

If you want the “TL;DR” version you can find a copy of my CV at https://docs.google.com/document/d/1MM_6nXIVU_wbrvkhdGL5xaJEwc46L7JblUqUot_g1ec but if you have gotten this far you may as well stick around and read the rest. I promise it won’t take long.

The Basics

OK! let’s start with some general observations I follow with regard to my own CV. Then we can get into the nitty-gritty of how bad mine is!

Recruiters

Love them or loathe them they are a part of the recruitment ecosystem and they will help you get hired. When you send them a copy of your CV bear in mind that they will most likely try to squeeze it into a format that will include their own branding and a cover sheet with some pertinent details on it. They may also then start redacting information off your CV in an effort to anonymise you. It is also possible that they will use the same CV for multiple roles meaning you will need to insist that they send your tailored CV if you are really bothered about winning a specific position.

Make sure to discuss this with your recruiter before having them put you forward for a role you are keen on.

Keeping Up to Date

Design your CV so that it is easy to tweak and update! Keeping your CV up to date is essential, and I don’t mean just adding your last role when you finally get fed up with your current employer abusing your good nature and rage quit!

Keeping your CV in top form means that you need to review the entire thing whenever you make an update. As your career progresses you will find that your perspective will change on what previous roles consisted of and how they would impact/reflect on the position you now desire.

You will also find that an up-to-date CV is easier to tailor to any specific job you might be applying for

Prettiness

I know his name is Riccardo, but I’m struggling to focus on anything else

Having a pretty CV is great! and if creativity is relevant to the vacancy you are hoping to fill then go for it… make it gorgeous. It is however very subjective so make sure that you understand what your potential employer is looking for. Sometimes less is more, especially considering they may be scanning through hundreds of CVs. If they have to spend half an hour looking for something specific, then it’s gotten lost in all that creativity. If you want to see some gorgeous-looking CVs take a look at https://weare.guru/creative-cvs/ all of them are creative and beautiful…

But… they could take 20 minutes, or more, for someone to read and extract the right information. Which will waste a lot of time for your potential new boss. Plus we are talking about technical CVs and I am not the most creative of individuals, so keeping it clean and well formatted with consistent fonts usage and sizing

Length

I’ve heard a lot of people say different things about how long your CV should be. 1 side of A4… 2 sides of A4 but only if it’s printed double-sided, even “length doesn’t matter” because the more information you put in the better.

I would recommend taking a middle-of-the-road approach. Keeping things concise is paramount… but if you need 3 or 4 pages then that’s OK… as long as you make the content captivating and interesting for the reader, that is what matters

PDF

This one feels like it should be a “no brainier”… Make sure to submit your CV as a PDF!

There are two very good reasons behind this. First, it ensures that the reader will view it exactly as you intended. If you send it over as a Word, Google, OpenOffice or other such documents, then you are not guaranteed the reader will be using the exact same tools. I for one don’t use Word and an awful lot of presentation is lost because someone used a fancy word feature or have a font that I can’t get hold of.

Second, While it is not impossible it discourages recruiters from tampering with it and spoiling all your hard work. I have known only a few recruiters in my time that are willing to learn (or pay for) a good PDF editing suite. It is possible for them to alter things, but they tend to have to jump through hoops.

Beginnings

And so we have the start of My CV. Looks pretty boring, doesn’t it? Black text on a white background. Nothing fancy!

We have some basic contact details that can be used to contact me and a very short profile statement. That is all I feel an employer needs to see before we get into the next section of my CV. On the surface, it doesn’t actually say much but lets scratch a little deeper.

Font

I have specifically chosen a font that I think looks clean and professional, With a nice easy typeface, it becomes easy for an employer to scan the CV. I keep my CV in Google Docs so I went with Raleway, which I think is nice, clean, professional and easy to read.

I’ve also chosen consistent font sizes and spacing;

16 for the main title
14 for headings
12 for subheadings
11 for everything else

Limiting Liability

Middle-aged, liberal, heterosexual white male programmer Swipe right to Hire Me!!! Please!

It may sound odd but I put as little personal information in my CV as possible. Hence why just my name and contact details exist. I don’t mention my age, gender, race, driver status or political preferences. People come with inherent biases, that is just a fact of life. so putting as little as possible negates triggering these biases.

I’ve seen people put all sorts of information into CVs… a personal bugbear is photos. As they can introduce a massive amount of opinion in the eyes of the beholder. Think Tinder but for recruitment!

So unless specifically asked for I would strongly recommend keeping it to a minimum and using the space it would consume in selling the things that matter.

Profile statement

1 paragraph! that’s all I needed to say regarding what is effectively a personal statement. This is not a UCAS application and I don’t need to detail a million things about myself. What is to come next will be the real sales pitch

My profile statement focuses specifically on what my future employer is going to get from me if they hire me. Passion! It is a statement of intent, specifically written to demonstrate that I will strive to bring my “A game” to anything I do in the future and also that I intend to encourage those around me to do the same. In effect, it is the opening line to what is a sales pitch.

I could expand on this to state other goals and ambitions but that would just detract from the main objective of the CV. Plus we will get an opportunity to elaborate later on in the recruitment process.

Skills

Now we come to the meat and bones of the CV. This is the headline! the bit that you will tailor the most in order to impress whoever is scheduling those interviews and guarantee you a chance to shine. If you can make this captivating enough for the person you need to impress they will then be more than happy to read the rest

My CV has a LOT of skills listed. This is mainly because I’m a show off more than anything else and in reality, I will tailor this heavily to suit whatever role I’m applying for. For example, if it doesn’t have a requirement for managerial skills I would drop that section entirely. Depending on the required attributes and skills asked for I would happily add/remove bits to any section of my skills.

With different types of skills, I will define them differently. As you can see I am quite generic with Managerial skills. A lot of people understand these and are looking for confidence in your ability to do certain types of tasks. Technical skills define different aspects of what I do that are not specifically tied to languages. It can be very difficult to be curt and to the point here. I favour labelling a technology area and then listing a few of the most prominent or recent items from my repertoire. A bad example on my CV is databases… I can use quite a few as you can see, but in reality, I’ve been greedy by listing MySQL, MariaDB & Percona… they are all effectively connected to each other, but my need to show off is far too much for me to resist.

Experience

When I first started out as a Dev I had a hiring manager who once told me that most of the time the main thing he wanted to see was;

did the applicant have the skills he wanted
what was the candidates’ personal assessment of their ability
how much genuine commercial experience do they have

Three really simple things that stuck with me. So the next time I came to write my CV I added a table for Skills which had only a few things on it back then but has grown massively over the years. I’ve tweaked and tailored it over the years, adding and removing things that were relevant as needed.

By quite clearly labelling my own perception of my skills, I give the person reading it an indication of my potential value. It allows them to tailor the interviews and technical tests to fit me as an individual. It also acts as a double-edged sword as the higher I grade myself the more chance of falling flat on my face when I get asked a question I can’t answer… So it’s always better to try and be accurate, but also not to be timid, there are always other competitors in the recruitment race.

I favour using really simple words to identify my skill level; beginner, intermediate, expert and expert+. It makes it simple for the reader to gauge and also allows me to mix the terms around

Stating how many years of commercial experience you have lets the reader understand your commercial experience. The number of times I’ve had recruiters do a typical keyword match and see that I mention c# once on my CV and then try to wave a job advert under my nose. I did .NET for 6 months 10 odd years ago. I legitimately can claim that experience, but it should not be the core on which I base my next adventure.

As a useful side effect, by stating a duration in years prompts me to review and update my CV regularly to keep it up to date.

Previous Employment

By this point, I’m hoping that I’ve captured the readers’ imagination. That they now envision a Development God has graced them with a CV worthy of filling any role they have…

And then come back down to earth with a bump! Next up in the firing line is Work Experience. Here I define some of the previous positions I have held in my illustrious career in somewhat chronological order. I say some because I have a general rule of limiting what I put on the CV to either 10 years or 10 positions, whichever comes first. This hasn’t been a hard and fast rule over the years, and it’s fine to flex in order to suit the roles I’ve gone for. There is no reason whatsoever though to go so far back in time as to describe my time as a pot-washer when I was 17.

In some cases, I’ve also omitted some things from my CV. Somewhere in and around 2012 - 2015; I happened to found and run a co-working space in Manchester City Centre. It was an interesting venture that I’m really proud of and am glad to say is still running even though I’m no longer a part of it. But in truth, it does not add anything of value to my CV for the positions I plan to go for in the future.

To the point

I don’t like big sprawling paragraphs of text if you haven’t already got the gist. So for me, bullet points are the way forward. I try to keep it fairly obvious and detail achievements and document things I have done, and not the tools I have used.

I try to explain why I joined the company and what my purpose was. I highlight important successes and demonstrate improvements I made to the company. Short succinct sentences should be chosen to illustrate aspects of your accomplishments that actually relate to your future goals in your new position.

By doing it this way you also make it easier to tweak and change things without having to restructure a whole piece of prose in the future.

That said my own CV has a glaring exception! When I was doing freelance work I was not able to accurately describe everything I was doing due to some pesky Non Disclosure Agreements. So instead I have a simple paragraph providing a positive high-level explanation of what benefits I brought to my clients.

Formatting

There is a lot of information condensed into this section which makes could make it hard to read if left unformatted. I stuck to the font sizes I had chosen previously and decided to use a more subtle combination of indentation, italics, underline and bold to make it more pleasing to the eye and easier to scan.

Each company name acts as a subheading with a font size of 12. I take a little liberty and include on the same line the dates that I was with them. This gives a clear timeline of events that a manager can then refer to quickly when they need it, such as in an interview.

Indenting everything under a subheading makes it easier for the reader to separate out the content easily. I include an address for the company. I am not actually sure why if I’m honest, it’s just something I’ve always done. I put this in Italics mainly because it’s an aside to the core of the information.

The job title will come next in bold of course to help it stand out. Followed immediately by the relevant bullet points. My last role obviously plays the most prominent part as it’s my headliner. In the case of Medicines Discovery Catapult. I’ve held two roles, “DevOps Engineer” and “Head of Software Engineering” so I break these into their own sections within this piece of experience. Prior to that, I was with Wakelet and here I merge the two roles I held there in order to conserve space.

Education

The bulk of the hard work is now done! We have put in the sales pitch and hopefully, we are close to being invited to an interview. Time to put in some supporting information

This may come as a surprise to some people but I didn’t do the whole University thing… I mean I lived in a University city and frequented the student union bars, but was never actually enrolled in a course. To this effect, I bolstered my CV when I started out by going and obtaining some (now significantly outdated) professional certifications.

Regardless of my lack of educational achievements I would always recommend keeping it simple unless it is your first position and you have no work experience (writing a CV in that situation probably needs to be another blog post entirely). List them in chronological order with some dates and a summary of what you obtained… no one needs to know that I completely fluked getting a GCSE in Art.

Were I to have a Degree I would obviously have the institution and dates in there along with my final marks. I would also look at listing the modules I completed that are relevant to my career, providing I did a Computer Sciences degree and not something like Biology. Again, it’s all about keeping to the point and providing specific information to bolster everything else you may have done.

Wrapping up

Time to finish off with a little bit of something personal. I don’t want to spend too much time here but I want to show that there is more to who I am than just work. I decided to keep it simple, a simple list of things that I enjoy doing in my spare time (When I have any, being a father of 3). The idea here is that these can become conversation pieces with the people that may be interviewing you. I’ve ended up a number of times having interviews where I talk about Scouts.

The final flourish here should be something simple but gives someone a helping hand at learning more about you if they feel so inclined. I include a link to my blog and my GitHub account, but you could include anything that may be relevant.

Last but not least… References are always available on request. My referees are varied and have changed over time. Adding them to your CV doesn’t actually impart any other information that could get you hired. Name-dropping is not the right way to get a job.

Conclusion

OK! so it’s not a pretty CV by any stretch of the imagination. It’s a bit on the long side in its full un-tailored, raw form, though not as long as it could be if I wasn’t being diligent in how I want to present myself. But this is the format I’ve used as my CV for at least 15 years now and I would say that I’ve been really successful in getting interviews out of it. I would say I get at least an 80% success rate of conversions from seeing my CV to a first-stage interview (watch me now jinx myself for the future).

A CV will never get you the job! It’s all down to you excelling in an interview situation and proving how awesome you are and that you can do everything you say you can on your CV. All it is meant to do is get your foot in the door. Hopefully, this breakdown of my CV will help you to take a look at your own CV and work on ways to improve your chances.

A reboot and a legacy moniker

Tue, 26 Feb 2019 00:00:00 +0000

So… my last post was a good 2 years ago now…. Hi how have you been?

It’s been a very busy couple of years with a lot of stuff shifting in my personal life meaning things inevitably take a back seat. However its been long enough that I needed to give myself a new start and see about blogging again and getting back into speaking again.

Still PHPBoyScout?

Since 2016 I’ve jumped around in my career a lot! This has exposed me to a lot of new languages and tech, all of which has been awesome but it now means that the moniker of PHPBoyScout probably isn’t accurate all that much any more. That said I still have a love for PHP and my first thought when presented with a new challenge is still “How would I approach this using PHP?”, so I think that means I can keep my twitter handle for a little longer rather than re-brand myself :-D

I’ve always had a penchant for picking up languages pretty quickly and have been an advocate of the idea that as long as you can think in the right way then languages can be learnt easily enough.

Employed and Employable

October 2017 saw me take on a new role with a company called Medicines Discovery Catapult. They are a grant funded not for profit organisation that is specifically focused on shaking up the medicine discovery pipeline by helping SMEs & CROs innovate and collaborate.

My role is very broad as I appear to have fallen in to the role of Head of Software Engineering very quickly. Though I started as a DevOps Engineer it has evolved very quickly. We work with a wide array of languages and tools and nothing is off the table if it helps to solve the problems we are working on. Currently we actively have code being written in Python, Node, Go & Scala (I live in hope that I’ll be ale to bring PHP into that mix eventually). Vast data sets and AI are the name of the game with my team of engineers helping to support the data scientists and Informaticians.

At the time of writing we are also hiring so if you are curious take a look at https://md.catapult.org.uk/about/careers/ and see if you like the sound of what we are doing and the challenge on offer.

Moving forward

The plan moving forward is to post about the tech we are working with, talk about the types of challenges we are facing and also maybe restart my public speaking career. Stay tuned for more and if you don’t hear from me soon then give me a nudge

Goodbye Dev in Charge

Wed, 05 Aug 2015 00:00:00 +0000

Over all the time that I’ve been a developer I’ve had people telling me that I should get in front of an audience and speak. However I’ve always suffered from a rather bad case of ‘Imposter Syndrome’ which meant my automatic response to those kind of statements has always been… I don’t really know enough about any one topic.

This is very true, I’ve spent a lot of my career learning a really broad swathe of technologies and techniques so I can turn my hand to any task that’s been presented to me so far. Even so people continue to try convince me that it would be a worthwhile pursuit.

Now that I work at Magma Digital I find that I’m often talking with @phpcodemonkey about all sorts of things and the topic of creating a talk came up while we were enjoying the most excellent PHP South Coast Conference. He knows I’ve been a Scout Leader for around 4 years now, and he suggested that I do a talk on the ‘Boy Scout Rule’.

I don’t know if he was serious or not at the time but it set my mind racing! This is a topic that I actually know quite a lot about!

So I’m now going to leave behind the Dev in Charge and have now rebranded as the PHP Boy Scout. I’ve already managed to pull together the basis of a talk on how Scouting principles can be used in conjunction with what we do as Developers and have a few other ideas that I’m going to work on over the next few weeks.

Fingers crossed I will be better at doing this kind of thing than I suspect I will be… but nothing ventured and nothing gained!

Its time for a change

Tue, 02 Dec 2014 00:00:00 +0000

So… Its been a long time since I posted anything of any relevance. This is due to having been super busy with my previous company Zucchi.

However that has all changed now! After three and a half years of running my own company I have decided that its not for me. I gave it my all, but in the end I was becoming too much of a Salesman and I missed getting stuck in with code.

I’ve now moved on and have joined the fantastic team at Magma Digital who have been leaders in PHP software development for somewhere in the region of 14 years as well as heavily involved in the PHP community having been a essential part of the PHPNW user group and conference.

This means I should be able to pick up where I left off all those years ago and start being more active again.

See you soon