Ruby code and why you should care

Ruby is the primary programming language that Consonance is written in, chosen for its readability and maturity. And last month, we were lucky enough to spend a thought-provoking and inspiring two days at the 2018 Bath Ruby conference.

I know that if you’re reading this post, you’re likely more interested in books than code. But I think you would have enjoyed the conference.

Because so much of Ruby is about the things that bookish people love. Ruby is about story, and its shifting shapes. It’s about becoming lost in something so beautiful you forget about time. It’s about feeling that you belong, and that your work matters, and that whilst much in the world might be awful, there are pockets that you can carve out for yourself which make everything worthwhile.

In the same way that books have history – and by books I mean everything from story and character to author relationships and production values – Ruby has history. There’s a rich, deep context to this language’s development and use which gives it grace and humility.

Publishing, as an industry, is not a fad or a flash in the pan. It has the quiet, solid confidence that comes from having been around for 500-odd years. In absolute terms, the Ruby programming language is young: a mere 25 years old this year. But in computer years, that’s about as established as it gets. And Ruby has the feeling, like book publishing, that we’re all in it for the long term. We can sagely ride the peaks and troughs of fashion, and wisely tolerate the bright frenzy of the new, because there are timeless truths at work.

Those truths will be familiar to you. The importance of clear words to convey complex thoughts, simply. The need to be kind to those around you, in order to get their best work. The fact that it’s the dance, not the destination, which matters. The idea that it’s the relationship between notes, not the individual notes, which make music.

The reason why I wanted to mention that we’d been to a Ruby conference, though, was not to draw parallels between code and books, fascinating and relevant though it is. It was to explain why you should care about our code.

One line in one talk in particular jumped out for me at Bath Ruby. Valerie Woolard, in her talk about code and coding as art, said your clients don’t care about your code. Only you care about your code.

This troubles me. She’s right. Why should you care about our code? It’s like me caring about what sort of pipes the plumber uses when they come round to fix a leak: just so long as the tools they use stop the leak that’s wrecking the furniture, I don’t care.

But our code affects you a lot more than the plumber’s choice of pipes affects me.

Not all code is created equal

Before I was a programmer, I fell into the trap of thinking that code was code: it either existed or it didn’t. I failed to realise there could be good code and bad code. You can have two web pages that, to the casual observer, look exactly the same and do exactly the same thing. But the code that renders them can either be diabolically complex, repetitious and strangely structured, or elegant, terse and readable. You might not see the difference, but it matters what’s under the hood, because the quality of the code affects how easy it is to edit, and how likely it is to break with new data, system upgrades and interactions.

Not all programmers are created equal

I also fell into the trap of thinking that programming was programming: you could either do it or you couldn’t. Of course, turns out reality is more complex. The gulf in capability between a struggling beginner and someone with thirty years’ experience is vast. And there’s nothing to say that becoming a good programmer is a function of sheer hours put in. There are plenty of okay programmers who’ve been at it for years. What I feel is that good programmers are those who work hard to understand the fundamentals of their specialism, such as object orientation, and apply that to their daily work. That means a lot of admitting that you’re wrong and being open to change: not traits that everyone is blessed with.

Not all teams are created equal

There are yet more things I didn’t realise. Good code is created by a team, not an individual. It’s the process of conversation, of peer review, of coaching up and down and sideways, of being able to change your mind without embarrassment, of having honest conversations without ego, that creates good code.

Good code doesn’t write itself

What is good code? It’s readable. Simple. Considerate to others of all abilities. The sort of code that does what it says on the tin. It’s well-structured, well-tested, so that if later code breaks it, an alarm goes off. The famous Mark Twain quote about not having enough time to write a short letter, so he wrote a long one, holds true: good code, like good writing, is the result of editing, reflection, redrafts and rigour. It’s the result of craft.

Good code comes from the right environment

So good code doesn’t happen unless you put the infrastructure in place for it to be created. We still have some legacy code from the very early days, but then we built the right team, the right working environment, the right strategic message that says where we work, quality is the most important thing. We don’t have client-facing deadlines. We don’t have death marches. We’re not flat-out perfectionists because then nothing would get shipped, but we don’t cut corners and accrue technical debt.

Good code futureproofs you

Why should you care? The code we write is good and maintainable, which means that when you contact us to ask for a change or an improvement, we can probably incorporate that change because we have built the code to be edited. It’s not a dangerously-teetering stack of cards, brittle to the touch. It’s well-organised, with test coverage and sensible conventions.

And because we write good code, we’ll also know when it’s wrong to incorporate your suggestion – because our spidey-sense will tell us that it would result in a garbled interface, strange convention-breaking or misplaced complexity. Much better to enquire what the business reason is for your suggestion to get to the root of the problem and fix that, than expect our customers to be systems architects.

This is a rather strange conference write-up, being about code quality rather than the actual talks per se, but the thing about Ruby is that it gets you thinking. And I write this on the eve of the London Book Fair 2018 – another event in the calendar that gives one a chance for reflection and inspiration, for seeing the bigger picture and the shape of the winds of change.

We’re one of the more technically-minded teams present at the book fair, I expect. Perhaps people like us are meant to embrace and exploit trends such as blockchain and the like. But that’s not for me. Craft, harmony, pride and doing the job properly have to define the future so that the code we write, that our customers rely on, rides out shrill trends and remains solid, planted and long-lived: just like the book trade, just like Ruby.

Are your current systems sabotaging your growth ambitions? Are you hungry to implement new business models, but concerned you lack the strong administrative foundations needed for innovation?

We're always amazed at how resigned publishers have had to become to the low bar in publishing management systems. Demand more.