Craftsmanship: Code, Guitars & Tech

Writing music, building guitars and writing software share more similarities than one would imagine at first.
Kevlin Henney, an independent consultant, chats with Dylan Beattie, creator of the Rockstar programming language, and Hannes Lowette, head of learning & development at Axxes, about the craftsmanship and creativity that is required from them. They showcase Hannes’ self-made guitar, the importance of making decisions at the right point in time or how there isn’t a default for solving problems in either of these domains, but rather a personalized and evolving approach.

---

Intro

Kevlin Henney: Good morning, good evening, wherever you are, wherever you are. Welcome to another "GOTO Unscripted." My name is Kevlin Henney. This is Dylan Beattie. This is Hannes Lowette.

Dylan Beattie: Hello.

Kevlin Henney: And I'm going to get these guys to introduce themselves and I'll introduce myself. We're going to talk about tech, guitars, music, and interrelationships.

Dylan Beattie: Guitars are tech.

Kevlin Henney: Guitars are tech. It's very true.

Dylan Beattie: Guitars are very technical.

Kevlin Henney: Dylan, introduce yourself.

Hannes Lowette: Especially if you're a Matt Bellamy, then guitars are, like, hi-tech.

Dylan Beattie: Well, we can talk about him because he does weird things with guitars. But, yes, hello. I'm Dylan Beattie, and I never know what to write when they put "job title" on the form. I write code, I make music, I make music about code. I travel around the world and I talk about it. And today we're talking code, and guitars, and technology, and all kinds of interesting things related to that. And, Hannes.

Hannes Lowette: My name is Hannes. I've been writing software for, like, a decade and a half. I started speaking about writing software a couple of years ago, just before COVID. And I enjoy the finer arts of writing code and building guitars. So I guess that's what brings me here.

Dylan Beattie: Cool. All right.

Kevlin Henney: My name is Kevlin Henney. I've been writing code for far too long.

Dylan Beattie: Hannes said a decade and a half?

Hannes Lowette: Yes. That's, like, nothing.

Kevlin Henney: And I managed to not play guitar for 25 years. There was a brief hiatus in the middle there. But my interest in terms of...let's talk about job titles, I don't know, either. Dylan Beattie and I work for ourselves, and it's just like, "Well, what do you wanna be this week?" Is just that…

Dylan Beattie: Chief everything officer.

Kevlin Henney: Chief everything officer. Chief lavatorial attendant. So there are lots of possibilities there. I have this interest in the relationship between skills, particularly transfer, because a couple of other interests that I have, fiction writing, short fiction and just trying to see, it's just like, this is interesting. Learning about this helps me with that, or to be precise, gives me another perspective.

It's like standing to one side and going, "They do this here, and they do the same thing there. I wonder if it's for the same reason." Or, "They do this here. They do that differently over there. I wonder why that is." And it's interesting because there's a lot of that with software, software as information stuff.

Similarities between code and music

Dylan Beattie: Something that I've often wondered there, it seems to me...and this is anecdotal, I don't have stats to back this up. But…

Kevlin Henney: We can make some up.

Dylan Beattie: ...if you get chatting to someone who's a musician, there's a better than average chance that they are also technical. They program or they've hacked around with code. And vice versa. I think there are more musicians in something like a software conference audience than you would find in the same sample of the normal population. And I've often wondered, is that because there is something about certain people's brains that's just, you know, code and music are ephemeral thought stuff? There's nothing solid. There's nothing tangible that you can touch and interact with.

And so, is that that certain people's brains are good at working at these kinds of ethereal abstractions, or is it that those are the things that you get into if you're a lonely teenager with no mates, who spends a lot of time doing stuff you can do on your own at home, and we just end up getting good at it?

Hannes Lowette: I think there's even a third factor here. Getting good at coding and to get good at playing music, takes a lot of practice. Somebody can explain to you how you produce the notes or how you construct a class, but to build a song out of notes, and how to build a working software system out of those classes, takes practice, especially if you don't want to get stuck in the mess that you created yourself.

Dylan Beattie: I think practice is interesting, but the massive difference between the two things for me is getting good at a musical instrument means being able to do the same thing consistently, to be able to repeat and reproduce a performance. There's improvisation and other things, but someone who can't play the same thing twice is probably on slightly thin ice when it comes to, "I know I'm a good guitar player, or piano player," or something. Whereas in software, if you write the same program twice, that's a waste of time. You're not supposed to do that. The craft of learning to play the guitar is like the craft of learning to type. And then everything else is what do you do with it after that point?

Recommended talk: Get Ready to Rock with Sonic Pi - The Live Coding Music Synth for Everyone • Sam Aaron • GOTO 2018

Kevlin Henney: Well, I think there's another interesting one, one of those things that, "They do that here but not over there," type things. That idea of repeating things, I do think, has value in software. It's just trying to find the level at which it is. Something I've done in several workshops is to get people to do the same thing again based on the principle. You know, and actually, it's interesting because I say, "Okay, some of you probably play a musical instrument. If I've done the round of introductions, yes, statistically," you know. And sometimes you even have in the room, or in the Zoom, you even have enough people to form a band, just like we have a drummer this time. Also, we've got two basses.

So you've got that, but there's that idea of like, well, you don't just play it once and go, "Yeah, I'm done." It's a case, "And what does that get you if that's the first time you encountered something?" So whenever I give people a kind of problem to work on, it's a case of like, if it's sufficiently small, I say, "Okay, that's really go's do that one again, because let's list of the number of things that were new to you, the whole idea of whatever it is that we're learning was new to you."

Probably the environment in which we're doing it, the problem itself was new, all of these things are new. So now you've seen them once. And we've gone through everybody's solutions, let's do that again with that knowledge.

Hannes Lowette: Make it conscious.

Kevlin Henney: Yes. And, sort of, lay that down. That's the thing they do in other disciplines, but perhaps we don't do enough of it in software. We could do a bit more of it. We don't want to end up recreating…

Code Kata

Dylan Beattie: Is this what they call code Kata?

