Mirco Hering is a Global DevOps Practice Lead, IT Transformation & Delivery Lead, CIO Advisor, Blogger, Author, and Public Speaker. He is the author of "DevOps for the Modern Enterprise". He starts off by deriving his own definition of DevOps. He also dives into some approaches used for DevOps, managing a DevOps team, challenges he faces and possible solutions, and many more!

Jonathan:

Hello everybody and welcome to another exciting episode of the Adventures in DevOps podcast. I am your host, Jonathan Hall, and here in my virtual studio with me is Jillian. Hi, Jillian. And joining us today, our special guest is Mirko Herring. Welcome Mirko.

 

Mirco Hering:

Thanks for having me.

 

Jonathan:

Would you tell us a little bit about yourself, what you do, maybe how you know anything about DevOps?

 

Mirco Hering:

Yeah, absolutely. So I'm the global devops lead for Accenture. For the last 13 years or so, I've been working in this space, really helping complex organizations try to make the best use out of devops. So I work a lot with what I call heritage applications like the mainframe or Java applications, Salesforce, Oracle, you name it. Basically in an environment where there's lots of, lots of interesting technologies to solve.

 

Jonathan:

Interesting. So I think maybe a good place to start then would be to hear your description or definition, if you will, of what DevOps is. Because it's a fuzzy word, everybody means something different by it. When you talk about DevOps, what does it mean to you?

 

Mirco Hering:

Yes, for me DevOps is really an umbrella term. And what

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

I mean by that is, is there's a lot of different practices that fit within this and they're all for the purpose of building IT solutions in a better way, faster, more secure. And ultimately make it easier for developers to solve the business problem.

 

Jonathan:

Fascinating. All right. Yeah, I think I can get behind that.

 

Mirco Hering:

I'm not too fussed with these specific buzzwords, to be honest. Like, you know,

 

Jonathan:

Yeah.

 

Mirco Hering:

like every couple of months you get a new DevSecOps, MLOps,

 

Jonathan:

Yeah.

 

Mirco Hering:

AIOps, SRE, platform engineering. And to me, it's all just, you know, they're kind of facets on a prism of what we're trying to do. But at the end of the day, we're all here to improve the overall way that we develop solutions.

 

Jonathan:

Exactly, right.

 

Jillian:

I like that way of thinking about it. It's more about thinking of the process rather than, you know, tightly defining the thing itself.

 

Mirco Hering:

Yeah, and I was just like the last couple of keynotes that I did at DevOps days, like there's different titles, but it's basically DevOps is dead, long live DevOps.

 

Jonathan:

Ha ha ha 

Mirco Hering:

Kind of making acceptance as argument.

 

Jonathan:

Yeah, we actually had an interview on this show a few months ago, I think, with somebody. I don't know if they were credited for creating the DevOps is dead meme, but they certainly perpetrated it and they were kind of feeling sorry for it. Like people took it entirely the wrong way.

 

Mirco Hering:

Yeah.

 

Jonathan:

So yeah, I like that DevOps is dead long live DevOps. There we go. So I don't know if you want to talk about a few stories, maybe specific client stories that you could tell about or a technical challenge that you face. How do you like to address this topic?

 

Mirco Hering:

Yeah. So let me, let me start with the way that I think about it.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

Um, because it's, I don't know whether it's unique, but it's certainly the thing that I've learned over time. And, and I've come through, you know, in 13 years, you come through a couple of waves of this one. Um, I was a an engineer initially and, um, I certainly thought that just having a better technical solution or better tools or whatever would give you the answer. And I've matured out of that understanding, now that it's a lot more about, you know, bringing, you know, the, the capabilities, so the practice like continuous delivery or continuous integration, together with the organization. So you can think about the organizational structure of having all these kind of siloed teams to more full-stack teams and then bringing that together with the architecture of your technology. Because from my experience, architecture is this kind of dirty secret. If you have a big, monolithic mainframe, then there's only so much you can do with DevOps. You have to basically address all three dimensions. You need to uplift your capabilities. You need to arrange your organization the way that is most optimized. And then you need to evolve the architecture to something that you can ideally support with that.

 

Jillian:

Are you saying the engineers should maybe talk to each other?

 

Mirco Hering:

be

 

Jonathan:

Ha ha ha 

 

Mirco Hering:

a good start.

 

Jillian:

Yeah.

 

Mirco Hering:

And I'm a big fan of full-stack teams instead of this idea of these unicorn full-stack engineers. So I think you need to have the capabilities in your team, but I don't necessarily believe that every engineer is going to be the superstar.

 

Jillian:

I definitely agree with that. There's just too many things for anybody to be a superstar in anything anymore, I think.

 

Mirco Hering:

And I think full-stack engineers work in your startup in a garage and there's like five of you because you have no choice. But if you get to big organizations, there's thousands and thousands of developers and you can just... That's just never gonna work.

 

Jonathan:

So you made an interesting point about the architecture, the technical architecture is important for DevOps. Are there architectures that you think are fundamentally incompatible with the DevOps approach? And if so, why?

 

Mirco Hering:

See, I think you can use DevOps ideas for everything.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

Now, I think there's a concept that I like to use with my clients, it's called transaction cost. It comes from Reinertson and from product management and so forth, but the idea is that if you build a solution then for that to go live, to become productive, there's a transaction cost. And the transaction cost... describes how quickly you can get something done. If you have a big mainframe or a big package software, then the transaction cost is high because you need to get all these changes together into one bundle. You need to compile it or build it. You need to deploy it and you might have to stop pretty much the whole organization to do that deployment. That's a massive transaction cost. If you have a microservice and you can deploy it at any point in time and you have multiple versions live in production, then the transaction not zero, but it can get very close to zero. So

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

the goal of all we're doing in DevOps is to reduce the transaction cost. Now the transaction cost on a microservice might be from five minutes

 

Jillian:

Thanks

 

Mirco Hering:

to four

 

Jillian:

for watching!

 

Mirco Hering:

minutes. The transaction cost on a big monolithic mainframe might be from three months down to two and a half months.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

And the principles are the same. You're looking for ways of improving the way that you validate quality, testing, test automation, code scans, whatever that is. or it's the actual deployment mechanism, or it's the validation afterwards. You have to kind of look for each technology, what is the bottleneck in that end-to-end process, and then improve that. You're looking at a series of constraints, you're looking for the one thing that is holding this specific stack back. And so to me, we have this tool belt, and we need to figure out what the contextual problem is, and then we use our tool belt to address that specific bottleneck.

 

Jillian:

So

 

Jonathan:

You

 

Jillian:

what are some

 

Jonathan:

made

 

Jillian:

interesting

 

