#122 - Essential Things Every Software Engineer Should Know - Kevlin Henney

[00:01:01] Episode Introduction

Henry Suryawirawan: Hello to all of you, my friends and my listeners. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If this is your first time listening to Tech Lead Journal, don’t forget to subscribe and follow the show on your podcast app and on LinkedIn, Twitter, and Instagram. And to support my journey creating this podcast, subscribe as a patron at techleadjournal.dev/patron.

My guest for today’s episode is Kevlin Henney. Kevlin is a consultant, writer, and speaker on software development. And he has written and edited several popular software development books. In this episode, Kevlin shared his 3 favorite things every software engineer should know based on the two books he edited “97 Things Every Programmer Should Know” and “97 Things Every Java Programmer Should Know”. He explained the importance for developers of taking an occasional break when working on deep book, putting code comments wisely, and using testing, not just for checks, but also for communication tool. Kevlin also brought up some timeless software development concepts that every developer should learn from the past, such as cohesion, coupling, and code quality. He also explained why he becomes associated with public software failures, widely known as KevlinHenney screens, and how the trend started in the beginning. Towards the end, Kevlin shared his views on why it is important for developers to improve public speaking, writing, and having more compassion towards each other.

I really enjoyed my conversation with Kevlin. Kevlin emphasized many essential things many of us software engineers tend to neglect, especially on some timeless concepts, such as cohesion, coupling, and testing. And I really like his explanation that many things in software development are about communication, and not always about the code and its correctness.

If you find this episode useful, please help share it with more people, so many more of us can also benefit from listening to this episode. Also leave this podcast a 5-star rating and review on Apple Podcasts and Spotify. It will help me a lot to make this podcast easily discovered by others. Before we continue to the conversation with Kevlin, let’s hear some words from our sponsors.

[00:04:11] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I’m very excited. I met someone who I went to a talk in 2013, which was Agile Singapore, and I saw his talk, very inspiring. I think he talked about architecture back then. And since then I followed some of his talks. I mean, he’s very influential in the tech industry. A lot of keynote speakers and things like that. And he wrote some books as well. So if you know this series called “97 Things”, Kevlin actually helped to edit a few books, “97 Things Every Programmer Should Know,” and “97 Things Every Java Programmer Should Know”.

So Kevlin, really looking forward to have this chance to talk to you today. Welcome to Tech Lead Journal.

Kevlin Henney: Thank you very much for inviting me, Henry. Great to be here.

[00:04:54] Career Journey

Henry Suryawirawan: So Kevlin, I always ask my guests to share your career journey. So make sure to maybe mention some highlights or turning points that you think are interesting for the listeners to learn from.

Kevlin Henney: Yeah. So I didn’t know that I was going to end up in software. I don’t think that was a part of the plan. Maybe something technological, but I didn’t know that either. My first degree was in physics, and I realized partway through that although I had some interest in the sciences and physics, this was not the direction I wanted to take. And I had been reading a lot of stuff on, at the time, AI and just learning about all kinds of interesting things to do with computers. It was a good distraction.

I kind of finished my degree. I had no idea what I was going to do, and a friend of mine said, “Hey, Kevlin, I’ve just gone for a job interview at a company and they’re looking for programmers and you don’t have to have any programming experience”. And I thought, well, I’ve got some programming experience from my degree and also being interested in home computers originally. I just went along and kind of that got me into this. And one of the most interesting things, the work itself was not necessarily that interesting, although in hindsight I think there were some really interesting opportunities. What was interesting is that my boss had this bookshelf, this huge bookshelf of books that were absolutely nothing to do with anything that we were working on. And I started reading up on computer science and programming languages. I think programming language is absolutely fascinating. I had no idea at this point and I was just looking through this stuff and I thought, “This is great. I’m really into this. Absolutely fascinated by this”.

And after a couple of years, I decided I want to take a different direction. I’d started learning about object-orientation and coming across these ideas and I thought I want to do something else. But I decided actually I’d do a Master’s degree in parallel computer systems, which happened to have some of the AI stuff I was interested in, but I also realized there was a lot of good programming paradigm stuff in there. That kind of sealed the deal for me. It’s like, yeah, you’re going to be in software development. That’s the way it goes. And so, I ended up working after that for serious companies. Typically, it was a kind of backend or embedded type stuff. Although I did do a whole load of UI stuff relatively early on.

But eventually, there came to be a point where I was getting really frustrated with company politics. And I think a lot of people work in environments where it’s just like, yeah, I’m enjoying the code. Yes. There’re my colleagues. This is all good. I’m enjoying all the technical challenges. But the politics and the people stuff can kind of weigh you down, and I reached a kind of crossroads thinking, “Well, what am I going to do with this?” You know, I’ve got this interest, but I didn’t feel like where I was working was working out for me. I would far too often come into conflict with company politics. And I eventually decided, okay, I’m going to take a completely different direction. I’m going to go into training and consultancy. So I joined another firm. I’d already been doing some contracting at that point, which is kind of a good way to shield yourself off from craziness up to a point.

But that’s where I really discovered I really enjoyed. I really enjoyed when I was a team leader. I really enjoyed the kind of like the connections that I was making with people. I enjoyed the use of whiteboard discussions. I enjoyed writing. I’d written a number of articles and I was writing more and more articles. And this was kind of this opportunity to use your knowledge and frame it differently. And it also changed the way that I thought about software development as well. When you start communicating it, you start realizing that, “You know what? Some of those really great ideas you had. They don’t sound so good when you say them”. They’re great in your head. When you try and explain them to other people, you get a very different feedback loop, and I think that’s really where I started appreciating much more the social side, but also how much I got out of communicating things. So from that point on, I knew that that was going to be part of my work. That’s how I thought about stuff. That actually the process of training people had allowed me to be a better programmer, and I found so many different connections there.

And eventually, I decided many years ago, I would go independent, fully autonomous, and I’ve been that way ever since. My work has kind of flowed between kind of workshops and training and consultancy and coaching and writing. So I get to choose a lot of the mix of what I’m doing. I won’t say there’s been major turning points since then because, for me, it’s all one big flow of many possibilities. Sometimes one month is the same as the next. At other times, I might be doing something completely different.

I guess the only other thing that really changed was the pandemic pushed me completely online, which has allowed me to change the way that I run and offer things like workshops, training, and also talks. I tend to do a lot more specific talks for companies these days, sometimes in person, but a lot of the time online. And that I find, for me, that’s always a great discovery. Again, it’s that communicating things. I tend to learn a great deal by trying to communicate my thoughts. In other words, I thought I knew something and then I tried to communicate it, and I normally see more opportunities in it, more possibilities. All the flaws in what I’ve just said become much more obvious. So, for me, that is part of what kind of keeps me going. It’s not going to be the same for everybody, but, for me, that’s one of the things that unlock some of the more interesting parts of software development.