Kevlin Henney: Yes. Code Kata and beyond. Then also nudging those. "Okay, just so you don't get your comfort zone, let's move that out a little bit." And there's another element, I think, there's a crossover with music. And I think it's an interesting one because there's the playing the same thing again, and people like to talk about music always having a language. But how many people get the opportunity to speak in that? There's a huge variation among people that play musical instruments. There are the people who are very, very good.

I've even seen this broken down, classical versus jazz, very, very good at reproducing that. That's what they shove them inside an MRI and their brain lights up when they get it right. That is their reward mechanism, whereas, improvisational-based approaches, it just knows the reward comes from creating something new. In other words, it's like last time, but not necessarily exactly. And I'm gonna take a little deviation here, and that becomes its reward. But many people don't explore that side of music as much.

Hannes Lowette: That is something that always struck me about piano music, for instance. If you hear an adequately skilled pianist and they play a classical piece, and they play all the right notes, it's good. But then you get a skilled pianist who can put the slight deviations and timing, they can do the phrasing right. They're playing the same notes in the same order, but suddenly it becomes something that makes you feel something. Is that what you're trying to get? 

Kevlin Henney: Yes. It's just like let's vary this and try something different. So the thing with coding Kata that sometimes people fall into is they end up doing it the same way and then get bored of it, whereas I'm trying to then say, okay, yeah, now we've understood the ground level. It's like with a piece of music "Okay, I've got a sense of where the chord's going. Let's try noodling around a little bit because I've got a solid base I can build on. Let's just try pushing the boundaries and then doing things that are sometimes within expectation." But also sometimes, "This is wrong." And that would be wrong by somebody else's move, but actually, it creates something good.

Dylan Beattie: There's an interesting...guitarists are learning to play fast. For certain kinds of music, jazz, and rock and metal music, being able to play fast is something a lot of people aspire to. The accepted wisdom is, well, to be able to play fast, first, you have to play slowly and then you speed it up. So you learn the whole piece with a metronome and then you increase the speed on the metronome.

I was trying to learn the solo for "The Final Countdown" by Europe and just couldn't get it because it's very, very fast. And I found a tutorial on YouTube was saying, "This is nonsense, you know. Being able to play it slowly, now, what you got to do is hit the thing at full speed and see how far you get, and go back and hit it at full speed and see how far you get," because being able to play it slowly does not...there's a paradigm shift in the technique you have to use. And your fingers will not do the slow thing fast. And so knowing, yeah, you know the music, you know the melody, but that doesn't help you with the physical technique required to play it.

I thought, it was just a sort of fascinating counter-perspective on what I've always perceived to be the accepted wisdom, that the way to learn music is to learn the piece slowly and then speed it up. I thought that was interesting.

Recommended talk: Software Is Details • Kevlin Henney • GOTO 2020

Kevlin Henney: There's an interesting thing in there, so, kind of, bring it back to the software space, that notion that sometimes you can have two contradictory pieces of advice and they are both in one sense correct. 

Hannes Lowette: That has never happened in software.

Kevlin Henney: Yes. They are both appropriate, but there's a contextual aspect. And more of the point, you've got to go at it with more than one idea. There's an idea of like, "Well, I've tried it that way, and this is the way I've been told." And that's what...my concern sometimes when we teach people or mentor people. Is that balance of advice of, kind of, like, "I'm gonna show you a way, and I don't tell you it is the way, but I'm gonna show you a way because it allows you to make progress. And then you're gonna discover contradictions and variations, and all the rest of it, but don't get too attached to the way that I've shown you."

But you can't just say or do whatever, because they don't know where to start, because, at that point, it's not just that everything is possible. A computer is a device with profound possibilities. Give somebody a programming language, and technically you can do anything.

But the problem here is somebody's trying to do something. They don't want to do anything. At that moment, they want to do something, and they need a little bit of guidance before they're able to break out. But one way might be the right way today, or for this kind of problem. But you've got to have that open mind and say because you've always got to watch out. If somebody says, "I've always done it this way. Every time I learn a new language, every time...oh, whenever we start a project, we always start with this stack. And we've always done it that way." The minute you hear that, you've got to go, "You know what? You might want to try something different."

The creative aspect of code and music

Hannes Lowette: I loved Woody Zuill's take on this. You know Woody, right? Mob programming. He says that if you have conflicting opinions in the team on how to do something...and in mob program, you're going at it with the full team in the same room, on the same computer, so you're all doing it together. Instead of wasting time discussing, what you do is you just do both and then pick as a team, like, which one you like.

You just make two branches in Git. It's not hard to do. And for maximum learning, start with the junior's idea first. Like, do that first. And then see if the seniors learn something maybe another way than the thing that they're stuck in repeating over, and over, and over again, it's like, "Oh, maybe we can also do it this way." Or the junior will learn from the second attempt where they will, like, go at it differently.

But I always like this idea of, instead of discussing, why don't we experiment and try and see what works for us, instead of being fixed in our status quo and the things that we've always done the same way. For me, very much is one of the reasons that I like writing software. Is, like, we get to do different stuff every time. It's like a different business problem you're trying to solve, you're using different frameworks, you're using different patterns, you're working with different people. But every time and again, you're creating value out of something that wasn't there before. You're building something.

And to be able to do that same thing, like solve a business problem with the software in so many different ways, and learn new ways every time, is what has kept me triggered in the software industry for as long as I've been doing it. And I don't see myself getting bored anywhere soon.

Kevlin Henney: Now, there's an interesting crossover. Woody plays guitar. He works in a guitar shop.

Hannes Lowette: He's also a very good woodworker.

Kevlin Henney: Yes. He's the full deal. Let's just learn this straight back. So, in software, we have this whole software craft kind of thing. It's a metaphor that we apply. And we use metaphors everywhere in software because otherwise, we can't talk about anything. 

I remember realizing this once on a system. The penny dropped for me when I suddenly realized, that in our system, we have four different things called networks. And we're dealing with an electricity network, we are dealing with a TCP/IP network, we are dealing with a mathematical construct graph. It's called network, and there was one other.

