Christian Clausen: 0:00

The thing with copilot is it seems to make our building blocks bigger, but it doesn't seem to alleviate any of the actual complexity of building a software system is still has the dependencies. It's still outside.

Fernando Doglio: 0:28

Yes, you're listening to another episode of 20 minute JavaScript where we talk about , wait for it... the JavaScript this episode, as usual is hosted by OpenReplay and open source session replay tool for front end developers. If you're looking for a way to understand how your users interact with your application checkout OpenReplay. I'm Fernando Doglio your host and local cat lover for the next 20 minutes, but today we're going to be breaking that rule. We'll be overstepping that 20 minute limit for a bit, but I promise you it's going to be worth it. We're going to be talking about code quality with Christian Clausen. So Christian, thank you for being here. Welcome. And please introduce yourself.

Christian Clausen: 1:04

Okay. Uh, my name is Christian. I work as a technical agile coach with a contrary to the name has nothing to do really with agile coaching or very little, at least it means I like the agile manifesto, but it also means I focus heavily on the technical excellence part. And so I do refactoring and I teach teams to do more programming and behavior during development and stuff like that. And I've also written a book on those topics that are called "Five Lines of Code".

Fernando Doglio: 1:28

Yeah, absolutely. And we want to, we're going to talk about the book in a bit uh, but today we have you here to talk about code quality and, and code smells, which by the looks of it, uh, it's a big part of your, of your job.

Christian Clausen: 1:41

Yeah. I, I love talking about code quality. Yeah. Very interesting topic.

Fernando Doglio: 1:45

Absolutely. So do I, I mean, I think that everyone has an opinion, every developer has an opinion, what quality is for their code anyway, let's try to define that. How do you considering in how, how subjective the term quality is. How do you find it so that everyone or at least. Within the same team, everyone agrees on the same things and measures the same aspects of the code.

Christian Clausen: 2:06

Yeah. I, I think there are primarily three avenues of, of quality that are prevalent in, in, uh, in code. And the first one is performance. That's the one that most students tend to think about when they think of quality. It's like this code runs really quickly. It's unreadable, but it's at least very high performance. Which is very rarely the type of quality I've worked with. The next one is a security code needs to be secure. And there are, there are different levels of security here. And again, there are specialists in this field who spend their whole career thinking about security and how they can make. Code better. And that's also not my, my avenue of it. The final one, the one I spent most of my time doing is it has few bugs or is it unlikely to have bugs or resilient towards bugs. And, um, and I spend a lot of time thinking about that and trying to search for that. My whole, basically my whole, a whole adult life has been an obsession with how to get closer and closer to, to bug free code. And I also did my thesis on that topic. Well, this was

Fernando Doglio: 3:04

the holy grail of developers

Christian Clausen: 3:07

yeah. Yeah. And how we can make it more human accessible to get this perfect code or, you know, the holy grail. And I found that it's, I think 90%, maybe more of all bugs are due to a non-local invariants. So it's what functional programmers would call side effects. It's what, uh, uh, big trends and programmers would call them well invariance properly. And they're properties that the programmer needs to keep in their head while they're coding. And the more we have, we tend to do that. The more our code is, has an affinity for that. The more likely it is that we're going to break something because we forget it's simply as a very complex domain we're working in and that makes it harder.

Fernando Doglio: 3:46

Absolutely. So the less we depend on our brains, the better it'll be. And on that note, have you tried or seen the effects of tools like a copilot from GitHub when it comes to writing code?

Christian Clausen: 4:03

So copilot pilot is interesting. It's something I've discussed quite a bit actually recently, because everybody's is fascinated by the tool. I think it's the correct word. Um, to me, I, we, so we talk a lot about cognitive load and cognitive theory and stuff. When in my work, which means I actually talk more about humans than I do about code, but it is code that's the subject. Um, and in this domain we use something called the Cynefin model. Uh, it's impossible to spell it because I think it's a Welsh word or something like that. I'm not sure, but in that we separate things from how disordered they are or how orderly they are, which domains we work with and how we, how we approach these topics. And I think that the thing with copilot is it seems to make our building blocks bigger, but it doesn't seem to alleviate any of the actual complexity of building a software system is still has dependencies. You can still have side-effects, you can still have all of these different things. So essentially I think what copilots, what copilot solves could be solved with a library. It doesn't actually make it easier to build complex software, but it does make certain parts of it a little bit quicker. I also saw a tweet once that I, that I like to quote where they had done a study and like 2% of time was spent for developers writing code. The rest was reading, understanding, talking to people, all of that stuff. And so optimizing those 2%, I don't think is going to change the world in my opinion.

