Episode 98: Julien Delange on Technical Debt and the Future of Coding

Brian Dawson: Hello. Welcome to another episode of DevOps Radio. This is Brian Dawson and I'll be your host. Today with me I have Julien Delange, the founder of Code Inspector, but as well, and hopefully he'll share it with us, he's done a huge amount of work. He is well published. He's worked with Carnegie Mellon.

He's spent time at AWS at a critical point in its junction. And as we just recently discussed, had a really interesting stint at Twitter as well as a number of other stops in his storied career. Hello, Julien, how are you doing?

Julien Delange: Hey. Good. Thanks for having me.

Brian Dawson: Yeah. I'm excited to have you. We, of course, did a little warmup discussion, and that was a podcast episode in and of itself, so I'm excited to dig in a little more here with everybody else listening. To get us kicked off, can you tell me and our listeners a bit about what you're doing today? And then maybe you can share a bit about your background. How did you end up where you are today?

Julien Delange: Awesome. Thanks. So, yeah, right now I'm the CEO of Code Inspector, which is a company to help developers produce better code. It's a startup that is backed by Techstars, so I'm in the Techstars program right now. Demo day's coming, so I'm basically preparing the final video and pitch for demo day. But before –

Brian Dawson: Oh, and you took time out of that to join us here? I appreciate it.

Julien Delange: Of course.

Brian Dawson: I could assume it's probably pretty intense preparing for that. But back over to you.

Julien Delange: Yes. So in terms of background, I got the Ph.D. in France in computer science, but at that time it was really about real-time embedded systems. And after that, I started working at the European Space Agency doing rockets, satellite software. That was fun.

Brian Dawson: Yeah, I was going to say it sounds fun. Is it as fun as it sounds? I guess so.

Julien Delange: I mean, you know, if you look – something really interesting is the power, the computing power you have on a satellite or on a rocket launcher. Most of the satellites that are operating today we had to pull off a Gameboy from the '80s.

[Laughs] But the hardware is totally different because you have radiation, you have a lot of things that can happen, and the software needs to be predictable, and predictable in real time. Real time does not mean as fast as possible. It means predictable. And people often miss the point. Real time means predictability.

When somebody tells you my software is real time, they mean the software is as fast as possible. Let me give you an example. You have your car –

Brian Dawson: Yeah, I'm curious about this. Yeah.

Julien Delange: Yeah. So you have your car, and your right now, you know, is operated by software. You probably have 20 computers in your car today.

It's coding CUs. And basically, what real time means is when you brake your foot – when you put your foot on the pedal, the software needs to start operating the brake within X milliseconds. Not before. Not after.

Julien Delange: But within 50 milliseconds. Which means that you need to have dedicated hardware, dedicated protocol. For example, for the avionics industry you have something called AFDX. So you have a bunch of protocol for that. But the point is really about data humanism, and that's really a point many people miss.

And you need dedicated operating systems. For example, you can't use Java because you have garbage collection that will happen and then it will take your time. So anyway, I had some fun, but I was really in love with the United States. I was really in love. I wanted to come, and I was working _____.

Brian Dawson: Well, we appreciate that.

Julien Delange: Thank you. Sure.

Brian Dawson: You know, what I do want to share – rudely to interrupt, but hold your thought – it is interesting, because this just jogs one of my aging person sentimental recollections when you talk about some of that software in the satellite being equivalent to a Gameboy. Ironically, I'll share that in the early days of PlayStation One we had to engage with the Fed around export controls of PlayStation One dev kits, because it turned out that the PlayStation One processing power, as woefully inadequate as it would seem today, was being chained together by nonfriendly states to calculate missile trajectories and launch trajectories. So it sounds similar to what you're saying in this little game system that now today barely had any power was more power than well-funded defense departments of our adversaries had to calculate launches.

Julien Delange: Right. I mean, if you have software that is well optimized you don't need a lot of processing power. Maybe for bitcoin. I get that. But most of your processing power on your computer is used to process JavaScript on the browser and it's very expensive.

Brian Dawson: [Laughs] There's a lot of wasted processing power, yeah.

Julien Delange: Exactly. So anyway, after that I worked in Carnegie Mellon in an institute called the Software Engineering Institute. It's an institute that works on software engineering and it's really famous for something called the CMMI that is about good software engineering practice. And I met two –

Brian Dawson: Well, and I'm going to interrupt you again, because when I interrupted you before we lost a waypoint. So you'd said you were really in love with the United States.

Julien Delange: Oh, yeah.

Brian Dawson: Which I assume means you wanted to come and work here.

Julien Delange: Yeah.

Brian Dawson: And so is it Carnegie Mellon was kind of the place where you landed to come work CMU in the United States?

Julien Delange: So the story is the following. When I was doing my Ph.D. I came in the US just as a visitor, and I came and I stayed in Carnegie Mellon because I was doing research on that topic. So, you know, I stayed for three months and this is how I was totally in love with the US after that. And one day somebody at Carnegie Mellon told me, well, there's a position open. You should apply.

And I'm like, okay. I'm going to apply, and then I got the job, and I was so excited. That was probably one of the best in my life, when I got my visa. I was like, that's amazing.

Brian Dawson: Awesome.

Julien Delange: I want to be here. And I stayed five years in Carnegie Mellon doing research, and I really liked it. And eventually, all of my friends were telling me you need to go in tech. You need to go in big tech. You need to see what's happening here. And the dream initially was to work for Duolingo. [Laughs]

Brian Dawson: Oh, interesting. Of all places.

Julien Delange: Believe it or not. Believe it or not, I really loved Duolingo's mission. I think that's amazing to provide free education.

Brian Dawson: Yeah, and it kind of connects – builds bridges and connections across language boundaries.

Julien Delange: Yep.

Brian Dawson: Yeah, that is interesting. I'm not surprised though if I think about it, that you would have had an interest there.

Julien Delange: You know?

Brian Dawson: You sort of – no judgment on that dream – you've sort of moved beyond that sense, I would say.

Julien Delange: Yeah. Totally. So I wanted to go in Duolingo. I interviewed at Duolingo who rejected me.

Brian Dawson: [Laughs]

Julien Delange: And for training to go in Duolingo I interviewed at AWS and AWS hired me.

[Laughter]

Julien Delange: So I stayed in AWS, and after that, after a year my partner wanted to move to California, and I decided to look for another job and came at Twitter. But, you know, through my career I saw it kind of come around when I worked on software. It was still real-time animated software and software architecture. When I was at the European Space Agency, when I was at AWS and Twitter, I saw that technical debt was a huge issue. So think about a satellite, think about a plane with Airbus; people that maintain the software today, they were not born when the software was written.