Henry Suryawirawan: Thanks for sharing your story. I think it’s pretty interesting. When you mentioned about finding fascination in writing, speaking, and getting feedback loops, I always find you pretty natural in speaking and engaging with the audience. I think that’s really cool. And I think for those listeners who also aspire to be not just a coder, later on we will discuss how you can follow Kevlin’s journey maybe to write more and speak more, in order to get that social aspect of the software development as well.

[00:10:13] Things Every Programmer Should Know

Henry Suryawirawan: Maybe let’s start with some of the things that you edited from your books, “97 Things Every Programmer Should Know”. Maybe if you can distill three to five key lessons because we won’t be able to cover 97 things for sure. What will be some of your advice for developers here? What things they should know? What gotcha they should avoid? Or maybe just some things that you think they should, you know, dive deeper.

Kevlin Henney: Yeah. I think that’s an interesting one. Cause, obviously, there are 97 things in each of the “every programmer should know” and “every Java programmer should know”. So, therefore, what are three or five that I would choose? It’s difficult to pick favorites, but actually what I might do, the easiest way for me to kind of pick a few is just to think of the ones that I’ve used in the last week, or directed people towards in the last week.

Here we are in 2022. The “97 things every programmer should know”, that book was published in 2010. And “97 things every Java programmer should know” was published in 2020. But the funny thing is the first book is 12 years old now, and 12 years is a long time in software development. And yet, I keep going back to the pieces of advice in that book, cause they are relatively timeless. You won’t find mention of microservices, but you will find mention of functional programming. You will find mention of, you know, caring about your dependencies and your structures and all the rest of it. The names that we use for various things have shifted. But actually a lot of the interests and good ideas are surprisingly stable and timeless. So I often use these in my talks. Cause I think it’s also good to point out whenever I’m talking, I tend to regard what I’m doing as I’m a clearing house. Everything I teach or communicate typically came from somebody else, and it’s synthesizing these and put together. So I think it’s always really kind of important to highlight that.

In the last week, one of the ones that I’ve certainly referred to is Burk Hufnagel’s piece in “97 Things Every Programmer Should Know”. He also contributed to “every Java programmer should know”. But the one that I always come back to in 97 things every programmer should know is the piece entitled “Put Down Your Mouse. Step Away from the Keyboard”. I like this cause it works on two levels. First of all, there is the general advice of the piece, which is exactly captured in its title. The idea is that sometimes when you’ve been working, when you’ve been beating your head against a problem too closely, you’ve exhausted everything that you can do at that level, that detailed level where you are concentrating intensely, looking at the screen. That line of opportunity has run dry, otherwise you’d have solved it. You’ve done everything you can at this level, and doing more of it is not going to help. So therefore, at this point, the thing you have to do is disconnect, disengage, go do something else.

And I think that the lesson of this is psychological in the sense that this tells us a little bit about how the brain works. That you are very much in this kind of focused style of thinking, which is not necessarily creative. You may be focused on detail. You’ll try to understand how things fit together, very detail oriented, very procedural, and that flushes out a certain class of problems and issues. But the associative connection-oriented style of thinking, the more lateral thinking, that doesn’t normally happen at the same time or you can’t force it to happen. And that, I think, is also a huge reminder to us because I think many people work in environments where the most common thing I get asked, “What if we don’t have time? We don’t have time for this”. And it’s just like, you know what? You do have time. It’s just that the thing you are not good at, and I don’t mean you as picking somebody else, I mean, you as a human being, are not necessarily good at is knowing how to use your time. This is not a strength that we have. We’re very poor at this.

And actually, if you want to save time, then stop working. This is counterintuitive to some people. It’s like, “No, I need to put in more hours. I need to put in two more hours on this problem”. It’s like, actually, you are probably going to solve that problem by not working on it, go and do something else. The solution will come to you, you know, five minutes, you’ll have solved it. You can’t tell when that five minutes is going to be. Maybe it’s while you’re having breakfast. Maybe it’s while you’re sharing. Maybe it’s while you’re on the subway, on the way home. The point there is that once you’ve let go, your brain is just no longer concentrating on that, and the ideas will connect. You’ve got to kind of trust the fact that you’re not trying to control the process. That it’ll happen. So that’s the kind of the broad message of his piece.

But I also like his piece because he shows a concrete example where he experienced this. It’s a piece of code, and he shows us the tidied up version. He shows us the piece of code after it’s been refactored, and it’s really messy. It’s complicated and procedural. It does the right thing. But then he steps away and realizes, you know what, this is just a pattern matching problem. I’m trying to approach it with kind of IFs. That’s what I tend to see in a lot of code. Oh yeah. You’re trying to solve the problem by using a lot of IFs. If this, otherwise. It’s just like there’s something simpler waiting to happen. And you just don’t know what it is. He reveals that it’s one of those things of like, take the foot off the pedal and a lot of things get solved. So thinking is important in software development, therefore you got to learn there are different ways of thinking and some of those are not about pushing yourself. They’re exactly about pulling yourself away, the exact opposite. So I really like that piece, cause it has a detailed technical message showing us perhaps where unmanaged technical debt comes from, and how code can become complex through no fault of our own. But it also shows us the relationship that we have with time and our attention and code. So that one, I think for me, always sticks out as quite a big one.

Another one I’m going to pick on, although this is a little bit self-serving because I wrote it, but it seems to have come up a lot in the last couple of weeks. The title tells you everything. It is a piece on comments, “comment only what the code cannot say”. The whole question of comments is an interesting one in software, because comments are code that is not code. In other words, they don’t have a formal syntax. They are code that is not code, which means that they don’t get checked for correctness. Most comments are wrong, and if they don’t start out that way, they become that way. But because they don’t trigger a compiler error and they don’t fail a test and they don’t cause a bug, our attention is not drawn to them. So they don’t have a process that causes us to correct. If you broke the build, you’re going to go and fix something. Okay. That’s the thing. But if your punctuation is a bit messy in your comments, that’s not going to cause anything. If you are stating things that are factually incorrect, that’s not going to cause anything. And so people have these various different philosophies of comments, and it’s an interesting one because it’s a kind of like, we have this absolute freedom. Absolute freedom is quite a frightening thing. People don’t know what to do with it. And so we have these observations about, okay, yeah, comments become out of date and all the rest of it. But we also have this desire to be helpful. We want to help people.