Fernando Doglio: 5:33

Absolutely interesting. Very interesting point. Okay. Moving on. Focusing on bugs, focusing on side effects. So, uh, are we talking about code smells here or are we talking about something else?

Christian Clausen: 5:47

Code smells are, I think largely they're often trying to alleviate this problem because other people than me have spotted that it's about non-local invariant. So there are a lot of different types of code smells in my book. I also refer to things that people have not conventionally call smells, but everything that it tends to make code more resilient to errors, I would call sort of a code smell or is it characteristic , it's the coast smell. Um, so classic examples are something like magic constants um, it's something when you put it in, you know, exactly what you're thinking of, why it's that, or for most people, except for that one metric consuming quake. And, but then you forget it over time, right? When you read it, it's like, why does it say this weird number or hexadecimal representation here? So that's one example. There's probably the most basic example and everybody knows you shouldn't have magic constants at least give them a name. Um, and the same goes for long methods. There's something where you have to remember what happens at the start. When you get to the end of the method, you've forgotten if it's a few hundred lines or even I've seen methods of a thousand lines, it's, it's insane. Um, and, and then for a more untraditional one, um, I also, uh, it like I'm mixing queries and commands. I, I, uh, doing something, um, in the same method, that's returning something you're changing some states. So if you're doing both things at once, it's hard to keep track of what's actually happening. Uh, iterators do this a lot where you called next and it both moves the cursor and return to the line. Interesting. In the space of Javascript, would you say there are specific smells that we developers tend to have in our code yeah, this is a great question, especially because I'm not a JavaScript expert. I don't consider myself a JavaScript programmer. Although I consider myself a TypeScript programmer. So I do I'm very closely related. Um, but I like the tools support at the type system and the tool support that TypeScript gives me, I have written actually a blog post, and I also use as a game when I was at university. Yeah. Or a drinking game where you have one line of JavaScript and then you type it into the console and people have to guess what it does. And if they guess incorrectly, they have to take a shot. And so I've done a little bit of JavaScript. The first thing that comes up when you talk about JavaScript, then that coding practices is eval um, eval can destroy any analysis, anything you try to remember, anything is different if you use that. So obviously don't use that, but on a more subtle and sort of more um, sophisticated note probably there was also using "var" and "let" and I would always recommend people use let, after it was introduced, I started coding JavaScript before. Um, but the scoping rules of var are not what people expect them to be because no other language has backwards scoping like that. Um, you can define a var at the end of the method and nothing will complain when it sees it. It will just be undefined which is crazy. Like, how do you come up with that?

Fernando Doglio: 8:44

It's like, it's supposed to be making your life easier. You know. Christian Clausen: It, no, because to declare everything up front, it's at the top of the method, it's not at the bottom of the method. I don't understand it. It's crazy. Um, another thing I would say that's unique to JavaScript or fairly unique is people tend to use type coercion a lot more in JavaScript than they do in other languages, especially if they do an IF and then just want to check that something's been initialized, they just put the variable name and nothing else. And in my experience that tends to you have an invariant there that you're not using the other falsy values such as null or the empty string or the empty array I think sometimes those okay. And if you aren't using those and you can sort of prove that you're not using those, that's fine. But in my experience, I've, I think I've done that a lot of times where it turns out later in the project, I've actually used those values. And now the, if statement starts to break and it's very hard to spot that era because you're like it, even in TypeScript, it doesn't help you. Right. It's still, so I like to actually explicitly check against undefined the null and I've started trying to do that consistent. To try not to make it more visible, what I expect this code to do and make, make my invariants clear. Um, and other thing that gets me every time in JavaScript is using a function instead of fat arrow. And then it, it overshadows the, this, and it's so annoying to know it like w Y yeah. So I always use fed arrows now. I never use function without interesting, or they have only on the top level where I can name it. And then I just use fat arrows a lot. Uh, and the something I've been struggling with lately is the async await when you mix it with, um, with exceptions because async await is great. It's a very easy way to work with promises and it's just, it's very seamless. But then if you start throwing something in the views, async/await. Then the context will be dropped between each function that you did this async. So you will get the super annoying JavaScript error where it says, oh, you have an uncaught promise thing, a rejection. This is not supported anymore. It's deprecated or whatever. And you'll be like, but I catch it at the top level, but it's just two levels deeper. And it doesn't, it doesn't work. So you have to every time now I do an async function. I always start the function, the function with the try and ended with a catch/rethrowne um, which is it's boiler plate. It does nothing, but at least it's trivial to, right. So that it keeps the same context of the exception. It's a yeah. Yeah. And the last one is to be careful with reg EXOS, reg X's are very seamlessly integrated into JavaScript, um, much more so than other languages, like except Pearl may be. And, but they're very difficult to read, so we should just be very. Yeah, I think the same about rig access that I think about constants, you should at least name them so that people know what is it. I also like that's actually one of the places where I like to put a comment saying, uh, this comes from this specific thing. Like I had a rig replicating how, what Docker image can be named recently. And I put this as the link to where the Docker image thing is. So that other people can see why I did this weird break RegExp. Right that makes sense. That's, that's something I've never thought about, uh, because it's, like you said, a RegExs are so integrated that you just, you know, start using them and yeah, I essentially, I guess I was expecting everyone to read them and understand them, but yeah. And not everyone likes them,