And I suddenly thought, and yet not one of them is a network. A network is a thing used...it's an older English word for "net." You use it to catch fish. None of these are for catching fish. And I just sat back looking at the windows on my system, and it's just like the desktop. And dealing with sockets and port, and it's just like, you know what? Every single damn thing...oh, file system, everything is a metaphor. So without metaphors, we can't talk about anything. But we import these things. We've got architecture, we've got craft and all the rest of it, but I always find it fascinating, and it's another one of those like, move over here, see what they're doing over there.

When I started the short fiction stuff, one of the most fascinating things I found was that in the creative writing space, they refer to what they do as the craft. Not the craft of writing. We don't bother with extra words. It is just the craft. When you hear somebody talk of the craft, they are talking about witches' covens, or they are talking about writing. It's one of the few things, it's just I'm fascinated by this kind of the whole thing. Given that we're aspiring to this, or keep borrowing these things, what can we learn from over there?

Now, when it comes to woodworking, I still have all of the digits that I was born with. However, I think that's a pretty close-run thing. That's not an area of...that's a physical thing. So we're moving out of the information and virtual space, but what I like is that …We talked about Woody, he's a good woodworker. You've built a couple of guitars yourself.

Recommended talk: The Art of Code • Dylan Beattie • GOTO 2020

Hannes Lowette: I have.

Kevlin Henney: So this is not just walking the walk and talking the talk. This is crafting the craft.

Hannes Lowette: No. And in many ways, building guitars and writing codes are similar.

Dylan Beattie: And in many ways, they are completely different.

Hannes Lowette: They're completely different. Yeah. When I first get into the whole crafting, to me the world of building guitars, or woodworking in general, is an industry that has been around for a very, very, very long time. They have figured out how to do things. They have had this whole trial and error stage behind them where they learned how to not split the wood when you're using a chisel, and what kind of planes you use to do cross-grain and to go with the grain, and all that kind of stuff.

So there is a proper way of doing certain things. And what you're building doesn't matter. I mean, the techniques that you're going to be using are different. It's going to be the same every time, over and over. Whereas in software, we are a very young industry. And we are still figuring out which techniques work for which problems, which is why I've seen so many teams shoot themselves in the foot looking at, what are the big guys doing? Like, looking around, seeing, what are they doing over there? What do they look at? They look at Netflix, Spotify, whatever, but they don't stop to wonder, like, "Okay, which problems are they solving? Are they my problems? Do their techniques apply to the problem that we are trying to solve here?"

So they shoot their foot because they're faced with a different set of problems, but they're just trying to figure it out. I think part of this is because we're still too young of an industry to have a defined set of rules that we can teach newcomers, like, "If you go about this type of problem, this is the way that you can solve it. And this type of problem requires a different type of solution."

Solving problems

Kevlin Henney: I'm gonna offer a different take on that because that one is one I've wrestled with for several years. I have a slightly different take on it. I don't think we are a young professional. I think we're just immature, and there's a big difference. It's the difference between growing old and growing up. We run the planet, software runs the planet.

Hannes Lowette: You're just seeing that because you're growing old, right?

Kevlin Henney: Shh. They will notice. But there is this whole thing, software development is older than any of us. There are lots of professions that I simply do not know the names of these days, that are significantly younger. Well, there are millions upon millions of people writing software.

Dylan Beattie: You know influencer isn't a real thing, right? That's not a profession

Kevlin Henney: I've got to tell my kids that. Yes. It's not a real thing. But that's the point, is that we have…

Hannes Lowette: But that worries me. I have three kids and two of them want to be a YouTuber when they grow up. It's like, "Oh, that's..."

Dylan Beattie: Good luck with that.

Hannes Lowette: Yes.

Kevlin Henney: Yeah. It's a game of probabilities. Yes, indeed. Luck is everything. So that's the thing, is I don't think we are a young profession. We're older than a lot of the professions that people have jobs in. I think it comes more to the point of the consolidation. In other words, consolidating around something. And we have a very poor sense of history.

That's one of the things, I think, in instrument making which I find fascinating as an outsider, is, along with many other crafts, there's a traceable history. When we look at architecture, if you're learning architecture, there is a traceable history. All of these things have a strong...now, we have a history, but we told ourselves we're so young we don't. But actually, I've done several talks where I say, "This idea..."

There's a talk I'm gonna be doing on concurrency and stuff. And it's, kind of, partly triggered by reading something that said, "Oh, let's talk about new technologies like coroutines." Coroutines were invented in 1958. They pre-date pretty much everything. And it's just like we have a very poor sense of history, which is why we have the sense that we are rudderless.

Most of the problems that people are encountering they've all been solved. There's a whole load of problems every...that have been solved. And so, there's an issue here, propagation of knowledge. I think that there is that. If we look at something like woodcraft, there's, like, much better propagation of knowledge within a core community there than perhaps we have within the software. So I think we're just immature. I don't know.

Dylan Beattie: I agree with you that we as an industry have a massive problem with people not understanding history. But then the flip side to that, I remember learning woodwork at school, and the techniques that I learned in 1992 about how to create something and make something out of wood are absolutely, directly still valid and relevant today. The IT I learned in 1992 is obsolete. You can't even buy computers. I learned to do BBC BASIC, which I think we were working on. Now, you know, something I think is interesting, we're taking a step back, is, like, you know, there are professional developers out there right now who weren't born when I started programming.

People are being born right now who we want to get those people to the point of being competent, trustworthy professionals, kind of, as efficiently as possible without a lot of dead ends. And we saw Rich Campbell yesterday doing the keynote in NDC. I've seen a couple of things. Talking about leapfrogging, talking about...never mind the next big thing. How do we start thinking now about the two, three, or four generations ahead?

And never mind, like, you've got a room full of 18-year-olds and you want to help them be professionals by the time they're 22. What do you do with the people who are being born this year in terms of making sure that when they get to that point, they've learned the relevant history, they've learned the problem-solving techniques, and, you know, the data structures?

I think the other big challenge that we have as an industry is so much of understanding the context and the history is about learning things that you should never do. We should understand how to create a relational database, but most of the time now people don't do that by hand. We should understand encryption, but never roll your cryptosystem, because you're not smart enough to do that. And there's only one of you, and you're not smart enough to know whether it's any good or not.

Recommended talk: Don’t Get Blamed for Your Choices • Hannes Lowette • GOTO 2020

