Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the sheer power of nature as manifest in an earthquake.

[00:00:30] Dave Adsit: I'm Dave Adsit, a VP of engineering, and recently I've been thinking a lot about seasons of change and change management strategies.

[00:00:38] Allan Stewart: Our topic for this episode is craftsmanship versus engineering. So when we started this podcast about five years ago, our first episode talked about craftsmanship and what we thought that meant and what it is. We introduced this concept and today we're revisiting it. And specifically contrasting it with engineering. Yeah.

[00:00:59] Dave Adsit: So over five years, I think that our understanding and perspectives have changed to some extent. They've certainly evolved through practicing and executing with them. One of the things that I've been thinking about a lot is semantic drift, which is the idea that definitions for things change over time. And almost always becomes... Less precise over time. So in the seventies, the term hacker meant someone who was highly skilled and passionate about technology, who was always exploring it and optimizing it and stretching the capabilities of systems. In other words, a hacker was someone who will hack away at a problem until they figure out a solution to it. And now a hacker is someone who will... Yeah. Exfiltrate your data, given half a chance. Yeah. And so not only has the definition changed, but the connotation has gone from something very positive to something pretty negative.

[00:02:09] Allan Stewart: When I was in college studying computer science, one of the books that I was required to read was called Hackers, Heroes of the Computer Revolution. It's written by Stephen Levy. And Heroes of the Computer Revolution is not what you think it is. It's not what you think about when you hear the word hackers anymore.

[00:02:28] Dave Adsit: No, it certainly isn't. In fact, when you say hackers, I probably think of that movie from the mid-90s about the high school kids that were hacking maliciously, trying to gain access to systems in a nefarious way, which shows you how quickly that definition had already started to change. If in the mid-90s, hackers were... While they were the good guys in the movie, they were doing things that we might consider nefarious. Right.

[00:02:56] Allan Stewart: So where this comes back around to craftsmanship and engineering, over time, I have had multiple experiences, right? Especially in the last five years, because I think about it more, given the title of our podcast and the work that we do. Multiple experiences where I felt like I've needed to defend my viewpoint of the word craft. So a recent example that came up... I was listening to a ThoughtWorks podcast. Neil Ford was on it, and they were talking about vibe coding. And then Neil said, And then he went on, he talked about, you know, like, beautiful building facades, but does it actually work? Is it something that you could only make use of? Is it something that you can use on a stage versus actual building that you can use? Right? So honestly, he kind of lost me for a minute. I had to rewind and listen to the podcast because I kind of got upset. I'm like, oh, well, he's talking about... He's saying craft, but when he says it, it's pretty clear that he's equating craft with like making, creating, like the production of something. But that's not what I think when I hear that word. And so once I did rewind and I listened to what he said... When I put it into that context and I say, oh, well, he's talking about just like the raw creation, like how much stuff can you build real quick with the vibe code? Then I pretty much agreed with his sentiment. But the words that we use have an effect on our ability to convey meaning, but also the emotions that it sparks within people.

[00:04:47] Dave Adsit: Yeah, I had a similar experience when I recently read Modern Software Engineering by Dave Farley. He talks about... Craftsmanship in that book. And he talks about engineering and he goes a long way towards trying to reclaim engineering. And so what he says is, what does applying an informal approach to scientific learning and discovery mean when we apply it to solving practical problems? There's a word for that and we call it engineering. So to further quote, he says, at this point, I got rather nervous. It seems to me that our discipline of software development, engineering has become either incorrectly loaded with meaning or emptied of meaning altogether. On the one hand, many people assume that engineering means stifling bureaucracy and heavyweight process control. On the other, engineering simply means writing code and nothing else, which again, goes back to kind of that analogy of craft as just doing stuff, making things. So back to Dave Farley, he says, both of these are profoundly wrong in other disciplines. Engineering. Engineering is simply the stuff that works. It is practical, pragmatic, and more, not less efficient. And so, you know, I've identified with software craftsmanship for a long time, but when I read Dave Farley's definition of engineering, I identify with that as well.

[00:06:10] Allan Stewart: Yeah.