Christian Clausen: 12:18

so, and they're difficult to read, like, I did this book challenge once at work. That's also on my blog now where you can, uh, where one of the challenges has this huge RegEx expended and the, and the exercise is you have to find out what the bug is and the code. And the second people saw the RegEx, they stopped trying. They just went away and like, no, it's an easy exercise actually, but they're like, no, they just give up immediately. And it turns out it's an unused variable. And it's like that they had nothing to do with the RegEx. Right. But they gave up because of the RegEx , it's an amazing and very dangerous property of RegExes. You just scare people off.

Fernando Doglio: 12:56

It's the effect it has on the other developers. Absolutely. But, but it's, they're also very powerful too. I mean, they're complex to read and because they're so complex, they're so a powerful, uh, they should be used with care. Absolutely. But they shouldn't be dismissed just because they're there.

Christian Clausen: 13:10

No. Yeah. And I used them for transforming simple data a lot. Like when I have a comma separated value file, I do regs with like ninja I mean, so much stuff all over the place. It's just, if they're in maintainable code, it should be documented somehow what it's doing.

Fernando Doglio: 13:27

I agree. Can we just backtrack just for a second and talk about eval because you went through it very quickly and, uh, I think. Um, pardon my expression by old developers like us, uh, know about it because we used to use it back in the day. Uh, maybe it wasn't the right choice, but it was the only choice we had to make some interesting behavior, but I don't think it's that known right now. So can you quickly tell our audience what the eval function is?. What is it supposed to be doing? And why is it so evil?

Christian Clausen: 14:00

Yeah. So JavaScript as an interpreted language actually has a way to interact with the interpreter. And that's sort of different from most compiled languages, which a lot of people use. Um, so in JavaScript you could directly interact with the interpreter by calling the email function, it looked like a regular function in the language, but it would actually take a string and then treat it as if it was code, so you could define new variables, new, you could have an entire program written a string and then give it to an eval and it would do it. And they used to be popular for doing things like importing stuff, uh, other libraries and, and different things. But before we had, I think it's, what's called P loading now where you inject this script tag and now we have require an import it's much more integrated and much more seamless. But we used to use it for. For good for things like importing other code, but it could also be used for anything else, like injecting things and doing cross site scripting and doing all these sort of nefarious things as well.

Fernando Doglio: 14:57

Yeah. Because it's really not checking or validating anything. It's just taking your word for it. Sort of speak and, and accepting any code you, you evaluate. So don't use eval even if it's there. All right. I think we already kind of covered these, but let's be specific one-liners versus expanded code. Where do you stand with that?

Christian Clausen: 15:22