Hannes Lowette: There's, like, a tremendous amount of gatekeeping going on in our industry, as well. It's like because I had to do these things by hand, the juniors that I am teaching should first learn how to do these things by hand before they learn the newfangled way of having a framework, or a library, or whatever that solves that problem for them.

Dylan Beattie: "Good morning, children. Today we're learning about the IIS Metabase."

Hannes Lowette: Exactly. History is important. And the "why" is important. But, like, learning everything over again, I think it's not a good system of getting new guys up to speed and being productive programmers.

Kevlin Henney: I think that's the interesting thing, is there's the personal history and then there are the lessons of history. And there's a very strong tendency to read...so going back to 1992, pretty much everything I learned in software development is still applicable. Not the programming languages I was using, not the platforms I was using, but the funny thing is all of the books that, if I go back...and it's finding the level of detail that you pick. This is one of those things in music and music theory, is that sometimes we learn too intimately without being able to take a step back. It's just, like, that allows you to generalize. And there is this interesting idea of, like, learning at the right level.

Now, something like woodwork is a very physical thing, and there's a difference there that we don't have the levelness issue that we have in software because there's a point...which, ultimately, everything becomes true. But that's the thing I find fascinating again…

Hannes Lowette: Well, you're gonna use different tools when you're chopping down a log into pieces that you can handle to start processing than when you're, like, carving out an inlay into an already planned piece of wood. So there are still levels, but they're different.

Diversity in tech

Kevlin Henney: Yes. But inlays are still inlays, and that vocabulary is...whereas in software, there's always taking a step back because it goes...actually, Dylan mentioned it in terms of abstractions earlier on, and that's exactly the right kind of way of looking at.

So, again it's one of those interesting differences. There's a groundedness, or chopping the tree out of the ground, a groundedness to this stuff, but also with actually physically making music. But there's another level at which the music does conform to the abstract, the music itself if you like. So this is kind of an interesting idea, in terms of improvisation, or what are the stable chord things? What is it to make a song? That kind of idea. And there's this kind of idea that has been discussed but is still evolving. There are still parts of music that are very stuck in whatever they do, and there are still parts to gate-keep.

Hannes and I were actually on the way over here, we were talking a little bit about this. And I mentioned that, unfortunately, for reasons of COVID, I ended up missing a Skunk Anansie gig last month. And if you don't know who Skunk Anansie is, go and check them out.

Hannes Lowette: Listen to the "Post Orgasmic Chill" album. That's a masterpiece.

Kevlin Henney: Yes. So innovative, and you point out that they're massively underrated for their contribution in the 1990s. And they were. A lot of it was to do with gatekeeping. There is no doubt that that band, for example, was a rock band, but in the U.S., they were filed under dance because the lead singer is black. And it's just like, oh, okay, I wonder if that happens in music. Yes, all over. To what extent? Do we do that in software? As well as just an old guy.

Hannes Lowette: They did. They just managed to defuse quite a couple of genres in their music, but, like, dance wasn't one of them.

Dylan Beattie: I was talking with some folks. I was at Jfokus in Stockholm last week, and we had an impromptu session about diversity and inclusivity. And one of the themes that came up in that conversation was particularly women at conferences speaking about things like UX design. There's a sort of perception that that's not technical enough. And I'm, sort of, thinking, have you seen the software that we had before people started doing UX? It was horrible.

Kevlin Henney: It puts the X in front of UX.

Hannes Lowette: I made some of that software.

Dylan Beattie: You look at the gatekeeping that goes on in elements of the tech industry. You're like, "You're not good enough to defend the thing you think is precious, because we've seen what you create left to your own devices. And it is insecure, and it is unusable, and it is hostile." And you're there going, "No. This is ours. You're not good enough to contribute."

Kevlin Henney: UX is one. Testing is another one. There's a massive amount of gatekeeping against it. I like to think it is changing. I do detect there is change. But I've certainly been involved in dealing with companies that, sort of, say, "Well, we get a whole lot of developers, and then we make them all testers. Then the ones that are good become developers." And it's just like, "Hmm. Yeah. And I bet you reflect that in your pay grades, as well."

And yet, surely testing is somewhat the most...you know, you go to another profession, "Let's put the word 'test' in front of the word 'pilot.' how skilled is that individual?" And suddenly you realize there is an inversion here. It's like, well, why is that not the case here? Surely, to be able to understand something, to be able to stand outside it and say, "I see this as a whole, and this is how this should work." "Ah, and this doesn't." Again, that's exactly the UX thing. It is like, conceptually, how should this feel like a human being working with this?

Recommended talk: Re-engineering Inclusion • Jill Wetzler • GOTO 2019

Dylan Beattie: An interesting parallel just occurred to me. So, the question would be, would you rather have a team of mediocre developers but good testers, or a team of very, very capable developers with very little in the way of testing going on? And it occurred to me this is, like musicians going into a studio with a producer, because some of the best and most influential albums of all time have been a bunch of musicians who were homeless drug addicts, let's face it. And the record company is like, "You need to get them in and you need to make them work. And you need to get this stuff down on record."

There are also, conversely, a lot of stuff, and, you know, I put my hand up, I've done this, where you know what you're doing in terms of playing it, but you have no idea how studio production works. So you just plug the guitar and you record it, and you're like, "That doesn't sound very nice." And then you just start, and you make it louder, and you put too much reverb on everything, and it ends up sounding horrible. The producers don't have to be musicians. Not a lot of them are, but a good studio producer maybe somebody who doesn't play any instruments at all.

Kevlin Henney: But likes music.

Dylan Beattie: They like music, and they know what to look for, and they know how to, sort of, direct and feedback to the musicians, "Now, try this. Do that, do that," and the role of testing in software.

The role of decision-making in software and music

Hannes Lowette: That's a very big difference in the studio as opposed to when you're on stage. On stage, you want everything to sound the way that you want it to sound to the audience. It's very direct. So if you want your guitar to sound distorted, you're gonna put distortion on it. When you're recording music, you're probably going to record everything a bit cleaner than you want it to sound in the end product because you can add effects and grit to it afterward. You cannot remove it. So if you put too much distortion on it when you were recording it, there's no way of rectifying that afterward.