Jonathan:

a-

 

Jillian:

problems you've been tasked with solving or come up with? Uncovered I guess.

 

Mirco Hering:

Yeah, we can cover like, let's cover kind of three different things and they are kind of going down kind of my favorite path of craziness, I guess. So

 

Jonathan:

Hehehehe.

 

Mirco Hering:

if you take something like the Siebel application, right, it's the big package. And one of the problems to solve there was like, if you have multiple teams working on a big monolithic package, is how do you manage code? Because at the end of the day, if you want to be at all independent in your individual teams, you need to find a way to share code. And so one thing that we had to then look at is, and what CBO does, and there's other package software that does it as well, is whenever I check in code, it basically creates a bunch of metadata that gets stored. At what point did I change this field or the specific data set? And what that means is when you compare code, you have only conflict because this kind of metadata always differs. And so the problem... that we had to solve is like, how do we identify just the actually the code that matters? And so we had to create basically it's a comparison tool that ignores all the metadata that doesn't carry payload and only look for the configuration that matters. And then you had to build this into your kind of IDE stack so that you can have the individual developers being able to use this and then still combine afterwards a fully working product. Right, and so that's it. that's really kind of you dealing with the kind of core architecture of an application that was not built with DevOps ideas in mind. And we had to kind of solve that for them.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

Yeah. It sales was very similar for a long time and they have brought out DX just a little while ago to address some of that. So. That's one of the things where you just kind of really get to the core architecture of it. And I find this fun as an engineer. Um, I'm not sure whether that's the, uh, the most traditional way of looking at it, but I find it fun to just look under the hood and figure out how we can, how we can play around with it. That's one type of problem. Then you have the type of problem that is purely organizational, right? So how do we, how do we look at large organizations that might have big testing centers or, um, very separated practices? And. reshape them. Yeah, and how do we bring organizations together? And really, my answer to that at the moment is to do barrier stream mapping, to bring all these people together in a room to Julian's point, get them to actually talk to each other, to start understanding, wait a second, what is your job in here? And how can I actually make your job easier by providing perhaps my content in a slightly different way, or with different metadata, or in a different format? And really start to just see how, once you bring people together, you can actually in an open-minded way and with some visual facilitation, that they can actually start addressing organizational problems. And then the third one that I find fascinating is, so how do we make it stick? Because I've been in several organizations, certainly in the earlier iterations, where you go in because you wanna do a DevOps transformation and the executives are getting really excited about that and you're gonna do this, and then the CIO gets replaced and they have a different interest. and I just stopped because no one can explain why we did this. And

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

I say, you know, show me where the benefits is. And, you know, you saw this with agile as well, where you say, oh, but we have, you know, we have more agile teams. So what? You know,

 

Jonathan:

So

 

Mirco Hering:

like,

 

Jonathan:

what? Yeah.

 

Mirco Hering:

what exactly? Or we have continuous delivery. OK. Like. How does it help?

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

You know

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

what I mean? So you kind of see if you want to be successful in an organization, you have to kind of address all these three different problems, right? You have to do the kind of engineering. You need to look at kind of the pros and the together, the human system. And then you also need to address the executives and the business case and the value and the like, why are we investing in this?

 

Jillian:

Those are really good examples. I always think it's really important for engineers to learn how to speak a little bit less in tech speak and then learn how to translate that back to, and I suppose we could say like the business case, but what is the problem that you're trying to solve and how does it relate to that? Just like you were saying, we have agile, you know, how does the person who's not in the in the tech speak know what that means or know why that benefits them or you know, like anything of that nature. So it's always really important to bring these concepts back.

 

Mirco Hering:

And there's no one walking around giving you the certificate at the end saying, you're agile, you're

 

Jonathan:

Right.

 

Mirco Hering:

done here. And

 

Jonathan:

Oh.

 

Mirco Hering:

this is actually one of the really fundamental problems, I think. It's what we're doing now is a transformation that has no end.

 

Jonathan:

You're right.

 

Mirco Hering:

And I think that's really hard for people to get their head around because it's not like there's no end state, right? It's not like as is to be, and we're just going to make our way across this chasm. It's like every week there's a new technology. Now we need to deal with, you know, how do we deal with... computer generated code more and how do we control that and how do we quality assure that and how do we give a CIP considerations and in three or six months time, we have the next thing that we need to start solving for.

 

Jonathan:

I think that's one of the reasons that, I mean, that's one of the reasons so-called Agile or DevOps transformations fail so often is because they really do never end. And that's almost a misnomer to call it a transformation. You might think of it a transformation of mindset. We were in the mindset of things go this way, and now we're in the mindset of things are never the same, they're always improving. But you never reach that end goal. There's no finish line, right? You're never like, okay, now we're Agile, we can stop doing those things now, we can stop being... We can stop improving our DevOps. I had somebody ask me once on an interview a few years ago, I think. So Jonathan, if a company does all the right things, can they say they're doing DevOps now and then stop improving? I was like, well, you could say you're doing DevOps at the moment, but once you stop improving, then if you're doing the exact same things a year later, no, you're not doing DevOps. If you aren't improving your processes. Every day, every week, you're not doing DevOps or Agile the way it's intended to be.

 

Mirco Hering:

Yeah, I use this analogy with my clients where it's kind of the equivalent if you are, you know, a slightly overweight, middle aged white male, and you go to the doctor and they say like, you know, you have high blood pressure and you're a bit of, you know, you should really lose some weight. And you know, what I'm looking for is for the doctor to give me this pill that I need to take once or you know, the cabbage diet for three weeks.

 

Jonathan:

Right.

 

Mirco Hering:

And what he's going to tell me is, Mr. Herring, like, you need to work out more and you need to eat healthier. And you will need to do this for the rest of your life.

 

Jonathan:

Right.

 

Mirco Hering:

And I think that's exactly the same, right? Like the kind of magic pill of the cabbage diet is the, you know, the SRE playbook and the latest CD technology. Right?

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

That's not gonna solve your problem. It's using all that stuff to really become a better organization on an ongoing basis.

 

Jonathan:

Exactly.

 

Jillian:

So DevOps is the vegetables of the tech world. I kind of

 

Jonathan:

Ha

 

Jillian:

like that

 

Jonathan:

ha.

 

Jillian:

actually as an analogy. We're just running around being like, you eat your vegetables, put down that ice cream, put it

 

Jonathan:

Do

 

Jillian:

down,

 

Jonathan:

your DevOps.

 

Jillian:

come on, like, you know, here's some broccoli, pretend they're tiny trees and you're dinosaur, go nuts.

 

Jonathan:

DevOps is good for you.

 

Jillian:

Exactly.

 