Um, I used to do quite a bit of a streaming and I did the coding game on the stream where you had a challenge that was called, do the shortest code that you can solve this problem. And I would always pick JavaScript because I can do it a lot more compacted. Then the TypeScript, especially because I'm a, I'm a programming language nerd. Uh, and, and I've also studied some of the weird things that you can do to make the code as minified. Like I can basically do some of the minification in my head, which makes it completely unreadable. Let's be honest, but it's also, it looks, it's fascinating to look at. Yeah. And if you just fire and forget as an, a game it's it's it's. Okay. Um, so, uh, so I work primarily as a consultant, right. Visit different teams, and I'm there for a very short time, usually six months at the most. And for that reason, I can't have any preferences basically. Um, because there'll be broken all the time. I'll see all these different teams. They're doing things slightly. So I'm very good at adapting to whatever I'm seeing. And so I don't really have any, any preference for myself, but I will say, as I always do that, it's about working in a team and your team should make the decision. It shouldn't be an individual decision. If your team is good at one-liners, by all means, do the one-liners I'll I'll adjust. It won't be a problem for me. And if it, if you like expanded code, I had the same question and not too long ago, from someone who said, should we use all these list comprehensions and all of these fancy new functions that are coming out and I'm like, well, is your team very young? Are they are most of them? Do they know them already? Or is it a big investment to learn all of these new techniques? Because there's nothing wrong with FOR loops really? Except they can go out of bounds if you're not, uh, like if you use the mindlessly, but if it's it's about the team productivity, anything that makes the team more productive as good, anything that makes people struggle or create a divide in the team where some people use one thing, other people use the other as bad, it doesn't work.

Fernando Doglio: 17:18

All right. I wasn't expecting you to, to, to be so, uh, politically correct let's put it that way.

Christian Clausen: 17:25

Yeah, no, but it's, I worked with so many people and all of them are typically brilliant when you get to know them. And so you can't judge them by their code. And some people are just really good at maintaining code that is really hard for other people to maintain, but so long as they're not doing it from an egotistical point of view, I'm fine with.

Fernando Doglio: 17:44

Yeah. Interesting. Okay. What about, uh, code comments versus nmemotechic names uh, conventions? I actually had a conversation on Twitter a few days ago about that, and this person was telling me, well, if I named the variable correctly or the function name correctly, that it states what it's supposed to be doing, then I don't care about the comment. And I was thinking well, but what if, you know, you have a very long or complex method. Is your name going to be like 50 characters long? I mean, what are you going to name it? So I know where I stand, but what are your thoughts about that?

Christian Clausen: 18:21

I'm not going to be as politically correct. I like to say there are, there is I don't like comments as a, as a general rule of thumb. I don't like comments. I really try to avoid them by using one of the things would be doing as you described, they're giving them methods, better names, making, breaking the methods down. So they're more in a tree structure where each method is sort of not very long because I've broken it up into meaningful pieces. And then we move up in abstraction with the method name each time, which tends to weed out a lot of the details. And so the method name doesn't get so long. Um, in a, in my book, I described five different types of comments. Um, there are outdated comments, the wrong comments out. Uh, there is, um, outcommented code, which should just immediately be deleted if you're using version control. There's no point in doing that. Never check it in. Then there is the code that the comments that are good are the ones that document and invariant. So they're like, as I described before, if I have some regular expression that is following something else, that's a foreign thing. That's not in the code base. That is by, by its very nature. It's a non-local invariant. So I have to put a comment. So every time that I cannot eliminate some invariant, then I put a comment. So it's not like I use zero, but I work hard to try to minimize. I really like what, um, what Kevlin Henney has said, like, um, the, the comments should only say what the code can not. Uh, so it's, again, it's about making the code work for it and, and I feel sort of the naming conventions are sort of similar, I think. And maybe it's because I'm also an author that I think the code should be. It's a writing craft. So it's about communicating intent and having good names and stuff. And I really don't like having common prefixes or posts fixes or anything. Um, Kevlin Henney again, has this example where he says, why do you call everything an exception? You know, if you're throwing it, it's an exception I mean, it's from the context it Java does this thing crazy is everything IO exception. Just call it, throw IO thing. And. George has a similar point where he's like people prepending are something manager, controller, all these useless words that are about the code and not about what the code is actually doing. It's. Like don't do it. Handle calculate all these things. We just, we just prepend them and it's fine. We can, we can just, it's a, it's a very lazy way of naming things. And when we are on the topic of naming, I think there are three properties I like from a name. Uh, it should be honest. It should do what it should describe the intention of the function. It should be complete. It should try to capture. What the function does as a whole. But then the favorite thing is that it should be from the domain and that's something I've stolen from Dan North. And I just read his article "code in the language of the domain" . Again, it's an amazing, uh, two page thing. It's it has so much depth that when you start unpeeling it, but it says that he points out. There was no real world thing called a linked list or something like that. An array might exist in the world, but it's not what we call an array in the. And when we're using these words, we make the code harder for, for the people we're working with and the business problem we're solving to communicate with, because we're thinking in these terms and they're thinking in these terms and they don't always align. And so I like to wrap everything in things that have the language from the domain, so that my code looks like a conversation with a domain specialist. It makes it much easier to communicate and it makes onboarding a little bit harder though. To note, but if you're, if you're doing long lived teams, as you should be, it's not, it tends not to be a problem. And it's, it's a lot easier to work with like that. Okay.