Dylan Beattie: There's a good...there's a great podcast. It's called the "Rule of Three," it's about comedy. They invite someone in to talk about comedy, how it's created, and everything. There's a comment from that that stuck with me. They were talking about music production, and they're saying the problem now is you don't have to commit to anything.

You can record all of your tracks completely clean, with no effects. You can record the drums and then afterward change your mind about what drum kit you wish you'd played it on, and just go and swap out the kit, which means that you get to a point now where it's like, "Right, everything's recorded, but we haven't made any decisions." Then you suddenly have this overwhelming thing of having to, put all the pieces in at once to get, kind of, the arch to stand up.

The point they're making, you know, back in the days of analog studio engineering. On day one, you're recording the drums, so you have to get the drums right. You know, you get the sound, you get the right amount of reverb. But then that's it. You don't have to think about the drums. The drum decision is made, and that is now fixed. And so the next day, like, we're putting bass or piano. Those are the drums. We can't mess with that. So we need something that complements that and works with it.

Kevlin Henney: So this goes back to the, anything is possible, but people don't want to produce anything. They want to produce something. It can become overwhelming. But that idea of...it's an interesting one because, again, with drums, you know, there's loads of stuff. Go out on YouTube and the web to find out, you know. And how were Bonham's drums recorded for "Kashmir" you know, on Led Zepp's physical graffiti? There's a whole load of stuff on that. There's all this kind of discussion. And the point in the studio is that we have an option. There's a degree of freedom, and it goes both ways. It's that sometimes that can be too much. We can do anything. But sometimes the artistry comes in constraint.

There's a really interesting interview with...I can't remember his name, but the producer of David Bowie's "Heroes" album, basically said, "We're gonna take Robert Fripp's guitar, and we're gonna put all the effects on it, all of it now and record that." And people said, "No, no. Just do separate tracks." And said, "No. We just can put on one which can do the whole thing, and we are gonna commit to that." And that was an artistic decision to just really say, "This is what the whole song hangs off, and we're not gonna start messing around and futzing around with it. That's not the degree of freedom that we want, and working in these different..." So there's a space of variation that works both for us and against us.

Dylan Beattie: But also…

Hannes Lowette: You go ahead.

Recommended talk: The Geek's Guide to Leading Teams • Patrick Kua • GOTO 2012

Dylan Beattie: I was gonna say, flip that around. How much of the complexity that you've had to put up within software throughout your career is because somebody didn't want to make a decision.

Kevlin Henney: "I don't know what to do. I'll add an extra parameter. Let's parameterize this. I'll put that in configuration." And then the configuration's wrong and nobody understands the configuration. The configuration is untested, and so on. Yes.

Dylan Beattie: "We need this abstraction in case...you know, we use ORMs, while we might change databases later." That's never happened. You know, and that's like beating the drum of best practice for my entire career.

Kevlin Henney: Yes. The overgeneralization.

Dylan Beattie: I was building a ticket system for NDC, and needed to send emails. And I was like, "I need an email templating system." And then I was like, "No, you don't. You need to send two emails. You can have a method that sends this one and a method that sends that one because there's only two at the moment." And, you know, it was that sort of being able to go, "No. We're gonna make a decision on this. Can I commit to something that works well for one thing? If it changes later, yes, there will be more work to do. But it might not change later. So let's not carry the additional burden of all of that complexity and flexibility."

Hannes Lowette: Also these degrees of freedom that you're talking about, also really apply when you're building guitars. Because we're all geeks, and if you get into the number of ways that you can wire up a couple of pickups in the guitar, that goes pretty broad. And you see, I'm in a couple of guitar-building forums, and I follow a couple of people on YouTube, and Twitter, and so on. And sometimes you see these monstrosities that add all the possible configurations. So you can do parallel series out of phase, all kinds of stuff, like, to every single pickup.

Then they have a whole switching mechanism to go with all...so what you can do is you can get 27 different sounds out of a guitar if you want. You're probably going to use four or five of them on stage. So having those 27 different settings, like, I have to remember to put that switch in this position, and so on, that is usually not something that enables people to create more. It's a limiting factor.

Kevlin Henney: So let's…

Hannes Lowette: So when I was building this…

Kevlin Henney: One, I want to look at the guitar. This is Hannes's latest guitar, he built and chopped down the word for. I remember that message. But also, to give people an opportunity, if you're not familiar with guitars, what we've just been talking about…

Dylan Beattie: This is one.

Hannes Lowette: This is a guitar.

Kevlin Henney: This is a guitar. This is an amazing] guitar. It has the scale length, which is how long the strings are. Is as long as a typical…

Hannes Lowette: Is this length, from here to here.

Kevlin Henney: What is the string length on that? Twenty-five and a half?

Hannes Lowette: It's 25 and a half.

Dylan Beattie: Standard Fender.

Hannes Lowette: It's Standard Fender.

Kevlin Henney: Standard Fender. What you see there, are two pickups, and the point there is that you can choose between them and how they're wired together. And, so for those of you who have any background in electronics, yeah, parallel or series, these produce different sounds. Even without knowing what sounds they produce, you're, "Oh, yeah, there's a possibility there." Just across a few pickups, you can do an amount.

Hannes Lowette: Well, let's start with the reason that I had for building this. I've been building guitars for a while. I started playing in Dylan Beattie's band, which meant that I was lagging my Fender guitar around the world to conferences, to just play conference afterparties.

Dylan Beattie: And airlines love guitars. They do.

Hannes Lowette: They love guitars. And I had this beautiful molded case for my Fender. And it got broken on two occasions. And then you…

Dylan Beattie: The case, that is, not the guitar.

Hannes Lowette: The case, yeah. The guitar always arrived in time.

Kevlin Henney: Case did its job.

Hannes Lowette: The case did its job, but it broke. So then you have to jump through all the hoops of, like, reclaiming the case from the airline. They'll give you a new one, it takes months. I have one that's in the pipeline at the moment that was broken in December. So I was tired of doing this. And the way that Dylan does it, he has this very small Steinberger that fits in this other bag in his luggage that he can check in.

