Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Reimagining CI/CD and Engineering Culture at Scale with Vlad A. Ionescu
Play On
11 APR • 2025
1 hour 12 mins
Share:
In this deep-dive conversation, Viktor sits down with Vlad Ionescu, founder and CEO of Earthly, to unpack the evolution of CI/CD, why developer experience is broken, and what it will take to bring sanity back to software delivery at scale.
From Google’s internal build systems to the chaotic sprawl of modern pipelines, Vlad draws on his background at FAANG and Earthly to highlight why most teams are stuck with fragmented tooling, unpredictable environments, and compliance bottlenecks that only get worse with scale.
We get into the core challenges of today’s SDLC:
- CI that is invisible but critical and riddled with governance gaps
- Why “run it locally” is still a dream for most teams
- The trust and tooling mismatch between platform and security teams and app developers
- The hidden risk of blindly using plugins and actions without audit trails
Vlad shares how Earthly’s new product, Lunar, aims to bridge these gaps by bringing monitoring and policy enforcement to the pre-prod lifecycle, much like observability did for production.
We also dig into:
- The tension between agility and standardization in microservices
- How remote and hybrid work affect engineering culture and accountability
- Why most companies do not suffer from lack of rules but from lack of clarity and enforcement
The conversation rounds out with a sharp look at AI in the software lifecycle. What happens when LLMs generate entire products, and what are the risks of skipping over code comprehension in favor of velocity? Vlad’s take: without guardrails, we are heading toward a future of tech debt at hyperspeed.
Whether you are in DevOps, platform engineering, or just tired of pushing CI fixes at 2 a.m., this is a real-world conversation on building smarter, safer, and more scalable developer workflows.
Transcript
Show/Hide Transcript
Thanks for having me.
So, yeah, absolutely.
Very happy to have you on.
We've been trading emails, had a few calls over the last like six months and there's a lot of overlap.
And the big reason why I wanted to have you on the show and do a bit of a kind of a devex SDLC kind of episode today.
And you have good experience in this domain and I kind of wanted to maybe kick it off there with what you're doing today and then we can dive into bigger trends industry.
But you are the founder of a company called Earthly and so maybe we can start off there with a quick intro to Earthly to just kind of level the expectation of the conversations going forward.
Okay, perfect.
Yeah.
So, hi everyone.
I'm.
I'm Vlad.
I'm the CEO of Earthly.
We've been building this company over the last five years or so.
We've been focusing around the area of managing the SDLC ecosystem better.
Our first product that we built is a framework to write better CI cd and that took off as an open source project.
It's now at 11,000 stars on GitHub, is being used by big companies such as Adobe and Roche and a bunch of other big names like that.
And currently we're building our second product which is kind of more aligned with the SDLC and perhaps the supply chain that I know Victor is a big fan of.
Our new product called Lunar is about managing the SDLC at scale in big organizations and managing engineering practices in these organizations.
Good stuff.
There's a lot to unpack there.
So what I find really interesting is kind of like taking a bigger step at this whole wave of companies, I guess that's trying to tackle this CICD pipeline.
I think it's kind of hard.
Can't have a really conversation without mentioning Dagger from solving I guess as well did something similar in this space.
And my impression is my impression, but this is coming from people coming from Fang, largely looking at what does the state of CI look like for non faang companies.
And I believe that's kind of what we started conversation like a few months back.
Right.
Like this is kind of like your ex Googler.
So is like maybe like we start there like how is the CI pipeline different at Fang or Google?
I mean I guess you can really speak about Google versus the rest of us, right?
Like maybe that's a good starting point.
Yeah, exactly.
Well, it's a huge difference.
Right?
So if you might have read articles about Google and Facebook and Twitter or X, I guess these days you might have seen that they have a significant investment internal developer infrastructure.
And I think Google started this trend.
They invented this technology called Basel to.
Basically they started off with a bunch of make files, and those make files were kind of getting unwieldy.
They have this massive mono repo where they shove everything, every single programming language, every single piece of code that they write, and initially it was all managed by a bunch of make files.
Now imagine how quickly that gets out of control, right?
Yeah.
And so, I don't know, maybe 15 years ago or maybe a bit more, they invested in a dedicated internal tool that you might call maybe a CI.
But this was pre Jenkins era perhaps, right.
So like it was very early on.
And essentially it's a build system that understands deeply the dependencies between the different components in the organization.
Right.
And it can do a lot of incremental building, it can do remote building, and it can do heavy caching, which is critical for C code bases that Google was actually heavy on.
And so a lot of that sort of central type of investment resulted in a very sort of standardized type of developer infrastructure.
And that has been actually a massive sort of productivity enhancer for Google.
And if you remember back in the day, Google was the hottest thing to work for.
Part of that was because they had really getting that really, well, like the developer infrastructure, making developers happy, productive and so on.
Now, outside of Google, in parallel, something else was happening.
Containers were coming along.
Google actually internally was kind of, I guess, late or maybe never even took on containers the same way.
But containers outside of FAANG in general created a very different type of shift towards heavy microservice use and freedom for each microservice to be defined completely differently in its own specific way.
Right.
And that meant, you know, there's more decoupling, that means you can have more freedom within each team to innovate better.
But at the same time, that creates massive chaos when it comes to the developer infrastructure.
Right.
It's decoupling, but also like a really complex mesh of interdependencies that are really hard to test in your CI pipeline.
Right?
Exactly.
Yeah.
Testing is just tip of the iceberg, Right.
When you think about, you know, how do you insert now compliance or how do you insert additional verification that maybe individual teams are not thinking about, but at scale.
You're now wondering whether every single team is following the proper engineering standards that your organization wants to abide by.
Right.
Whether that's driven by compliance or, I don't know, maybe protecting your reputation, avoiding incidents in production, preventing security incidents.
And so on all of those things are difficult now to kind of enforce.
It's just a big sea of heterogeneous sort of different things that.
And basically you no longer have a single insertion point.
I think that's the biggest sort of drawback of this sort of movement.
Yeah.
And the docker file is almost like the modern make file.
Right.
It's of the modern CI pipeline and the dev environment.
And yes, one of the biggest pain points that I've seen is GitHub Action has become kind of the norm for CI these days, I would argue.
And the problem is that you can't run this locally, like you can't run GitHub Actions locally, which means that every time you just want to test things, as things are running on CI, you need to push to CI.
And that kind of like, adds a lot of latency when you just want to see if things are working.
So that's the other side of this whole wave of new CI tooling, I would say, like CI agnostic tooling that could also run locally, like maybe speak a bit about how you see that as well.
Yeah, for sure.
The history of CI, I guess, started becoming mainstream with Jenkins.
Jenkins was probably the first popular implementation of such a system.
I guess it was called Hudson back in the day.
But over time we kind of organically grew in this direction, where CI and local dev stack are two completely different things.
Right.
And that hasn't really changed.
And there were some innovations in the field.
Perhaps companies like CircleCI and others have sort of taken Jenkins and made it a SaaS like you no longer have to kind of manage it.
It's also much more isolated.
Every single job starts from scratch with a completely new blank slate and.
And so on.
And these were good innovations, good sort of steps forward, but we never really integrated the magic of containers into this whole experience.
And the beauty of Containers is that it runs consistently no matter where you execute it.
Right.
That's a big thing.
You kind of isolate its dependencies and so on.
For that reason, we haven't really taken the CI experience to put it on the developer's laptop as well, which is part actually of our mission.
With our first product, we allow companies to essentially develop their cicd pipelines on their laptops and be able to test and execute those CICD pipelines on their laptops.
And when they're ready, they can push it up to GitHub and it's pretty much guaranteed that it's going to work, because you've run all of that in containers through the magic of Earthly, we found that to be a good enabler for debugging CICD failures, which are oftentimes very difficult to reproduce.
But also developing new CI CD pipelines much faster.
You no longer have to wait for git commit over and over again.
Do that long cycle like that.
Finally, there's something to be said about cross team collaboration.
We mentioned about microservices where every team has its own dev stack and that means each team has difficulty reproducing the build of the other team.
There is perhaps a readme there.
You have to follow line by line, configure this file and this other file and so on.
Whereas with Earthly, everything is containerized, you just run this one command and everything just works.
Right.
So you never have to kind of wonder how exactly you're going to get this other project set up.
And that has been very powerful for our open source users.
Yeah, And I think, I mean this as CIs evolved, like if you go back into the days of like early day Jenkins, right.
CI was just a bash executor, right.
That was like you just ran a bunch of shell scripts in like a sequence that's no longer true.
Like look at git, look at a modern CI pipeline on GitHub.
Like you have GitHub Actions module.
You do this, you do that, you pull in caching from here.
Like it's so much more complex than way back when you're not dealing with a dsl, essentially it's almost a dsl.
Right, Exactly.
I think in many ways some of the same basic concepts have remained similar.
Yeah.
Now we write in YAML, it's no longer exactly like a bash sort of line by line, execute this and execute that.
And yeah, we have caching, although I would argue that caching is still kind of rudimentary.
And we found that, you know, if you actually invest in understanding the dependencies between projects and you have a system that really can leverage that heavily, you can get to like 10x faster CI builds just by doing that.
Right.
And that's part of what Earthly actually also delivers.
The other thing I've seen in recent CI sort of environments is that there is use of plugins.
Right.
That's kind of natural.
And recently there was this vulnerability in, I was going to say change files.
Right?
Yes.
And before that, some years ago, there was codecov.
Right.
Things that you put in your CI and there's very little governance around.
Like people care a lot about what you put in production, but maybe aren't so careful about what they're putting in their CI, right?
There's no S bomb for CI cd, right?
Or there is, but people don't.
Funny enough, there is a conversation I read this week actually on the system analyst about actually defining this stuff before.
I think they call it a P bomb, like a pipeline bomb essentially.
But you're absolutely correct, right?
In particular in the world we live in with Cursor, that I would imagine Cursor is probably writing a lot of the GitHub action files these days.
And it's just like write me this pipeline and it just pulls in various modules and one of the first thing I always do is like, okay, cool, but do we need this or can we actually do ourselves?
That is the first thing, right?
And also like, and if we do need it, what's the security track record?
Like how many, Even if you use like something very rudimentary, like how many GitHub stars does this have?
Like obviously in the change of change log, perhaps not very good as a proxy, but at least is a proxy rather than a project out there with like five stars on GitHub that we have no audit trailer at all.
Oh yeah, Even the more popular ones, you know, we've seen some really low level stuff that is extremely popular, basically ubiquitous and you know, after many years of exposure, we just figured out, oh, there was a vulnerability here all along, right.
And you don't know what kind of like state funded foreign government has been leveraging that all along or you just don't know.
It's kind of like this big unknown sort of risk you're kind of taking.
Yeah.
And that's it, right?
Like it's.
There are so many levels of abstraction involved, right?
So like if you look at the anatomy of one of these modules, like it's the basic GitHub module, like it's probably, let's say for instance, written in Ruby, also Ruby in npm, like in JavaScript.
Right.
Like will it probably pulling in like 50 or 150 different dependencies which in turn all might be have their own vulnerability track record, right?
So it's such a complex space to do proper security audits on, right.
You kind of need like, not only do you need to pin the mod you're using, I know Open SF got some tools around this for pinning a hash against the version or all that stuff, right.
And that's great, but you also need corresponding like an S BOM essentially against that hash.
So you can all say, okay, cool, this has this.
But also this actually is included in there.
So if there is a CV in there, you can actually find this.
But that's.
Yeah.
Now it becomes such a tremendously complex problem to just run your CI.
Yeah, exactly.
Especially that we want to insert all of the security verification in CI CD when perhaps the goal of each individual application team is to ship features and not to be held back by security scanners and all that.
I think that's where there is a bit of misunderstanding between central teams like platform and security and so on and the individual feature or application teams.
I think in that regard, a lot of times the responsibility of owning the CI CD pipeline is kind of shared.
Right.
So like the platform team or the security team wants to insert a security tool and the application team doesn't even acknowledge the PR whatsoever.
They're just, you know, full steam ahead.
We have to ship this or whatever.
Yeah, right.
And it takes, we've heard from companies.
We were doing this industry research last year.
Sometimes it takes a year for PRs that are submitted by the central teams to get merged into all of the projects.
The long tail is insane.
And all that time you're kind of exposed and don't even know what exactly your posture is all around your organization.
We found that to be a big issue because there's individual tools to extract S BOMs for different types of languages, containers, and you kind of skin the cat in so many ways.
But currently there are no good tools out there to understand whether those tools have actually been implemented everywhere within the organization.
One thing.
Right.
And the other thing is how do we make this shared CI CD pipeline have clear boundaries about who owns what?
You know, perhaps the platform team does need to own some piece of that to be able to answer verification.
Right?
Yeah.
And there's also like not all CI runs are equal either.
Right.
Because if the attack vectors are different, right.
If you have a run that just does something to your checked out code base and doesn't actually write anything back or ship any artifacts or ship any binaries or ship anything.
Like the blast rate is done as pretty slim, right?
Sure.
You could do something nasty.
Maybe you can leak the secrets.
Okay, sure, that's bad, but it's not going to have any significant security issues on you actually what you actually ship into your customers.
Right.
So yeah, that's another element that is so much more complex in this pipeline because you can't like it's hard to I guess programmatically detect that in the pipeline, what it does.
Yeah, exactly.
So you touched on a great point here.
A lot of the companies that need to insert this very strict type of verification, oftentimes invest in central CI CD templates.
So every project would have to import that.
And that means you're going to get all or nothing.
You either import that and you're going to get the whole shebang of security verification.
And it's going to be extremely restrictive.
Even though maybe, like you're saying your application might not be even talking to the Internet, maybe it's not even handling any user data, it might be just an internal thing.
Right.
Maybe not shipping anything at all.
And in that regard, you need a way to create scope for what you care about.
Right?
Have a definition of scope.
What's in scope for this type of compliance, what's in scope for handling pii, what's in scope for things that are exposed to the Internet and so on, and all of these different things you probably want to treat differently because you want to have as much agility as possible in general.
But for the things that are more sensitive, you.
You can afford to kind of insert that scanner, maybe takes 20 extra minutes of your, you know, CI time or whatever.
But you have to kind of treat these differently.
Yeah, yeah.
It's such a complex thing to apply this blueprint across all these things.
Because I guess the benefit with the old style CI where everything was a bash script, was that there was limited attack vectors in that sense.
Right.
Like, there were like fewer things that were easier to audit, I guess, in many ways.
Right.
But now we have this level of abstraction.
You have like the CI modules that you're calling on, you have docker files that you need to be audited.
You have like, there are so many possible attack vectors.
And not only that, like, how do you even audit that?
Right.
Like, what version, like, are you running an UL Docker container with like, I don't know, like an node version that's not even.
That's eul, Right?
Like, right, yes.
It's so complicated.
Right.
So how do you, like, exactly.
How are you approaching this as a problem space?
Yeah.
You know, the way we've been sort of the mantra we've been operating on with this new product has been, you know, there's a lot of monitoring that goes in production.
You know, you have logs, you have metrics, you have instrumentation, you have alerts and firewalls and policies and so on, but there's nothing like that for the sdlc.
The stuff that happens before production, that has been our guiding light towards what we're building here.
We're basically building monitoring for sdlc.
What does that mean you have to understand what exactly is being built and how it is being built throughout your sdlc?
Like I mentioned, there's that high degree of diversity within each project.
You want to be able to insert centrally this verification without having to integrate with individual projects one at a time, where you're depending upon each team to adopt your templates or your additional gates or whatnot.
You need to have independent control of some of these general gates and be able to select.
I want to apply these to the services that are in scope for this compliance versus I want to.
I want to enforce these things in this other way.
For things that maybe have different kinds of requirements from the compliance or security perspective.
Having this ability to insert in a single spot and create a system of record of the posture of each application.
When I mean system of record, I mean things like, is your application properly tested?
Is your application using the right security scanners, Is your application perhaps handling this kind of data or in scope for this other compliance and so on.
All of this posture information can then be used as a way to monitor things.
How is code coverage deviating over time and so on?
Or are you handling your vulnerabilities within the right timeframe?
I believe for many compliances is like 30 days for critical vulnerabilities, for example.
Then you create policies based on these things.
You can say things like, if your code coverage is not 80% or whatever, initially I'm going to monitor it, but over time I might even enforce it and give you feedback in your pr.
As soon as you open a PR and affect your code coverage, I will block your PR and be able to insert myself as a platform team without ever having to edit your CI cd.
Yeah.
So I've heard of people doing similar things with like.
I know there are banks out there who are using like dependency track, for instance, to do like audit on SBOMs.
And then they tie that into their policy agents to say, oh, if you have any cvs, block the deployment.
Right?
Yes, yes.
But that's also a little bit flawed because what if you already have that vulnerability and now you actually, you're improving the posture but you're still blocking the improvement, right?
Yeah, it gets a little bit tricky.
Exactly.
You need what we call gradual enforcement.
And that is like each control you want to enforce has to be treated differently and we have like different levels.
So for example, you could initially just monitor things whether they're, you know, in a good state or not, and perhaps use offline sort of, I would call it an offline sort of campaigns where you kind of advocate for this new practice within the engineering teams.
You know, send them GitHub issues, send them JIRA tickets and whatnot, and get the percentage higher and higher.
And then when it's close to 100% or maybe 80, 90%, you announce that you're going to start blocking PRs.
Right.
And maybe after you start blocking PRs, then the next step is perhaps blocking production.
But sometimes there's, especially in the security space, there's going to be false positives and you want to be careful with blocking things unnecessarily.
So some things will forever stay in this mode where you kind of monitor things, but not necessarily strictly enforce them.
And you kind of couple that with the security team helping out, triage all the false positives and all that.
But we've seen this.
It's hard to have a hard and fast rule for everything.
And you need the flexibility to be able to say, these policies I want to be very strict about because I know they're going to cause incidents, whereas the other policies, I want to be more flexible because they could be false positive and such.
Right.
There's a lot to unpack there.
So the one thing that I'm curious about how you're approaching is the whole, like, problem of building.
Right.
Because, like, how do you monitor a build?
Because you essentially, in order to do it properly, you can need to monitor every single request that your build does outbound.
Right.
You need to have like a firewall, like, oh, you spoke to.
Like, oh, you're building a Debian package, but instead of pulling that, you pull in something completely random where you're like making random requests.
Right?
Yeah.
Is that part of Pipeline as well?
Or like, how granular in your access control do you get there?
Yeah, yeah.
So the way Lunar works is that we have a CICD agent that is one of our insertion points.
The other insertion point is that the code level doesn't depend on the cicd.
Right.
But I think this pertains specifically to cicd.
So in cicd, the agent monitors every single pipeline that runs in your organization.
It runs alongside the CI runner.
If you run GitHub Actions on prem, for example, we run alongside that agent, essentially by understanding everything that runs in every single CI pipeline, we can see the types of processes that you execute.
We allow the user to say things like, every time I see MVN test being executed, I'm going to look for junit XML and put that in my metadata and collect that.
And maybe I have policies around some testing, for example.
Right.
So it's at that level of instrumentation where we look at the syscalls that are being made and are able to be very precise with extracting information from the right places now.
And there's like a collection of plugins that make this easier.
Now when it comes to network traffic, that oftentimes is more difficult.
You can create, you can see what IPs are being accessed, but a lot of times that can be very noisy when you try to create an allow list or a block list based on that.
What you can do instead is perhaps making sure that the different tools that are being used are configured to use the right artifactory or image registry and so on.
That tends to be a bit better from the, you know, the precision of it.
Alternatively, like, you almost have to run everything through like a SOCKS proxy or something like a transparent proxy of sorts.
So you can actually like get what are you actually pulling down.
Exactly.
That tends to be much better.
So like you might, yeah, you might have a kind of like isolated network and then you kind of know that you want to block, I don't know, maven central because you have your own mirror that has been kind of blessed internally.
Right.
And that tends to be like a very effective strategy.
It does.
It kind of slows down teams because if they need like a net new dependency, they have to go through channels to kind of get it approved and everything.
If you're really, you know, big on security for whatever reason, you might be like a highly regulated industry and so on.
That tends to be probably worth it for.
For those kinds of organizations.
Yeah.
I had a Steve Springett on the show quite a few episodes ago talking about these as an attack vector for esp.
Well, he was talking about for esports.
But one of the interesting attack factors there is like, if you're using like private namespaces for private packages and then you have name squashing attacks essentially in the public space.
Right.
So if you know that Salesforce is using this internal package name, but then you go and register that in whatever the artifact, whatever the registry is that they're pulling, like npm, whatever, and then you can infiltrate that and just have a rogue version of the same thing.
So that's an argument for having some kind of proxy that sits in between.
Right, exactly.
That sounds super dangerous.
And I mean, somebody's going to run that thing that NPM install with no authentication by accident, and it's going to pull the wrong thing from the Internet.
Right.
It's just one environmental.
You forgot to define some environment variable and now you're pulling from the Internet rather than from your self defined run.
Right, exactly.
Yeah.
That's very nasty.
That's very nasty.
It's hard to protect against everything, right?
Yeah.
I mean you kind of need to have this like in particular as.
I mean it's annoying because you're adding friction.
Right.
Like one of the big upsides with the container revolution, if you call it may.
Right.
Was that it brought back autonomy to the teams.
They're like, oh, we want to use this, we want to use that.
But now we kind of come in full circle actually.
But actually you probably shouldn't have done that because you actually didn't know the ramifications for doing that.
You just want to solve the problem as quickly as possible.
Exactly, exactly.
Yeah.
There is such cases where oftentimes you can enforce for dependencies to be clearly like explicitly named so that it can only match the internal private one.
Right, yeah.
That it might not be obvious to enforce, but it is one of the things that we focus on as well.
If you have any custom verification, we allow you to write a central, I would call it a global CI.
It's like a definition of a bash set of bash instructions that apply to every single repository and you can use that to collect information about them.
So you might collect information about.
Okay, are you using this dependency by its ambiguous name or by the very specific private name?
And then you can sort of enforce that Through Lunar.
We've seen people come up with extremely custom and very specific things.
They want to add their enforcement based on perhaps past postmortems based on public incidents or based on just their engineering culture.
And I think this kind of flexibility is kind of difficult to define in traditional CICD pipelines.
You kind of need something that sort of runs beside it.
It's dedicated to a different sort of purpose.
Yeah.
And I mean it's going back a little bit to the whole point of like the difference between the fang of the world.
Like they, they have internal tooling that can give you the best of both worlds almost.
Right.
They, they can provide all these guardrails without slowing down development.
But most companies cannot do that.
Right.
That's, that's not realistic for more small to medium teams or even enterprise teams.
Right.
They don't have their tooling for this, Right?
Yes, exactly.
And every company's culture is just very different.
You know, the way they've, the rules of how they deploy to production and you know, the different conventions they use internally.
It's hard to have a one size fits all Especially when, you know, like you have 10 microservices and every now and then one of those 10 microservices is going to be like the weird one.
It's going to have its own sort of deployment way and its own way to, I don't know, extract dependencies or whatnot.
Well, yeah, it's just the pad, like, oh, this is an old application.
We haven't upgraded.
We know it's end of life, but we have no resources to actually update this.
Right, exactly.
Either because it's external vendor.
External vendor, that's sunset it.
Or you just don't have the engineer resource internally to do it.
Yeah, exactly.
And that is sort of manageable when it's like the one odd out, you know, when you have like 10, 20, 30 microservices, but when you start to have like, I don't know, 70, 100, you know, 200 microservices, that's where something being weird is actually the norm.
There's always something weird in your infrastructure and that means you're going to have less ways to enforce proper engineering practices, basically, and security and all that.
Yeah, I mean, I had a Dustin Kirkland from Chain Guard on a few episodes ago and we talked about the whole thing of like rolling versus stable releases, which is kind of a tangential problem space here, which.
And he's a big fan obviously of rolling releases and like you deprecate things as they get deprecated, which is absolutely best engineering practices.
I don't think anybody could make an argument against that.
Well, I'm sure people can, but like, rational is very sensible.
But it does create that problem of like, it's great if you have a good team with good culture, with good velocity, and you can just like, oh, let's fix it up.
But yes, many, if not most engineer teams do not operate like that.
Right?
Yeah, yeah, exactly.
Yeah, that's a great example.
And I think I, I watched that episode and he was saying like, okay, but now you have to upgrade things, but that's fine.
It's like, yeah, I forgot the analogy, but it sounded like, you know, it's either you break your legs and you.
Know, maybe to break your leg or things like that.
Yes, you still break your legs.
Yeah, exactly.
Yeah.
And it's spot on.
Right.
But like, the reality is that a lot of these positions are kind of held on a higher level.
Like in a lot of.
This is a cultural problem more so than a technical problem in many ways.
Right.
It's just like, yes, the budget is to shipping new features not to maintain what we have.
That's how most companies operate.
Exactly, exactly.
Yeah.
Whereas some teams may be more like, you know, like a library team or whatnot and they have to support the use of that library for many different applications in different ways and the decision might be different.
So, so like having this freedom to create your own engineering process is both good, that you know you can use the right tools for your job, the right practices and so on.
It does come with its downsides and you kind of need to have a good plan around, you know, managing those downsides.
Yeah, it's this constant like battle and you kind of need to not stop it.
We at Squeanly, we do what we call system tools week.
So we do two week sprints and then one week system tools, where that week is earmarked, generally speaking, towards like improving our internal tooling.
And you kind of need this time, but essentially generally speaking, because if you just jump from Sprint to Sprint and in small to mid sized team, you're never going to get around to fix these problems, Right?
Yes.
So yeah, yeah.
All right, so let's switch gear a little bit to culture, because I think that's something you spend a lot of time on, engineering, management and culture, which is kind of like.
Well, I guess it's a good segue over to that from that.
And we're both fans of remote teams and building and scaling remote teams.
So maybe let's kick it off there.
Like, what have you learned over the years building and managing engineering teams?
I'm really curious about your input and your thinking around that and what you've learned over the years.
Yeah, And I should preface this by saying that I've managed startup engineering teams, which is perhaps a bit different than FAANG type of teams, right?
Oh, absolutely.
Yeah.
Right.
But I think one of the key decisions as a startup is how do you find talent that is extremely effective and doesn't, you know, doesn't burn your Runway, you know, too fast.
And as a startup founder, you oftentimes, it's not as critical these days, but you oftentimes have to be in the Silicon Valley area to kind of have access to the investors.
For whatever reason, they see that as a benefit, like a dedication, your commitment and whatever.
I would say I used to be so more so 15 years ago or 20 years ago than today, I would argue.
But yeah, 100%.
Ever since COVID I think even that has changed dramatically.
but I happen to be here in the Bay Area and hiring here in the Bay Area is Like, extremely difficult.
You know, like these total compensation packages are.
Are wild.
Especially when they're.
There's, you know, the companies they work for have a certain stock that has been growing for the last few years.
It's not unheard of to have like 500k sort of total compensation.
I saw somebody done a comparison like on, I think, like, I think it was a Level 6 engineer at Facebook.
It's like a total comp is like a million or something like that, north of a million.
And it's just like, yeah, you can't compete with that as a normal company.
That's just exactly.
Yeah.
I mean, imagine, you know, seed stage startup might have raised, I don't know, like, say six, $7 million.
Like, does that mean for two years running away, I'm gonna just afford three engineers, you know, like.
Yeah, that cannot be right.
No.
Right, exactly.
So marrying that sort of requirement of having high talent but doesn't break the bank type of thing.
At my previous company at Shift Left nowadays called Quiet AI, I led the engineering team and with my colleague, the cto, we built a team from scratch.
And we looked internationally, mostly.
Right.
We looked one of the centers that we found our chief scientist and actually the person who ended up creating most of our secret sauce, if you will.
We were able to hire in Germany.
That's an odd choice.
That's not something you normally hear.
Like, usually people stay away from Germany because they have very tight labor laws and it's just very difficult to hire there.
That's true.
That's true.
I think it was not necessarily our top choice because of what you're saying, but also this person was in Germany and actually it worked out really well for us.
And so we built a team around this person in Germany.
And we also hired like about a third of our team was fully remote.
So there were people from like New Zealand or Argentina or Brazil and so on.
And perhaps one of the things I learned early on was that this sort of time zone scattering is extremely difficult to manage.
Even us, the central office here in the Bay Area versus Germany, the time never overlapped.
Somebody had to make a compromise to be able to get on a simple meeting.
They had to stay up later or we had to get up earlier.
That created echo chambers.
We were not aligned from the product standpoint.
In some ways.
You have to find ways to work around that and be able to collaborate better this time around.
As I built the new engineering team here at Earthly, I knew that we had to go remote because of that sort of cost aspect.
But at the same time maintain roughly the same time zones.
Right.
And the prices for engineers are not as good here, sort of in this time zone as they are in Europe.
Basically.
In Europe you get half price, essentially, which is like crazy, right?
Yeah, sounds about right.
Yeah.
Whereas here you still have to pay significant amount of money for the top talent.
But it allowed us to be within the same time zone.
Especially in a startup where the product definition evolves very quickly, you have to be constantly in sync with the engineers.
I think that's key.
I think if you want to manage a remote team, you have to have a very stable and very well defined API between that team and the rest of engineering.
So for example, a great example I've seen at another company was they had the payments team in Turkey, for example.
Right.
Then payments is kind of like, okay, you know, you have to kind of swap for credit card.
You just have to support all these different countries and integrate with Stripe and a bunch of other vendors and so on.
Yeah, but it's kind of like a well known entity.
It doesn't have like dynamic product requirements.
And I think that tends to work really well if you can have that sort of API between teams.
Otherwise I personally prefer to kind of have teams centralized from the time zone perspective.
But also we're embracing the full remote culture.
And when you embrace the full remote culture, you also have to have frequent off sites.
You have to kind of get together frequently and be able to kind of get on the same page.
Sometimes our thinking and ideas deviate over time, even if you have like daily standups or weekly standups or whatnot.
And that kind of helps get everyone on the same page and sort of revitalize the energy of the team and so on.
100%.
I agree with the off sites.
When we started doing that about almost a decade ago, like the culture ship was so phenomenally different.
Like you could just.
It's just so different to have an interact with somebody, even if it's a video call, versus sitting down, having a beer with somebody.
Like you get to know people at a completely different resolution.
Right.
You understand like the nuances and that helps smooth things over a lot more when you go back to a video call once you've had those face to face interactions.
Right, exactly.
And the key thing is building trust.
Right.
It's a bit harder when you're a remote team.
You have to rely heavily on async type of communication, written documents and all that.
And that trust element is sometimes lost in the communication there because you're brief, you Kind of directly say what works, doesn't work or what things to be different and people might perceive that negatively or like adversarial if you will.
Right, yeah.
Whereas in person there's more nuance.
I'm a big fan of team bonding.
So one of the first things we do in off sites is just spend the day hanging out, you know, like.
Yeah, doing non work stuff.
You know, we actually put that as the first day, the fun day.
You know it's funny because a friend of mine reached out because they were doing the first stand up first off site for his new company and he was asking me like what my experience was like and actually very much to your point.
To me the first day is a write off because it's just obviously we travel all that depending on how many times but beyond that it's about getting together and just like even as a manager, like, or leader, see how the dynamics happen organically within a team.
That's super important as well.
And see how other people, how the teams interface with each other as well.
Yes, exactly.
That was like one of my first, like make sure it's at least three days because less than that is just pointless in my opinion.
And first day and last day write offs because like first day of arrival, people tried, people have been up early, like it's not going to be a productive day.
Last day of travel, same thing.
Like people get ready for the airport, people have different flights.
At least three days would be one day of actual productivity.
Exactly, exactly.
And like being locked in a single room for, I don't know, eight hours in that single day is also exhausting.
So you kind of wanted to use that energy with a lot of intentionality, I guess.
Yeah, 100%.
So there's a lot of like, I guess definitions around these, like remote first, remote hybrid, all those stuff.
Right.
And now obviously now we get to see the, the boomer way back to the office and all that stuff.
But that's a whole different conversation.
But I guess you guys are not really remote first because you do have an office as well.
Or, or do you consider yourself entirely remote first?
No, actually at this new company we no longer have any office and we never had an office.
We started at my previous company.
We did, were hybrid.
Right, okay.
And perhaps this other lesson is hybrid is actually much more difficult than fully remote.
Yes.
Because there's going to be like, you know, like people talking in the office about certain things in person, making decisions, moving fast and then the rest of the team is like, okay, but wait, what happened?
We talked about this other thing last week.
You have to now catch me up or whatever.
You know, so much always left behind.
We've coined the phrase.
It's the water cooler effect, right.
Where it's informal communication that happens in an office.
So we try to mimic that in Slack essentially, like have a water cooler.
Like sometimes it works, sometimes it doesn't.
But it's like it's not quite work, but it's stuff that would happen in regular work environment, right?
Yeah, yeah, exactly.
There's a trick for.
We use this.
You have like a little schedule, like a rotation.
Every person asks an interesting question per day in the water cooler channel.
And we found that sparks like interesting conversation that would otherwise not happen because otherwise we're kind of focused on work and like, yeah, you know, nobody wants to talk about, I don't know, cats or whatever.
But if you ask like informal questions that about something fun and every team member comes with something every day, it creates much more sort of engaging conversation.
It's not necessarily about catching up on work or anything.
It doesn't necessarily solve that problem, but it solves a little bit of the trust problem that perhaps is often missing in async communication.
I mean trust is such an important piece here.
I wrote a blog post that made its way to Hacker News a while ago about a decade of remote work.
So I basically captured what I've learned or doing like remotely for a decade.
But one of the biggest things is kind of.
We already touched on the first one being either you go all remote or you all in office.
I think hybrid is kind of like an illusion because.
Yeah, it's just this particular about documentation.
It's a big one.
Like how do you document things?
Like if you're a remote first company.
And obviously there are plenty of good examples, GitLab being one of the good ones about this.
Right?
Then you have a documentation culture is different.
Whereas if you're a kind office based company, there are a lot of like unofficial ways and like wisdom like are spread by asking people walking over to their desks, right?
Yeah, yeah.
It can get a bit political too because like you know this person better than this other person and you're gonna talk with that person about, you know, the requirements or you know, the goals and whatnot much more than this other person.
So there is subtle ways in which you accidentally empower more people differently across the team.
Plus I think there's with this new RTO return to office sort of thing that's Going on right now.
I feel like companies are the norm is now hybrid, which is kind of bad, right?
I mean honestly, in the office and so on is like somewhere.
Honestly, the RTO thing is just a big mass firing in disguise.
That's really what it is, right?
That's, yeah, that's, yes.
It's not like, yeah, I, I don't believe in it.
I think it's just people want an easy way to weed out the people who are not as dedicated and that is NAR policy is like, okay, cool, 20 plus people don't want to come back.
Cool fire dude.
Done.
Yeah, yeah.
The sad thing about it is like a lot of times you're going to weed out the people that perhaps have kids or something.
Like it's a bit of discrimination in disguise.
I, it's, you can't really put your finger on it, but it is going to sort of affect different people differently because of that.
Oh man, I, I, there's no way I'd have a desk job where I had to go and commute in every day.
Like no way.
I would never do it.
I've done remote now for like what, 15 plus years.
Like there's no way I'm going to allocate an hour plus a day commuting.
Like there's no way, like it's just a way better way to spend that time.
So.
Absolutely.
The other thing you mentioned that I have the same kind of observation as you have is trust when it comes to remote.
Right.
The trust is so difficult, but it's kind of like the whole agree up remote.
Because if there's no trust like things, there are a lot of cultural implications of that.
Right?
There are a lot of things.
But speak to me about how you view this and how you've kind of building accountability and like as part of this.
Because remote is difficult, right?
Because yeah.
The one thing you could say about an office is like, oh yeah, you showed up cool.
But you can't quite say that about somebody working remotely and Right.
Oh yeah.
Like how do you measure people and make sure that they're actually at work?
Right.
And yes, and there have been so many bad takes on this, you know, like spying on employees, computers, making sure they're like moving their mouse or whatever.
Yeah, yeah.
I think that's bad.
Right.
If you get to that point where you have no idea if your employees are productive, you're not measuring your employees properly.
Properly.
Right.
You should be measuring them on output, not on activity.
Yeah, that's so much so true.
Right.
Because like one of the things that I, I'm fully on board with is like if my people are working remotely, I'm okay with them going and doing things.
Make sense.
If they want to go and get their haircut at like 2pm on a Wednesday and they have no other meetings, like, go ahead, like, why not?
That's fine.
I don't care.
Like just as long as you get your stuff done.
Right.
Whatever.
Yeah.
And the way I've also talked to remote teams about this is that, hey, you can take your kid to daycare, do your haircut, go shopping, whatever.
You need to be flexible.
And occasionally we will ask for you to be flexible for us.
An incident on the weekend and whatnot.
Two way streets, so.
Exactly.
We, we don't typically ask that many times, you know, but I think everyone would prefer if that were the case more frequently than not.
Right.
I started my career actually back in Romania where post communist country, perhaps the culture was much more based on measuring activity as opposed to output.
Kind of like you were doing communism regimes.
Exactly.
Low trust and all that.
And so I just took it for granted initially.
Oh, it's nine to five, I really have to be, if I'm late by five minutes, I have to kind of put that in the system and all that.
I now found it extremely ridiculous that many companies have just continued that way.
Not just in Romania, but in the western world a lot as well.
Right.
But I think that's a boomer mindset.
Right.
It's like, oh, but in the desk.
But like in the chair at the desk, like that's more important than what you get as output, right?
Yeah, yeah, perhaps.
Exactly.
And I think there is something to be said about hiring the right middle management and lower management teams.
Right.
If, if those teams are unable to properly measure the output of their employees, that's a much bigger problem than your ICs not working or your not being able to trust them.
Right.
So I'm a fan of hiring people that are self sufficient, that they can be the kind of like the CEO of their own jobs.
Right.
And trust them completely on what they execute on and work with them sort of on results and outcome and such as opposed to, yeah, you know, the nuts and bolts of like, were you, where was your butt in the seat at this time and whatnot.
Yeah.
This is interesting.
Right?
Like, and have you, is there any framework that you adhere to in terms of quantifying these things that you found working better than others?
We don't have like a very formal framework, and I think that would be kind of natural for a small company like ours.
I think at scale you probably need some sort of framework, but it's probably similar to career ladders and such.
You know, you typically have performance reviews and you measure people based on what they were able to achieve and such.
I think those are great on their own for the measurement of, you know, was this employee present at work?
Sort of from the execution standpoint and less so, you know, other sort of information.
I've seen big companies, though, insert things like, you know, badging data and computer activity data in their performance review.
I think that's kind of backwards.
Yeah, yeah, I'd agree with that.
There's.
There's a framework that I kind of like, which is entrepreneurial operating system.
They have like.
They have like three very simple questions for like, performance reviews.
It's funny because I was working, literally working on this today, so it's fresh in mind.
But they have like, can you do it?
Do you have the capacity to do it?
And do you want to do it?
Those are like the three main questions, like, if you can, like, those are good determinations of, like, is this a good fit for the role?
And if you're delivering it.
Yeah, it's very distilled down.
The simple.
Yeah, that makes a lot of sense.
I think those three questions are probably the.
The best balance.
You don't want to create like, you know, a review system that takes everybody offline for a whole week or something.
Yeah.
And you still want the data from it.
You kind of have to balance the sort of precision and number of questions and all that.
Absolutely.
Is there one lesson that you would say for somebody who's new to managing a remote engineering team that they need to get, like, what's the one advice you would give them?
Great question.
I would say I can think of two or three here.
So one I kind of already mentioned, which is think about time zones and how your teams are going to collaborate.
Right.
I think that's critical.
The other part of it is perhaps how do you work together and managing the async sort of communication style and being fully bought it into that style.
Like, default to documenting decisions, default to reviewing design documents, default to relying on GitHub comments and Slack messages as opposed to word of mouth and such.
This is kind of like a muscle.
You have to.
Maybe it's a bit unintuitive for someone who's new to this, but if you trust these, a few official tools, I Think that's also important.
Don't use both notion and drive and so on.
You have to kind of standardize on a limited set of tools and then any communication that goes through that tool is just as official as any other channel.
Right.
And investing deeply in that is really important.
So I think that's perhaps my top two sort of takes on remote work.
Fair enough, Fair enough.
All right, let's switch a bit more gear to something that is kind of more back to your story before, which is AI in the pipeline, I guess, and more specifically in the sdlc really.
And I, I'm curious about your take on that.
Like I, I foresee a world where AI will write code and AI will review code and then we have agents talking to agents and then there's probably some human loop somewhere to review and make sure that nothing crazy is going on.
But talk to him more about how you see that shifting given that you are deep inside the STLC world.
Really.
Yeah.
There's a few ways this could go towards.
Right.
And I think it's hard to really predict the future, but I can think of the far future type of system is where they're no longer software engineers, they're more like PM's writing prompts.
Right.
And iterating with a system.
And it's sort of all taken care of behind the scenes.
Perhaps in such an environment there's more reason to standardize the tech stack.
Like if the AI is going to write everything, why not write it in a single programming language?
And maybe it's like extremely geared towards AI type of workloads.
So maybe it's still transparent so you can see and audit the logic behind the scenes and so on.
So it's still human readable, but it's not as necessarily as diverse.
So that's one possible option.
I think in the short and medium term there's going to be a lot of hybrid work between human and machine, if you will.
And in this hybrid work, kind of like with self driving cars, the problem would be so much easier if there were no humans on the street.
Right.
You couldn't have beacons and we have no car accidents.
Exactly, yeah.
And the uncertainty of it all just goes away tremendously.
Right.
And that is kind of similar with AI.
Right.
You still have to rely a lot on human engineers and this might be the norm for a very long time for all we know.
We have no idea how fast it's to evolve.
Right.
And in this short and medium sort of time span we probably need to treat computers with the same care as sort of an engineer to some extent.
So either that way you say like, you know, an AI agent is an engineer and you apply the same principles.
Somebody has to review their code, you have to scan their for their stuff for vulnerabilities, you have to enforce engineering standards and so on.
And so that's one way to see it.
Or perhaps the AI is like an extension of the human and everything the human authors is with the help of AI.
I think that is where we are right now.
Right.
And the human might be a little bit sometimes careless about what the AI introduces.
And for that reason you need even more verification on top to make sure that no strange things have been introduced, no vulnerabilities have been sort of added to the code base.
Maybe whatever training the AI had was a bit out of date and using old dependencies or whatnot.
Exactly.
Right.
You want to make sure you're not sort of behind the curve of what security today is in terms of dependencies and all that, or engineering practices that are specific to your company.
So I think in the short term there's much bigger need for this kind of guardrails and verification and making sure everything is abiding according to engineering standards and security standards that you want to enforce in your organization.
So yeah, I think over time we're kind of learning as an industry how to manage all this.
But definitely it's a huge shift that is perhaps changing our mindsets the way we think about SDLC and all that.
Yeah, I mean, I'm a big subscriber of your first vision.
Right.
I think engineers will essentially become managers of AI agents.
Right, right.
And, but this is the important part because I'm sure you saw this broke this week as were recording on Twitter, this guy who wrote some Microsoft, wrote some Sauce product and that is like, oh, holy shit.
People are injecting stuff into my database, they're bypassing payments.
I have no idea what this, my code base does.
And it's like he was a non engineer who written some piece of software using Cursor, essentially, or the likes of Cursor.
Right.
And it's just like there is a scenario where we will have these AIs who can write good enough code autonomously that a non engineer can manage.
But I think that's pretty far out, right?
It is, it is.
And going at it with a naive mindset like I imagine a non technical CEO is going to assume.
Okay, we have to kind of heavily rely on AI now to be efficient and they're going to just create a lot of chaos, you know, because like that AI is going to write stuff that is pretty much a black box for everyone else.
And it's going to be riddled with vulnerabilities and like duplicated code, no logic complete.
That's the funny thing.
Like if you think about logically, it's probably cheaper for an LLM to write new code than to maintain existing code.
Oh yeah, 100%, yes.
So it will.
It's just got to duplicate everything like a third time, right?
Yes, yes, exactly.
Yeah.
So I had this conversation with some friends a few weeks ago and I'm basically like, my big bet is that in the next 12 months we're going to have a lot of these companies that managed to build a product, manage to capture revenue, and then they realized they have no idea how the price written, what it does behind the scenes.
It's completely a black box to your point.
And then they're gonna, well, they're gonna be in for a world of pain and there are probably gonna be a lot of people who gotta make a lot of money trying to savage the disaster that is their code base.
Oh yeah, oh yeah, exactly.
And catching up from that, you're just kind of digging a hole for yourself.
And getting out of that hole is going to be very expensive at the end of the day.
Like the original goal might have been to save money, but you know what, it's not actually going to work out that way in the long term.
No, I mean there's an argument that is that, well, these product would have not existed otherwise, so therefore it's a net benefit.
But you can still, like there is probably like a happy medium.
Like you still need like AI is not going to replace engineers anytime soon.
It's going to 10x good engineers, but it's probably going to hurt shitty engineers.
Oh yeah, exactly.
And a lot of companies that are not engineering culture first, you're not necessarily seen as tech companies.
They happen to depend on tech.
Just because just about every company on earth nowadays depends on tech.
And having an engineering team in house, I feel like those are the companies that are gonna suffer more from this, you know.
Yeah, it's really hard.
Even in today's market where, you know, people are laying off engineers like crazy.
Even today it's still hard to get top engineering talent to kind of drive engineering culture properly in all these organizations.
And yeah, they're gonna be in trouble.
Hopefully, you know, it's.
We will manage as an industry.
But the writing is on the wall.
In some way, 100%.
And if you.
Actually, for me, I think if you follow the money, you get very close to the truth here.
Because the people that are most bullish and most vocal about this, like, oh, AI.
All code written by AI in the next five years.
Almost everybody who says makes those bold claims are either writing tools that are writing or in the AI ecosystem and directly benefit from it.
Or there are people who want to basically slash your entire engineering budget and not hire engineers.
Right?
Yes, yeah, exactly.
One of these two visions is kind of crazy in the short term.
Yeah, yeah, exactly.
No, it's, it's going to be an interesting ride.
I mean there is a scenario where the LMS and the tools will catch up and by the time this disaster of a tornado will hit the tools, we're good enough to fix themselves.
And that's a possible scenario.
I guess we can't rule that out.
Yes.
And in case.
Fantastic.
And maybe that was the right bet then.
Yeah, exactly.
It's like that, yeah.
The curve of like, you know, intelligent people making one decision and like.
Yeah, yeah.
The average.
It's like there's going to be a decision that makes sense for the most intelligent and the least intelligent ones and if that comes to become the truth, it's going to be interesting.
But yeah, for now I'd say from my perspective, I would be more careful than.
Yeah.
The immediate current state of affairs with AI feels like not ready yet.
You know, you can sort of create demos where you build from scratch with AI and sort of have mini games and such and they're maybe bug free mostly and they're safe, that's fine.
But managing something bigger than that, it's just not real yet.
I would challenge a little bit because I think Cursor and the likes of are fantastic at doing busy work and just like refactoring busy work.
Right.
Stuff that would take you forever to do.
But it's not super complicated.
You can describe it easily.
Where they struggle is when things gets too complicated.
Right.
Because the context window is just not big enough to.
Yes, it's not there.
Right.
Which is why they just rather write new code than actually refactor the existing code.
Because it's too expensive to read in all the context.
Yes, exactly.
Yeah.
They're just not going to follow all the requirements and maybe that will be surprising.
You have to have strong tests for all the requirements and all that still takes a lot of work.
Yeah.
And not the security is crazy.
The amount of times I've had cursory.
It's injecting and editing a lock file and managing dependencies.
Like, whoa, hold on a second.
Don't just change things.
But yeah, like it's, it's a crazy world.
But I mean, I'm still bullish on the fact that this is gonna be a net benefit and there's no, I mean, I'm 100 sure there's not benefit.
Right.
It's just, I think it's too naive and there are too many people that are too naive about what things can do today.
It's just like, yeah, they will be able to do at some point, but we're not there yet.
Today.
It's a tool that allows good engineers to better but not non engineers to become engineers.
That's the other thing I'm wondering as well.
What does the next generation of engineers, what does that look like?
Right, because there's less need for the junior engineers.
Right?
The AIs can do a lot of that.
But now there's going to be maybe like a skills gap because those junior engineers will not become senior engineers.
Or maybe they're fine on the trajectory that maybe AI will get better faster than they would anyway.
So maybe there's less need for senior engineers.
Well, I mean, I would argue most likely there's less in need for junior engineers.
Right?
And I mean this is a fantastic point, right?
And I've done a lot of hiring over the years and one of the things I have been surprised by, I mean, I'm getting old, but I'm hiring fresh grads these days.
Like, I'm surprised by how many of them do not understand fundamentals anymore.
Oh yeah, yes, right, exactly.
Like, because the CS education, okay, there are the good schools, like there's the Stanford of the world and all those, of course they have like world class engineering schools.
But for the bulk volume of engineering schools, like I've had like people coming out of CS program, like you have to teach them how to use like git.
And it's like, what the hell have you been doing for the last four years?
Exactly.
There's so many abstraction levels that make things so much easier for us, the engineers that we kind of forgot where we came from.
And now that's a knowledge gap that is gonna affect people, I think.
Yeah, because I would imagine we're like roughly the same age and we grew up in, grew up using like Linux early on.
Like you grew up learning a lot of those things by doing and Like I have no CS degree but I've schooled CS people a lot because just I've been exposed to it for so long.
Right, you just learned lower level stuff by virtue of playing around with it.
Right.
And that's.
Yeah, that knowledge gap is very real today and I think it's going to be even.
It's going to be 100 start in like 5, 10 years.
Right, with these level abstractions.
Yeah, yeah, exactly.
You're going to be building with REACT or like AI agents and so on and you have no idea how HTML works or HTTP.
So like yeah, today, yeah.
Whilst today we're like annoyed that new hire newer graduates do not understand like the Linux kernel or whatever.
Like that's going to be like move like five level abstraction further and they're like it's going to be so high level that the Linux kernel is like Cobalt to us essentially.
Right, yeah, exactly.
Yes, yes.
Because yeah, you could argue the previous generation are complaining that we don't know how punch cards work or whatever.
Right, exactly.
Yeah, yeah, it's an interest analogy.
but this has been super interesting.
I think we covered a lot of good ground here and I'm very happy about what we got covered.
So thank you so much for coming on the show.
Before we wrap, are there any closing notes, any shout outs you want to do people want to learn more about Earthly or so on?
Yeah, well, thank you for having me.
And, and yeah, if you're interested in improving your engineering excellence, your engineering standards or managing SDLC at scale in your organization, check out earthly.dev dev and yeah, hit me up.
I love to talk to you.
So many thanks Victor.
Amazing.
Perfect.
Thanks for watching bud.
Have a good one.
Talk soon.
Cheers.
All right.
I think we covered a lot of ground though.
That was, that was actually really good.
I think it was a lot of good stuff there.
This episode will go live not the next Friday, but the Friday after I think because I have another one that I need to pipeline before that is very timely but sounds good.
Found an error or typo? File PR against this file or the transcript.