Fernando Doglio: 22:04

Interesting. Okay. So you answered my question. Uh, my followup question, because you're, you're, you're saying then that the code. should speak to the developer and it should tell them, uh, everything they can to, uh, about what it does. But then I was going to mention that. What about the cognitive load of having to read through code, even if it's well written, um, compared to the one that you get by reading normal English or, you know, your natural language in a comment, but then again, if you're aptly naming, your variables and everything to within the domain of your problem. Then, I guess that problem goes away. Right? I mean, you're not having to translate the concept of an array or a linked list or a class or whatever into the domain. It's already there.

Christian Clausen: 22:53

Yeah. It's uh, it comes from, usually I start by having an, an interview or a conversation with the, with the domain expert where they've described, like, tell me, step-by-step what I have to do. And then I write down with their words, even though I tend to not understand them, I'm not very good at learning all these new domains, but I'm very good at data modeling. So it's, so I write down the steps and then I put them in the code, even though, you know, they're not what I would say. They are what I need to say when, when they start breaking or what the customer will describe to me, it's this part of this thing. Um, and so I try to use yeah. To make it easier. And then having short function to this. Not as extreme as for the cognitive load.

Fernando Doglio: 23:32

Interesting, honestly, uh I'm um, I have to admit the kind of comment first name, name is second, but you kind of made me think about it, you know, in a way, so thank you for that. Um, back to code quality. What tools do you use? Because I'm sure there are tons of tools and this has to be somehow automated, uh, or, you know, if you want to be objective enough when you present the quality or the quality of this project needs to be increased. For whatever reason, you have to present a number, I guess, or a set of numbers. And they can't just be uh, you know, pull them out of your hat. So w what kind of tools do you use for that?

Christian Clausen: 24:16

Um, I, so I am a bit old school in that regard. I don't like to rely on tools. I like to think of myself as sort of a master craftsman who creates a chair and I don't want factory chairs. I know, I know that it scales very poorly. I like to do a lot of work with education and with making people feel and see the same things that I do. And then, you know, code quality will automatically improve if you give people the skills and the tools to do it. But, uh, but from, I do know of some tools because obviously also work in the real world. With some organizations, SonarQube is, like sort of the, the top, uh, known one, everybody uses. SonarQube for static analysis and code quality metrics. I think I also discussed their algorithm for how, how they do cognitive load in the book I do. This is how you can calculate it if you want to. And it's based on cyclomatic complexity, but it's sort of more sophisticated based on how cognitive theory has shown that human think. Um, so I do discuss sort of how you can put a number on it. Um, another, uh, very common one is. Semgrep, I don't know how common it is, but it's one I'm very curious about where you can put in your own patterns sort of for what code defaults tend to have. And then you can make this tool. You can teach this tool to find the types of errors that your team is prone to. So you can say we, we tend to put an IF(true) and then not get it removed. You can just put that in and say, look for this. More semantic, mark, more sophisticated than just the regular grep. Um, and a third one that I think is very cool, but I unfortunately haven't got the opportunity to use is Adam Thornhill's Codescene. At which comes from the book, also "treat your code like a crime scene" where he does things with the git history. And he looks at what are the files that are likely to have errors in them. And then you can do sort of this forensic analysis on the code, which just really, really sounds. I really want to try it someday really cool.

Fernando Doglio: 26:11

All right. So you focused on teaching them on, on, on making these teams. See, like I said, see what you see or what kind of workflows or strategies do you recommend then? Because I'm sure you have preferred ones.