Mirco Hering:

I can tell you that my six-year-old actually puts on the pizza spinach and broccoli, which I find terribly weird. But I

 

Jonathan:

Whoa.

 

Mirco Hering:

really

 

Jonathan:

If

 

Mirco Hering:

love

 

Jonathan:

it gets them to eat it, why not, right?

 

Mirco Hering:

him. Yeah. It's like, it's not the pepperoni. It's like, spinach and broccoli on a pizza. Hmm, okay.

 

Jillian:

Kids have always been okay with broccoli because you can pretend you're a dinosaur and that they're little trees and they're eating them. And for reasons that's always been, except for my 12 year old, she's too cool for that now. But back in the

 

Mirco Hering:

the

 

Jillian:

day, it worked and she still likes broccoli. So we're good.

 

Mirco Hering:

Well done, well done.

 

Jonathan:

So I have a couple questions, and one of them is probably gonna be a stumper, but I hope you have an answer because I've been looking for one for a while. But first, you talked about bottlenecks. How do you identify bottlenecks when you're working with a company? What's the process you use to identify the bottlenecks to improve?

 

Mirco Hering:

Yeah. And look, I, as I said, like, I think my, my, my magic tool is, is a value stream mapping. It's just what I found the most useful thing, which is you, you really kind of mapping out the IT process from idea to production and, you know, the specific steps. And then bottlenecks, when you have a couple of different flavors, because bottlenecks can be, they can be seen to take a long time, you know, like standing up environment, getting access to an environment, creating test data, whatever, whatever that is. So it's a kind of a duration bottleneck. I think the second type is a quality bottleneck where we find too many defects, the environments are too unstable, the deployments are not reliable enough, so you have a quality bottleneck. And then the third one is spec flow, where you have basically things that you sort of solved but they're coming back and that might be just clarifications, it might be incidents, and so it's all kind of different bottlenecks. that you can identify. And usually, I mean, if I show you the YSFMACs I've done, it's gonna imagine you have kind of green Post-it notes for processes and red Post-it notes for problems.

 

Jonathan:

Hmm.

 

Mirco Hering:

They usually have nearly as many red Post-it notes as green Post-it notes. It's a target rich environment, usually in big organizations. And then it becomes, you know, which ones... A can be addressed because it was in our remit and it's not like I need the SEO to make changes or we need to change the budgeting process or those kind of things and still have an impact. So you kind of do like impact versus how difficult it is on a two-dimensional graph and then you figure out which ones you can actually address with the thing that you have.

 

Jonathan:

Mm-hmm. And

 

Mirco Hering:

And

 

Jonathan:

then

 

Mirco Hering:

then

 

Jonathan:

my

 

Mirco Hering:

you can

 

Jonathan:

next,

 

Mirco Hering:

finally make progress. So that's

 

Jonathan:

yeah.

 

Mirco Hering:

a benefit.

 

Jonathan:

So that, and that was gonna be my next question. How do you know if you've addressed a bottleneck? How do you know if you're making progress? And let me paint the picture a little bit further, because sometimes it's obvious, you know. Deployees were taking six weeks, now they're down to a day. That's progress, right? That's pretty obvious. But sometimes you have a... process change that maybe has a long lead time, or it requires people to learn something new and there's a learning curve to it. So maybe an example is, we're gonna throw away Jira and start using stickies, or something like that. And there's a lot of pushback because, oh, this feels harder, or there's more work to be, I don't like writing, or whatever the, imagine a scenario where you're getting pushback. How do you know if that pushback is legitimate and that the new process is worse versus, you know, because the short-term pain, you know, the pushback usually comes from some short-term pain. Is that short-term pain endemic of something bigger or do you need to push through that short-term pain with the faith that something better is coming through? How do you make that call?

 

Mirco Hering:

Yeah, and this is where you would like to get the magic answer, which I won't

 

Jonathan:

Of

 

Mirco Hering:

be

 

Jonathan:

course,

 

Mirco Hering:

able to give you.

 

Jonathan:

yes, everyone wants this answer.

 

Mirco Hering:

Um, but

 

Jillian:

Thank

 

Mirco Hering:

I

 

Jillian:

you.

 

Mirco Hering:

think there's, see, I described a lot of this as, I'm a man of terrible analogies, but I described this as kind of breathing in and breathing out, because I think there's these, these things that you just try and experiment with, and you're going to allow this to go for a while while you're kind of breathing in. And you just let it run for a little bit. But if after three months or six months it's not, if it's the same as before, all right, then let's stick with it. Like there's no

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

reason to move back. And if it's worse, still after that period of time, then we need to try something different. It might be going back or might be, you know, yet a third option, but if it's better, let me now agree that this is now our new standard and that that applies for for process changes you described, but it also applies for, Hey, like we really hate, uh, get we want to go back to Bitbucket or whatever, right?

 

Jonathan:

Sure, yeah.

 

Mirco Hering:

Okay, be my guest. I'm letting this team go for a little bit, but if they can't justify after three months why this thing is better or not, but it has extra cost for us because, you know, different licensing or whatever else. And then you have to come back to the fold. So a lot of this is, you know, you can describe it as a pendulum spinning, you can explain it as breathing in and breathing out, but I think you just have to have some of that because not everything is linear in transformations.

 

Jonathan:

Yeah, that's good. I like the way you put a time cap on it, too. You said six months. Sometimes that's appropriate. Sometimes you might just need a few weeks. You know, but yeah, I think putting a. You know, I like the phrase, let's try an experiment when you get

 

Mirco Hering:

Yeah.

 

Jonathan:

pushed back. Let's try it for two weeks. Let's try it for a month and then we'll come back and reevaluate. That's good.

 

Mirco Hering:

That will be and I stay with my energy of the of the guy is trying to get fit right? That's like doing your first workout the next morning you wake up, and you're aching and they come on that

 

Jonathan:

Yeah,

 

Mirco Hering:

again

 

Jonathan:

right.

 

Mirco Hering:

No, no, you just act for a little bit proceed it is actually getting better

 

Jonathan:

Excellent analogy, yeah, yeah. I hate running. I hate work, literally, I hate running. I don't mind some workouts, but I hate running. But yeah, if I were to judge my success based on the morning after, especially the first week, I would just, I would never do exercise.

 

Mirco Hering:

But it is like that. And a lot of this stuff, I mean, there's no, if there would be, and this is now that I'm a parent, it's true for parenting, right? If there would be a right answer, everyone would tell you the right answer. Given that there's everyone, there's like 50 different ways that people tell you how to do it, that means there's no one answer, which means you need to

 

Jonathan:

Right.

 

Mirco Hering:

find the one that works with your child or with your team.

 