Brian Dawson: Yes. That's interesting.

Julien Delange: So the software was written probably like 30 years ago and you have new people that are 20 years old start to write Ada or C code, don't know what the hell they are doing, don't know how the software is working, and ultimately lead to some issues. And you see technical debt – if you look, for example, at a more simple issue like Knight Capital – so Knight Capital was an investment firm and they had deployment issues. They lost, I think, multiple million of dollars in 40 minutes because they did a bad deployment.

And the company is defunct right now. And you have a bunch of issues like this. I saw that at Twitter, a bunch of issues that we had, and I started to really think what can we do about that? In the meantime, I was writing a book. When I was in Carnegie Mellon I started to have a good connection with two colleagues, Rick Kazman and Neil Ernst.

Rick is a professor at the University of Hawaii. Neil is a professor in the University of Victoria in Canada. And we started to write a book, and I started to think, okay, what does it take today to help you manage technical debt? What is out there? And I started to think about making a company.

And in 2009, I funded the company but I was still at Twitter at the time. And just as some point I was also a teacher at Northeastern University. I was part-time faculty at Northeastern University. I was also leading a team. I was a tech lead at Twitter.

And at some point I was like, you need to decide what you're going to do in your life. [Laughs] You cannot do everything.

[Laughter]

Brian Dawson: I didn't get that message yet. I'm still figuring that out. But, yeah, I get it.

Julien Delange: At some point you need to come to a resolution what you want to do with your life, you know?

And I could stay at Twitter. You know, the job was good, I was doing great, money was good, and then I was able to teach on the side. But really I wanted to do my own thing. And so I left Twitter this year in January and dedicated my life – I dedicated, Brian, all my time full time on Code Inspector.

Brian Dawson: That is awesome. Now I'm going to want to dig in a little more into technical debt and then Code Inspector in particular. But from your intro to your background, I have something that I'm curious about, and that's that you spent a bunch of time in academia and then you made this transition at the prompting of others, this transition into what we'll effectively call commercial software development, right?

Julien Delange: Yep.

Brian Dawson: AWS, backend B to C. But ultimately it's commercially-driven work. How was that transition? Did you find it easy, difficult? Any observations between the difference of working in academia and research versus commercial ventures?

Julien Delange: I loved it.

Brian Dawson: Really? Okay.

Julien Delange: I loved it. This is where I want to go. This is where I want to be. Research is a lot about politics, you know?

Brian Dawson: Oh, interesting. Okay.

Julien Delange: You know, to get your paper approved you're asked about being a friend with some people. [Laughs] That's what it is about. And I didn't really like that. I mean, I'm pretty sure my friends from academia right now are going to send me emails, like what the heck are you saying?

Brian Dawson: [Laughs] Yes. What do you mean you didn't like it? But you're saying, right, there wasn't – it was less of a meritocracy than ideal, I also assume, and there's politics or hoops to jump through to get your work out to have an impact.

Julien Delange: Yeah.

Brian Dawson: You don't have that same burden or didn't at AWS or Twitter, for instance.

Julien Delange: So the thing is, I shared this post on Twitter about the laws, these amazing laws, that basically you have, the Peter Principle that you have people that rise to their level of incompetence, which is pretty right in academia. You have people doing software research that don't even know how to open a terminal and clone a Git repo. And the only thing I can think of is why are you here?

[Laughter]

Julien Delange: You know, and so in tech you still have that. You still have people that have a degree in computer science just because of the money, and there is nothing wrong with that. You know, if you want the money, that's fine. But you also have some people that want to come in software engineering for the money and don't really follow the software engineering principle or don't know how to program. But really quickly, as you have a system, especially in a company like AWS, which is really meritocracy-based, if you are really good you're going to be promoted.

You're going to have interesting projects, and then you're going to continue and grow in the company. Whereas if you don't produce that much, where you're not going to have this growth and eventually you leave because you feel you are not useful to the company and you don't contribute. And I didn't see that in academia. And that's why for me I was really frustrated in some sense that people were not actively coding in academia. I was really frustrated by that.

I really wanted to do more. I wanted to experiment more and prove that with some proof of concept. Hey, is that going to work? No, prove me. Show me the code.

Brian Dawson: Right, right. Okay. Gotcha, gotcha. And that's of particularly interest to me just because in the space that I talk about a lot or shared with you that I existed in the early stages of my career kind of bleeding edge in terms of – just bleeding edge software, bleeding edge technology meant we often had to take work in academia, coming from academia, that arguably was incomplete. Figure out where the gaps were and actually make it real versus a theoretical. So that's always stuck with me. So now shifting a big, so going back to Code Inspector and technical debt. So you founded Code Inspector with the mission of helping developers and managers produce better code.

Julien Delange: Yes.

Brian Dawson: And directly or indirectly based on our discussions in work, this involves technical debt. So I'm going to conflate two questions for you, and maybe you can answer them in one. I'm curious. What were some specific challenges that led you to create the company?

But then more specifically, maybe you can share with me or help me better understand where does technical debt come from? What are sources of technical debt? Because I assume that's in the body of challenges that said, hey, I need to go create Code Inspector.

Julien Delange: Yeah. So we wrote a book with Rick and Neil on technical debt, Rick Kazman and Neil Ernst on technical debt, and we explained the different aspects of technical debt and where it comes from. So of course you have the technical debt that comes from the code you couldn't see, and as you probably know, today you should not use STS CPI to copy a string because you're going to have buffer overflows, and people are still using that today. So have these coding issues that is a debt or you have some design issue.

For example, if you code in Java you're going to have a class. Everybody depends on that class. And then it's going to be what we call a got class, and you should not be using this kind of design pattern. Maybe sometimes you will use dependency injection, and you don't use that properly. You're going to have these kind of issues at the code.

Brian Dawson: Okay. And again being rude, interrupting, how often – I'm curious. I'm just suspicious. How often does that hark back to some other things that we discussed earlier, to people just not having an understanding of the domain? How much of it is lack of knowledge, lack of experience, versus just a standard side effect of the work we do at the pace we do it?

Julien Delange: Yeah. I think it's a mix. I think sometimes people are – so I think you have two aspects, and I like to take the meter for all that. You have technical debt, and technical debt is like exercise. Having a good habit is not hard, but we don't like to do that. We are lazy.

We are lazy. We are ignorant. Look, you know you should exercise every day. You know you should vegetables. But then what you do is you go to a restaurant and takes a burger, orders the fries. Everybody loves that. And give me the shake because, you know, it's freaking good.