There are two extreme schools in this. One school of people is like, don’t comment your code, all comments are bad, all this kind of stuff. Your code should be self-documenting. From one perspective, I look like I lean a little bit more towards that camp. But my system of belief on this one is slightly different to the way that these are articulated. The idea is I don’t think that all comments are necessarily bad. That’s not the useful position. I also don’t think that saying that you shouldn’t have comments, it automatically improves your code. Although I’ve seen code which would be improved by deleting the comments, I don’t think it’s an automatic consequence. So there’s a lack of nuances. I find most of the advice saying, “Don’t comment. Your code lacks intelligence.” nuance. You want to understand why.

But at the other end, the comment-everything crowd, is just like, it’s just noise. And I’ve seen far too many examples of that fail. So the way to understand this is don’t comment what the code already says. That’s a fairly standard piece of advice. So that tells us some of the things we don’t want to do. But there’s a really interesting connection here between understanding what it is that you are trying to communicate. So for me, there’s a deep message here. What am I trying to say? How am I communicating? And what is then said in your code? And for me, that’s the driver. It’s like, what can I say? Why would I want to put a comment here? I would want to put a comment here, because the code is not obvious. It doesn’t say alright, it’s not obvious what I’m saying here. Okay. So recognize that as a need. That doesn’t mean you need a comment, yeah. It just means, oh, there’s a communication shortfall between what I’m looking at on the screen, what I’ve just created, perhaps, or what somebody else has created. There’s a communication gap between that and the thoughts in my head, what I feel I want to communicate. We’re not saying everything that we want to.

So that’s a good first candidate for maybe why we want to comment, but don’t do it just yet. What is it that you would want to say? And then suddenly say, hang on, could I say that in the code? Could I say that in the thing that is going to get checked? Or am I just apologizing for the code? In other words, if I’ve got a variable A, and I put a comment, A is for Altitude, then I’m apologizing for the code. Why don’t I call it Altitude? There you go. I’ve got a better name for it. In other words, I can say it in the code. If I’ve got a big block of code and I’ve got a big banner up at the front, then it’s kind of like, well, why is this not a method? Because that’s what a method is. It’s a named block of code. You know, when we see large methods that are hundreds, if not thousands of lines long, there are two thoughts here. It’s just like, why are we not factoring this out into methods? That’s what they’re for. They are blocks. That is what a method is. Fundamentally, it is a captured block with a name and a clear set of parameters. And if that deserves an appropriate Java doc style comment, then that’s fine. Cause that comment is for external documentation. It’s not for the reader of the code. It’s for the user that belongs to documentation say, as opposed to being something that is in line with it.

So that leads to the advice, comment only what the code cannot say, not what the code does not say. But what can’t it say? In other words, what can I do to get to the point? And that the way I often motivate people. Imagine you didn’t have comments in your language. Now write the code. Write the code if you didn’t have comments. Right. Now you’ve done that, is there anything else you’d like to say to the reader? You’ve said everything you possibly could. Whatever is left is the thing that cannot be easily communicated that you couldn’t say in the language. Now you have your comments back again. And at that point, your comments increase in value. That’s the key to have things that are of value. One of the ways we drive value is scarcity. A kilogram of iron is worth significantly less than a kilogram of gold. Although iron is technically more useful as a material, the higher value of gold is defined by its scarcity. If you had as much gold in the world as there is iron, a kilo of gold would be worth a lot less than a kilo of iron. It was not a very useful substance in that quantity. So the idea there is, scarcity helps define the value. If you put comments everywhere, they’re worth nothing. So for me, that’s something I find in communication to people, it’s much more balanced way of thinking and it caused me to think about how do I value these? What do I think is a useful way of thinking about this?

Probably a third piece. I don’t think there’s a specific third piece, exactly. I would say, what’s interesting in both of the books, the “97 things every programmer should know” book and the “97 things every Java programmer should know” book is there is a really strong emphasis, people are really consistent on testing. I get a lot of pieces and very well written pieces on testing. This idea that’s part of the coding cycle, that is part of the fabric of software development. It’s not something else. It’s not there as software development and there is testing. Testing is a part of software development. That is a consistent view that has been with us for a while. But, perhaps, I think there is continued scope for improvement on that. I think we can always do that. We can always do that better. And in fact, there’s a really nice piece in 97 things every Java programmer should know from Marie Van Dyke on this, where she really breaks down the value of communication in testing.

So you can actually find all the book items online. Somebody moved it to GitBook. I intentionally created the book with a Creative Commons license so that people could do that, so there’s a GitBook version of it. For “97 things every Java programmer should know”, we took submissions through Medium, as well as through a kind of Google form style thing. But all the Medium stuff is still online. Including “Use Testing to Develop Better Software Faster” by Marie Van Dyke. Marie breaks down really the intention about what makes a good test. That’s the other thing that I think is really important is the idea, again, think of your test as communication. Tests are not merely checking. Anybody who’s kind of communicating, “Oh yeah, tests are just checks”, you have totally missed how to do testing in software.

But sure, they have value as checks, but that’s not the full story. That’s kind of the sound of one hand clapping. It’s like it’s part of the story. But you really got to understand it’s an act of communication. That makes the story much, much bigger. It reframes the way you think about tests. Tests are not merely checks. They are an expression of intention. They’re a form of communication. They’re kind of an opportunity not only for somebody else to understand what’s going on, but they’re also an opportunity for whoever’s writing the test. Whether you’re doing that on your own, as a pair, part of a mob, of trying to say, well, what are we trying to say here? And that’s actually the hardest thing. The mechanics of the test are something, I think, we get drawn into a lot. But actually that’s not the hard part. The hard part is, what are we actually trying to say here? That is the challenge. So that, for me, is the most important thing about testing. Tests are not second-class citizens. They are an opportunity to express something that perhaps, again, you could not say in the code.

So this connects with what I just said about comments, is we have all these other means of communicating our intention. And, again, sometimes I might be writing a piece of code and I say, okay, here’s a thing I couldn’t say or is not easily said in the code. And I might start writing a comment and I say, well, maybe if I showed you an example of interaction. What a great idea, an example of interaction. Look, here’s a piece of example code. It shows the interaction that’s of interest. And just to make sure that we’re all good, I’ll put a bunch of assertions at the end. Bingo. You’ve got a test. You’ve communicated intention. You’ve created the test from understanding that you were trying to say something that was not otherwise easily said. So, for me, this full part of a thinking system in that sense.

Henry Suryawirawan: I know it’s very hard to pick favorites from the 97 x 2. I don’t know whether there are any overlaps from the two books. Just to summarize, the first thing is about being detached from working intense for a long time, right? So sometimes we, as developers, we crank the code, we just rush, and we just deliver features over features. Sometimes when you are in this kind of coding mechanics, we tend to probably don’t see a pattern that we can improve, in terms of maybe problem solving, looking at the code and things like that. Or even ideas how we can do things better.