Jonathan:

Yep.

 

Jillian:

Yeah,

 

Jonathan:

Very

 

Jillian:

kids

 

Jonathan:

true.

 

Jillian:

are the ultimate example of a science experiment. They really are. Yeah,

 

Mirco Hering:

and

 

Jillian:

I've also found that when working with a big group of people, that's often a good way to get some kind of buy-in is... don't let anybody be too, including yourself, be too emotionally invested in what you think the outcome is going to be and frame everything as, all right, this is the hypothesis that we're testing. And I think using a time frame is a really great example. We're going to test this out using this time frame. And this is the outcome that we're hoping to get to say if this was successful or not. Or maybe have some other metrics in terms of what's successful and what's not. get people on board with something like that pretty swiftly.

 

Mirco Hering:

And I'm a huge fan of getting metrics. It's just some of this stuff is, it's hard, like, you know, what feels easier, right? I mean, how do you, how do you put a metric around this? Um, but other things are very metrics driven and, you know, the engineering processes are pretty aligned to that where you can, you know, you can measure deployment times, you can measure effect, right? You can, you know, there's a whole bunch of stuff that you can measure. Um, but for some of the stuff you just need to stick with it. And then, you know, after a while, there's this, Hey guys, like, what do you think? Is it now more painful to go back? Is it, you know, is it worth sticking where we are?

 

Jillian:

So you said you concentrate on kind of what sounds to me like sort of an enterprise software, maybe stack, you know, like Salesforce and I don't remember what were the other ones that you mentioned, but have you found any kind of patterns or just anything, you know, interesting you found specifically with working with these types of software? Because I know I don't work with any of those. So I'm just interested in your experience, much more on like the startup side of things rather than the enterprise. And it's all a bit like what's happening over there.

 

Mirco Hering:

Yeah, what I find amazing and this is, this is again, one of the things that, um, I've only only come to realize over the last couple of years, it's, I find this by the way, amazing how, you know, I have completely believe that I need to disagree with myself once in a while, like, you know, I very much disagree with myself from five years ago, I'm probably going to disagree with my today in a year's time, right?

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

Um, I used to think that there's technology specific solutions and that these technologies are very specific. Actually, in the overall scheme of things, when you look at the build process, the deployment process, the testing process, et cetera, they are pretty similar. Like the individual components underneath are different. But there's an overarching process that we can align. And I think that's becoming a lot more important, certainly in larger organizations, than the optimization of the individual team. I take a really simple example from my early days of Agile where lots of organizations say the teams can choose their own tools. It's a

 

Jonathan:

Hmm.

 

Mirco Hering:

brilliant idea, up to the point that you realize that now these people can't even speak to each other anymore.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

Your geo-dependencies against the Azure DevOps, against the Rally, against whatever, it just doesn't work.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

We sometimes forget that this is an overall system, and that means we need to really optimize the overall system rather than give it to components. That means we need to have similar language, we need to make sure that our mainframe colleagues can speak to the same people as our Google data lake people. And if you don't facilitate that, then we can't expect the organization to work well. So for me, that is one of those things that I've spent a lot of time with now to try to align these worlds and get people to understand that the overall process of, you still build an application. Yes, it's completely different for your Salesforce application to a Java custom build, but you're still building it somehow. It might just be that it's abstracted away from you. And you're still deploying it, and you're still dealing with an environment. Even if it's a SaaS product, there's still an environment somewhere. There's still a data consistency somewhere that you're dealing with.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

And so it's really getting this kind of commonality and highlighting that over the difference that I spend a lot of my energy on, and that I think is helping organizations to improve the whole thing, and not just have the runaway cool team, and then the older guys falling behind.

 

Jonathan:

Mm-hmm. It's really easy, isn't it, for techs, whether it's SREs or developers or whatever, anybody in the tech field to get caught up with the shiny new tools and fall in love with their tooling. But from a business standpoint, that's almost irrelevant. It's not completely irrelevant. I mean, it's kind of like if you, let's say you own a fleet of rental cars, and you hire some mechanics to work on those cars, they may care about the exact fuel injectors you use and the exact... brake pads and you know whatever or maybe they want the new greatest you know regenerative braking technology whatever that whatever they might get excited about they can care about that and that's not unimportant but at the level of managing a fleet of vehicles you don't care what kind of brakes are on those vehicles as long as they could stop when they're supposed to

 

Mirco Hering:

Yeah.

 

Jonathan:

and you want them all to be the same because you don't want to

 

Jillian:

Thank

 

Jonathan:

have to

 

Jillian:

you.

 

Jonathan:

keep stock of 800 different types of brakes

 

Mirco Hering:

Yeah, and look at organizations, right? Big organizations, when you look at the tools they use to run their IT, it is as complex as the business applications they run, right? Because they have dozens and dozens of tools, right? And I'm with you, right? There are some tools that are better than others, but I've done DevOps automation with Control-M, right? I mean, that kind of worked, right?

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

And all these people that are spending months trying to decide whether they go with ToolX or ToolY, I think they're really missing the point.

 

Jonathan:

Definitely. Yeah.

 

Jillian:

I wonder how much of that is gonna kinda start to go away a little bit with the, with just the huge advance that we're seeing in AI and in these kind of, I'm not exactly sure what they're called, these sort of transformative tools where you're like, yeah, you have Python, but then you get like this sort of. schema that then can be translated into any of the other languages, right? Like the, um, like a lot of the web APIs have this or now, you know, for example, I've been getting back into C plus plus lately because I have, you know, the GitHub co-pilot and the AI tools and my IDE and they can very easily auto complete for me. And so I care less about the fact that I'm like, Oh, you know, I have to remember all these things with C plus plus that I don't really feel like remembering because the IDE remembers it for me. And so I wonder how much this is going to kind of influence. you know, maybe some of these teams that are on one side of the fence or the other, where they're very, very constrained with their tool choice being very, very open. And if it's going to make the people who are very, you know, constrained kind of maybe move towards the, well, maybe we can be more open with our tool choice because it just, it just doesn't matter as much anymore. Have you seen

 

Mirco Hering:

I'm

 

Jillian:

any

 

Mirco Hering:

really,

 

Jillian:

of that?

 

Mirco Hering:

I still have like this inherent hope, never really materialized, but that we get to a point that we get these tools to work together, right? The kind of the ESB for tech tools. Like we just never got there. And it's kind of frustrating because each tool ended up becoming its own walled garden. I'm the one who orchestrates everything, but don't you dare try to orchestrate me. And that's just like, I think an anti-pattern, you see, you can see this kind of, again, this pendulum swing, right? We have all these new tools coming up and then they all consolidate because one vendor gobbles up a whole bunch of them to build this end-to-end solution. And it's, I find this fascinating when you go to the individual kind of tooling conferences, you

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

