Cariad Eccleston

Just a gin-filled dork.

On coding, creative writing, peer-review and editors

21 January 2018

I’m on the cusp of sending a short story to an editor, and it’ll be the first time I’ve had a piece of creative writing reviewed by a professional.

I have some feelings about this!

My day-job

During the day, I’m a DevOps/lead software engineer. With a very shallow glance, I could say I:

  • Write design documentation on how I think new features should be built, and:
  • Write code to build new features.

…but that really tells far less than half the story. My days actually look more like:

  • Write design documentation on how I think new features should be built.
  • …but spend more time reviewing other peoples’ documents, to make sure I agree that their proposals are appropriate.
  • Write code to build new features.
  • …but spend more time reviewing other peoples’ code, to make sure it’s accurate, secure, and maintainable.

See, here’s the thing: every single document and every single line of code I write gets peer-reviewed by a team of professionals that I’m blessed to work with.

It’s difficult, sometimes. You’re not always in the mood to be told you could’ve done something better. But – oh boy – it pays off, and I wouldn’t give it up.

The bad old days

Back in the very early days – before I had a lead or senior title – I didn’t work in a team that did reviews. The aim of the game was to fix as many bugs as possible, without oversight to slow you down.

And can you guess what happened?

Sure, we fixed a lot of bugs. But:

  • Without checks on our work, we wrote terrible code.
  • Without reviews or feedback, we didn’t learn how to be better.

We kept writing the same junior-level code over and over again. There wasn’t a time set aside for someone with more knowledge than us to review our code and give us the benefit of their experience.

There are so many conversations back then that would’ve been immensely valuable to me, like:

  • “Here’s an edge case you haven’t considered…”
  • “If you write the function like this instead then you can write automated tests…”
  • “You can refactor these three functions into one…”

But without anyone to tell me these things, I didn’t have any fuel to improve.

The painful old days

Mind you, it’s only with the benefit of hindsight that I know that feedback would’ve be useful.

Because – of course – one day, we started peer-reviewing our code.

And it was painful.

I’m not sure if this is a controversial statement outside of the software industry, but: coding is a creative process. I mean that literally – as in, coders create things – but also in the way that it engages the same neighbourhoods of the brain that creative writing does.

Coding isn’t just a matter of sitting down and slamming out code until the application works, in exactly the same way that creative fiction writing isn’t a matter of sitting down and slamming out “And then this happens…” over and over again until the story is told.

So, with that said, I bet you can imagine how horrifically painful it is to pivot from absolute freedom of creative expression to having your work critiqued and torn apart by your colleagues.

I spent a lot of time as that junior developer having the senior folks tear apart my creative work and reconstruct it to fit their own styles. It hurt, because I suddenly wasn’t expressing myself any more, and everything I did wrong somehow in ways I didn’t understand. I felt restricted, and I felt stupid.

The better old days

The pain of the reviews wasn’t dulled by time. I didn’t have any personal epiphanies.

It’s just that – one day – I started getting code reviews from folks with awesome attitudes.

Rather than just rubber-stamping a “FAIL” on my work, they used it to start a conversation. They wanted to collaborate, and not mock. They were friendly, not aggressive. They took all the time I needed to understand why a few tweaks to my code would be awesome, rather than just suiting their personal taste.

It was a real whoa period of time for me, and the quality of my work shot through the roof. The number of “fixed” bugs being returned for more work dropped to almost none. As the team got collectively better and better, fewer bugs were raised overall. As we revisited old code, we used our new knowledge to instantly see how to make it more efficient, more maintainable, more secure, and more reliable.

And it was all down to the quality of the “editing” my work was getting.

Now, after ten years of collaborative coding, I’ve been promoted through to senior and finally lead. My code is pretty damned good. In fact, my employer has sent me across the UK and the USA to talk about my work and spread the good news.

Today, starting again

So, fifteen years ago, I started a software development career. I was entirely self-taught. I wrote amateurish code, and I didn’t get awesome until my work was critically reviewed by folks with more experience than I had. My pride took a kicking, but I love the results I have now because of it.

Flash forward to today.

I’m starting a creative writing career. I’m entirely self-taught. I write amateurish stories, and reckon I won’t get awesome until my work is critically reviewed by folks with more experience than I have.

And my pride will take a kicking, but I’ll love the result.

And hell yes I’m nervous about having an editor look at my work. I’ve called on a successful author and a good friend, and – more than anything else – I’m scared of my terrible writing leading to him thinking less of me.

But… every ounce of experience I’ve had with having my creative work reviewed tells me that’s not going to happen.

I’ve never worked with anyone who held a grudge over a code review. No friendships or personal opinions were ever harmed. Because – shockingly – we’re all professionals, and we all just want our friends and colleagues to be successful.