It's like, oh, that sounds like something I want to do. But being a builder, I felt like I wanted to do my own. And when I set out to make this one, when we get back to the degrees of complexity that we talked about earlier, I wanted to have a single switch for the pickup combinations, because basically what we have here is three coils, and you can wire them together in a bunch of different ways to create a whole bunch of different sounds.

And I wanted to have one switch with five positions, which I felt was going to be enough. Like, to use on stage, that would be perfect. But I also made the mistake of trying to make this guitar as portable as I could be, which means that if you look at it this way, this is only a 32-millimeter body.

Kevlin Henney: Again, I remember this exchange where we were talking pickups and options.

Hannes Lowette: So the problem is that the switch that allowed me to do five positions that had all the wiring possibilities that I wanted to have in this guitar was too deep for this body. It just didn't fit. So I had to go to two switches, which now give me more degrees of freedom. It also made things more complex because if I want to put this guitar into a certain configuration, there is this switch that configures how this double-pickup works. That can work in three different ways. And then I have a switch that selects between these two pickups. That's very classical.

I can still reason about that. It gives me...you would feel like three times three, that would be nine different sounds. But when this switch is in that position, whatever I do here doesn't matter. So it's seven different sounds on this guitar. But I already feel that when we were rehearsing the other day for our gig, I'm only using, like, three or four of those. So it doesn't matter that it has seven, I just want those four.

Kevlin Henney: And I think that's one of the things that you, kind of, look at some guitars, and also some guitar...and they are bristling with options. One of the guitars I have at home has a single pickup and two knobs. There are no switches. And I used to have a single-pickup, single-knob guitar. That was one knob too few. I like a tone control.

Hannes Lowette: You like a tone control, okay.

Dylan Beattie: Eddie Van Halen recorded Van Halen's debut album on one guitar with one pickup and one knob, and no switch.

Kevlin Henney: Yeah. He is the classic...kind of, like, actually really is paired back…

Dylan Beattie: And it had a volume control with "toe" written on it.

Kevlin Henney: But I'm not Eddie Van Halen. I think that's very, very clear to me. So in other words, that guitar, one of the reasons I love it is because it has just, like, there are the sounds, and you have limited variation, and somehow it makes life a bit easier. For my other guitars, there are a few more options.

Hannes Lowette: Whatever you play is going to come out of the guitar. I mean, you're not fiddling with knobs or...like, it's just playing.

Love of complexity in music and software

Kevlin Henney: Let's relate this to...and we've all seen those frameworks and those possibilities, and those extra bits and pieces, and it's amazing what you can do with just some of …we compare it back a little bit too far sometimes, but, yeah, sometimes you take it this way. But, normally, we're not in any danger of getting close to what we might consider the optimal level, under abstraction, or, you know, too few features is rarely the problem.

We normally tend towards...you know, and I'm gonna say guitar forms are gonna be filled with a bunch of nerds. They may be different nerds. A lot of them are the same nerds, going back to the earlier observations, but there's that kind of love of possibility and complexity, the love of what could be.

Recommended talk: Microservices When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020

Hannes Lowette: And just like in the software world where we believe that we need microservices if you want to scale anything big or whatever, in the guitar world, there's, a bunch of woods that have been debunked that persist. It's like, for instance, the idea of using something called tonewood.

Kevlin Henney: Oh, tonewood.

Hannes Lowette: For the viewers out there, I mean…

Kevlin Henney: …clearly of one mind on this one.

Hannes Lowette: ...if you're building an electric guitar, the length from this point to this point is going to affect your sound. The thickness of your strings is going to affect your sound. The type of pickups, where they are, and how high they are mounted, that is going to affect your sound.

Kevlin Henney: All this is straightforward physics. And remember it's an electric guitar, what happens is there is a signal that comes out, and that's it. So, therefore, that leads to the next question, what about the wood?

Hannes Lowette: I think, on electric, we're probably not even up to 1% of the sound. It's going to be a fraction of a…

Dylan Beattie: I'm going wave a little flag here and say that I think the tonewood debate is not as pronounced as journalists make it out to be, but I did once play a granite Stratocaster. And the sustain rang for days because the body absorbed so little energy because of absolute mass.

Hannes Lowette: But then you're back to physics.

Kevlin Henney: Yeah. Okay. So I'm gonna say we're out of tonewood. I mean, this is true rock music.

Hannes Lowette: Because, honestly, what type of wood I make this out of, or that out of, that doesn't matter nearly as much as how tight this joint between the neck and the body is, because if that is somehow...and "loose" is not the right term, but, like…

Dylan Beattie: Sloppy.

Hannes Lowette: Like, sloppy, or not packed together. And it doesn't matter if it's screwed or glued, or whatever, if you have a good fit here so that the resonation from the strings goes through, you will have pretty good sustain…

Kevlin Henney: And it's not a question of...so the one that the wood has is the sound in the room when you're playing it unplugged, and the feel, I think that's the one true thing, is there is a difference of the feel.

Hannes Lowette: Oh, yes. Definitely.

Kevlin Henney: And that may change how you respond to it but it won't change those little electrical signals, the quality of those that are coming out. The contribution is minimal. Now, you've highlighted the tonewood debate. If you're not sure about this and you don't know, just google "tonewood."

Dylan Beattie: There was a guy, who had a YouTube channel, he made this during COVID. He started with a guitar.

Kevlin Henney: I saw it. 

Hannes Lowette: And then he took a very expensive guitar and took a very cheap guitar, and they put the pickup in the same position, same height, same strings, whatever. The sound was identical. And then he went as far as mounting the bridge on one bench and the…

Dylan Beattie: Nut.

Hannes Lowette: The nut on another bench, and there was air between them.

Kevlin Henney: No wood. 

Hannes Lowette: But the pickup…

Dylan Beattie: It's a incredible.

Hannes Lowette: ...same position. Yes. We have similar interests.

Reversible time in software vs hardware

Dylan Beattie: So let me ask you a question while you've got the guitar. And we're gonna get you to answer this on camera. We talk a lot about software craft, and that is a real craft.

Kevlin Henney: So that's a metaphor.

Dylan Beattie: Show us the bits where you wish you'd had an undo button.