can totally see that pattern, right?

 

Jonathan:

I kind of wonder if, I mean, in some ways we've standardized. I mean, like, Docker is a pretty universal abstraction layer that virtually everything uses. Not literally everything. I mean, if you're using Heroku or something, you know, maybe you're not always using Docker. But almost all the big tools can use Docker. So there's one layer of abstraction that's pretty common. Terraform doesn't really give... it sort of gives you a layer of abstraction on top of everything, but it's not... really abstraction, it's just a common file syntax that works with everything. So

 

Mirco Hering:

Yeah.

 

Jonathan:

it's not like you can just drop in S3 and place it with Google bucket or vice versa, but it's kind of an abstraction. On the other hand, if you want to, and then things like Kubernetes give you an abstraction mostly. You could more or less take your Kubernetes payload from one cloud to another with some tweaks, I mean, depending on exactly what you're doing. But I think in a lot of ways it's similar to going back to the car analogy I just made. If you're driving an American car versus a European car or a Japanese car, they all work more or less the same. But you have to learn different things. You have to get metric tools or imperial tools. But for the most part, the principles are the same. Nobody would say, oh, I can fix a Japanese car easily, but I have no idea how to fix an American car. That doesn't happen. You have specialties. But... It's not so foreign that you can't transfer your knowledge. And then now we have the additional dimension of internal combustion versus electric versus hybrid and maybe even hydrogen. We've seen a few of those driving around. I don't know if they're commercially available yet. So you get different drive trains and that changes the picture a little bit. But still, for the most part, they all have wheels and they all turn and they have to break when you come to red light. And so those mechanics kind of are universal. a different size wrench for each vehicle. So

 

Mirco Hering:

Yeah.

 

Jonathan:

I wonder if we're in a similar situation that the big cloud providers, unless Microsoft buys everybody eventually, which I'm sure they'd love to do, we're gonna have this splintering, but maybe that's okay.

 

Mirco Hering:

And I agree, because I obviously run a practice with a whole bunch of developers guys, and that's my argument, right? If there's a specific tool that you're looking for that our engineers need to know, if they know similar ones, then I'm quite happy with that, because they can pick that up, because they're not that different. If you know the principles, then moving from one to the other is not that hard. And I think that's certainly, I think the, compared to what I said earlier, the overarching steps continue to be similar. There's orchestration, there's automation, there's infrastructure, there's these components you need to pull together. You build some templates. I mean, infrastructure has now become like code, right? Where it's like open source, you pull these different components of the infrastructure together. So it's becoming closer and closer.

 

Jillian:

That's interesting that you guys are saying that because on the data science side, I feel like I'm seeing almost the opposite where there is a really big push to standardize. And so I kind of sort of see both sides of the argument where, you know, okay, as long as you know the fundamentals, it's fine. And you can switch pretty easily between frameworks, because I think that's quite often the case. But then on the other side, I am seeing much more of a big push to kind of standardize these different processes and workflows, like how we treat, you know, like a data frame, which is essentially, you know, like an Excel file or a CSV. At least that's the data model that you can keep in your head, or how to train, you know, machine learning models, how to test them, how to evaluate the hyperparameters. There's like a huge push towards standardizing all those kind of processes that have, you know, like I don't even know how many machine learning libraries are out there these days, but like there's, there's a lot, there's a lot, but now, you know, lately you're getting some that are... not even new machine learning libraries, just like, we have had enough, we want a standard way to talk to all these libraries so that we can test, you know,

 

Jonathan:

Mm-hmm.

 

Jillian:

across all the different types of models with all the different hyperparameters, which was, you know, some ridiculously large matrix, once you get to the end of it, and all that kind of thing. So, I don't know, it's just, it's interesting because I'm not really that sure like which direction it's going to go in. Is everybody going to keep pushing for standardization or is the, you know, is it going to be like, you know, you need to just kind of adhere to this. so that the computer can understand your code so that it's easy for like the IDEs to sort of translate between the different languages. I don't know, I'm not sure.

 

Mirco Hering:

I don't either, but I have hope. I mean,

 

Jonathan:

Hehehe

 

Mirco Hering:

I find it amazing, right? If you look at how big IT is, and how, if you look at it objectively, how immature we are when you think about, you know, how do you even measure whether you're progressing? Getting energy

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

from one organization to the others, these principles that Johnson and myself talk about are similar, but there's no guarantee that the process looks anywhere similar for them, right? Because you measure completely different things, you have

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

completely different processes. It feels like there is a castle on the hill that everyone wants to get to, that we all agree on, which is this kind

 

Jonathan:

Hehehe

 

Mirco Hering:

of hyper automation where you just really define the payload. But it's just completely wandering around this mountain range.

 

Jonathan:

Hehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehe

 

Mirco Hering:

It's like, you know, some people are going down this pathway, some of this pathway. And we never really get there, which is sort of kind of fascinating.

 

Jonathan:

I'm curious to hear what you think. I think the part of the problem is that we think it's a technical problem, but it's not. It's really a people problem.

 

Jillian:

Yeah, it's never a technical problem. It's always a people problem, almost always.

 

Jonathan:

When

 

Mirco Hering:

And

 

Jonathan:

I...

 

Mirco Hering:

the tech makes it easier. And then we get, I mean, but this is no different to why we have this thing here that is like 10,000 times more powerful than what Apollo had to fly to the moon.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

And still opening Safari browser takes three seconds.

 

Jonathan:

Yeah.

 

Mirco Hering:

We're basically lazy. As soon as something gets easier, we become lazy and then it bloats. Right? And it's like

 

Jonathan:

Yeah.

 

Mirco Hering:

you get new technologies. You now have microservices and you have moved from your architecture, from your architecture, you have fully microservices. Fantastic. Right? And then because it's so easy to do, you just have incredible amount of redundancies in these services that you then have to manage and I'll be spending all our time dealing with that redundancy. Like you will always, you have to continue to exercise. We have to continue to stay healthy. And that is just a bit that we failed. But we are getting better. So slowly. Haha. In the outskirts we are getting

 

Jonathan:

You know,

 

Mirco Hering:

better.

 

Jonathan:

we are getting better, and it is slow, but I think the more we get better, this is just what, basically, I'm rephrasing, I think, what you just said or something you alluded to. The more we get better, the more we realize how much better we can get. So that castle on the hill is always getting bigger and fancier and more luxurious and farther away.

 

Mirco Hering:

Yeah, that's true. And it gets fancier, right? It's like, oh, and we can add an extra bit here and an extra bit there.

 