Brian Dawson: Or come home and make some chocolate chip cookies because it feels good, even though it's not the right thing. Yeah. I'm not speaking from experience by the way.

Julien Delange: Oh, that's my experience. I feel guilty.

[Laughter]

But the point is, we are human, like to take the path of least resistance. Sometimes we are lazy. It's a behavior we have. This is why you have Coach. And what I like to say is Code Inspector is a kale smoothie of your coding diet. Code Inspector is going to be the one that's going to tell you, hey, here, don't take the French fries.

Take the broccoli. It's going to tell you don't use STS CPI because you're going to have a buffer overflow. It's going to tell you, here, document the function. It's going to tell you don't put credential in your source code. Because if your source code is leaked your credential is leaked, and then everybody is going to access your S3 buckets online and then all your data is going to be leaked. So this is what we are doing.

And interestingly, it's the reason why I call that Code Inspector, is exactly because when you buy your house you have an inspector to check your house and make a report of what's happening, what is good and what is bad. And Code Inspector is doing the same thing but with your code, look at your code and say here there is a problem. The basement is dirty. You have a wiring issue with your electricity. This is basically what Code Inspector does, but with your code.

Brian Dawson: Okay. And so we're going to go back to the challenges in previous jobs that led to, hey, I've got to create this, but before I do can you help me understand what is the difference between Code Inspector, which arguably is doing what is in the space of static code analysis, and traditional or existing code scan, static code analysis tools? I tend to think we're looking for patterns, right? Are there cyclical calls, are there open-ended conditionals?

Julien Delange: Yep.

Brian Dawson: It seems like you're in the same macro space but you're taking a different approach.

Julien Delange: Yeah. So I'm going to be totally candid here. The way Code Inspector works today is just checking out your code on GitHub, GitLab, Bitbucket, whatever it is, doing that at every push or pull, and then I run a bunch of static analysis _____ that really exist that are open source. We run them and we calibrate them, which means that we don't report any false positives. The goal is not to have false positives in the tool.

It's to be really useful. You're going to probably ask me, hey, what's the value of that? I can run my own analysis on my computer. You know, people are telling me that, and I will say, yeah, you know what? 10 years ago people said the same thing about infrastructure.

Brian Dawson: About builds, right. Yeah.

Julien Delange: Builds or running your own server. The thing is you don't want to maintain your own infrastructure. You don't want to maintain the configuration of the _____ between all the different developers. You want to have the same configuration around all IDEs. You want to have the same configuration running your pull request.

Brian Dawson: Yeah, that's interesting. Because at the end of the day, the feedback from Code Inspector, a static code analysis tool, is or should – it's going to manifest itself in the patterns of the shared code.

Julien Delange: Yep.

Brian Dawson: So you're highlighting something I particularly personally hadn't thought of, and that's if we're bringing that feedback in localized, well, there's another thing that's going to tend to happen. We're all going to adopt our individual patterns and there's going to be divergence of approach, which is probably fragility in its own right.

Julien Delange: Exactly. First of all – second of all, we configure the tool and we upgrade them. We upgrade all the tools when there is a new version so that you don't need to worry about that.

Brian Dawson: Manage the stack, right, okay.

Julien Delange: Exactly. So that's where we are right now. But we're going to do something way better. Like we have something in the pipeline that's going to be amazing, that's going to be our own.

We manage that and we purpose that for $10.00 a month per user. And some companies love it because you have automated pull requests and code reviews. Ultimately, what we want to be is having something that helps even the developer write code, automate the code, put your code onto a pilot. If you've driven a Tesla, you see that the Tesla is driving better than you 90 percent of the time. And then, I want to do the same for code.

Why Grammarly is better than me at writing English, I should do the same for writing code. This is where we should be. This is today we are entering the AI space, and we should start doing that for code. In a few years, we will probably stop writing code. You start to see solutions emerge in the code solution and all that stuff. You see Facebook. Facebook was able to translate the Python code into Java COBOL and do the translation at 70 percent using AI and an LP.

Julien Delange: So we're going to see that and see what we are working on. I will not disclose our secret master plan.

Brian Dawson: I thought you were going to break news here and give me the secret recipe, but okay. No, I do want to call out that is really interesting, is there is an emerging focus on developer productivity, engineering efficiency. The company I work at, the sponsors of DevOps Radio, CloudBees is one of the people that recently released an engineering efficiency model. I bring this back to – and you alluded to it.

I don't know if you call it out in terms of positioning or marketing, but even in upgrading the tools and removing false positives from the back end open source scan solutions that you're using, you are also adding important value in just improving – not only helping you write better code but helping you write better code more efficiency.

Julien Delange: Yeah, correct.

Brian Dawson: And I guess at the end of the day, bringing ML and artificial intelligence into that process, you could add even more efficiency. So really going to dig in and go on a tangent. What is your take on low-code/no-code? When you say why do we write code – and I love the Grammarly comparison, by the way – I'm going to tend to say that you and I are probably roughly the same age, and so you also came up in the era of 4GLs are going to be the answer to everything, right?

Brian Dawson: And now our conversation of 4GLs is now the emerging low-code/no-code discussion. So you made the statement that one day we're not going to write code. Is that truly what you believe? That low-code/no-code is where we'll all end up?

Julien Delange: No. So I don't think – so we will reduce the friction _____. That's obvious. We're going to reduce the friction ultimately. Look, this is exactly what Tesla is doing with a car. Start to have autopilot, you stay in the lane. After that you change the lane, and ultimately you should have a full self-driving car. After that we can debate a lot about what Tesla promise and the timeline. That's totally [laughs] _____.

Brian Dawson: Right. But assisted driving or the software equivalent of Tesla autopilot is imminent, you're saying.

Julien Delange: Grammarly. Look at Grammarly. Like I used Grammarly, and it's amazing how it all catches, and it can just even rephrase for me in Google Docs.

Brian Dawson: Yeah, it's pretty –

Julien Delange: It's really good.

Brian Dawson: As an early Grammarly adopter it has changed my life, and so that's why that resonates, right? For me, look, I have to admit I was never the best coder. I was good at problem-solving, probably better positioned for an architect. But I'm probably in the class of a Code Inspector client, or maybe even that couldn't save me. Right?

I needed a Grammarly to help me write code. I think cognitively I can understand it. In practice, I wasn't a prolific programmer, right?

Julien Delange: Yeah. So there are mutual trends I see. The first is the rise of automation. We automate more and more. We automate builds. We automate tests. We automate deploy.