Kevlin Henney: So that's one of the things that distinguish anything, the world of software from the world of hardware is we have reversible time. We can undo, we can revert. We even have parallel universes we can branch. We have all the science-fictional possibilities at our fingertips.

Dylan Beattie: Until you put it in production and have customer for it.

Kevlin Henney: Until it hits physics, and until it hits the world. At that point, things are a little less reversible, but there's still a little bit of slack unless you lose too much money in making mistakes. However, there is a commitment here.

Hannes Lowette: So, I already told you about, I have a €20 switch sitting at home because it's a super switch, those things are expensive. That didn't fit because I had routed away too much wood in this guitar, and there's no way to re-add the wood. The wood is gone.

Dylan Beattie: I'd have put in at 45 degrees.

Hannes Lowette: But this is small.

Kevlin Henney: The best time. For those of you guitar makers out there, take that…

Dylan Beattie: If this was GitHub, I'd be sending you a PUT request right now with a 45-degree main switch in it.

Hannes Lowette: I was routing out this neck pocket. I had made a mold for it. And while I was holding my router, it moved. So there's, like, a little piece of wood here that got routed away.

Dylan Beattie: I saw it yesterday. Yes. I was gonna ask about it.

Hannes Lowette: And I had to shape and grain-match a little piece of wood to go in here. And I wanted the grain to be in the same direction. That cost me, like, two hours to fix. That was a two-second mistake that took me two hours to fix.

Kevlin Henney: You know, I think there is a parallel to software that we...I'm feeling it at this point.

Hannes Lowette: So that is, like, a stupid mistake I made. I didn't clean up this glue joint very well. So, I could go back up and sand this completely, and then refinish the whole guitar, but I only noticed when I was applying oil, which means that it was already too late. Any other mistakes in here? Oh, yeah. This is an interesting one. So, this is with a burning stamp that I put in there in the wood. It's my brand. I had made a metal piece that would fit here so that the stamp would align perfectly to the neck so that I could just push it against and push it down.

And it would be straight because I felt that was going to be important. So I had gone through all that work, heated the stamp, and pushed it down. I had tried, on a blank piece of wood a couple of times. Like, how long do I have to keep it down to get, like, the correct amount? Because there's no one doing. If you burn too deep, the whole area is ruined. And I push it down, lift it back up. It was upside down.

Kevlin Henney: Reversed the polarity.

Hannes Lowette: So you don't see this, but this fraction of the guitar is sanded slightly back. I had to sand away the whole thing and redo it. You don't see this. I fixed it pretty well.

Dylan Beattie: You did.

Hannes Lowette: But if you were to measure, like, the thickness of the wood here and here, that varies about 3 millimeters where I had to curve this away and get…

Kevlin Henney: Just talk about it as weight relief, unintentional weight relief.

Hannes Lowette: It's under 2 kilos, which is like really light for a guitar anyway. And I'm happy that I bought most of the woods before the pandemic wood price. It's ridiculous. This wood, which is American swamp ash, used to be €7,000 a cube meter, which is already expensive. Now it has gone up two and a half times that.

Dylan Beattie: Wow.

Hannes Lowette: So this, if you buy a single beam of wood, like, 3 meters long, about this wide and maybe this thick, that was already a €400 piece of wood. And it gets even worse. But still, since you're building guitars, you only use very little of it. So the price of the wood doesn't affect the final price of the instrument as much as pickups and electronics, and all that stuff, because that adds up.

Recommended talk: Investigation and Creation of Software • Jessica Kerr • GOTO 2020

Kevlin Henney: Okay. The hardware is the limiting factor here.

Hannes Lowette: And the number of hours that you put into it, like craftsmanship, that is the big defining factor in what you'll end up paying for any guitar. If you have machine-made guitars...that's the problem as a guitar builder, you're competing against brands like Fender or Gibson who have automated every step of the process. They can put out a guitar for €1,500 which is very, very hard to equal when you're building by hand. So you have to spend years and years getting better and perfecting every step of the way just to get to that level. But then you're putting 50, 70, maybe 100 hours into a guitar, which means you can never Leo Fender sell it for €1,500, right?

Dylan Beattie: I mean, that was Leo Fender's great innovation, because he and Les Paul are two kinds of iconic guitar makers of the 20th century. And Les Paul was a musician, you know, bestselling recording artist. Leo Fender couldn't play the guitar.

Kevlin Henney: Yes. It's one of those bizarre things, you can tell in certain elements of it.

Dylan Beattie: He was like, "I'm gonna design a guitar you can make in a furniture factory." And that was the Broadcaster and then the Telecaster, and then the Stratocaster was all just, you know, bolt-together the pieces of wood. He used the same paint that they were using on cars so we could get them all sprayed at the place around the corner. So all those iconic Stratocaster colors, were what the car spray shop around the corner happened to have available.

Hannes Lowette: He also had this...he had to solve the problem of neck break angle, like, the break angle on the nut, because before, we were building guitars, you had this way of building just the way that violins were. The neck was tilted slightly back so that you could have a break angle with a bridge here.

And as you said, Fender, being the engineer, is, like, flat pieces of wood are the easiest to manufacture. So he tried to get everything as flat as he could, which meant that he dropped a lot of the bridge into the body a little bit. And then here, also, we had, like, the slanted headstock. Well, this guitar doesn't have a headstock because I tried to keep it as short as possible for travel.

Kevlin Henney: Stockless. Headless.

Dylan Beattie: Headless.

Hannes Lowette: Headless. But that was angled for a reason that if the strings go over the nut and there are angles, that's a good thing. It means that this point of contact is solid and the string vibrates properly. But if you have these long Fender headstocks, like the upper strings, those tuners are pretty far away from this point. And because there is no angle in the headstock on a Fender guitar, that break and angle here is almost nothing, which is why on Fender guitars, you see these things called string trees, a little piece of metal that is screwed into it to just increase the break angle here.

Dylan Beattie: That's a hack.

Kevlin Henney: That is a hack. Yeah.

Hannes Lowette: It is a hack.

Myths of software and music