Jonathan:

Mm-hmm. We just look at Star Trek, you know and the 60s Star Trek was really forward-looking, you know Oh my gosh, so such amazing technology They haven't you know and then in the 80s when they came out the next generation look back in the 60s Like how ridiculously old does that look you know if that's our castle on the hill It's evolving to ahead of us But you know, yeah There's some of the things from the 60s Star Trek that are still way cooler than what we have now, you know Fasten light travel transporters my goodness. They use tapes and they printed out papers What the heck?

 

Mirco Hering:

When I started this in our company, I was kind of one of the early guys before people believed that this would be something real. I quite honestly put in my targets that we'll just have DevOps adoption everywhere and then I'm going to go off and do something different. And I've now resigned myself to the fact that I'm probably going to do devops for the rest of my career and hand it over to my son to run it afterwards. But you know, like, it's just not going to stop. Like, there's always the next technology and the next barrier to break. And we will all have to get better and keep up with those capabilities. I give you another example, and this is, I don't know whether that reflects what, but I used this recently with a client where, like, why does this matter? And if you think about it, a few years ago, If you wanted to go live with an enterprise application, you had like, I don't know, a dozen components and you went live over a long weekend. And a dozen components, I can manage in my head. But I can say, this is version one, version three, version six, and then I cannot go live with it. Now, if I have hundreds of components and I go live every week. then you can't keep it in your head anymore. That means we needed to create capabilities to manage that complexity. Right, and then we get faster again and we have more components and we use more open source elements that I need to manage and we need more kind of infrastructure components that I can ethereal and, you know, just come up for a mini second. But now I have to manage that. Right, so you have new capabilities and then I have to create capabilities to manage that complexity. And then I get new capabilities and then, you know, it kind of, it's this flywheel.

 

Jillian:

bots to manage the bots to manage the bots.

 

Mirco Hering:

and it's turtles all the way down.

 

Jonathan:

Hehehe

 

Mirco Hering:

But it's because we are dealing with, I mean, we have a world around us that is more powerful, it can be more powerful, it can also be really frustrating

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

and we need to help manage it. I mean, our job I think it is in the industry is to keep up with it because otherwise we go out of control. There's this beautiful saying that to make a mistake is human, but if you wanna create a catastrophe, you need automation. And I think that is absolutely true and I've seen it multiple times. For you to take down a production environment with 300 servers and to do that manually is pretty hard. There's a couple of automation scripts, you can do that in seconds.

 

Jillian:

I think that should be like somebody's villain origin story, you know, like comes up from tech and they brought down thousands of servers accidentally. I'm just waiting for the day. I'm sure it's already happened.

 

Mirco Hering:

There's three really nice examples. There's this guy who built a cloud-based company that creates development environments. And they woke up one morning, and basically, the whole library and everything was gone in the cloud because they had run a script with a variable in it, and the variable nulled out. And so basically, it went to the root and deleted it all. His company disappeared overnight, because there was no backup, nothing

 

Jillian:

Oh no.

 

Mirco Hering:

like that. It was not small, it wasn't huge, but it was like a couple of million dollar revenue company. Then you see the example of the guy who got into a fight with, I want to say it was GitHub or whatever it was, where he took his little library out with the, you know, removing the left space and basically brought the whole internet to breaking, to the point

 

Jillian:

Oh yeah,

 

Mirco Hering:

that...

 

Jillian:

was that an NPM package or something?

 

Mirco Hering:

Correct, yeah. And then he basically then agreed to put it back in. But again, like they have the complexity that we can't, and it's not like that you or me can't write this piece of code. It's just we didn't know that it was in so many other things, these transient dependencies that no human can manage. And then there was the example of the Amazon outage where they basically had a whole bunch of things where they're like, okay, I'm gonna clean out a bunch of old data sets. and he basically ran it on the wrong qualifier. And because the pop-up that came up for the engineer was, are you sure? Well, has anyone ever pressed no? Of course you're sure. I mean, you wrote what I think. But again, because it's out of context, right? If it was that, are you sure you want to delete five quadrillion datasets?

 

Jonathan:

Hehehe

 

Mirco Hering:

He would have said no, but he just said, are you sure? And so,

 

Jonathan:

Hehehe

 

Mirco Hering:

you know what I mean? Like these are the things that are outside of our control sphere, and we just need to have the systems that help us.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

And now from the faster than, like this is, I'm a very, I'm an optimist and yet I'm cynical.

 

Jonathan:

Yeah. Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha Good combination, I think.

 

Jillian:

I think it's all a distance metric. It's like how far you have to go to get to the castle is also how far you have to fall into the underworld. I think it's

 

Jonathan:

Hmm.

 

Jillian:

just a vector going in either direction. You just got to hope that it's going in the right direction.

 

Mirco Hering:

And I think part of all the kind of coaches and transformation guys and whatnot, I think part of the job is to make it a somewhat enjoyable journey. Like it can't be this kind of death march. It has to be something where people, you know, enjoy the landscape and get some pleasure from making the next mark and the next step forward and so forth.

 

Jillian:

I think in general tech attracts people who have what I call I'd like to learn new things disease because the people who don't have that disease tend to find something else that makes them you know less frustrated with the world than

 

Mirco Hering:

I'm gonna go.

 

Jillian:

this library

 

Jonathan:

Mm-hmm.

 

Jillian:

has had another you know version upgrade and all these syntaxes don't change right.

 

Mirco Hering:

So I, and this tells you why I'm in this industry. So when I was a teenager, I actually wanna become a tech advisor. It's a very weird kind of dream job to have. But I had this idea that, you know, I make money and then I also learn how to optimize, how to get the minimum amount back to the state. Anyway, I did an intern job in an IT department and then one day I came home to my dad and said like, I'm gonna go into IT and he's like, what a strange miracle, like why you wanna do that? And I'm like. I've been now in this department for a week and I realized what they do. They build a product, they roll it out, and then later on they get paid to fix it. And then they build the next

 

Jillian:

Thank

 

Mirco Hering:

version,

 

Jillian:

you.

 

Mirco Hering:

they get paid to do the next version, and there's no end to it. It's like,

 

Jonathan:

Ha

 

Mirco Hering:

you

 

Jonathan:

ha

 

Mirco Hering:

will never

 

Jonathan:

ha.

 

Mirco Hering:

be out of a job. I find that genius. Very insightful

 

Jillian:

I mean,

 

Mirco Hering:

for 16 years.

 

Jonathan:

Ha ha ha.

 

Jillian:

yeah, that's like trying to explain paperwork to kids. You know, I'm giving, I'm doing this paperwork so I can give it to somebody else and then they give me back more paperwork and you know, so on and so forth. Yeah, you're right. I haven't thought of it like that. It is. It's the job that never ends because you, you're constantly creating yourself new jobs.

 