[00:06:11] Dave Adsit: I think it's very clear that the intersection of software craftsmanship and software engineering is it's very high intersection. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.

[00:06:44] Allan Stewart: Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.

[00:06:46] Dave Adsit: Yeah. Yeah. Yeah. Yeah. Feline bureaucracy and Gantt charts and waterfall methodologies. And I think that his framing of engineering is simply the stuff that works makes a ton of sense to me, given my experience working in at not even at the apprentice level, but working in trades with my dad. So engineering as the stuff that works and craftsmanship as doing the right thing at the right time with the right tools. These are very similar types of ideas. And I think that they, they work well together. And I think that we should reclaim them. We should lean into clean definitions versus whatever we, we see out in the, in the industry from people who are being less precise with language.

[00:07:45] Allan Stewart: Agreed. So regarding definitions. What does craft mean? What does it mean to us? What does the T what did the term mean when we started using it versus what people think now? What alternate terms do we think about?

[00:08:01] Dave Adsit: Well, so when, when we say craft, the first thing that comes to mind for me is a tradesman from middle ages, craft guilds, you know, someone who has gone through the apprentice journeyman master process, like a blacksmith or a woodworker. And so I think about that. I think about the, the movie, the Patriot with Mel Gibson, where he is in his barn, trying to make a rocking chair for his wife. And he has dozens and dozens of not quite right rocking chairs hanging from hooks in the barn. And he is perfecting the, the craft of making this wooden rocking chair. Something that he feels comfortable giving to people are giving to his wife in the movie. And I think about it in terms of someone who is maybe running a small workshop where they are building chairs or burnt a building, various furniture for sale to customers who then value those products and use them. So that's, that's kind of where my head goes naturally when we talk about craft or craftsmanship. Yeah.

[00:09:16] Allan Stewart: I like that idea. I like the idea that, that you're caring about the thing enough that you're doing it to the best of your ability, right? You're, you're continuing to learn, you're continuing to develop and grow so that you can get even better at it.

[00:09:30] Dave Adsit: Yeah.

[00:09:30] Allan Stewart: So I went to the dictionary and because I'm lazy, I just go to the first dictionary that pops up in my browser. So when I search for craftsmanship, it tells me it's the work of a craftsman. So look at craftsman. There's a man who practices a craft with great skill. Yeah. And you know, immediately we start getting into some of the gendered language word, but setting that aside craft with great skill and go back and okay, well let's go to that root craft skill in doing something or making something as in the arts, profess proficiency, right? And the strong synonym there was skill. And I liked that aspect. And to me that resonates. And when I think about craftsmanship, that's the thing. That I typically focus on. It's like, Hey, skill. But in that definition, it says as in the arts, right? And so I think it's only natural that we have to consider, well, what are other people thinking? And if they're thinking about software as art, we've spoken before about the, you know, software as a Faberge egg and whether that's good or not. Right. So in some contexts that might be okay. If you're trying. Yeah. If you're trying to make and sell Faberge eggs, then, then great. But if you're trying to make software that does something useful for a customer, then, you know gold plating, you know, the perfectionism of details that are not visible, some kind of navel gazing are all things that people might be considering when we use this word.

[00:11:08] Dave Adsit: Right. I've heard many of those accusations from people who do not personally identify with the concept of craftsmanship. One of the most common. Common ones that I've heard is elitism. Like, oh, you guys are just being elitist for no reason. You're not creating additional value or whatever. You're just being elitist to an exclusionary, which has not been my experience with people who identify with the term craftsmanship, but it has been my experience with people who don't identify. So it's interesting to see definitions of the term from people who use it versus definitions of the people of the term from people who don't use it. Right. Uh, and how they use it. They mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly structures, machines, processes, and systems, which sounds an awful lot like engineering is the stuff that works, being practical and pragmatic. I like just kind of picking out words,

[00:12:24] Allan Stewart: scientific and mathematical principles. That's something that I relate with. One of the things that I think about when I think about software craftsmanship is principles. In almost any discussion, when people start asking me about how should we do a thing, what are best practices, what should we recommend, how should we create our team culture, all those kinds of questions, for me, I always want to go back to principles and say, oh, well, what principles do we espouse? What value do we want to get? Then we'll figure out the pragmatic side of it, the actual practices. What are we going to do once we know the thing that we're trying to solve?