Kevlin Henney: It's a workaround. Now, there's an interesting thing, going back to this, and, again, when we start talking about things like myths, there are several things, we certainly see in software there are several, kind of, like word of mouth, you know, "Oh, I do this practice because..." And it's just like, "Well, hang on, that's kind of mythical." But there's a bunch of other ones, one of the ones I was fascinated by when talking about the process. So the building, like, violins leaves you with something, with an angle, and mentioned Les Paul and his guitars have all of this.

Now, one of the most interesting things I...traveling a couple of years ago with a speaker who had a guitar. And I saw him just as he was checking the guitar in at the airport. And he was loosening all the strings. And I said, "Oh, that's interesting. Why are you doing that?" And he says, "Oh, well. You know, it's a thing because the strings tighten up during...you know, you don't want to break the neck." I didn't think about this one, and I thought that's an interesting thing, that's a point of experience. For somebody who hasn't come across that, that's an experience, guys.

Then I started coming across a couple of things, and eventually, I found out this is a side effect. It's nothing to do with this. It's to do with if you look at neck breakage, it's all Les Paul's. I looked for Fender neck breakage, doesn't happen. There are tales of people, particularly with Telecasters. Telecasters are serious guitars.

Somebody was mugged. You know, a country player was mugged on the way to his gig, and he had a Telecaster guitar. He whacked the mugger, and he continues to the venue and played on that. You could not do that with Les Paul because of all of this. In other words, it's an artifact, and people built up all this religion about, "Oh, no. You need to loosen the strings because that one..." No. It's in the design.

Hannes Lowette: It's in the design.

Kevlin Henney: It's a part of the design. And Leo Fender was an engineer, and he says, "Okay, we're gonna build something that works." And I don't think he said, "We can hit people on the head with it." But that was an interesting side effect, but it did involve a couple of hacks and workarounds. But it's an interesting one that this myth…

Hannes Lowette:, the fact that Fenders are more sturdy, the fact that they are more sturdy than Gibson's, a lot of it is due to the hacks that he took to make them easier to manufacture. I don't think he had sturdiness in mind. But the fact that the headstock was straight, meaning that all the grain of the wood is going straight, and there's no scarf joint, means that if you drop it on its head, like, the forces are going to go straight through the piece of wood. There is no angled piece of wood on there.

The grain is all straight, as well, so the piece of wood is very unlikely to break. Whereas if you have an angled piece of wood here, the forces are twisting it away. The same with a straight and an angled neck joint here, which Gibsons have, they have this little neck tilt in there, it's the same story.

And the fact that the way that Gibson makes these...because in a neck with an angled headstock, you're gonna want to make this out of two pieces of wood. Because you want the grain and the headstock to go straight with the headstock, and the grain and neck straight with the neck, which means that somewhere here you're gonna have to join two pieces of wood together.

Kevlin Henney: And now I have two pieces of wood, not one.

Hannes Lowette: Because if you would just take a very thick piece of wood and, like, route it away so that it's at an angle, which means that in your headstock, you have all these pieces of grain that, like, they cross through the headstock, that makes it very easy to break. But then this scarf joint comes into play. And the way that Gibson does is they move it a little bit too far back, which means you see all these Epiphones and Gibsons breaking.

There are ways to do that better. If you move that joint a little bit further here, you can prevent a lot of the neck breakage that you see in these guitar builder forums. I mean, I see posts every week, "Well, my headstock has broken off."

Kevlin Henney: There's an important point here because it brings it to a close, but also relates to software, is that the whole point is, as you say, in the forums, and as I've noticed, there's all these kind of folklore that gets built up, and it's not grounded in reality. It's grounded within a particular community that has a particular focus. And it's just like, "You know what? I think I might have come across that a few times in software." You know, there's a lot of that, and it's a case of there's, again, that invitation to, kind of, take a step back. It's like, "Are we dealing with facts, or is that just words you got from your mate or did you find it on a blog?"

Dylan Beattie: And on a note which has nothing to do with software or guitars, but which happened to me recently, I used to be into mountain biking. That was, like, the other thing. There were computers, there were guitars, and there were mountain bikes in the '90s. And in the '90s, all the magazines were like, "You have to have this. You have to have one of these. You have to have the bar ends. You have to have, you know, 28 speeds with 3 gears on the front." And I stumbled across…

Hannes Lowette: That doesn't add up, dude. It's 27.

Dylan Beattie: Twenty-seven. Yeah. Twenty-four speed.

Hannes Lowette: It has to be divisible by three if you have three in the front.

Dylan Beattie: I stumbled across this article in an online magazine which is just like, you know, "Ten horrible mistakes we all made in the '90s. Ha ha, do you remember bar ends? They were stupid. Lol. You remember three sprockets on the front?" I was like, "We did that because you told us to." Like, the press was all like, "You have to have this, and this, and this." And you realize, you know, so much of it is just…

Hannes Lowette: Fashion.

Dylan Beattie: Fashion.

Kevlin Henney: Yeah. You know, in software, we are fashion industry.

Hannes Lowette: Like microservice and Kubernetes or?

Dylan Beattie: Yeah. Microservices by Issey Miyake coming to a catwalk near you.

Kevlin Henney: And on that note, thank you very much.

Dylan Beattie: Thank you, Kevln. Thank you, Hannes.

Kevlin Henney: Thank you.

Hannes Lowette: Very nice talk.

Kevlin Henney: Yeah. Very nice. I hope you got something out of that. I certainly have. And feel free to @ us wherever you find us online…

Hannes Lowette: About guitar building or software.

Kevlin Henney: Yes. And anything you agree or disagree with, or anything we missed, or any extra nerd points. We are open to those.

Dylan Beattie: What's gonna happen is people are gonna skip the whole thing and this is gonna start a massive threat about tonewoods.

Kevlin Henney: Yes. That might be of the legacy of the tonewood.

Hannes Lowette: And then somebody will come out and goes, "But acoustics." So I think we specifically mentioned this was about electric guitars, right?

Dylan Beattie: Yes.

Kevlin Henney: Yes. There is a difference with acoustic. And that is for another session. So...

Hannes Lowette: When I start building acoustics, we're gonna have that conversation, because also in that world, there's, like, lots of innovation happening.

Kevlin Henney: Cool. Have a good one.