And the second one is about comment. Don’t put comment if the code can already say that. So I think it’s really crucial because sometimes I still see comment, like you mentioned, right? The comment is totally wrong. The code has evolved, maybe, by multiple people editing it. So the comments did not get updated. So I think it’s really crucial. Don’t put comments if you don’t have to.

And the last one I think is very important. Testing. I think almost everyone is talking about testing. Testing TDD, testing as a practice. And what you mentioned just now is about communication, right? It’s not just for validation. I think there are still some examples that I saw from time to time that people just put validation as the main intent of tests. But the test names, the test cases, all the things that are inside the test, probably, as just random variables and things like that, and it makes it hard for people to maintain and update over the time. So I think thanks for sharing that.

Kevlin Henney: Test as communication, and, again, that idea, comments as communication. If we regard what we’re doing in creating a code base, we’re creating a system of knowledge, and we want to communicate that. And when you start looking at it like that, you suddenly realize what you do want to do, but also what you don’t want to do. And we also realize the half truths. In other words, sure test do validation and verification. That’s a part of their story, but that’s not the whole of their story. They can tell us a lot more. And I think that idea when we start stepping back and going, oh yeah, it’s not just a mechanical thing, it’s an intentional thing.

[00:25:35] Learning From the Past

Henry Suryawirawan: So one thing that I noticed when you mentioned in the beginning, before you brief these three things, is you mentioned the books have been written like 12 years ago, and there are still some things that are timeless. And this is something that you mentioned before we had this talk that we can all learn from the past. There are many things that stay relevant. There are many things that stays true even till now. So what would be some top key lessons from the past that you think we, as programmers, covering the old programmers and new programmers, should know? What are the things from the past that still stay relevant?

Kevlin Henney: So let’s go back to the origin story. So I read a lot of books. When I got into software development, it was at the end of the 1980s, which is quite a long time ago, and the world has changed quite a lot since then. The books that my boss had were from the 1980s and the 1970s, and I read a lot of these things. So they were kind of already historical, a lot of them. But what I found was a surprisingly timeless quality to some of the books and their advice. So I was brought up on a lot of ideas about how to think about code in terms of cohesion and coupling. We are losing this message. People have got distracted by guidelines that don’t emphasize these properly, or have watered them down in a particular way.

Cohesion and coupling. Cohesion, the degree to which things cohere and naturally hold together. Now, sometimes people kind of say, oh, isn’t that the single responsibility principle? Well, not really. It’s a kind of cohesion. It’s not about responsibilities. The original quote is that single responsibility principle is actually about single reasons for change. It’s nothing to do with responsibility. So naming is hard. We know that. Single reason for change. What does that actually mean? It doesn’t really mean much. It’s a kind of cohesion, but there are other kinds of cohesion. So why people have got fixated on one kind of cohesion to the exclusion of others? I don’t understand. We should be teaching people about cohesion.

And then, again, if we look at things like the SOLID principles or many of the principles people describe, they don’t talk about coupling. In other words, dependency management, the degree to which things connect. And we have far more dependencies in code bases now. And for some people, when they talk about dependencies, they are talking about external dependencies and you sort of say, oh, dependency management. Yeah. And they show you all their external dependencies. It’s like, yeah, you’ve got half a million lines of code here. I’m talking about the dependencies in the code base, not just outside the code base. Some people kind of ended up kind of losing track of that. So coupling, cohesion, these are ideas from the 1970s. They do not go away. They are fundamental. There’s a lot of things people have been trying to push as fundamental. Those are. Coupling, cohesion are for us. They are for our benefit. By the way, the code doesn’t care. The compiler’s just going to compile what you give it. It doesn’t care about coupling and cohesion. The processor you are running on doesn’t care about coupling and cohesion. It’s just going to execute what you say. Coupling, cohesion are for our benefit. They’re so that we understand, so that we can maintain, so that we can build. That’s what that’s about. So for me, these are really old ideas and, more appropriately, timeless ideas. They don’t go away. We should be building on them, not trying to muddle the message. Therefore, paying attention to this stuff is important. And I think that’s what a lot of people are trying to do when they reiterate or try and reframe these. They’re trying to get that message out.

But then there are other things that I think we haven’t paid attention to. Code quality. So these days, the popular way of framing things in terms of issues of code quality is in terms of technical debt. Now, that’s not really quite right, but it’s not a bad metaphor, although we do misuse it a little bit. But if you look back at the past, people have been talking about code quality issues forever since they realized there was an issue. One of the things we’ve learned is that this really does make a difference to the future of development. So how can we expect people to easily add things in future? Put it another way, most developers are living in the past. When somebody sits down in front of a piece of code, they are projecting themselves into the past. Maybe it was past them. Maybe it was past somebody else. But when people are working on a code base, they are spending, let’s say, in an eight-hour day, they are spending about seven to seven-and-a-half hours dealing with the problems of the past.

“Oh, I’m trying to add a feature”. Yeah. I can see you’re trying to add a feature, but actually what you’re doing is you’re grappling with the way that the code has evolved. You’re actually fighting the past, because you know that you want this feature to be different, but you don’t understand the code that’s there. Or you are fixing a bug. Fixing a bug is living in the past. Trying to understand code that was written, that’s living in the past. Working around something, that’s living in the past. Writing a test for a piece of code that doesn’t have a test, that’s living in the past. In other words, these are all things that should have been solved in the past. People spend most of their time living in the past, and I’m not saying that we don’t do that or shouldn’t do that. Well, there’s always gonna be some percentage. But I think that actually defines most of what programmers do. Very few developers actually spend their time genuinely adding value to code bases. They spend their time compensating for the problems of the past. And this is a distinction that systems thinker, John Seddon, highlights as value demand versus failure demand. The demand for your work, how much of your work is actually spent on dealing with problems that have arisen in the past? And more importantly for me, problems that are actually solved problems.

So let me bring something more up to date. So refactoring. I think for many people, they just assume that’s part of the software development landscape. Actually, until the late nineties, that wasn’t really a known term or a popular idea. In one sense, we’ve done really well here. But if you go back and you look at Martin Fowler’s original book on refactoring or the original writings in terms of extreme programming, which really focused, tried to bring refactoring as forward to the front as it were. So refactoring in many people’s heads exists in one of two spaces. Oh, refactoring. That’s a big work we do on a legacy code base. You know, refactoring is to do with legacy. It’s to do with bad code. And then the other one is, oh, refactoring. Yeah. That’s a shortcut key that gets me to rename things and occasionally extract method. And it’s just like, actually, refactoring is a design practice, and it’s not always about bad code.