Mirco Hering:

Yeah, it's probably the same for most of technologies these days, right? Like it's not like the TVs and washing machines and so forth last for a generation. But certainly in IT it's extreme.

 

Jillian:

No, I'm convinced every like appliance now has a three year like ticking time bomb inside of it where it just explodes like my blender every three years on the dot.

 

Jonathan:

Hehehe

 

Jillian:

My great uncle had the same blender for like 30 years, I think like 30 years. Yeah. All right. That's that's a complaint for another time. But I'm very annoyed that my blender is currently not working.

 

Mirco Hering:

I've heard that I haven't bought it yet, but I have the same experience. And I've been told, my wife is Sri Lankan, that in Sri Lanka, they still sell some of the kind of old school stuff and that lasts like, you know, 10, 15 years. So it's on the list for the next trip to just bring back a blender.

 

Jonathan:

Hehehehehehehe

 

Jillian:

That's a good idea. Save yourself the frustration.

 

Mirco Hering:

But it's amazing, I mean think about cars, right? I remember my older brother fixing a car, like an old car, and just repairing it. And

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

now, I drive a Tesla, what am I going to do with that thing? If there's something broken,

 

Jonathan:

Yeah.

 

Mirco Hering:

there's nothing to fix here. And that's actually, again, a good analogy, right? You can stay with your car analogy, Jonathan, because it's the same thing. In the old days, you could probably fix a whole bunch of stuff yourself. And you had a much broader range of what you can do. Think about

 

Jonathan:

Mm.

 

Mirco Hering:

when I had my first PC, the config system, auto-exit button, and whatnot that you kind of tweaked to make the memory allocation better. You wouldn't try to do any of that stuff now, because it's just outside of

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

all of your area of access.

 

Jonathan:

Yeah, of course, I played with configsys, and then I switched to Linux, and I compiled my own kernel, and I would go through and disable all the modules I didn't want, and read up on all the, I could set this number to 128 or 256. What does that mean? I'd look all that up. I haven't compiled a kernel. I think last time was about three years ago when I was trying to use an HDMI capture card that required a specific kernel patch. And then I stopped using that. So yeah, I don't do that stuff anymore. I don't need to.

 

Mirco Hering:

Yeah. Well, and there's probably way too much now in there for you to actually understand it all, right? It's not

 

Jonathan:

Oh

 

Mirco Hering:

like

 

Jonathan:

yeah.

 

Mirco Hering:

the 15 things that you could worry about. It's like it's 5,000 and it means like better even start. So you need to use the instructions. You have no choice.

 

Jonathan:

Yep.

 

Mirco Hering:

But it's, yeah, this is fascinating. This is a really great

 

Jonathan:

It

 

Mirco Hering:

conversation.

 

Jonathan:

is.

 

Mirco Hering:

This is very more, much more deeper than I expected.

 

Jonathan:

No, it's always fun to have these chats.

 

Jillian:

I think one of the really fun examples of that is looking at package managers, just even in the last five or six years and how much more complex they have all become and how many of them have bots to manage the bots to manage the bots. You can really go and dig into these things because a lot of them are online. So for example, I used to do a lot of work with the conda package manager. I don't know how many layers of abstraction that thing has anymore, but it's a lot. And then it was too slow. So then somebody rewrote it and like, you know, C or C plus plus, and then somebody rewrote the rewrite and like, it's just, it's, it's getting out of control. It's wild.

 

Mirco Hering:

Yeah, I mean, I read the one of the security reports, and what it said, like, it's all about transient dependencies now because it's just, it very quickly that tree becomes very quickly so large that you can't control it anymore. And so you have to kind of figure out like where can we even interface with this stuff anymore. It's just kind of scary to some degree. And then we get to, we're doing DevOps weeks at the moment here in our company and like a week long conference. And we have lots of people were presenting, there was quite a few machine learning conversations. And just the difficulty of controlling that, because if you train something, you're now training not on individual data sets, but you're getting the gigabytes of data that you basically have to version control, because that is what created that model. And you have multiple of these experiments running in parallel, and it's outside of anything that you can control anymore. You just have to assume that the abstraction is good enough.

 

Jillian:

that reproducible research has been struggling with the same problem for, I suppose, as long as there has been research. I remember Nature came out with a paper, I don't know, it was a while ago, but it was about how nothing was reproducible and it was quite the scandal when it happened. But

 

Mirco Hering:

Yeah.

 

Jillian:

yeah, specifically because of what you're talking about, you also have to version control the data and the data is very large and you get into this, you know, into then all of these new types of problems. So you have to version the data, version the changes, you know, specifically with a lot of the machine learning libraries. It's a whole lot more things than anybody could ever possibly manage in their pad.

 

Mirco Hering:

Yeah, and then we come back to the ghost in the machine, right? Like you're doing the same thing and it just turns out differently because there's one variable somewhere in this that you didn't control. Or you're getting statistics now, right? Because, I mean, there's machine learning. You end up, I mean, we're doing demos, right? To clients around, you know, Gen.I created code and co-pilot and so forth. And they're not completely by the outcome. Like I just can't. Right? And then it's, you just have to be comfortable with the variability in this.

 

Jillian:

Well, I mean, yes and no. So for a lot of... Specifically with the machine learning stuff, you're supposed to have some external way to validate that that does not rely on a computer, right? Like in biotech, a lot of times you're testing for a compound that has some medicinal activity, and then you get a computer to generate something that looks similar, and then you go generate that thing that was generated, and then you go test it in the lab. So there's still, there's some feedback loop in there somewhere that should be real. When you exist too much in software though, does get a little bit, I don't know, it's like too meta or something. There's too many layers of abstraction. Like you said, it is a ghost in the machine. Who even knows anymore?

 

Jonathan:

Hehehe.

 

Mirco Hering:

I remember going to the machine as long as I go back. I went to my first engineering project. For whatever reason, the answer to the problem was to allocate A to A, and then the problem was then solved itself from home. Never knew why, but those things used to happen, and I'm sure it still happens.

 

Jonathan:

Is there anything else we should touch on before we start to wrap up?

 

Mirco Hering:

I think I've come up my ground, to be honest. Like, this is kind of the stuff that I'm fascinated by.

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

I mean, the only thing is probably the, the rallying cry that we really need to focus on solving those problems and not get too excited about those buzzwords. We didn't talk too much about this, but I find this incredibly frustrating. Oh, you know, now everything needs to be SRE, and everything needs to be platform engineering, everything needs to be this and that. And I find this obsession a bit, you know. I think Agile has it worse because they have these kind of really strong fractions where you know the safe framework versus the scrum framework versus whatever and

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