Right now the next thing is automate bug fixes. So we're going to have that. That's the first aspect. More quality, more automation. I don't think we're going to stop writing code any time soon. It's going to take a lot of time to get there and write maybe just diagrams to explain how this thing works or whatever it is.

But in the next 10 years we're going to have a trend, and the trend is the following: you're going to have a huge number of developers that are going to enter the market, and only a third of them are going to be able to have a university degree. That is the statistic of the Department of Labor.

Brian Dawson: Yes. That I agree with fully, yeah.

Julien Delange: So then the question is basically what to do for 66 percent. So some are going to boot camps, and we know that boot camps are like three months. You learn a technology, you learn JavaScript for three months, and then good luck. These people are going to need training. Right?

Brian Dawson: Yes. Agreed.

Julien Delange: So then you need tools to help them produce better code. And something like Grammarly, I mean Grammarly for code, like Code Inspector, is going to definitely help you do that. Something else we are working on, it's not done yet, this is a feature we're going to release. So you have your big news.

Brian Dawson: [Laughs] Okay.

Julien Delange: It's a feature that is coming in the next two months. It's called Code Coaching. S Code Coaching means we're going to look at all the code change you are doing in your editor and in your pull requests. We're going to look at all the mistakes you are doing, and we're going to send you tailored feedback to improve. So for example, hey, you know what?

You did these buffer overflow in C. This is a video to explain why and what the pattern you need to adopt to stop doing that. Or in Java, hey, you are using the Singleton design pattern wrong. This is how you should do it. So we're going to provide that.

And then, if you think about it again, the cost of Code Inspector is not going to change any time soon. So for $10.00 we give you a tool to improve the quality of the code that is going to be shaped by your developer. I think for $10.00 for training your developer, that's really cheap.

Brian Dawson: That's a value. And I'll go – and I did not mean to, you know, fully dig into your entrepreneurial adventure, but it is so interesting. Some things that resonate, a couple of things in my experience, one is I have a 23-year-old daughter, CS graduate, that is trying to find her way into the working world and is just kind of turned on to LeetCode, right? And of her group, there's this LeetCode generation.

And one thing that resonates perfectly is something like Code Coach seems like a perfect pair for people like my daughter trying to find their way in this LeetCode generation. What I'm also learning from her harps back to some experiences we had in doing some research with developer share at the company I'm at now, and that's even in this age of social coding. The work we do can sit on GitHub, we can share our LeetCode scores, open source communities and communities are bigger and more natural.

It still can be somehow of a lonely venture when you're still learning. And let's keep reality; most of us feel like imposters our whole career and we're constantly learning. So one of the things that's really exciting, Julien, and why I'm kind of rambling here about what you're doing is it also hits to some very core psychological triggers we ran into in interviewing developers.

Julien Delange: Yeah.

Brian Dawson: And something that both junior and senior developers mentioned alike is that they constantly feel like an imposter, they constantly feel like they're behind in learning, but they don't want to be that person that continually taps the shoulder of senior engineers or their lead engineer. So there's a gap or challenge that Code Coaching can help with. Yeah, anyway, sorry to riff on that, but it's exciting. I think there's a lot of potential and opportunity there.

Julien Delange: Thank you. And about the imposter syndrome, I saw so much damage being done by that. You know, a junior developer that comes in and says I'm not worth it. I don't know. I don't want to ask. And senior developers – I've seen senior developers being also very – how can I say that? – productive. Like they try – because in fact, you're going to find out really quickly the senior developer says that he knows, and most of the time he does not know.

Brian Dawson: [Laughs] He doesn't yes.

Julien Delange: And a junior developer is just going to say I don't know. And the thing is, the senior developer doesn't want to say I don't know. At some point we need to come to a conclusion to say we don't know, we will figure it out.

Brian Dawson: Together.

Julien Delange: And maybe the senior is going to pick it up quicker than the junior, and that's fine, but I've seen – you know, one of the best things, and when I joined – after I switched from academia, I was really new to some companies – AWS, Twitter, even some communities – and sometimes I was pinging the senior developer to say, hey, or people that were here for a long time, hey, how does that work? And they were not answering to me and were like, oh, I'm really busy. And after a while I just figured out, no, they just don't know.

Julien Delange: They're embarrassed to say I don't know.

Julien Delange: And I think just at some point being more honest and just saying I don't know how this thing is working, and that's fine. If you look at a system, like again, you look at a system like Twitter, the system lives for Rhino 2008. It's a little rearchitecture because it switched from Ruby to SCADA. But even if a system is running for, let's say, six years, the likelihood that somebody was there when they wrote the system is really low. So nobody's going to have full knowledge –

Brian Dawson: So no one really knows, right, you're saying.

Julien Delange: Yeah. Exactly.

Brian Dawson: Because no owned the original code. So let's work – let's engage and work on it together.

Julien Delange: Exactly. Which is why also you should document the code and write what this thing is doing. I remember one staff engineer at Twitter, and I asked him – I complained, and I said this code is not documented. That really sucks. And the answer was, in all my career as a staff developer I never saw a code well documented.

Brian Dawson: I've seen very little code well documented, yeah.

Julien Delange: But it's like, yeah, you know what? Everybody does a bad job, so we should not do a good job, and –

Brian Dawson: Right. You're saying it's not the reason. Right.

Julien Delange: Yeah.

Brian Dawson: It doesn't need to be because it's never been.

Julien Delange: Exactly.

Brian Dawson: So don't worry about it, Julien, yeah.

Julien Delange: And one of the things, one argument from the same person, is that code changes so quickly and so often that it's not necessary to document because it's going to be so painful to document it. To what my argument is more like, if you change your code every time maybe you have a design issue and maybe your code should be more stable in the first place, and start to architect your code correctly. But that's kind of a reflection people really don't have and that I think we need to coach people better. Again, I don't think there is bad intention here.

Brian Dawson: Yeah.

Julien Delange: I really don't believe there is bad intention. It's more laziness or ignorance about these kind of principles.

Brian Dawson: Yeah, yeah. And I also think that there's – look, there's just a number of external factors. It's easy to confuse the pursuit of velocity and the pressure to deliver faster and the word agility misused as, hey, you know what, our code's never going to be stable, we're going to constantly change it, so therefore why document it? And that probably couldn't be further from the truth.

Julien Delange: Right.