Christian Clausen: 26:25

Yeah. Um, we, so I like also to tell teams that, uh, having a clean code base and removing code smells, it's like weeding. And when I in a garden, uh, it requires continual attention to keep it down. It's going to spring up. There's nothing. It's not like there is a do this once and then you are done. Even if you have a lot of seniors who are very experienced and. Um, you know, uh, do write good code it over time. Uh, you'll have these fluctuations where really a clean code basis, the one that's most, um, most, um, can most easily do the changes that you want to do with it. So if your code base is geared towards the types of changes that are coming, then it'll be very easy and a clean code base, but sometimes you will have guessed wrong and that's just . Inevitable that the market, the people, the software, everything is unchanging and chaotic. So, uh, so when that happens, you will have technical debt of some sort. So we have the technical debt will come in no matter what. So the, the point is just that we need to continually go back and sort of readjust. Is this still the direction we think is this still the direction we're thinking and trying to readjust it with, with refactoring? I tend to say there are three big blockers for people not doing refactoring. In the, in the amount that they should. Uh, first of all, it can be they're lacking skills. They simply don't know how. And I tend to solve that with increasing their communal programming, doing either ensemble programming or pair programming. So that we get more of the seniors to share with the other seniors and with the juniors and how should this code look? And it also helps to get a lot of conversations about, oh, I saw you did that thing. I thought that was bad, considered bad style. Are we doing that now? Should we have a discussion on the team about that? So it brings a lot of things into the light, which I really like. And another thing that could be lacking as a culture, they don't have the time they're busy, everybody's busy and it's like software developers never have any free time. Right. Um, and so I like to introduce a concept. We call improvement Monday, where we spent and we reserve the whole Monday to just do improvement work. And it means the developers can choose completely themselves what they do. Uh, there are no guidelines and there are no, um, I I've never said no to a suggestion from a developer. Um, because they tend to want to fix the things that annoyed them last week, which is perfect because that's what I want them to work on. So it's . Like, uh, what he would say, creating an environment where excellence is inevitable. Uh, they can't do anything wrong on this day and I've had so great success with it. And the reason it's Monday is because if it's in the middle of the week, people are already in product mode and they have all this momentum running. They'll tend to still have that in the back of their minds. They won't relax with it. They won't be as, as creative. So we place it on Monday. And it also means that people are excited in the weekend to get back to work, because they're like, this is my improvement day. This is going to be so awesome. I can do whatever I want and they can do experiments. They can improvements all of that. And the final lick, which is more simple it's if people don't know what to refactor, if they don't know what the problems arethey simply are not a senior enough apparent perhaps to know the coat smells and the code melts are sort of fussy and there are a lot of them and you have to, there are an acquired taste and that's exactly where my book comes in and tries to make it more simple.

Fernando Doglio: 29:42

Alright. I love the improvement Monday. Definitely. I think, uh, it's an idea that needs to be, uh, copied across, uh, other companies.

Christian Clausen: 29:52

Yeah. I stole it from, or I didn't steal the Monday concept, but I stold the improvement time in, from the DevOps handbook, they say that 20% of time should be reserved for non-functional requirements. And I think even the Toyota production system goes as high as sixty so it's at the low end with 20, but it's something that's at least doable, my experience and organizations.

Fernando Doglio: 30:13

Yeah. And it's not that big that will scare product managers and clients and so on. Yeah, just one day of the week. Interesting. Okay. So, uh, we've mentioned with, with, uh, dance around your book. So tell us about your book. Tell us about, uh, what "five lines of code" is about.

Christian Clausen: 30:33

Yeah. Uh, it's a split. There are sort of two parts in the book. And the first part is a wonderful example. It's a 2d game that we take the full code based upon we refactored. And through that journey, we discovered that some rules that are not code smells, but related to code smells, they're simpler. They're easy for, for a junior person. And they're easy to remember and easy to get started with. So the idea is you read this. You can do something better tomorrow already and start improving. And it, it's just, uh, I'm, I'm very proud of the first part. It's a, it's a really cool example and it has all the refactoring patterns and it has all of the things it's a self-contained thing. And so that one is, is, uh, is very focused on individual skill when it comes to code quality. And it's, it's a great tool for junior. So for people, training juniors have also heard a lot of good feedback. Uh, and then there's a second part which focuses more on the team disciplines, sort of like what are the principles that are important in a team and when working with code, and if you want to do your own rules, or if you want to make modifications, as you keep these things in mind, and that's more widely applicable, I think seniors will probably get more out of that part then out of the first part. Um, so, but it's all about taking refactoring and making it more accessible to more people, faster.'cause the, the, the, the other books on this topic are basically masterpieces. They're very, very good, but they're also difficult to read and even more difficult to apply. And so that's what I try to do, make a sort of a half a step towards that.

