REFACTORING 2018

For the uninitiated, could you tell us what Refactoring is?

Refactoring is evolving code to make it easier to understand and easier to change over time. Make the code communicate clearly what it’s doing. It’s a core practice in agile programming, and not just one to use on legacy code - it’s a key skill for any programmer who wants to write clear, readable programmes. Everyone who can code can, and should, refactor.

Why revisit Refactoring, after almost 20 years?

Well, lots of reasons. Firstly, the book is showing its age. The kind of Java that the original talks about is pretty foreign to most Java programmers today. Yet refactoring is still relevant, in fact, increasingly relevant, as a technique. There are still huge numbers of people coming into programming, and so there is still the need for an introductory book that teaches people the technique.

Importantly for me though, there are people from different backgrounds coming into the programming industry, which books like these support. One of the things that's often concerns me is how does somebody get into the software development world without necessarily going to some expensive college? I feel we need to provide other paths.

And, finally, the desire to take the book away from it’s class-centred route, which we discuss in more detail here.

What was your path into Software development?

I was really lucky. When I was 18, at that time in the UK you could get into a top University and not have to take on a huge amount of debt. So, from a working class background, I was able to make that happen.

It’s frightening now, to see the amount of debt that has to be taken on to undertake a degree, especially at a top level college (in the States, but increasingly in other countries too). It horrifies me, honestly. And it’s not necessary.

What advice would you give someone without a CS background?

Off the top of my head... most importantly, don’t worry about not having a CS degree. A lot of the stuff I was taught, and is still taught today, was handy, but hardly the most important. Don’t ever let a lack of formal training put you off. I question the need for the traditional maths background.

Why? Because good software development has as much to do with communicating with other people as anything else. Comms skills, and being able to take on ideas are really important.

It’s also really important to go on a continuous learning path - you will never stop learning because software is constantly changing. The ability to learn and absorb things is key.

Then you need a lot of persistence. Because making software is like that - trial and error, breaking things, trying something else. Not giving up, pushing forwards.

So comm skills, pushing through, ability to learn. And finally, somewhere in there is a sense of taking something complicated, and making it clear and simple.

How do you balance your views with community wisdom when you’re writing?

With any book, reviews are hugely important. I set up an advisory group - people I somewhat knew, and whose work I respected, and who would give good feedback. I’m not that familiar with all the corners of the JS community, and I wanted to make sure I had people who could feedback on those elements.

They gave me comments on each refactoring – just through a simple mailing list – and were a very useful source of information.

How do you distinguish the signal from the noise?

I find good people to listen to. There are lots of good people out there, doing this, you don’t have to cover all the ground yourself. This is why I like being at Thoughtworks. While the most obvious form of filtering is the radar, which is all about pulling the signal, I do it much more informally. I know lots of good tech people at Thoughtworks and chat to them about what’s interesting.

My advice is to develop your instinct for finding the right people to listen to.

What’s your advice for budding writers?

The most important thing is practice. Blog. Write things down. Your first draft is almost certainly not what you want to publish. Re-work the words and the ideas.

Writing is just like programming, just keep iterating. It’s perseverance, but also recognising when it’s time to ship. That’s a frightening thing with a book, as you can’t change it. But be confident about the fact that in most media you can change it.

Find people to give feedback. Good reviewers are worth their weight in gold. At Thoughtworks we’re lucky, we have the software dev mailing list, a global group of techies, now in its thousands, who are thoughtful and responsive – many a discussion on that list has provided me with excellent feedback. You’ll need someone who is detailed and challenges you. That kind of feedback is worth so much. And worth the effort to pay attention to!

So, where is the tech going?

I’m not a futurist - I’m an intellectual dumpster diver. I look at things in the past that have not been done as much as they should be, and shine a light on them.

What now for you?

It’s now my task to get this book out (Autumn / Fall 2018). I’ve been so focused for 2 years, I’m looking forward to taking the blinkers off and seeing what catches my attention. I’m open to see what comes next, but I’m not allowed to look until later this summer.