Refactoring is the idea that your software is supposed to be soft. And therefore, when you come up with a better understanding of something, you’re, oh, wait a minute, there’s a better way of writing this. I should be able to reshape it easily so that I reflect my current thinking instead of using yesterday’s thinking. I’ve got my current thinking. I keep the code fresh. Therefore, it’s constantly in the state of improvement and response. Cause we’re always operating with incomplete knowledge, we can never know everything. It also allows me to be more forgiving, if you like. Yeah, we got that wrong, but now we can make it right, and that’s not a big deal. That’s part of what we call software development. It’s not a separate thing. It’s not a separate activity I have to ask somebody permission for. It doesn’t have that idea there. It’s just part of the flow. And so, I think that although you open up a modern IDE, it’s got refactoring there. Most people don’t use that, apart from rename.

I kind of have a standard joke when I point out to people. It’s just like, isn’t it great these days we don’t have legacy code? Cause when I joined the industry, we had legacy code. In fact, the term legacy was first used in 1989. So the term legacy applied to code was actually the year that I joined the industry. And I say, isn’t it great these days that we don’t have legacy code? Because we’ve got the refactoring tools that eliminate most of all the problems. You know, when people used to complain, oh, we’ve got this method, it’s too long. It’s so good that we don’t have that problem anymore, because we have ways of breaking up methods. And people say, oh yeah, classes that are too big. Again, we don’t have those problems because you can extract class. Eventually, kind of people get the idea that I am joking, and actually I’m asking a deeper question. We have these tools, so why do we still have all of the problems that these tools solve? And what that actually teaches us is it was not a tooling problem. That’s what it teaches us. We have given everybody everything they need.

So in other words, this is the interesting thing. For most software, we know how to deliver it with low defects, with low unmanaged technical debt, and to deliver it close to being on time. These are solved problems. By the end of the 20th century, every single one of the problems I’ve just mentioned was solved. And yet, we still struggle with them. So for me, that’s the bit of the past you want to live in. What are the good ideas we are still not applying consistently? I still have to discuss with people whether or not they should test. That shouldn’t even be a discussion. Okay. You write tests. If you can get high statement coverage, well done. There’re other forms of coverage, but that should be the minimum. When people say, oh yeah, we’ve got less. Do you have a hundred percent statement coverage? No. No, we’re at about 50%. Okay. You do know that a hundred percent statement coverage is really easy to get, and people are always shocked by that. It’s just like, well, yeah. You just do test driven development. That’s it. People who TDD don’t worry about coverage, or rather they worry about when the needle dips below a hundred, cause that normally means there’s some dead code. Statement coverage is only interesting for people that don’t do TDD or other forms of continuous testing. The idea if you are doing continuous testing, coverage is not interesting. It’s a figure that you always expect to be high because you’re always writing your code and your test together. Maybe you lead with the test, TDD style. This is a solved problem. We solved this years ago, but people still struggle with it. They try to justify having to write tests.

I was talking to somebody yesterday from Microsoft about this whole thing, about why is it that people are not using static analysis and high warning levels more. There are reasons, but they’re not very good ones. Why do people not have clean builds? Once you solve all of these, it leaves you with the real problems that are interesting. Once you’ve cleaned up the bad code, once you’ve cleaned up all of this kind of stuff, you will still have legacy. But that legacy will be there for a different reason. That legacy will be left over decisions from the past. Your challenge is now to deal with like, yeah, we took this decision, but the technology landscape or the requirements have moved. So that decision is no longer appropriate. It’s not a bad decision. It just doesn’t fit the world anymore. And we wrote this code in good faith, but now it’s no longer right. So we need a better fit for the code and the world.

So don’t worry, once we’ve solved all the problems, there are still plenty of problems. But what I’m saying is that most of the things that people have said, hey, modularise your code. Use a coherent paradigm. Have less state mutability. That doesn’t mean you have to go doing functional programming. If you’re in a functional language, that’s absolutely brilliant. If you’re in a language that really nudges you in that direction, that’s great. But even as somebody who’s worked in C and Fortran, I’m going to say, you don’t have to have highly imperative code. That’s never been a great idea, and you are not forced into that. There are simple techniques you can deal with. Modularise your code. Use various techniques. A class is a module. In this sense, it is a modular construct. Any form of data abstraction is a modular construct. Microservices are modular constructs at a larger scale.

But the idea is if you think that microservices are going to solve your poor modularity in your code, they’re not. Whenever everybody says, hey, we’re doing microservices cause it’s going to improve the structure of our code. Well, you don’t need microservices to do that. Microservices solve a very specific problem related to deployment and scaling. That’s what they’re really good at. If we have had so many paradigms over the last few decades that are about how to organize your code, you don’t need anymore. You’ve got every single tool, and if you can’t do it with that, then you should take a step back. Put the mouse down, step away from the keyboard and go, wait, what’s really going on here? What is it that we are missing as a team collectively to reinforce these practices? So yeah, the past is an interesting place. We get drawn back to our mistakes in the past, but we fail to learn from our successes. So that would be my general advice on this one.

Henry Suryawirawan: Listening to your explanation is very fascinating. Because a lot of developers these days chase this hype driven development, right? Oh, there’re the new cool technologies, new framework, new libraries, new paradigms like microservices. Event driven and things like that. But if you look back to the past, there are probably so many theories that still stay relevant. And in fact, I noticed some of these thought leaders in the tech industry like Dave Farley, Robert Martin, Uncle Bob. They wrote books titled like Modern Software Engineering and Clean Craftsmanship. But if you look at the things that they are advocating, actually it comes from the past. The same fundamental things that stay relevant even up until now.

So I think the key message here I want to emphasize is that for developers, please go back to the fundamentals. Don’t always chase the new shiny things. There are still things that we can probably master to become a better developer.

Kevlin Henney: Yeah. And I think the value is that when you understand that it gives you a more solid foundation, and when something new and shiny does come along, you now have a more objective assessment. You can separate out and go, okay yeah, this is building on foundations. There’s nothing new here. And then you can look at the bit that actually is shiny and go, this is the value of this. Or you may say, wait a minute, there is nothing shiny here. This is just repackaging the past, and also its mistakes. So maybe let’s not do this one. It gives you a more objective sense. Of course, most people in technology get into technology, cause they like the excitement of something. So we have to kind of watch ourselves a little bit on this. We are our own worst enemy at this one.

Henry Suryawirawan: So one thing that I always find fascinating also, because there are tools that are built by developers that make things easier for us to churn out code, but not necessarily comply with this cohesion or this coupling. So think of it like the frameworks, software frameworks, right? So I think that’s also another thing that is fascinating. Like we tend to want shortcuts, deliver something faster, but not adhering to the good, best principles that software should be written in.

[00:38:28] KevlinHenney Screens