Fernando Doglio: 32:02

Cool. All right. Uh, perfect. And in the show notes, we'll have a link to it and a discount code count as well. So make sure to check out. Awesome. All right, so we're on the last leg of the interview. I'll just ask you a set of quick questions. So what's the best advice you had you ever received?

Christian Clausen: 32:22

For my life? The biggest, uh, the biggest impact of bias. I've gotten my first mentor at university and he said the key to being consistently brilliant is hard work every day. And he was trying to sort of mock me because I wanted to be the smartest kid ever all the time. I tried really to be smart. And he's like, it's not hard. You just have to work really, really hard for the rest of your life. And I wouldn't recommend that for anyone. It's a really hard lifestyle, but I started doing it and I've been doing it for so long. Almost never relaxed. Oh, I'm always working, but it does mean that I tend to get quite lucky quite often. We we'd also say luck favors the bold, but in my case, it's more of the hardworking people get lucky a lot more often. And so it's had a lot of impact in my life.

Fernando Doglio: 33:05

Alright. Yeah. Cool. What's the most excited project you worked on?

Christian Clausen: 33:09

Um, I would've said something where I did, uh, when I was quite a bit younger where I try to automate things, but right now I'm actually working on a really cool new platform where we're trying to make a serverless uh, more accessible and work with it in a new way. And we're going to launch it pretty soon, which is really cool because I've gotten to use both very complicated type theories and really cool modern tools. And I think it's going to help people in the real world, but I'm not quite ready to launch it just the second, but, but stay tuned for that.

Fernando Doglio: 33:36

Yeah, definitely will. Uh, last one, uh, what is one thing you wish you knew before you started coding?

Christian Clausen: 33:45

First, make it work, then make it better. That mantra and that thing being engraved in you, it's going to save you from so much trouble. When I was starting out coding, I would always try to write the perfect code once. You know, it's like, you have only this many type strokes and then you cannot do anything else, but that's not the case. Uh, and if you try to do it right and make it work the first time, it's so much harder, it's like it's exponential. They multiply together and you end up with this w this, you locking yourself in where you can't type anything, and you're just stuck completely. So I've sort of paraphrased it to make it a little more brand awareness. So I, I like to say code with your heart and then refactor with your brain.

Fernando Doglio: 34:24

Okay. Interesting. Okay. I'd like that. I like that. Uh, it's funny. I, I love these. Three questions, uh, so much because you get some really interesting nuggets from all the guests, but the last one, this, this same advice has been repeated several times already. So it's so crucial and it's so common. So on our own, on all developers on new developers, we just focus so much on making it perfect the first time around. And it's just impossible.

Christian Clausen: 34:54

I had a talk at the university about, I was like, this is why people don't like university people or people come straight out of university because you spend basically five years. Um, or in my case, seven years learning all the ways you can write code in a wrong way, all the ways you can be wrong. And that means you get, uh, you get super scared, right? I don't, I was terrified to do anything super anxious afterwards. And I used, when I, before I started university, I could code like the wind. I would just type stuff because I didn't care. I didn't know all the ways I could be. So it's, it's very common and it's very, very dangerous.

Fernando Doglio: 35:24

Absolutely. Okay. That's all the time we had. So please tell our audience where they can find you online. And we'll just put all those links in the show notes.

Christian Clausen: 35:34

I'm on Twitter. I'm on medium where I have my blog. I'm on GitHub. I'm on most places where developers are and I'm called the same thing everywhere. So it's @thedrlambda, and that's just that.

Fernando Doglio: 35:44

All right. Perfect. Thank you again for being here. It was really interesting I hope our listeners will get some, some insights into code quality from this talk. And if not, they can just check out your book and learn even more. All right. Thank you.

Christian Clausen: 35:59

Thank you for having me.

Fernando Doglio: 36:00

Yeah.