[00:13:03] Dave Adsit: Yeah. As we talk about... About definitions, I'm reminded that which we call a rose by any other name would smell as sweet. The other thing that I've heard often is by their fruits, you shall know them, right? So that's kind of the idea that you take away... You look at the outcomes or the outputs, and that's how you measure the thing versus necessarily by the definition or the name that's applied to it. We could call it engineering. We could call it craftsmanship. But what it is that we want out of it... Yeah. ... is doing the practical thing, doing the right thing. And so that to me is what is most critical about working with people who care about what they're doing and what they're producing, is that they're continually re-learning... Not re-learning, but they're reinvesting in learning so that they can deliver at a higher level over time. And so that... Yeah. Yeah. I do think it's important, though, that we step back and say, hey, are we talking about the same thing? Are we using this term in the same way?

[00:14:12] Allan Stewart: Absolutely.

[00:14:12] Dave Adsit: Are we talking across purposes with different... Using different terms for the same thing or using the same term to mean different things? And I think that that's really helpful for us when we're trying to actually communicate as people.

[00:14:26] Allan Stewart: Agreed. So if we take our Bill Shakespeare quote and say, what are the elements of... Yeah. ... this rose that we find appealing, right? What are the concepts and ideas that we think are important, regardless of the specific name that we use to define it, as we think about this overlap between engineering, craftsmanship, developer, coder, all these different words, right? For me, one of the first ones that comes to mind is professionalism. Is this person doing right by the person who's paying them?

[00:15:05] Dave Adsit: Yeah. Whether that's a direct employer or a customer who they are selling to directly, professionalism is very critical. Very related to that for me is the first thing that comes to mind is delivering value. Delivering value to customers, employers, whoever. I want that value creation. And that's probably a part of professionalism.

[00:15:26] Allan Stewart: Yeah. I also think about having high quality. Are you doing a good job? Are you producing something that is good? Something that is actually going to meet the need and not fall apart?

[00:15:40] Dave Adsit: Yeah. The next one for me is, are you continuously learning? Are you reinvesting in your own knowledge so that the work product that you create today is better than the work product that you created yesterday?

[00:15:55] Allan Stewart: Going back to one of those definitions, the words that came out of the definition, skill. I think that is an important one for me. And skill mastery. Are you developing, developing your capability so that you can do these other things, right? Like the professionalism, the value, the quality. Are you applying that learning that you're doing so that you are mastering the skill and you can do it even better? You can understand trade-offs better. You can make the right decision in the right context.

[00:16:24] Dave Adsit: Yeah. And very related to that is commitment. You're committed to this, developing this collection of skills over time, right? You're not doing the, the jack of all trades type of thing or the, I don't know, we often call it colloquially ADHD thing, right? You're bouncing around. You are, you're focused and committed to this area and being as good at it as you can be.

[00:16:51] Allan Stewart: And the last one that comes up for me is, is practice and just experience in general. One of the things that we have often said is sometimes the best answer is to go and work for 20 years best answer. So if you can go back and ask the question again, because sometimes you just need the experience. There's no substitute for it. You need to try a bunch of things and you need to get some things wrong sometimes and figure out why it is that certain coding patterns or certain situations or certain team dynamics, you might have to work in a different way in each of those to be effective. And you're not going to learn that just solely by reading blogs or, you know, asking chat GPT, what's the best thing? Because you have to have

[00:17:42] Dave Adsit: that depth of context. Yeah. The practice and experience kind of reminds me of that somewhat snarky statement that I can explain it to you, but I can't understand it for you. And sometimes the understanding comes through experience and practice. So when we talk about, when we talk about craftsmanship and engineering, one of the things that inevitably comes up and you already alluded to it is the idea of title. What is the title? Is it software engineer? Is it engineer? Is it developer? Is it coder? Is it hacker? Is it programmer, web developer, web master? What of these titles matter? And so I think that we use titles in different ways in our industry. And probably the first thing I would think is title doesn't matter. Except it kind of does. And it matters for different reasons in different contexts. And one of the ways that it matters is titles can be used to indicate position in a hierarchy. So you might have software developer two, and that's a positional title, but it's also a pay grade. And so it's really important for your HR team that you get these titles correct. They're applied correctly to different people in the organization. Mm-hmm.