Henry Suryawirawan: So, Kevlin, another thing that you are very popular in, it’s what people call Kevlin Henney screen, right? You can see in Kevlin Henney’s Twitter. Just look at “What we call software failure”. And these are normally public software failure, and people just send, you know, pictures of these software failures to Kevlin. So maybe the first thing is tell us what the story is all about? How come people actually send all these things to you?

Kevlin Henney: So the story goes back a long way. I used to take screenshots. Whenever something crashed on my machine, I’d take a screenshot of it. And sometimes I would integrate it into a talk. And then, of course, phones have cameras. So I started taking pictures of software failures in public places. Because software runs the world, but it doesn’t always run in a way that we wanted to. There’s a lot of reboot screens and screens which trace very elegantly the whole text stack that’s just crashed.

I started taking photographs of these, and again, I’d incorporate those into talks or I’d just kind of put them on my screen when running a workshop. A good source of entertainment, but also going back to this question of quality as something I’ve always had an interest in. It’s a reminder of like, yeah, in the tech space, we have a certain responsibility. We are creating things that crash. We are creating things that don’t work. A bug is personal inconvenience to you, or a configuration issue is a personal inconvenience to you, or it just becomes a ticket. The thing is to realize that it exists in the world. It’s not an abstraction. It actually exists in the world. It’s amusing sometimes, but also it’s probably preventing somebody else being able to do something.

So I kind of highlighted these. Then as a result of this, people would then start emailing me these things. Then we hit the social media era, so it’s much easier. They don’t have to email me, they can just tag me. So this is becoming a popular thing. On Twitter, in particular, what I would do, because that’s a very public space, is that I would just retweet these. Then people started making a point of doing this, and in 2016, somebody actually started saying, oh, a Kevlin Henney screen. Because it had reached a particular point. And so that’s how my name got associated with it from that point. There’s even somebody put an entry in Urban Dictionary, and there’s even a mention in the register of this stuff. So that’s kind of an interesting thing.

I was also asked by somebody, “Kevlin, what does it feel like to have your name associated with failure?” Which I think is an interesting way of looking at it. It’s just like, yeah. I don’t cause these screens. But it is interesting because it’s a reminder for me that, you know, when we deal with software, when we develop it and when we deploy it, we are part of a larger system where our failures in software are no longer about us. They are about other people. They become very visible. And in a world that runs on software, that becomes a prominent point.

Some of them are quite revealing in a way that you don’t want to be revealing. Like I said, sometimes you get a complete stack trace. In fact, I saw one yesterday, which was quite interesting. The stack trace was not visible even though there was an error, because whoever created this had the wisdom to say, you know what, we are showing our internal structure that can be used against us. From a security point of view, you discover that somebody’s using an unpatched version of something. You go, oh yeah, that’s interesting. I’ve got a new attack vector there. But it also tells us something about the organizations that run them. I still get images of Windows XP boot screens and failure screens. Windows XP has been out of support for a very long time. Again, we are living in the past. A lot of the world is running on stuff that everybody thinks they left behind, but there isn’t. It’s actually all there. We have a responsibility there that we need to get a little better at this.

But then, we also get the obvious programmer level bugs. It’s just like, yep, we should have perhaps configured that a little more carefully or tested that more thoroughly. It tells us about us. That’s what a lot of these things do. But what is also interesting is that sometimes when people tag me, particularly if it’s something like public transport, they will also tag the public transport company. And some of the time the public transport, whoever’s on Twitter at that point, will sort of say, “Oh yeah, sorry about this,” or “Yes, we’ve seen this problem. It’s been resolved”, or “Please tell us more cause, you know, this is embarrassing for us”. So it’s also a public service at that level.

Henry Suryawirawan: I hope you all, the programmers who build systems, never had a chance for your systems to be sent to Kevlin Henney for failures. But I think the story that you just told, right, I think there’s a lot of things here that are insights. So when you deploy software, especially for public systems, like public transport, airports, sometimes I see, or elevator. So there are a lot of responsibilities. Software failure can impact a lot of people. These kind of things are definitely for one thing is funny, yes. But at the other end, it’s something for us to ponder about. Software failures should be treated more seriously.

[00:42:49] Public Speaking, Writing, and Compassion

Henry Suryawirawan: So coming back to the beginning when you mentioned you also love writing, public speaking, and things like that. You mentioned that developer should focus not just on coding. Maybe you can explain why we should all think about writing more or speaking more or having more compassion, which you mentioned as well before we talk.

Kevlin Henney: So people have many different roads into software development. Therefore, that reflects different motivations. So this is my story as a teenager. I was interested in home computing, all this kind of stuff. This was the technological change that affected me and was a natural area of interest. But, of course, that was very much about you being an individual and solving problems and playing around. It was ultimately all about play. There is that idea, but it’s also ultimately about you.

Other people arrive in software from very different paths. It’s because they work with teams. So I know a number of people who have moved, as it were, from the customer side or the product owner side, the business side, into being a developer, because they worked so closely. So in other words, their initial point of contact with software was not from the technical ground up perspective. It was not the bits and the bytes. It was not that perspective. It was not as a formalism. It was as a business tool and working in teams. So they have a much more social perspective of that.

So some people already have that view of software development. But I think many people end up in software development without properly appreciating that what they’re trying to do is communicate. Ultimately, that’s what we do. And we’re not just talking to a compiler. We are talking to ourselves, our future selves. We are talking to our colleagues. We are talking to people we will never meet. In one very simple sense, we are organizing our thoughts. That is what a programming paradigm is. It is a framework for organizing your thoughts and your knowledge. You are taking knowledge that is technological and technical. You are taking knowledge of the problem domain, and you are bringing together in a formal structure, and you are saying, here is how we have chosen to meet this requirement to the best of our knowledge and best of our ability at this particular point in time. That’s what you are effectively communicating. By the way, it compiles and runs. That’s kind of important.

But there is an idea here. When we take a step back and we realize communication is the clarity of our own thoughts. We often don’t think clearly to ourselves. It’s a discipline. Different philosophical schools go back potentially thousands of years. They are often about how do we do the day-to-day? How do we communicate our intentions clearly? How do we take a step back and separate what we believe from what actually is? Cause sometimes our beliefs do not match up to the way the world is. I mean, these are age-old questions.

Software is one of the places we bring these all together. So, for me, that idea means I need to have a bigger understanding than just, hey, I can use a framework, or I understand formal systems and perhaps I have a mathematical background and so on. The word itself, communication, comes from the Latin. Communis meaning together. It’s about being together. That’s what it is. That’s the whole idea. And what is it that causes that and improves that? For me, different people have different paths in. So I think writing is an interesting one. Because when you look at advice for writing, a lot of it transfers straight into software development. There’s no boundary there. You go, oh yeah. The intentions are the same. But it reminds you that you are an author for somebody else. You’re not merely instructing the machine. It’s not merely a functional thing that it should go. In fact, that’s a reminder.

