In the tech space, we have a certain responsibility, we are creating things that crash. We are creating things that don't work. It's a reminder for me that, you know, when we do 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. There are about other people. They become very visible in a world that runs on software. That becomes a problem point.
Hey everyone. My name is Henry Surya, we Robin. And you're listening to the technology, you know, podcast the show where I'll be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal.
Hello to all of you, my friends and my listeners, welcome to the package, you know, 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 technology, you know, 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 technology. Not deaf / Patron, My guest, for today's episode is Carolyn honey. Carolyn is a consultant writer and speaker on software development and he has written and edited several popular software development books. In this episode, Carolyn shared his three 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 deeper. Work putting code comments, wisely, and using testing not just for checks but also for communication tool. Carolyn 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 Carolyn, hennesy screens and how the trend started in the beginning towards the end, Carolyn 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 Kathleen, Kathleen 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 of five star rating, and review on Apple podcast and Spotify. It will help me a lot to make this podcast easily, discovered by others. Before we continue to the conversation with Carolyn. Let's hear some words from our sponsors. Today's episode is proudly sponsored by skills method. The global community and events platform with more than 100,000 software professionals here members, can organize their learning experiences around the technology topics.
They care about. Most you get on-demand access to their latest content thought, leadership insights, as well as the exciting schedule of tech events running across all time zones. So whether devops our data science is your bus or you are fan of functional programming or all things Cloud. You can make real connections with people who share your interests head on over to skills method or Cam to become part of the tech community that matters most to you. It's free to join and you will
find it easy. See to keep up with the latest tech Trends. Hello everyone. Welcome back to another new episode of the pycnogenol podcast today, I'm very excited. I met someone who I went to a talk in 2013, which was a jail. 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 Oh, this series called 97 things haven't actually help to edit a few books, 27 things, every programmer should know, and 97 things. Every Java programmer should know. So Carolyn really looking forward to have this chance to talk to you today, and welcome to Tech to Juneau. Thank you very much for inviting. Me Henry, great to be here.
So, Carolyn 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 Yeah, so I didn't know that I was going to end up in software. I don't think that was part of the plan, maybe something technological, but I didn't know that either. My first degree was in physics and I realized part way 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 finish my degree. I had no idea what I was going to.
Do in a friend of mine said, Hey Kevin, I've just gone for a job interview at a company and they're looking for programmers and you don't have to have a 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 by the most interesting things, the work itself was not
necessarily that interesting. Although hindsight I think there were some really interesting opportunities. What was interesting is that my boss had this bookshelf, this huge book shelf 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. I was just looking through this
stuff and this is great. I 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 do a master's degree in parallel computers. Systems, which happened to have
some of the AI stuff. I was interested in, but I also realized it was a lot of good programming Paradigm stuff in there that kind of sealed the deal for me is like, yeah, you're going to be in software development, that's the way it goes. And so, I ended up working after that procedure is companies, typically was kind of back-end
or embedded type stuff. Although I did do a whole lot of UI stuff relatively early on, but eventually there came to be a point where I was getting really frustrated with company politics. I think a lot of people work in environments where I was just like, yeah, I'm enjoying the Yes, there's my colleagues. This is all good. I'm enjoying all of 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 called sex 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 fertilizer. I'd been doing some Contracting
at that point. Which is kind of a good way to seal 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 enjoy the kind of like the connections that I was making these people. I enjoyed the use of white board 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 Communicating it, you start realizing the, 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 to explain the 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 that and Really, I decided many years ago, I would go independent fully autonomous and I've been that way ever since my work is 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 went to a, there's Betty major turning point since then.
Because for me it's all one big flow of many possibilities sometimes, one month is the same as the next and other times. I might be doing something completely different. I guess the only other thing that really changed was the
pandemic. She completely online which has allowed me to change the way that I run an offer things like workshops training and also talks they 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 against 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 I 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 unlocked some of the more interesting parts or software development. Thanks for sharing your story. I think it's pretty interesting.
When you mention about finding Fascination in writing speaking and getting feedback loops, I always find you pretty natural in speaking and engaging with 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 K Journey, maybe to write more and speak more in order to get that social aspect of the software
development as well. Maybe, let's start with some of the things that you edit it 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 thing's for sure. What would be. Some of your advice for developers here, what things they should know what God said it should avoid, or maybe just some things that you think they should.
A should you know, dive deeper? Yeah, I think that's an interesting one because obviously there are 97 things in each of the every program should know and every Java program 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 a think of the ones that I've used in the last week or directed people towards in the last week.
Here we are 20 22.97 things. Every program should know that book was published in 2010 and 97 things every child program. She knows probably In 2020. But the funny thing is the first
books 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 because they are relatively Timeless, you won't find mention of microservices, but you will find mention of functional programming, you will find mention of caring about your dependencies in your structures and 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 tools because 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 Clearinghouse everything, I teach or communicate, typically came from somebody else and if 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 birkhoff naugles. Piece in 97 things.
Every program should know. He also contributed a Java program should though, but the one that I always come back to, in 97 things, every program should note is the Entitled, put down your Mouse step away from the keyboard. I like this because it works on two levels. First of all, there is the general advice of the peace 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 opportunities run dry. Otherwise you have solved it, you've done everything. Nothing you can at this level and doing more of it is not
going to help. So therefore this point 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 certain
Also, 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 on. 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're not good at and I don't mean you as picking somebody else. I mean, you as a human being Being and not necessarily good at is knowing how to use your time. This is not a strength that we have with very poor at this. Then actually, if you want to save time then stop working. This is counter-intuitive. Some people, I know I need to put in more hours. I need to put in two more hours on this problems.
Like actually you're 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 why 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 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 was peace, but I also like his peace 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 reflected and it's really messy and complicated and procedural. He does the right thing but then he steps away and realizes 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. It's 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 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 there. Exactly about pulling yourself away, the exact opposite. So I really like that piece because 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 Co so that one I think for me always sticks out as a, 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 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. I have comments is an interesting one in software because comments are code. That is not code. You know, as they don't have a formal syntax, they are code, that is not cone 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 Messy and your comments. That's not going to cause anything. If you're 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 a quite a frightening thing. People don't know what to do with it. And so we have these observations about, okay? Your comments, become out-of-date more 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. People is like, don't comment your Code, all comments are bad. Always kind of star.
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 in automatically improves your code.
Although I've seen coat which would be improved by deleting the comment, I don't think it's an automatic consequence. So there's a lack of nuance. For most devices, like don't comment your code. Lacks intelligence Nuance, you want to understand why? But at the other end, the common, 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, 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're 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 is 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 what I, it's not obvious, what I'm saying. Okay. So recognize that as a neat, that doesn't mean you need a comment yet, 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 Caishen gap between that and the thoughts in my head, what I feel. I want communicate. We're not saying everything that we want to, so that's a good first candidate for baby why we want to comment, but don't do it just yet. If 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 In for the code. Why don't I call it altitude? There you go. I've got a better name for it and I was, I can say it in the code. If I got a big block of code and I've got a big banner up at the front. Let's go 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 is just like, why we not factoring this out into methods? That's what therefore, they are blocks. That is what a method is fundamentally. It is a catcher block with a name and a Clear set of
parameters. And if that deserves, an appropriate, javadoc style Comet, then that's fine because that comment is for external documentation, it's not for the reader of the code, it's for the user that belongs to documentation, says, post 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, right? Code, write the code if you didn't have God. 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 kg of iron is worth significantly less than the kg of gold. Although iron is technically more. Useful, as a material, the higher value, gold is defined by scarcity.
If you had as much gold in the world, as there is iron, a kilo of gold be worth a lot less than a kilo of ironing. Not a very useful substance in that quantity. So the idea there is scarcity helps to find the values. You put comments everywhere they worth nothing. So for me, that's something I find. I'm 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 therapies except that I would say, what's interesting in both of the books that 97 exemplary program should notebook. And then I've said, things, every Java program should do book is there is a really strong emphasis people have really
consistent on testing. I got a lot of pieces and very well, written pieces on test this idea that as part of the coding cycle, that is part of the fabric of software developers, not something else, it's not there as software development and there is testing, testing is a part of software. Element 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 programmers should know from research 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 in to get books. I intentionally created book with a Creative Commons license, so that people could do that. So there's a gift box version of it. 497 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 dijk, 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 testers, communication tests are not merely checking anybody who's
kind of communicating. Oh yeah, tested. 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 some 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 expression of
intention. There are four of communication, they're kind of an opportunity. Not only for somebody else to understand what's going on. They 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 all what are we trying to say here? And that's actually the hardest thing mechanics of the test or something. I think we get drawn into a lot but actually that's not the hard
part. The hard part is one of you 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 Next with what I just said about comments, is we have all these other means of communicating or intention and again sometimes I might be writing a piece of code and I say okay here's the thing.
I couldn't say always not easily said in the code and I might start writing a comment. I said well maybe if I showed you an example of interaction. What a great idea. An example of interaction. Let here's 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 to test.
You've communicated Tasted intention, you've created the test from understanding that you are trying to say something that was not otherwise easily set. So I for me, these for part of a thinking system sets, I know it's very hard to pick favorites from the 97 times to. I don't know whether there are any overlaps from the two books just to summarize. The first things about being detached from working intense
for a long time, right? So sometimes we as developers, we Crack the Code, we just rash and we just deliver features of a bitches 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. Exactly looking at the code and things like that or even ideas how we can do things better. And the second one is about common, don't put comment if the code can already say, is that.
So I think it's really crucial because sometimes I still see comment. Like you mentioned. Write 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, or 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 test. But the test names, the test cases, all the things that are inside the test, probably as just a 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 test is communication. And again, that idea comments is communication. If we regard what we're doing in creating a code base for 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 Just a mechanical thing.
It's an intention setting. So one thing that I noticed when you mention in the beginning before you grief 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 stays relevant there, 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 are still stays relevant. So let's go back to origin story. So I read a lot of books. When I got into software development was the end of the 1980s, which is quite a long time ago and the world has changed 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 all 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 these message. People have got distracted by guidelines that don't emphasize these properly or have watered
them down in a particular way. It cohesion, and coupling cohesion, the degree to, which things cohere and naturally hold together. Now, sometimes people kind of psycho wasn't that the single responsibility principle, well, not really it. They kind of cohesion, it's not about responsibilities. The original quote, has the single responsibility principle is actually about single reason for Change has nothing to do with responsibilities, so naming is hard. We know that single reason for
change. What does that actually mean? It does 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 dependent And it sees in code bases. Now, for some people when they talk about dependencies they are talk about. External dependencies, you sort of say, oh dependency management. Yeah. And they show you all their external dependencies. Like yeah, he got half a million lines, count. It I'm talking about the dependencies in the code base, not just outside the code base.
Some people are kind of ended up kind of losing track of that. So coupling cohesion, these are ideas in 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 For our benefit, by the way, the code doesn't care. The compiler is just going to compile what you give it. It doesn't care about coupling
and cohesion. The processor you're running on doesn't care about coupling, cohesion. It's just going to execute what you say company, cohesion, for our benefit there. 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 a message there for paying attention to.
This stuff is important. And I think that's A lot of people are trying to do when they reiterate all 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 go quality. So these days, the popular way of framing things in terms of issues of Co 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 quality issues forever, since they realize 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 the past them, maybe it's passed 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. 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 is evolved, you 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're fixing a bug. Fixing a bug is living in the past, try to understand code. That was written that living in the past working around, something that's living in the past, writing a test for piece of code.
That doesn't have a test that's living in the part, you know, because 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. Don't do that or shouldn't do that. We will, 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 to pass and this is a distinction that systems thinker, John said and highlights just 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 that I think for many people are just assume that car of the software development landscape actually. Until the late 90s, 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, and terms of extreme programming, which really focused trying to bring refactoring as forward to the front as it were so refactoring. Many people's heads exist in I have two spaces all refactoring that big work, we do on our Legacy code base. You know, Refractories to do with Legacy is to do with bad code and then the other one is 0 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 by a 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 do, we make this better way of writing this, I should be able to reshape it
easily. So that I reflect my current thinking instead of me 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 because 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 is still a separate thing. It's not a separate activity. I have to ask somebody permission for, it doesn't have that idea. Oh, it's just part of the flow and so I think that although you open up a modern IDE, it's got refactoring their.
Most people don't use them apart from Reno cut of have a standard Joe when I point out to people is just like, isn't it great, these days, we don't have Legacy code because when I joined the industry, we had Legacy code. Hey, 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 a refactoring tools that eliminate most of all
the problems. You know when people Used to complain. Oh, we 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 efforts and people say, oh yeah, glasses that are too big, the game. 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? It was not a tooling problem. That's what it teaches that 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. I manage technical debt, and to deliver a 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 salt 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 apply 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. Even coverage well done.
There's other forms of coverage but that should be the minimum when people say, oh yeah, we've got less. Do you have 100% statement coverage? No, no. We're in about 50%, okay? You do know that 100% 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 do tdd, don't worry about coverage or rather, they worry about when it needle, dips below 100 because 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 So 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 TD style, this is a solved problem we solve 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 that the people are not using static analysis and high warning levels more there are reasons but they're not very good ones. Why do people that have clean build once you All of all of these 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 challenges now, to deal with like yeah we took this decision but the technology landscape all the requirements of mu. So that decision is no longer appropriate. Not a bad decision.
It's just doesn't fit the world in and we wrote this code in good faith, but now it's no longer. Right? So we need a better fit for the code in 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, modularize your code, use a coherent Paradigm, have less state mutability. That doesn't mean you have to go
doing functional programming. If your unit 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're not forced into that, there are simple techniques, you can deal with, modularize your code, use various techniques, a
class has a module. In this sense, it is a modular construct, any for data, abstraction is a modular construct, microservices. A 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 when everybody says hey, we're doing microservices because 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.
I'm 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, death away, from the keyboard. 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, past is an interesting place, we get drawn back to our mistakes in the past, but we To learn from our successes. So that be my general advice on this one. Listening to your explanation is very fascinating because I love developers these days. Chase this hype driven development, right? Oh, that's the new cool Technologies. New framework, new libraries new paradigms, like microservices event-driven and things like that.
But if we look back to the past, they're probably so many theories that still stays relevant. And in fact I notice some of these thought leaders in the tech industry like they finally Robert Martin Uncle Bob they wrote books Book's title 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 stays 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 developers here. And I think the value is, when you understand, that 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. 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 because 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. So adding that a always find fascinating. Also, because they are tools that are built by developers, that makes things easier for us to turn out code, but not necessarily comply with this, cohesion, or this coupling. So I think of it like the Frameworks of are Frameworks,
right? So I think that's also another thing that is fascinating, like with then do one shortcuts and if we're something faster, but not adhering to the good, best principles that software should be written in. So Cavalier, another thing that you are very popular in its what people call Carolyn hennesy, Right? You can see in felonies Twitter, just look at what we call
software failure. And these are normally public software failure and people just send, you know, pictures of this software failures to Kaplan. So maybe the first thing is tell us what the story is all about how come people actually, send all these things to you. So you can story goes back a long way. I used to take screenshots whenever something crashed on my machine or take a screenshot of it and sometimes I would integrate it into a talk 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 it in the way to re-watch it to. There's a lot of reboot screens and screens, which Trace very elegantly, the whole Tech stack, that's just crashed. I started taking photographs of these. Again, I did incorporate those into talks or I just kind of put them on with 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 Don't work a bug isn't personal inconvenience to you or configuration issues 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's actually exist in the
world. It's amusing. Sometimes would also probably preventing somebody else be able to do something. So I kind of highlighted these then as a result of this people within start, emailing me these things. Then we hit the social media error, so it's much easier. They don't have to email me. They can just tag me. So this is Coming a popular thing on Twitter, in particular what I would do because that's a very public space is that I would just retweet this.
Then people started making a point of doing this and in 2016, somebody actually started saying, oh, okay, Evelyn any screen because it had reached a particular points. And so that's how my name got associated with it. That point there's even somebody put an entry in Urban Dictionary and there's even a mention on the register of this stuff though. That's kind of an interesting thing. I was also asked by somebody Then what is it? Feel like to have your name
associated with failure? So thick it is, and it's just a 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 when we do 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. There are about other people. They become very visible 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 revealed. 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're showing our internal structure that can be used against us from a security point
of view. You discover the somebody's using an unpatched version of something you go. Oh yeah, that's interesting. I got a new attack Vector there, but it also tells us something about the organizations that run. I still get images of Windows XP, both screens and failure screen. Like peas been out of support for a very long time. Again we're living in the past. A lot of the world is running on stuff that everybody thinks they left behind but there isn't it?
Actually all there. We have a responsibility there. We need to get a little better at this but then we also get the obvious program. I level bugs is just like, yeah, we should have perhaps configured that looking 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 tagged me, particularly with something like public, Transport.
They will also tag the public transport company. And some of the time, the public transport, whoever's on Twitter that point was at all. Yeah, sorry about this or yes. We've saw this problem has been resolved or please tell us more because, you know, this is embarrassing for us, so it's also a public service at level. I hope you all the programmers, who build systems never had a chance for your systems to be sent to Kevin honey for failures but I think the story that you
just told, right? I think there's a lot of things here that I insights. So when you deploy software, especially for public Systems like public transport airport. Sometimes I see all 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 is something for us to ponder about software failures. Should be treated more seriously.
So, coming back to the beginning when you mention, 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 In which you mentioned as well before we talk. So people have many different roads into software development, the flight reflects different motivations.
So this is my story as a teenager, I was interested 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
team. So I know number of people who have moved as it were from the customer side of the product owner side, the business side into being a developer because they work so closely. So in other words, their initial point of contact with software was not in the technical ground up perspective, it was not the bits in the B. 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 developer. I think many people end up in software developed without properly. Appreciating the war, they're trying to do is communicate, ultimately, that's what we did. 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're taking knowledge of the problem domain and you are bringing together in a formal
structure. And you are saying here is how I've 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're 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 to actually thousands of years. They are often about how do we do the day-to-day? How do we communicate or intentions? Clearly, how do we Take a step back and separate what we believe from what actually is because sometimes our beliefs do not match up to the way the world is and 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 the word itself communication comes from the Latin communis, meaning together, it's about be together. That's what it is. That's the whole idea.
It. And what is it that causes that and improves that for me different people have different parts 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 of 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, not about project is about products. It's a project is something that you finish we're a software development. Generally the goal is not to finish. I don't 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 mean communication to ourselves, you always have a way more overconfident belief that, you know what you did in future that I'm the near 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 translate very well to and one 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 if our colleagues you are potentially very
vulnerable. And that's a big ass. 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 a 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 The structure that supposed to make sense, There are rules and boundaries on their 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 town like things that I would like to think I could bring to my work as well. My pastime. So the idea is, 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 guitar. But we 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 world?
Can I move my Skillet communication and expression into something more verbal because code, is ultimately, a verbal construct. Its word based. It doesn't mean everybody's going out speaking the same or necessarily it was going to be totally comfortable with it. But the more you do it, the easier it becomes. You start realizing your own gaps, your own shortcomings and you generally get a bit better. If you were nervous at the beginning, you're less nervous in future.
If you are very nervous at the beginning, you're just nervous. Listen future. If you were a little bit nervous, you're not nervous in future just by doing it and repeating it. But that also goes to compassion, because just now you mentioned compassion. And also just said, when you write, if you publish a Blog, you are potentially vulnerable. You are exposing your thinking and your thoughts and your writing particularly if you are writing a language that is not your first language.
You may feel very vulnerable that made things. People always a lot Kinder than you think they are actually will appreciate your effort if you think you have. Nothing new to add yeah, you're mostly wrong infant. That what I don't like to tell people their role but you must be wrong because you have a point of view. I was telling somebody the other day, I said, there's 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 game because I remember most things but you're about to enter a point in your career where you're 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, you didn't think you could, you're going to have technical insights, you've been working with Frameworks that you Talked about but then you're 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 will definitely be very imperfect. The world is missing that contribution. But that's the idea compassion is also very important. We literally fell in love compassion means to suffer with somebody. Compassion means to understand that you see somebody else's. They're making a bunch of
mistakes. And yeah, you know what, I know what that feels like 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 is that kind of recognition that we spend so much time working with machines and tools, we've got to remember our yes humans. So, for me, I think that's a really important. Important emphasis, the emphasis has come about slowly Through The Years.
Seem people talk about this in a few years ago, April Wenzel really kind of coined. This idea of compassion. Coding is 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 to 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 form
and expectation and soul. If you can take a little bit of that off, it goes again back to following. Put the mouse down step away from the keyboard. It's allows you to think differently and more Loosely. If you are constantly being 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. 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 man. Whoever wrote this was an idiot. It's just like Like maybe it was you maybe the Ada was passed 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 been 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 going to work with something else, so do it. But that also means in future, you got to go back and go out. 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 that damn we were idiots. We should never be allowed near
keyboards again. It's a very harsh way of looking at it. So that the 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 Austria, that's actually an important ingredient in creating large software. Teams and companies based on software, you kind of have to rid 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 while they're so many things straight from your explanation, right? Starting from how to organize start 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.
Medication 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-paced always deliver always churning out things but they lack compassion thinking about the thing that they are, people are chasing. It's actually thinking about the people aspect as well, not just
producing code. So, I think you're Message is really important for all of us here to think about compassion, and not to always downgrade people. As a developer, we have skills in abstraction, we should be careful about applying those skills to people. Yeah, yeah. So we should not downgrade people thinking they're just developers. So, Kevin has 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. Yeah, I think they asked kind of follow on from the previous points. We making interestingly enough, that's taken us to a very interesting plate. The first thing I guess a really
simple one. When we talk about technical leadership is definitely lead, by example, and that's a 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 You're writing that communicates. What's going on? Don't just give a description of everything that's going on and you don't have quote marks
around. I don't love you anymore. She said, angrily, what's that? Would angrily doing there? How do people behave when they're angry? She slammed the door, as she left are slamming little wow. Okay, she's angry. And I was show me the think, don't just tell me the things show me the thing and I think same thing applies paid to richer picture.
So is very easy to fall into a position where potentially, if we're advocating a practice within a team, we're telling people Sure that message might get through, but it probably doesn't, and he probably doesn't mean anything. You got to work at the level. 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're using a different commit, message philosophy to the way that I'm writing commit, but your commit message philosophy, seems to have a clearer communication and you break your commits down to smaller levels than perhaps to other people in the team do. And you realize they 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 that you're 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 going to do something else but also because it may mean more to people when they actually see it in action, whatever that practice is whatever that advocacy is. Well there 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 technically, there's an 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 all the 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're not going to lead, you shouldn't do all the work, otherwise you're going to end up in a position where you become a micromanager know to lead. And also recognize that particular 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 at software. There's a lot of creative individuals and everybody knows something that you don't need.
You know, they know the things that, you know, they will know them. Different cannot know, something for somebody else, and you cannot know it necessarily in the same way and she 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 as 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 go. Yeah, that person to 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 and a really hard thing to do. Sometimes that may be at our personal communication level with somebody, you may make a mistake, you may misjudge something. You may be too emotional. You may miss read somebody else's emotion, but it may also be something technical perhaps that you kind of always staked your career on, we're going to do this and you 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 that 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'll 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 there people will see them. Yeah, admitting we are wrong. Sometimes is very difficult. We putting our Ourselves with vulnerabilities, some people fear about being vulnerable people being attacked, right? Yeah. If I'm supposed to be the ACT but and I got something wrong.
Does that mean I'm no longer the expert on my got, that puts you, in a very vulnerable position. As a perfectionism there, that becomes quite predatory and quite dangerous and doesn't help anybody's mood. Whereas actually is occasionally. Yeah, you know, what you were wrong and that's fine. It's okay to be wrong. Yeah, especially in Tech where people have egos and have impostor syndrome. 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 Carolyn 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? Yeah, I'm going to number of different places. My parents were kind enough to give me an internet unique name before the internet was
invented. So, Carolyn Hannah is an easy thing to find, so you can find me on Twitter there as Kevin Haley, you can Follow me on Mastodon as Carolyn at Mastodon social 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. I'll put that in the show notes, thank you so much for this time. Kevin I learned a lot from you today.
Thank you, Henry. Thank you for listening to this episode and for staying, right until the end, if you're highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you are new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show notes of this conversation on the episode page at tackling Journal, dot death website, including the full transcript interesting. Chords and links to the resources mentioned, from the conversation. And lastly, make sure to subscribe to the show's mailing list on package. You know, dot f to get notified for any future episodes. Stay tuned for the next technology. No episode. And until then goodbye.