Craft and Cathedrals

http://brightonruby.com/2016/craft-and-cathedrals-jay-caines-gooby/

Hi, my name’s Jay and I’m going to be talking about craft and cathedrals.

The outline of the talk looks like this:

I want to talk about why I’m here, discuss a possibly loaded word: craft, and then talk a bit about cathedrals. I was going to own up to working on a monolith for a decade, but that will have to wait for another time…

I’ve got just five minutes, but I’ve tried to pack in some references to topics or ideas that might pique your interest, because that’s really the genesis of this talk.

I’m here, because at the start of the year, I decided to try some things that were out of my comfort zone…

This talk was originally subtitled “Designs that change over time”, and I had the idea, primarily because of some books that I’ve recently read.

Now, I like to read, I read a lot, but it’s a little err, niche…

But I’ve also been trying to read a lot more non-fiction, because learning new things or hearing about stuff outside your immediate bubble or set of skills is always a good thing.

Aaron Swartz put it much more eloquently: “Be curious. Read widely. Try new things. What people call intelligence just boils down to curiosity.”

So, amongst others, I’ve read these:

• Richard Sennett’s, The Craftsman
• Edmund De Waal’s, The White Road
• James Rebanks’, The Shepherd’s Life

And hence I’ve been reading about goldsmiths, master builders, potters and shepherds, and surprisingly some aspects of their work, or their working practices are actually relevant to us as software developers. Or at least, I hope to convince you that they are!

I’ve only got time to talk to you about Richard Sennett’s book, but I’ll happily speak to you about the other two, if you come and grab me later.

In Richard Sennett’s, The Craftsman (there is an apology for the gendering of the title, in the book), he talks about the idea of craftsmanship — the desire to do a job well for its own sake.

Now craft can be a loaded word, especially when people co-opt it to try and justify a way of working. Sarah, who’s here today, tweeted recently about this.

But I want to be clear that I’m not talking about craft in this sense! Richard Sennett’s book is purely about the art of doing something really well.

There’s a chapter about goldsmiths which I found particularly interesting. Goldsmiths would start their seven-year apprenticeships doing really basic jobs; weighing, mixing, heating, hammering, and learning by copying.

Years later, they would have acquired enough skills to become journeymen. Now a journeyman would quite literally journey around the country, working for different master goldsmiths in their studios, picking up new skills and techniques, making items that he might not have encountered before, that that particular studio specialised in; gold salt cellars, gold bowls, gold cups, gold bracelets… well, you get the idea.

Sennett talks about this journeyman period being the best time in a goldsmith’s career.

Eventually the journeyman would decide that they’d learnt enough and would want to become a master goldsmith in their own right, and subject to proving their skills to the guild, they would then set up their own studio, settle down, and invariably produce forevermore, the one or two gold items they had become known for.

Now I want you to think for a moment. Think about your journeyman phase of coding… Think about the time you first discovered Ruby or Rails.

Think about the time you first laboriously typed in a program line-by-line from a badly-printed book on BASIC, fixed some typos and got it to run.

Think about the time you first saw DHHs’ screencast, the first time you saw how jQuery just worked!, how you heard about a technique and successfully used it; do you remember that excitement? That sense of Yes! It works!

The journeyman phase of coding is a fun time, and it’s these moments of discovery and the feelings of success throughout your career that probably mean you keep going, keep learning, when in fact, coding can often be a Sisyphean task.

Or perhaps you’ve got a bit more experience, and you know what works for you and your clients. Perhaps you’re sat in your studio knocking out solid gold Rails apps?

This is a good time too — you’re confident with your skills and you’re happy to use them to make money or to keep your customers happy. But I bet you’re still learning, that there’s still a little-bit of the journeyman in you! And hopefully, if you are, and you have people working for or with you, that you’re helping them to better themselves…

The Ruby community itself might be said to be going through its own Master Goldsmith stage at the moment, and Avdi spoke at length about this in his Soul of Software talk at this conference last year.

So.. Cathedrals

Again, in his book, Sennett talks about the Master Builders (they’re always masters aren’t they, never mistresses) — the people who designed and built cathedrals. Well, when I say designed and built, I don’t really mean it. Because the building literally took hundreds of years. Like, many hundreds!

What’s the longest software project you can imagine? 5 years, 10 years, 25 years?

Hands up if you worked on a project for 6 months — 1 year — 5 years — 10 years?

Cologne cathedral took 630 years to complete!

Can you imagine starting a software project today, having a good idea of what that program should do and trusting it to generations of coders who will stick roughly to your vision, deliver it, and then not only does that code run, but it does pretty much what you originally expected it to do. That’s more than I can often do with my own code!

Returning briefly to the original subtitle for this talk, “Designs that change over time” — there’s a line in Sennett;

“The immense Salisbury Cathedral began, in 1220 as a set of stone posts and beams. The builders had a general idea of the cathedral’s eventual size, but no more”.

When I read this, I had an Aha! moment, because I remembered that Notre Dame in Paris looks very different to how it was originally meant to. My wife is an art-historian, so I know a lot more than I ought to about churches, columns and greek temples…

Notre Dame’s builders wanted to create a larger, more light-filled, beautiful interior, so they built higher and higher until the walls were unable to support themselves and started cracking from stress.

Because of this, the builders had to patch the cathedral, physically patch it with buttresses. It was one of the first buildings in the world to use flying buttresses. So these things that Notre Dame is arguably most famous for, are structural cruft! Perhaps we can feel a little less bad about some of our own monkey patching!

So how come medieval builders were able to do something — specify, design, build and deliver a project — that we as software developers are notoriously bad at?

Well, the process was pretty different for start. Turns out that building in winter is pretty horrible and stone masons really don’t like it. So your typical cathedral had two sprints a year; a six month building sprint during spring and summer, and then a further six month design sprint over autumn and winter.

The master builders would move in, on-site, and in many cases would literally sketch their designs out on the ground, at a 1 to 1 scale.

These designs would then be transferred to wooden templates which the stone masons would then copy, the next year.

So actually, if we only coded for six months of the year and then spent the next six months planning and prototyping, we probably would get some high-quality software! It might deviate a little from our original idea, but broadly it’s going to be fine.

Just don’t forget to tell your boss or the client that it might take a couple of hundred years and the work will be partially completed by your children and then finally finished by your grandchildren!

Thanks to Alice, Russell & Kim for their presentation templates.

And thanks very much for listening.