to the point that they can't talk to each other. If I'm the

 

Jonathan:

you

 

Mirco Hering:

principal of one then you can't be the principal of the other. But I'm really, really, in our community we need to make sure that that doesn't happen because one of the good things for us is that we never had a definition and that we never kind of had these hard barriers

 

Jonathan:

Mm-hmm.

 

Mirco Hering:

and I think we need to continue to just strive to improving the situation. whatever we have available to us. And every new idea, every new tool is just another tool in the toolkit and you can choose to use it or not and that's up to you.

 

Jonathan:

Shall we go to Pixton?

 

Jillian:

Bye.

 

Mirco Hering:

Let's do it.

 

Jonathan:

Do you have one, Julian? You want to start us off? OK.

 

Jillian:

I do. So I have been messing around with the AI tools lately, specifically GitHub Copilot and Tab9, which are both plugins or extensions you install into your IDE. I mostly use PyCharm and C-Lion, which is like the C++ version of PyCharm. And I'm pretty happy with the different tools now. They're pretty cool. They do a pretty good job. Sometimes they give me that was a function that existed. It turns out it was not a function that actually existed,

 

Jonathan:

Ha ha.

 

Jillian:

and so then you know that threw me in error. So GitHub Copilot, I'm not sure what happened there. I'm also, I'm pretty excited for the voice, like the voice activation that's supposed to be coming along with GitHub Pilot. I would totally pay for that if somebody is here who, you know, has the inside scoop on GitHub and can get me added from the waiting list to the actual product. I would very much appreciate it. So those were really neat, and it's actually gotten me kind of to learn, you know, some new frameworks and I've been a bit... I don't know if I'm getting too old for this or what, but I'm like, oh, I don't want to learn any of these new frameworks that you crazy kids are using these days. But now since it's so much easier with the AI autocomplete tools and things like that, I'm getting into the PyAero C++ library, which has really good performance. So that's been fun. And then the other one that I have is AWS Omics, which is like their kind of... platform for doing genomics research recently released these workflows called ready to run, which are these kind of like pre pre configured analysis workflows for different types of genomics genomics and a lot of chemical informatics engineering. And I think it relates really well to what we've been talking about on the show with this idea of like continuous improvement and the ghost in the machine and all this kind of thing, because to get a workflow that you know, you're treating like software, you have to have so many different moving pieces, you have to have data itself that is under version control so that you know like what to expect in the data, some of these. Data platforms aren't deterministic, so then how do you test to see if some result is within an acceptable range or not? How do you get the results? Where do you store the data? All these different kind of ideas that people have been struggling with for as long as there's been research, I guess. There's now kind of some really interesting answers, I think, for the first time, at least that I've been working in research, that these different pieces have come together, because it used to be, okay, we can have these workflows, but we just don't have... the storage to store enough variations of the data that we can really test this thing on demand. Now they are able to be tested on demand. And then specifically for the more self-serving side of myself, I do a lot of this kind of analysis optimization and I work with a lot of startups that they want to create an analysis workflow and then kind of license it or rent it out to collaborators and things like that. So having yet another platform that allows for that is pretty exciting for me personally. So that's it. Those are my picks. What about you guys?

 

Jonathan:

I have one pick this week. It's an audio book I'm reading. I'm sure the paper book is just as good if you prefer that. It's called Stealing the Corner Office, the Winning Career Strategies They'll Never Teach You in Business School.

 

Mirco Hering:

Mmm.

 

Jonathan:

And the author talks about, he has several anecdotes from his own life and life of people he knows, but it basically talks about the problem, the reality that we all have experienced incompetent managers. and the paradox of how to incompetent people become managers and why is their career always advancing when those of us who are trying hard and doing the right things are being overlooked for promotions and so on. So he takes the approach of what can we learn from these people? What are they doing right that we can copy without also becoming incompetent to advance our career? So that's the premise of the book. I'm about halfway through it and so far it's really good. So that's my recommendation for the week.

 

Jillian:

Do you know the answer yet? Is it people skills? So you have to read the whole book to get to it.

 

Jonathan:

There's, I think he says seven different techniques or traits that he recommends borrowing from these people. So it's not just a single answer, it's a little bit more complicated.

 

Mirco Hering:

Never is. Alright, I'll choose two picks. One is a book, New Dark Age, from James Bridal, which is very much related to what we've been talking about, to be honest. It makes the argument that we're getting into a new dark age. And the definition of a dark age in his view is that we're using technologies that we don't understand and that we can't get under the covers to figure out how the mechanism works. Obviously in the original dark ages there was a lot of those kind of things that... started working for us being in chemistry and physics, whatever. And then it took us quite a while to get to understand why. And now we're getting into this world with AI and everything else where the individual can't control it anymore and doesn't understand how it works. And that means, you know, like we are, we are at the mercy of technology. So he's, he's very interesting. The way that he describes is, um, he has this fantastic example of, of YouTube where you have AI is creating content and AI consuming content. And in between, companies spend their marketing money, people creating videos only being consumed by AI and how do we control this? So it's a very, very fascinating topic. He has also, I think, a couple of TED Talks, if you wanna just get the 12 minute version, but I find it incredibly fascinating. And then... My second pick is a bit self-serving, which is my own book. So if you like kind of what I've been talking about, I have a book called DevOps for the Modern Enterprise, that goes a little bit into this kind of thought process of how do you deal with it in a large organization. And I give away pretty much all my consulting practices in the book and basically say, here's what you can do at home and something you can try at home.

 

Jonathan:

Awesome. Great. And how can people, if people are interested in reaching out to you, are you on social media? How can they contact you?

 

Mirco Hering:

Yeah, so obviously LinkedIn, Mocha Herring will work. I have a blog called Not A Factory Anymore, which takes this kind of principle that we shouldn't call software factories and stuff like that. It's a more artisan practice. Yeah, and then on Twitter, Mocha Herring as well.

 

Jonathan:

Great. Well, thanks Mirko for coming on. It's been a pleasure. It's fun, fun topics we've been discussing. So thanks for coming on and hope to see you on here again in the future perhaps.

 

Jillian:

It's been

 

Mirco Hering:

This

 

Jillian:

great,

 

Mirco Hering:

was absolutely

 

Jillian:

thanks.

 

Mirco Hering:

fascinating. So yeah, I will be very happy to come back and do another round of fun.

 

Jonathan:

Wonderful. And thanks to everyone for listening. We'll listen to you, or edit that out, please. Thanks everyone for listening. We'll talk at you again in about a week. See you then.

 

Jillian:

Bye.