Brian Dawson: I'll take a moment as I get you back on the track of the questions I promised I'd ask you shortly here, I will confess in the pursuit of removing the imposter syndrome both the number of years I did CDD, which is compiler-driven development, I have no idea what the hell I'm going but I'm going to count on the compiler to tell me whether it worked or not. [Laughs] And then what I did experience, having worked for the company that founded Subversion, as we went to centralized version control effectively, was the resistance of developers to commit early and often, which was both I think a factor of imposter syndrome but also a factor of I feel like it takes me iterations to write code worthy of people seeing. So I'm going to hold my commit until I'm comfortable sharing it with the world.

Julien Delange: Yeah, yeah. Totally. You know, which comes back to this rule "look good to me" dilemma. If you want to quick ship a line of code, hide it in 1,500 lines real quick.

Brian Dawson: [Laughs]

Julien Delange: There's some truth to that. There's 100 percent some truth to that.

Brian Dawson: Yeah, yeah, yeah. And look, I know for the most part, like you say, just to get on this thing, is there's no malicious intent.

Julien Delange: Yeah.

Brian Dawson: But I do say things like that, hiding a few lines of code in a huge pull request is actually I think due to fear and other psychological reasons, things that people practice in the field. Obfuscation of their work due to insecurities or what have you.

Julien Delange: You know, there is something when I joined AWS, something really I pulled from Jeff Bezos. As you said, there's no bad intention, but the thing is good intentions don't work. He has a video about that that says good intentions don't work. It means it's not because you have a good intention it's going to work. What you need to have is a process.

Brian Dawson: Correct. Right, right.

Julien Delange: The process about writing, testing, validating. And I think sometimes people are like, yeah, but I really wanted to do something good. It doesn't matter. Because it's not going to work.

Brian Dawson: Right. The intention is not going to show through –

Julien Delange: Exactly.

Brian Dawson: – unless you get to the end. All right. Now I'm promising – I know eventually you have to get back to preparing for your demo day and other work, so I'm going to jump in and ask – let's get back to the root question. What were challenges that you experienced in your day-to-day work as an individual, as an IC, as a lead that said we need Code Inspector?

Julien Delange: Oh, yeah. So that day was – I mean, that was when I was definitely at AWS and Twitter and when I was writing the book and I saw a lot of what was happening in terms of technical debt and all the issues that came with technical debt. So I mean, again, I can talk about the Twitter case, because Twitter is a really good example and they publish a bunch of blog posts about that. What was happening is it had a huge monolith service at the time for serving ads, and what they decided is to break the system into multiple systems.

So to come back to what we are saying at some point is, you know, you have these huge systems that evolve over time, and nobody really knows how it works. Nobody has an idea really how it works. We have a rough idea about this. But the point is it's such a huge monolith that it's really hard to make a change, deploy. You're going to have a bug you need to roll back. So one of the things I decided is to say we're going to stop developing new features for maybe, you know, I think it was a year, and I think it involved 70 people over a year, which is again at the –

Brian Dawson: That's a big bet. Sorry, go ahead.

Julien Delange: Yeah, totally. But the breakdown, as they start to break down the big monolith into microservices, again, like there's a bunch of details on the Twitter engineering blog. You have a bunch of really smart engineers that work on that problem. And when I start to see that I'm like, 70 people for a year to solve only the architecture issue, because it's just an architecture issue, just talking about architecture, how to bring down the monolith into microservices. And I started to see all the pending issues that were still here.

And like, oh boy, there is a huge opportunity here. [Laughs] And I keep hearing the same story. I had friends at LinkedIn that have the same issue, and many tech companies that keep telling me that's an issue. So if you look at Stripe, in 2018 they did a report on technical debt. The report was the following: today, on average, a developer works 23 hours a week.

They spend 13 hours because of technical debt, difficulty to deploy, bad code, no test, no documentation whatsoever, and an additional three hours because of bad code. So let's sum up bad code and technical debt costs 16 hours a week per developer, and they work 23 hours on top of that. So you basically have about 40 percent of your development time that is taken by taking your debt and bad code. So you're like, okay, if I can make a tool for $10.00 a month that can give you back some of your productivity, I think there is a huge possibility here.

Brian Dawson: So that was kind of the lightbulb moment, and at that point, yeah, it's sort of a no-brainer.

Julien Delange: Totally.

Brian Dawson: Well, then this gets to it, and I think there's a correlation, this blog post that you wrote, which I love, by the way. I got a chance to dig in before this call about the 10 software engineering laws developers tend to ignore. And real quick, before I get to my ask of you, I'll call out, for example, Conway's law, a topic of a particular talk that I've been giving, also known as you will ship your org chart or the Mythical Man-Month, Brooks law, adding manpower to a late software project makes it later, and I love the Parkinson's law, which applies to all of us, number four, work expands so as to fill the time available for its completion.

Julien Delange: Yep.

Brian Dawson: Right? So these are an aggregation and an expression of these that are awesome. But my question for you in bringing this forth is why do these laws tend to be ignored?

Julien Delange: Again, I think the same thing – business ignorance. It's so easy to think you're going to solve – when you have a problem that is already kind of solved and you're like, oh, I need two more weeks, you're going to take the two more weeks. It is probably not going to get done. You're going to need two more weeks again and two more weeks again, when at some point you just ship tech metrics, see what's happening. All the while you will keep taking more time. At some point, you need to draw a line.

The Brooks law is the one that I saw. I saw this law so many times. Look at some engineering organizations. Look at a company like Discord. Discord, I think they have like 200 engineers, something like that. It's really – I mean, I don't know. Last time I Googled it, it was a really small company. Compare that to Slack. Slack, they have maybe twice or three times the number of engineers.

But the reality is do you see a lot of outage with Discord? No you don't. Do you see a lot of outage with Slack? Yes you do.

Brian Dawson: Right, right. The rates of return, yeah.

Julien Delange: Look at the organization. Clubhouse. I think Clubhouse is 15 engineers.

Julien Delange: I believe. I will need to check. But the point is adding more people – and we talk about that in the book on technical debt in practice – I mean, it's where – covered in Peopleware. That is a book that – I love that book. That basically if you have more people you're going to have more communication challenges.

Brian Dawson: Yeah. Right, right.

Julien Delange: You know?

Brian Dawson: You cannot just keep scaling.

Julien Delange: Which comes with a rule of the two-pizza team.

Brian Dawson: Right. And the microservices, as we talked about earlier.

Julien Delange: Exactly.

Brian Dawson: One of the efficiencies you gain is you kind of counter that Mythical Man-Month, adding more engineers doesn't help.

Julien Delange: Correct.

Julien Delange: There's also a problem today you have in software engineering management. There is a huge issue about people are being judged by the number of people they have in the whole efficiency team. If you have more people under you, you're going to be promoted, because you're a great manager, you can handle so many people. But we don't look at the output. And then other thing people want – why do people want to go higher? Because they want to play the politics and have more people under them to be promoted, which basically will – but we know that they're not going to be more productive.