[00:19:00] Allan Stewart: Mm-hmm. Mm-hmm. Mm-hmm. Mm-hmm.

[00:19:02] Dave Adsit: Because improving your title also improves your pay grade. Right. So another purpose of a title is to communicate ability or skill. And this one is a little bit iffy in some cases, because it used to be when I first started in the industry, we only had three titles. We had junior engineer, software engineer, senior engineer. And you weren't going to be a senior engineer until you had probably seven or even 10 years of experience. But mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly mainly

[00:19:48] Allan Stewart: mainly mainly mainly mainly mainly mainly Because some people have one year of experience 10 times. Some people have two years of experience, but an inflated title. Some people work at a small startup and they're doing something really amazing and they're super smart. But there's only five people in the organization. And so they don't have fancy titles while somebody else works at a huge 50,000 person company and they have all kinds of levels of titles. So that one becomes hard. But the other purpose that I think is related is your employability. You use a title on things like a resume. And it is kind of a facade for you of can you be employed? And if I go to another company, it's at least an attempt to say, hey, this is what I want to do. Right. So like my actual job title for the last few years has been. Lead engineer. And my boss right now is reevaluating those titles. But I think of myself and like when we record the podcast, I present myself as software architect, because to me, that aligns better with how I think about myself and how I want to be perceived in a resume standpoint.

[00:21:12] Dave Adsit: Right. And I use a title that is aligned with the manager time of the career trident. Right. If we talk about you can as an engineer. At some point, you decide if you're going into people leadership or technical leadership or deep individual contributor. I pick a title that is aligned with the people leadership because that's that's where I've been applying most of my effort for the last decade. I am reminded I think this was probably 2012, maybe 2013. I met a guy at a software conference in Chicago and he handed me his business card and his title was software sorcerer. And that title told me two things. One. He got to pick his own title. And two, he is not interested in getting a job at another company working in one of these deep corporate hierarchies. So, yeah, title can be somewhat related, but somewhat distinct from the concepts of software engineer, software craftsman.

[00:22:10] Allan Stewart: Another aspect of title that I think about is that in some disciplines, a title like engineer requires certification. There's regulation. There's laws. There's laws about it. In order to be an engineer, you have to have accomplished certain things. Right. And then even beyond that, you were telling me that there are professional engineers. Right. Which is different from engineer.

[00:22:35] Dave Adsit: In some disciplines, you have to be an additional level of certification to become a professional engineer. This is true in some engineering disciplines in the U.S., but it's very true in a lot of disciplines in European markets.

[00:23:17] Allan Stewart: If you don't have them title wise, I used to call myself craftsman because it kind of set me apart from people who had these titles like software engineer two or junior developer grade three, or, you know, all these different things. And even these made up ones like software sorcerer or grand poobah, right? Like I kind of felt like it was a way to signal that I was doing something a little bit different. And hopefully in a good way. But now I feel like I have to consider how people perceive the title.

[00:23:53] Dave Adsit: Yeah, that's definitely the case. Because again, it goes back to the idea that we are attempting to communicate. And communication, as they say, it happens at the listener's ears, not at the speaker's mouth. And so if we are attempting to communicate what we care about, then maybe a term like sorcerer. Software engineer, as defined by Dave Farley, is as good or better at communicating that deep care and pragmatism and professionalism than the title software craftsman. I think in my groups of friends and engineers that I've known for a while, I will continue to use that term extensively. But I think I've come around to being a lot more comfortable with also referring to myself as a software engineer. As that term has been reclassified. Reclaimed by people like Dave Farley through his book, Modern Software Engineering.

[00:24:52] Allan Stewart: Agreed. I think in our case, this podcast is somewhat of a similar attempt to reclaim something and say, hey, what do we mean by crafting code? And hopefully anybody who listens to the podcast for any amount of time will very quickly understand what we mean by it so that we're not misunderstood just because of the semantic drift.