Software development is not about projects. It’s about products. A project is something that you finish, whereas software development, generally, the goal is not to finish. I don’t mean don’t deliver. I mean, the idea is that we are always building. We are not aiming for a release. We are aiming to keep on releasing. The name of the game is to keep on playing the game. And so, therefore, we need to create a sustainable environment. And code is the environment we create. So we need to get better at communication, and that also means communication to ourselves. You always have a way more overconfident belief that you know what you did in future at the time than in future. And in future you will come back and go, I have no idea what I was thinking when I wrote this. You remember it was clear in your head, but you don’t remember why. So that idea of genuinely organizing your thoughts, and, for me, writing, is one of those techniques. And the advice that we find on writing translates very well to a lot of the things in code.

But then also things like speaking. Speaking is an interesting one because many people fear it, because you’re standing up in front of strangers or in front of colleagues. You are potentially very vulnerable. And that’s a big ask. It’s not something that necessarily everybody’s going to feel comfortable with. But the one thing we can say, and this goes for writing as well and other works, you know, so occasionally, I run across people who express themselves differently. There’s a very high number of people who play musical instrument in software, for example. That’s you expressing yourself. It’s not expressing yourself in the same way with the same intent. But that is you creating a structure and enjoying doing so. What can you take from that?

There are two things. One, you are creating a structure that’s supposed to make sense. There are rules and boundaries on that structure. Some of those rules and boundaries can be broken to create new rules and boundaries. But there is also skill and there is also enjoyment. Hey, these all sound like things that I would like to think I could bring to my work as well, my pastime. So the idea is that there’s a lot to be learned from these other forms of expression. And so, sometimes people will be more than happy to stand on stage and play a guitar, but say, oh no, I can’t stand in front of people and talk in front of slides. And it’s just like, take a step back and think, hang on, what could I transfer between these worlds? Can I move my skill at communication and expression into something more verbal? Cause code is ultimately a verbal construct. It’s word-based. It doesn’t mean everybody’s going out speaking the same or necessarily everybody’s going to be totally comfortable with it. But the more you do it, the easier it becomes, and you start realizing your own gaps, your own shortcomings. And you generally get a bit better. If you were nervous at the beginning, you are less nervous in future. If you are very nervous at the beginning, you are just nervous in future. If you are a little bit nervous, you are not nervous in future just by doing it and repeating it.

But that also goes to compassion. Cause just now you mentioned compassion, and I also just said, when you write, if you publish a blog, you are potentially vulnerable. You are exposing your thinking and your thoughts and you are writing. Particularly if you are writing a language that is not your first language, you may feel very vulnerable. The main thing is people are always a lot kinder than you think they are. Actually, they will appreciate your effort. If you think you have nothing new to add. Yeah, you are mostly wrong on that one. I don’t like to tell people they’re wrong, but you’re mostly wrong cause you have a point of view. I was telling somebody the other day. I said, there is something I envy you for, because I will never be able to go back to that stage. At this point, I will never have that journey of discovery again, because I remember most things. But you are about to enter a point in your career where you are going to start learning things for the first time and they’re going to be exciting, and you’re going to discover you can do things that you didn’t think you could.

You are going to have technical insights. You’ve been working with frameworks that you were taught about, but then you are going to go above and beyond that, and you’re going to suddenly realize, hey, I have a bigger picture here. And I understand something about architecture that nobody’s ever told me, and you see that for yourself. There’s a whole load of things there that you and only you can experience. So you have that ability to offer that to other people. And wouldn’t it be a shame if the thing that holds you back from doing that is a fear of your own communication? And that doesn’t mean you’re going to write the perfect thing, but you know what? If you don’t write it, it’ll definitely be very imperfect. The world is missing that contribution.

But that’s the idea. Compassion is also very important. Literally, funnily enough, compassion means to suffer with somebody. Compassion means to understand that you see somebody else is, they’re making a bunch of mistakes and yeah, you know what? I know what that feels like. Somebody else is struggling to give a talk or organize their thoughts. You know what, maybe they’re having a bad day, or, I understand what that feels like, all of these things. It’s that kind of recognition that we spent so much time working with machines and tools. We’ve got to remember, oh yeah, it’s human. So for me, I think that’s a really important emphasis. The emphasis has come about slowly through the years. Seeing people talk about this, and then a few years ago, April Wenzel really kind of coined this idea of compassionate coding. And it’s just like that, it’s just like, oh yeah, this is a big signal. This is absolutely okay for everybody to talk about this stuff. It’s okay to make mistakes. You understand the other person is human, which means, hopefully, they understand that you are human. Which takes a lot of pressure off. I think a lot of people are under a lot of pressure to perform an expectation and so on. If you can take a little bit of that off it goes, again, back to funnily enough, put the mouse down, step away from the keyboard. It allows you to think differently and more loosely. If you are constantly feeling pressured, that’s going to box your thinking, that’s going to reduce your ability to be creative and have insights. You become a machine, which we’ve already got those.

So, you need to kind of give people that space. There’s emotional and social space there as well, which I think is important. So for me, that’s part of the message as well. And, again, when we look at a piece of code and we don’t like it, it’s really easy to go, “Oh man, whoever wrote this was an idiot”. And it’s just like maybe it was you. Maybe the idiot was past me. But more to the point is, yeah, you know what? Maybe they weren’t an idiot. Maybe they just had a bad day. Maybe they were working to the best of their ability. That idea is that in the future, you will always know more than you do now, but the code is not being written in the future. It’s being written today. We may revisit it in future. We may refine it in future. And again, it goes back to that idea of like refactoring being a forgiving process. You’ve got to work with what you’ve got today. Unless you have a time machine, you’ve got to work with something else, so do it. But that also means in the future you’ve got to go back and go like, yeah, I remember thinking this. Yeah, I was wrong. There’s nothing wrong with being wrong, but you’ve just got to frame it in a way that goes like, yeah, we did our best, but now we know better. And that’s absolutely fine. That’s a better frame than, damn, we were idiots and we should never be allowed near keyboards again. It’s a very harsh way of looking at it.

So that, for me, compassion is that missing ingredient. And that was never made clear to me when I joined the industry, or in fact, for most of the time I’ve been in the industry. That’s actually an important ingredient in creating large software systems and companies based on software. You kind of have to have a bit of that if you want to have the longevity and all those quality and productivity aspirations people have. There’s a magic ingredient, and it’s the appreciation of other people.

Henry Suryawirawan: Wow. There’s so many things great from your explanation, right? Starting from how to organize thought, clarifying your thinking process. Many programmers probably started their career thinking that they will work just with machine and keyboard. They don’t like talking with other people. But, actually, software development is about communication. Communication with other people, not just from business, but maybe with your users or maybe some other people as well. When you can clarify and communicate better, I think you become a better software developer as well.