So one of the leaders actually, evaluate your manager according to the output of their team, not the –

Brian Dawson: Right. And you don't mean volume necessarily. Maybe volume.

Julien Delange: Yeah.

Brian Dawson: But also probably other attributes like quality.

Julien Delange: Yeah.

Brian Dawson: Maintainability.

Julien Delange: Exactly. How many outages did you have in the last few months? If your team is good at producing quality software that don't crash, having that is a valued thing.

Brian Dawson: Yeah. There's an interesting riffing on that a bit. Again, at the risk I'm going to get myself in trouble by riffing, but a previous guest I was having a conversation with, we were having a discussion about this concept of an SRE, a site reliability engineer, which is taking off in the topic of discussion. And I don't mean to fight any developing religion here, but someone in a conversation with me had raised the argument that's a patch problem. And you may have a different view, so we can take a fork to debate it, right?

Should we have to have somebody whose sole job – now it brings value in the reality of today's world, but as to ensure site reliability, or to your point, if we incent based on different attributes than size of your org, the equivalent of lock or lines of code that you push out, can we inherently implement coding practices and engineering practices which preemptively address reliability?

Julien Delange: So there are two things I want to cover, really important.

Brian Dawson: Okay. Good, good. It looks like I've prompted some thought though, so that's good.

Julien Delange: Yeah, yeah, yeah. First of all, you have some productivity engineering tools that are out there, that comes in a long line of code, everybody, every engineer adds, and some organizations raise an engineer based on the number of line of codes they add. That is not good. We should not use the line of code as a metric. That's not – no.

Brian Dawson: Absolutely not. Right.

Julien Delange: No. Like in that case, you should use Java that is very variable. You can have a lot of code. The number of line of code is not a good measure for productivity. There are many other things we can use, but we should not use that.

Brian Dawson: Is the length of my pull request comment a measure of productivity? Can you measure me on how many words? No, I'm messing around, Julien. [Laughs]

Julien Delange: We are actively having a feature on Code Inspector to tell you redo what code request, but the way we try to turn this feature is having a blameless approach. Let me explain. If somebody doesn't do a pull request for a week, for us it's not an issue in productivity. For us, it might be because the person has imposter syndrome and doesn't want to reach out to a senior developer. So these absence of pull requests might be a sign for the manager to say, is there a training issue here?

Do we need to have a senior developer that helps this person to complete the pull request? Instead of saying this person didn't pull the pull request, didn't do the pull request, it's bad, we want to say maybe it means that in your organization you need to have better communication. That's one thing. So it's how you see the feature. We don't want to take this to blame the developer.

We want them to take insight about how you need to manager your team. The second thing I want to address is about the SRE and the role of the SRE. Having an SRE or not – you know what? That's a debate. I don't have a particular religion. What I want to say here, an SRE should be the person that will basically make sure your software operates correctly and recovers. The SRE is going to make sure that your VM are spinning up, you have enough capacity and all that stuff.

After that, the SRE should not be the one that checks if there is a bug or not. They should be the one saying this version is buggy and fix it with the software developer. But ultimately the rule of the software developer, to make sure there is no bug by making tests, making sure they're trying a staging environment that can be automated and all that. There's like two different rules; one for the infrastructure and one for the software that is running on the infrastructure.

Brian Dawson: Yeah, yeah, yeah, yeah. And absolutely, and I think it's important for me to say that in engaging in that question I was taking a very rudimentary, surface level definition of what an SRE is. So I agree with you, and thanks for that clarification. So before I get to a couple of our standard questions, I do want to dig in a little more into some of your impactful work. So I think we'll shift back the laws a bit, and I ask our listeners, go out, give that a read. If you have questions, comments, reach out to Julien.

But next I want to dig into this thing that we've hit upon a couple of times – technical debt. And you published a body of work, a number of articles around technical debt, including one through MIT Press. I want to ask more tangibly for you, based on that work, what advice do you have for enterprises and developers who are faced with technical debt? And in fact, I think oftentimes the technical debt is uncovered or discovered when you're already pressed for time, late in the development process.

Julien Delange: Yeah.

Brian Dawson: Any advice?

Julien Delange: Yeah. Don't panic. Don't panic. It's going to be fine. You know, many companies are afraid by trying to find what's going on and what is bugging that code. You know, it's like when you're overweight and you're like, I know that I should lose weight and you don't go on the scale because you are afraid, and you're like, no I don't want to see the number.

So don't panic. You have tools to try to diagnose. So Code Inspector is one of them. There are a bunch of other tools that I think about. ProMyze, that is a tool made by a partner in France. There are a lot of tools you can run your CI/CD pipeline on, even at run time, that's going to help you to find bugs and issues. Some of the issues are more hard to find.

For example, your system architecture, how you are using your database and all that. That's harder to find. In that case, you need to have people that are going to come and have a passion for craft, like being really passionate about having good software and good architecture. So in that case they will work on that. But I think that's possible for companies to find ways to adapt and try to address it.

So the last thing I want to say is technical debt is not always bad. You know, it's like, hey, maybe you bought a house and maybe you took a mortgage, so you have some debt and sometimes it's okay. If you want to go fast and you really want to ship a feature really fast and quick, that's okay. You're going to take some debt.

But you need to repay it. So have a plan. Have a plan. If you are about to go bankrupt, stop, have a plan to repay the debt over time, and execute. But don't be like the person that wants to lose weight, start to have a plan, and they come on the couch at night and they say, "I'm going to get ice cream." [Laughs] Don't do that.

Brian Dawson: Right. That goes back to what you're saying, a process, right? Or a reasonable mortgage repayment plan without an exploding arm that can adjust.

Julien Delange: Correct.

Brian Dawson: Let's say we're taking on debt, but we have a process and a plan for managing and mitigating that debt, and it's all right. It's when you don't have the process and plan. Is that correct?

Julien Delange: Exactly. That's exactly right. This is where you have the plan and when you don't have the discipline to repay it back that is bad. Again, if you have some pounds, you took some pounds because of Thanksgiving and Christmas, that's okay, and you know at some point you're going to be, okay, for three months I'm going to work out and eat better. And you shave the pounds and that's okay.

But if you keep doing that for 10 years you know you're going to have some health issues and all that. It's just about having good habits, a process, and having discipline.

Brian Dawson: So digging into that a little bit more, are there particular tips that you have? So I love the don't panic. I'll just reiterate some of it, right?

