You might think the only things a typical journalist and software developer have in common are their computer keyboards and a vague lower back issue that turned up when they were in their early twenties.

But when I decided to ditch the newsroom after nearly ten years to commit to a lifetime of screaming at obscure console errors, I found myself better equipped than I had expected.

That’s not to say the journey from writing copy to writing code (hack to hacker, anyone? No?) wasn’t a completely gruelling uphill struggle, and I certainly would have rather come to my first year in software development equipped with the query skills of a data scientist (still don’t have them), the agile expertise of a project manager (still about as agile as a spanner) or perhaps the calm of a Zen monk (F$%K YOU VIM GAAAH).

Still, I’m here to say that accidentally doing the wrong job for a decade is a shiny feature of my career, not a bug. Here’s why:

Attention to detail
I spent a not insignificant chunk of my work life staring at copy with an eagle eye, looking for mistakes. Others may utter a mild but audible sigh when firing up a code review with 253 changed files, but not I – my laser focus will hold for just long enough to spot that console log you left on line 9,354.
A subeditors role is also to find clearer, more succinct and easier to read ways to write the same thing. Sound familiar? It’s everyone's favourite coding task: refactoring. My instincts for spotting which parts of your code are nonsense and unreadable are well honed – but don’t worry, I’ll tell you nicely – I’ve had years of practice.

Explaining the complicated
Most software teams are aglow with polite smiles and engineers saying ‘they think they sort of get it’ whenever someone attempts to communicate something tricky. But boiling down difficult concepts and stories to their bare bones is the stock in trade for journalists around the world. To put it another way; you have to become an expert in what you are writing about, and explain it to a non-expert in a way they can understand.

The first mantra they taught me in headline writing class was ‘simplify, then exaggerate’. There isn’t a lot of use for exaggeration in tech (and some would say journalists should lay off it too), but the skill of breaking something down to its most basic version has served me well already – my team mates might not understand why I’ve written such terrible code, but at least they understand what it does.

Cat-like curiosity
How do journalists find stories? Put simply, they are interested in things. They keep researching and asking questions about topics they are curious about. And eventually, they hit upon something so interesting that they decide to tell the wider world about it.

Tech people don’t have the burden of having to write up the things they learn on a deadline, but I see this same unquenchable determination to know about things in them. Engineers are constantly learning, whether doing a course on a new language or just Googling a method they haven’t seen before. Journalism and tech – both industries for the curious.

My favourite journalist, Simon Hattenstone, taught me that one of the best skills you can have when interviewing a source is to not be afraid to look like an idiot. By asking them to explain everything to you, you better serve the reader and often learn far more yourself. And so it is in tech; pretending to know more than you do can only hamper your learning, so you can’t be afraid to play the fool and ask for explanations, even if you half-understand. And just to clarify for any of my colleagues reading this – yes I have just been pretending to be an idiot this whole time. Honest.

Final thoughts
One final crumb of insight from the newsroom before I leave you; when you write a news story, you never really add a neat ending or conclusion because you don’t know where the editor is going to have to cut the story to fit it on the page. And so quite often when you read an article, it just suddenly, and unsatisfyingly, ends.