And I think compassion, I hear you loud and clear. Many people these days, especially in the tech industry, in the startup world, they tend to just thinking of fast pace. Always deliver, always churning out things. But they lack compassion, thinking about the thing that there are people are chasing. It’s actually thinking about the people aspect as well, not just producing code. So I think your message is really important for all of us here to think about compassion and not to always downgrade people as a developer.

Kevlin Henney: We have skills and abstraction, but we should be careful about applying those skills to people.

Henry Suryawirawan: Yeah. Yeah. So we should not downgrade people, thinking they’re just developers.

[00:53:46] 3 Tech Lead Wisdom

Henry Suryawirawan: So Kevlin, it’s been a great conversation. Unfortunately, due to time, we have to wrap up. I have one last question though, that I would like to ask you, which I call the three technical leadership wisdom. So think of it just like advice for other people to think about or ponder with their journey as well. So maybe can you share with us those three technical leadership wisdom?

Kevlin Henney: Yeah, I think they actually kind of follow on from the previous points we’re making, interestingly enough. That’s taken us to a very interesting place. So the first thing, I guess, a really simple one when we talk about technical leadership is definitely lead by example, and that’s harder than it sounds. But the idea is when you are trying to instill a change, we are taught about telling people. And funny enough, in the writing world, there is this idea of show don’t tell. When you write something, the idea is what is it in your writing that communicates what’s going on. Don’t just give a description of everything that’s going on and, you know, and have quote marks around, “I don’t love you anymore.” She said angrily. What’s that word angrily doing there? How do people behave when they’re angry? She slammed the door as she left. Ah, slamming the door. Wow. Okay. She’s angry. In other words, show me the thing. Don’t just tell me the thing. Show me the thing.

And I think the same thing applies. It paints a richer picture. So it is very easy to fall into a position where, potentially, if we’re advocating a practice within a team, we’re telling people. Now, sure, that message might get through, but probably doesn’t, and it probably doesn’t mean anything. You got to work at the level at, what does it mean? If I recommend a practice, can I show you what it is? What if I do that? What if nobody else does that? That’s fine. But imagine you did it and you were able to point to it. What’s that you’re doing? Oh, okay. That’s kind of interesting. I see you are using a different commit message philosophy to the way that I’m writing commits. But your commit message philosophy seems to have clearer communication and you break your commits down to smaller levels than perhaps other people in the team do, and you realize they’re much more transactional. Well, there you go. You’ve got an example. Lead by example is a really important thing. And sometimes that means leading before you tell. Do that in practice. It becomes more of a habit. You are also in a better position to talk about the adoption of it. It’s an example, not just because you’re not being a hypocrite. “Hey, I’m telling you to do something, but I’m doing something else,” but also because it may mean more to people when they actually see it in action. You know, whatever that practice is, whatever that advocacy is, whatever that recommendation is, if you can see it in the world, it makes a lot more sense to me than just being told it. So I think that’s kind of the first one.

The other one. So people get called team leaders. They get called technical leaders in organization. They get called leaders. But that doesn’t always mean you are leading. To be a leader, you have to have people who follow. They can either be told to follow you or they kind of follow you. So the leading by example is one thing, but the other thing is you got to realize that if you are trying to advocate things, you are not going to come up with everything. You are not going to lead. You shouldn’t do all the work. Otherwise you’re gonna end up in the position where you become a micromanager, not a leader.

And also recognize that, particularly when we talk about teams and organizations, they are social constructs. Again, we’re back to the people. There’s a lot of intelligent people in software. There’s a lot of creative individuals. And everybody knows something that you don’t. Even if they know the things that you know, they will know them differently. You cannot know something for somebody else and you cannot know it necessarily in the same way. Actually, rely on other people to come up with ideas. It’s not your job to do all of the work. Rely on other people and give them credit. So that’s the important thing. Make that visible. I sometimes see with people who consider themselves to be leaders is they think they have to do all the thinking. No. Actually, your value goes up by recognizing and letting other people do this and make it explicit that they came up with that. That’s where people will go. Yeah. That person’s a leader. They credited me. They see what I’m doing. You got to see them and make that visible and make sure other people see them. So that’s a really important idea.

And the other one picks up on another theme that we’ve had throughout our conversation today, which is admit you’re wrong. You’re going to make mistakes. That’s a really hard thing to do. Sometimes that may be at a personal communication level with somebody. You may make a mistake. You may misjudge something. You may be too emotional. You may misread somebody else’s emotion, but it may also be something technical. Perhaps, that you kind of almost staked your career on, we’re going to do this, and you’ve got to go, you know what? I was wrong. Actually, that wasn’t the best option, and now I understand why. That whole thing rather than trying to hide it or dig into it even more deeply. That’s a really important thing. Again, your stock goes up as a result of that. But also that’s a compassion for yourself. Don’t hold yourself to unreasonable standards because otherwise, you always miss. So that’s very much the idea of work with a growth mindset rather than a fixed mindset. So yeah, you’re going to make mistakes. We are always operating with incomplete knowledge and we are inevitably imperfect, and that’s absolutely fine. Just roll with that. That’s the way that you do it, and the people will see that.

Henry Suryawirawan: Yeah. Admitting we are wrong sometimes is very difficult. We are putting ourselves with vulnerabilities. Some people fear about being vulnerable, people being attacked, right?

Kevlin Henney: Yeah. If I’m supposed to be the expert and I got something wrong, does that mean I’m no longer the expert? Oh my God. That puts you in a very vulnerable position. There’s a perfectionism there that becomes quite predatory and quite dangerous and doesn’t help anybody’s mood. Whereas actually there’s occasion like, yeah, you know what, you were wrong, and that’s fine. It’s okay to be wrong.

Henry Suryawirawan: Yeah. Especially in tech, where people have egos and have impostor syndromes, so they tend to hide all this. So I think that’s a very beautiful message. Not to fear of admitting we are wrong sometimes.

So, Kevlin, for people who love to connect with you or maybe follow some things that you write or speak about, is there a place where they can find you online?

Kevlin Henney: Yeah. I’m in a number of different places. My parents were kind enough to give me an internet unique name before the internet was invented. So Kevlin Henney is an easy thing to find. So you can find me on Twitter there as Kevlin Henney. You can find me on Mastodon as @kevlin@mastodon.s ocial. You can find me on LinkedIn. So these are the most obvious places where I hang out. And so I look forward to seeing people online.

Henry Suryawirawan: I’ll put that in the show notes. Thank you so much for this time, Kevlin. I learned a lot from you today.

Kevlin Henney: Thank you, Henry.

– End –