Julien Delange: Yeah.

Brian Dawson: But you have to have discipline. You have to commit to managing your debt and addressing it. Do you have tips for the best way? And in particular enterprises, right? These larger software development teams, a portfolio of products and projects, sometimes business critical.

Are there any tips that you have for ways that enterprises could manage the accumulation of technical debt and strategies for them to drive reduction or mitigation of that debt?

Julien Delange: Yeah. So there I think you have multiple things you can do. The first is, of course, you can use tools. Hey, you can use Code Inspector today. You know, come be a customer for $10.00 per person.

Brian Dawson: And I'm not knocking you Julien, I do count that as at least the second shameless plug.

Julien Delange: [Laughs]

Brian Dawson: But, yes, you can use Code Inspector.

Julien Delange: But one other thing that is the most important, I believe, is culture. Set a culture in the company that is going to be _____ quality. Yesterday I talked with a VP of engineering of a really amazing company, and what they have is basically they hire people that truly have good knowledge about software craft and what it means to have good quality code. So they hire – they have a culture in the company, and the way they do that is having first senior engineers that really care about having good quality code.

They teach and they mentor junior engineers when they come. Sometimes they even take one month before they really start to write code, they take one month to write good code. They organize a book club to talk about multiple, different technologies they may use or they use already and are in good practice. And then they read the book, after that they do some exercise to practice what's in the book. So it's definitely an engineering culture you need to have.

That's the first thing. The second thing is have a culture about reviewing the code in a non-blaming way. Again, imposter syndrome is coming back. Somebody's going to write code, somebody may review, and they're going to be, oh, my code is so bad.

Brian Dawson: Yeah. You've got to implement practices so that people don't try to obfuscate and hide, I guess you're saying, right?

Julien Delange: Correct.

Brian Dawson: Get people out in the open so we can have these discussion, which can turn into fruitful inspections first.

Julien Delange: Yes. And also there is this – we need to get away from the – I think in the industry, and that's something that companies can foster in terms of culture, stop to see the senior staff engineer as the guys that know everything and is like god. This guy can be wrong. That's also very important to –

Brian Dawson: Or gal, I must say. This guy or person, I'm sure you mean.

Julien Delange: Yeah, yeah. Totally.

Brian Dawson: But that person could be wrong, yeah.

Julien Delange: Yeah. Exactly. That person can be wrong. And in that case, a junior developer can come and say, "No, this is not good enough," even to staff. So in fact, I have a story at Twitter. There's this engineer. She started six months before I left Twitter.

And every pull request I was doing, a lot of people giving me a ship it, ship the code, and she was coming back and saying – she'd block my ship and say you didn't write the code here. You didn't write the test – sorry, the test. So she was raising the bar. Super junior person, but I really appreciate how she was putting an emphasis on quality.

And I see many senior developers that will say, "Who are you to do that?" And I think you need a culture to say it's open, that's fine. Comment. You're going to raise the bar. And to be really frank with you, she raised the bar. She made me write better software.

Brian Dawson: Yeah, that's interesting. So she had to have a certain amount of audacity to do that, but it was valuable, and if we can promote that culture.

Julien Delange: Yep.

Brian Dawson: I want to underscore – before we shift to your DevOps moment, I want to underscore something you said that's probably obvious, but wasn't obvious to me that really resonates, is in my experience engineering – okay, my career in technical management. The company was dumping a bunch of money into shared management training. All kinds of core as well as ancillary training. We'd go get in sessions, we'd do workbooks, we might even get certifications. When it came to technical training it was, hey – and I'm guilty of this with my team as well – here's a budget to buy any book you want and put it into the library.

We said go out and learn on your own. What you highlighted that is really interesting, and I don't know if you've seen this in practice, but I want to underscore for the listeners here is an engineer's skills and capability, knowledge and training is so fundamental to what we are paying them for that it only seems logical that we implement shared and structured training within our engineering program so we're up leveling everybody together.

Julien Delange: Yep.

Brian Dawson: But I don't see that happen much. So I guess two questions for you to hand it back. Is that an effective summary of what I think was your second tip, and have you seen that done well or is there a deficit of it?

Julien Delange: No, I think it totally depends on the company. Again, a bunch of startup companies prefer to offer t-shirts, decals.

[Laughter]

Julien Delange: Yeah. They're going to give you a balloon for your birthday, you know? [Laughs] But at the end of the day, does that make you a better developer? No, definitely not. So I see a bunch of tech companies are just doing that or, hey, you have a smoothie bar. I mean, to be honest, I don't really care about the smoothie bar.

What I care about is basically be good at my job. Because what you say is really important. Today, as a software engineer, what you are doing, it has nothing to do with what we will be doing in 10 years. The language will change, the technology will change, the landscape will change. You need to plan –

Brian Dawson: The practices change. Yeah. Right.

Julien Delange: And you need to constantly train. So you have a bunch of companies that don't invest, and you have some companies that invest, like the one I was talking about. They have a book club. They send people to conference. It takes even some time to practice what is in the book. That's very rare.

Like to say, take eight hours of your time to do an exercise that has nothing to do with your work. Imagine just saying that. People will see that as you are wasting the time, but no, you are not really wasting the time. You are really investing to be better.

Brian Dawson: Yeah. Man, we're out of time to really unwrap that. I would've liked to have – that is so, I guess, deceptively obvious but important, right? And I'll kind of put a point on it and make the suggested – I always joke about the job descriptions, right? Must know LAMP, Nginx, C coding, specific Java classes, and you must be able to do this on second Thursdays between 12:00 and 3:00 at midnight on this generation of server. Right?

These very specific tasks that, you know what, instead of looking for someone with an unfulfillable skillset, get someone with Roots, and then invest in them developing the skills that they need. Yeah. Anyway, I can really go in on that. But no, thank you for raising that. I think that that is really enlightening for me and an important way to look at things.

I do want to ask now, since you've given tips, I'm sure some of these tips you have learned the hard way. You might've even learned them through a Dev oops moment. Dev O-O-P-S. So I'm wondering can you share with us a time in your career where you ran into a challenge – or let's be frank – you kind of screwed up, technical or otherwise, but you took away an important lesson from it?

Julien Delange: Yeah, sure. So this is probably my biggest bug I had. So, you know, I was doing software to manage a server and automate a new _____ of servers, and there was something to remove a directory in the system. So to remove the directory it was like aim-aif/variable, and the variable got emptied, which turns to aim-aif/.

Brian Dawson: Oh. Yes, I think I've done that before myself. [Laughs]

Julien Delange: Yeah. But the thing is that bug happened in production after we deployed the software on a closed ML. So we basically erased the hard drive of all the closed MLs, which basically taught – I mean, the lesson I take away from that, there are two things. First, control the variable you have as an input. Always control.

Brian Dawson: Yeah. You have to put checks around it, effectively. Well, control the input, but where you can't control the input you have to put checks around the variable. Is that –

Julien Delange: Exactly. Like for example, I was doing aim-f/variable, check the variable is not never, check that that variable is not empty, check that variable is not a space.

Julien Delange: And this kind of thing. So that's the first thing. The second thing is, I'm going to be honest, at that time I was not writing test. It was like ship it and don't write test. And right now I was like, well, you know what? That costs a lot of money for the company and that costs a lot of Rhino. We need to ship a new product and all that stuff. Write a test. It's going to take you 20 minutes, and then it's going to save you a lot of time, you know –

Brian Dawson: Later, later.

Julien Delange: Yeah. So –

Brian Dawson: Yeah, that's a good one, and I think I've been there. It is – look, wear your seatbelt, write your tests. You may not need them, but when you do you're going to be damn glad you took the extra time to do it.

Julien Delange: Yep. Exactly. So, you know, it is a thing you just need to do and we don't – it's really hard to quantify the value of writing tests, because you're not guessing the impact when you deploy it, but when you don't these kind of things happen. I mean, when that happened I was like, that was so dumb.

Brian Dawson: Oh, I can imagine how your heart felt, right? [Laughs] I can just picture your heart dropping to the pit of the stomach and the stress. I have been there. No, great point. There's 1,000 reasons to come up with – it breaks my flow, I don't know what I'm doing yet – as to why to not write test.

But to rephrase some of what you're saying, look, you need to get into the process, practice, and discipline of writing them, figure out a way to do it that it doesn't interrupt your flow, but in the long run it'll make you a better developer, a better team member, and may save blood pressure spikes and some years off of your life, right?

Julien Delange: Correct. That's correct.

Brian Dawson: So a couple of more questions for you, Julien. What is a book, podcast, or other resource, a person to follow, a book to read – and you can mention yours, but if you do you've still got to mention another – that you would absolutely recommend to our audience?

Julien Delange: Yeah. So the book – okay, I can recommend mine but I mean –

Brian Dawson: You already know I'll do it. Everybody, I recommend that you go out and read Julien's book – buy when available – Technical Debt in Practice. Okay, so I got that out of the way.

Julien Delange: Okay. So there are two books that I really love, and they're old books, but I think they wrote the book, and it's still valid. The first is, of course, is The Mythical Man-Month.

Julien Delange: I mean, that's a universal book. I think the book was written in the '70s and it's still – I mean, you can still apply the same principles today. The second one is Peopleware. Peopleware is basically saying – so Peopleware – the argument of Peopleware is the following: did you ever see a project failing, that failed, because of technical issues?

Brian Dawson: If it was, it was a misnomer I think you're saying. At the core of all of this –

Julien Delange: Is people.

Brian Dawson: – is people. People develop software, and I always like to say ultimately no matter what they capacity, for people. So your comment start point and end points of failure – or start point is going to be people.

Julien Delange: Yeah. Exactly. And basically what you should care about to improve your software is people, and the book is all about that. Managers, how you manage your team.

Brian Dawson: That's awesome.

Julien Delange: Even office space and how the office space is organized, because the office space is going to have a dynamic about how people interact and talk.

Brian Dawson: That is actually another surprising one. I always like the surprises. I like both of the references, and we get a whole range, but I love that focus on people. And stay tuned. I expect that sometime this year we're going to issue a list of all of the DevOps Radio guest recommended readings.

So finally, first, Julien, before I hand it over to you for final thoughts, this so far has been a joy. It's getting cliché when I say this, but I do absolutely think that we can have a marathon episode and talk about this stuff. So I've enjoyed it so far. Before we get ready to wrap, do you have any final thoughts, words of wisdom for our audience?

Julien Delange: So one of the things I have, something I really think about where we are going, is the developer environment. This is something that is – I don't know if it's controversial or not. I think the developer environment is going to go away into the cloud, and if people have opinions they can contact me about that. I will be really happy to discuss about that. I think the future is going to be to be able to have less friction to edit code, which means that your code editor, Vim, Emacs, IntelliJ, VS code, all of this is going to go away.

Basically, we're going to have a code in the browser. We're going to code in the browser, and everything right now is going to be done in the browser. Because basically what you can do after that in the browser, you can have the same platform. You don't have any bad dependencies, you're not going to have mismatched dependency version between your environment and your coworker's environment. Everything will be seamless.

You're going to need just a Chromebook to code. And I think this is where the future is going. The future is going with less friction, more automation. And you start to see that with GitHub and all the CI/CD pipeline. We automate more and more every day. And the next step is going to get away from the traditional editor you have, and your common operating system or platform is going to be your browser and JavaScript.

Imagine a world with the domination of JavaScript. Do you want to live in that world?

Brian Dawson: Yeah. As a guy that – a person that still loves procedural C and assembly and spent half of my life installing localized software, I believe it, but cognitively I have a hard time. And that actually leads to a question I forgot to ask you, Julien. If I understand, you founded this company around something called Code Inspector, I believe?

Julien Delange: Yeah.

Brian Dawson: I think I heard it a couple of times. But what I ask, does Code Inspector integrate with Jenkins?

Julien Delange: Yeah, yeah, yeah. Totally. Jenkins, GitLab, Action. We can integrate with CircleCI, all these tools. We have open API, we have graphical API, and one can interact.

Brian Dawson: Awesome.

Julien Delange: And we're going to have more tools that are going to be open source to interact with Code Inspector. In fact, as a matter of fact, I just hired a developer of operations this week. She just started, and I'm super, super excited –

Brian Dawson: That's going to be awesome.

Julien Delange: – to have her in the team and produce even more content to help people onboard with Jenkins, CircleCI, GitLab, Action and all that.

Brian Dawson: Phenomenal. Well, Julien, I am really optimistic about what you've started here with Code Inspector. I've enjoyed talking through it with you. I also appreciate the unveiling of Code Coaching or Code Coach, the new feature on our show here. And I look forward to hopefully us getting a chance to have you back on again or just have some conversation while I watch where Code Inspector goes. Fantastic knowledge set, view of the past, as well as fantastic vision of the future.

Julien Delange: Thank you. Any time. Thank you so much.

Brian Dawson: Thank you.

Julien Delange: Bye.

Brian Dawson: Bye.