# Software Engineering Laws: Strategy, AI, and Organizational Impact

**Podcast:** Tech Lead Journal
**Published:** 2026-08-10

## Transcript

I see that no one is thinking, everyone is doing, but you can't build real stuff without thinking.
Today's guest is Milan Milanovic, author of Laws of Software Engineering.
56 laws and principles collected from real software examples, already read in 74 countries.
Speaking about laws, some people think it's all about architecture, design, coding principles, but actually you have something more.
What we think in software, we really think that everything is technical.
But what we figured out during my own career that software failures are really purely technical.
There's the trap of using AI and it ended up with complex systems or complex code.
Complex system that works is always fun to have grown from a simple amount that works.
Don't just try to produce something because you can now easily produce.
Optimize for judgment, not out.
Writing code is of course our main thing how we solve problems, but not the only thing.
If you can solve problems without coding, that's the best thing.
So no code, no problem.
Tell us more about good hard slow.
This is also something that is quite timely and relevant to talk about.
When a measure becomes a target, it stops being a good measure.
The moment you measure AI output, people optimize that metric, not the outcome we want.
We also saw this token maxing, where some companies try to say like more tokens, the better.
People talk about, I can use AI and it just runs by itself because people assume things will be easy.
Let's talk about downing career effect.
It says that people with low...
ability in her tasks overestimated while experts underestimate themselves.
And when we bound this to AI code generation, people now ship convincing looking code they can't evaluate because the tool hides the gap in their competence.
Thanks for being here and let's get back to it.
Hello everyone.
Welcome back to another new episode of the Tech Lead Journal podcast.
I have a repeat guest today.
Very excited to meet Milan Milanovic again.
So I checked earlier today.
I think we did an episode almost two years ago.
So that was about, you know, how to become a great software engineer and all that.
Milan actually just recently published another book titled Laws of Software Engineering.
I think it's a very interesting topic, right?
Talking about laws of software engineering.
For some of you, maybe you may have heard a few laws here and there.
But Milan actually came up with 56 laws in his books and even published it on the website.
So we'll talk a lot more about these laws.
Are they still applicable in this AI era?
And yeah, welcome Milan to the show.
Looking forward for this exciting topic.
Thank you, Henry, for the invitation.
So we meet again to talk about this, I would say.
interesting topic and topic that will be with us for many years to come.
Yeah.
So Milan, let's go the first place, right?
What made you write this book, right?
What's the background, right?
Especially when everyone is talking about AI, you seem to go back to the root of all things, which is talking about law of software engineering.
Yes, exactly.
Well, I...
probably as many others in our field of software engineering learned some of these flaws in their careers.
When you start as a junior software engineer and then rise up in the ladder, you fail a lot.
And some of these failures are actually described by some of these flaws.
I was always impressed when I figured out like, okay, this thing has a name, so someone like 20 years ago named this problem I have now, and I started to collecting them.
For some things I didn't have long names, I had my explanation of the thing that happened, but during the time I slowly tried to put this on the paper.
Then I saw that also many other people did the same, so they also collected these things.
Some things had names, some things didn't have names, but in the end, when I started to, like, when I decided to start working on this book, because I thought it would be worthwhile, I researched it, like, a lot on this topic and figured out that, like, there are like a lot of these laws scattered all around, but not on the one place.
And so no one could sit on one place and learn everything about them that should be learned.
Yeah.
So when you talk about failure, right, I also remember, you know, myself learning some of these laws.
Definitely no one taught them in the university.
Maybe some lecturer would have mentioned it, right?
But it's like nothing in the theory book, right?
But whenever we learn from...
our career, our experience, some of these laws is actually kind of like, wow, very insightful, right?
Someone already figured it out.
And yeah, it has a name, which is something that is also interesting, right?
So I recently also seen your post that your book has been sold, a thousand plus copies, right?
For like 74 countries around the world.
This is something quite unique in my view, right?
So there's still a lot of people interested in these kind of topics.
So tell me more about your wide reach of audience here.
What do you feel about that?
Yes, I analyzed like a book, like how it's selling the first two months and it was like 1,500 or more copies in 74 countries.
Like that number was not like...
Interesting, but the number of countries was on one side, but on the other side, maybe it is not, because many of these laws are the same in all countries.
So it doesn't change from San Francisco to London or Bervet or Singapore.
So they hold their ground in all countries and in places.
So from that side, I think it could be expected.
Yeah, nice.
I think it's very true, right?
These laws wouldn't change based on your location, your language, software, programming language and things like that.
So I think, yeah, congrats for that.
So one thing that I would like to ask before we maybe go into some of these laws, right?
How should we actually use your book, right?
Is it like a dictionary?
Is it something to read cover to cover?
Like, how do you advise people to read and use your book?
Yes, my recommendation is like, because Many of these laws are like on a different level of abstraction.
So someone on the team level, someone on the architecture level, someone even on code level, on like people level, so on different levels.
So you cannot know all of these laws in your head.
There are 56 laws, but there are more like than 60 or even 70 principles, different.
like smaller patterns and principles which are part of these laws.
So my recommendation is to read the book once so you have a grasp of like what can happen, you know, on these different level of abstractions.
Then when the like when the problem happens tomorrow or some issue you detect, you will remember, aha, I saw this, this is a dead law.
Then you go again to the book or my website and then check the details.
There are of course more details in the book.
How to better understand this problem and how to resolve it in a proper way.
Yeah, so I think for those of us who have been around in our career, I think some of these laws are definitely very interesting.
But for those of you who are new, maybe in the software industry, you may...
never heard about these laws before, right?
I think my advice also would be to just at least walk through all the books, right?
All the title, maybe the summary.
You put actually a good summary at the beginning of each of the law.
So at least you kind of like resonate with some of them.
So speaking about laws, there are 56 or maybe more, right?
Like you mentioned, right?
But what I'm interested in is the span of categories.
So it's not just like when we talk about laws, maybe some people think, oh yeah, maybe it's all about architecture, design, coding principles, and things like that.
But actually, you have something more, right?
You talk about teams, you talk about planning, you talk about scale and making decisions.
So tell us why there are so many wide variety of categories talking about loss of software engineering, right?
Yes, exactly.
What we think in software, usually, especially when we are starting in this field, that everything is technical.
So we are only interested in technical stuff.
But what I figured out during my long career, that software failures are really purely technical.
So one production incident can lead to organization chart or to metric or even to some kind of a bias that happened.
So the book tried to reflect that in a way, like architecture decisions constrain people decisions, and then these people decisions move timelines that we have on projects, and then these timelines force quality trade-offs.
So people try to build complex systems under limited time, knowledge, and coordination.
So you need actually...
all these laws about people, math and organization, not only technical and code stuff, you know.
Yeah, so many people have mentioned about it.
Software engineering is a socio-technical thing, right?
So it's not just the technical aspects that you need to think about, but it's also the social aspect like people, you know, project management.
I think that's always...
You mentioned something that's also quite insightful to me, right?
So many of the software failures, software project failures is actually not because of...
just purely technical, right?
So it's like in the people aspect, right?
Maybe in the making the decision, putting something that is probably not like too complex for the state of the project at that point in time, right?
So I think some of these definitely very, you know, very exciting to cover some of them.
So let's go into some of your favorites, probably.
Any one that you would like to pick first as the law to cover?
Yeah, there are like a few.
that I like the most because I think they are, they exist almost in all projects or the way how we try to work in this field, at least until we understand them properly.
The first one is Gauss Law, let's say like complex system that works is always fun to have grown from a simple one that worked.
So I took the example of Instagram in my book, where Instagram was like first some kind of a check-in service with gamification but the thing was that this thing didn't work properly for founders and then they took one small thing that was like image sharing and built Instagram for that.
So from there.
So they started from a small thing and then build up the rest later.
In software engineering field we had similar thing in previous years with this microservices movement.
Everyone started to put microservices in all projects even though probably most of them didn't need them.
So Galt's law say like start with the monolith network, start with simple thing and then split of pieces when you already understand them.
The same thing is with the AI now.
So you can now generate a lot of code, a lot of complex systems, you know, but this is the trap.
So generated complex is still a rest of our assumptions.
Nobody validated.
So we saw a lot of generated stuff, but still we didn't saw some great software in the last few years that happened to us, you know.
Yeah, so it's very interesting law, right?
Gauss law, right?
So almost every working system, right?
A complex system actually start from something that is simple, right?
Is this something also quite related to the premature optimization thing?
You know, like the root of evil is like premature optimization.
The root of complexity, sorry, it's not the root of evil.
The root of complexity is like premature optimization.
Is that also something similar?
Yes, exactly.
This is similar, although Donald talked more about the code, but this is more on the front side, I would say.
But it is the same.
So don't overcomplicate from the start, start simple.
They're more or less talking about the same thing.
So if you try to create a super complex thing from the start, you will probably fail, you know, because there are too much unknowns in building super complex stuff.
from the start.
So building the small thing, and this is actually directly bound to MVP approach, which goes well with that.
Start with the simple things, build a small MVP and then build up from there.
Don't build like something really big from the start.
Yeah.
So I think we all used to hear about all these microservices versus monolith debate, right?
Although maybe lately it's less prominent on the internet simply because everyone just talks about AI.
But I still remember, you know, we all have this passion about, you know, certain technologies, certain complex systems, right?
And we tend to use that.
So speaking about AI, you mentioned there's the trap of using AI and it ended up with, you know, complex systems or maybe complex code in the first place.
So how would you advise us to actually apply this Galslow and using AI?
Is there some tips maybe that you have tried?
Yes.
Regarding AI, I wrote recently about that.
I think what is more important is not like big production of code.
Like I see everyone is like, okay, I'm using 10 agents, 20 agents, 30 agents.
So there are so many agents working all the time.
But where is the judgment?
And we need to have the right judgment, you know, what we want to build.
And also to validate...
what was built by those agents.
Is this like something really valuable for us or not?
And like some of these laws are actually, including golf law, talking about that.
Don't just try to produce something because you can now, you know, easily produce, which is like a nice thing for all of us, but we need to have like more, more...
shift now toward the other side, like from how to why and what, you know, just to think more on that side, on the thinking side.
I see that no one is thinking, everyone is doing, and there is always problem with that.
I heard that from one of my CEOs once, who said to me, like, why is he doing these operational things?
Because when you're doing operations, you cannot think, you don't have time to think.
and this is somehow somehow that uh it is like i uh i was also find out uh that in this way no one is thinking everyone is building but you can build great stuff without thinking this is just you know my two cents on this all ai movement yeah yeah especially um people who love vibe coding right uh or using multiple agents right like what you mentioned or even like one shot an application you know like I don't know, build a game simulation of blah, blah, blah.
And AI just came up with the program altogether.
So I think definitely if you just write it once, you know, and use it once, probably it's okay, right?
But if you try to evolve it and make it a successful product, I think it takes more than just, you know, using AI to do that.
So I think, yeah, it's very, I would say it's very timely to mention about this, right?
Because we all focus on building.
you know, asking AI, prompting AI, thinking about what's the best context engineering, prompt engineering, loop engineering and all that.
But thinking about the what and the why I think is still important.
So let's pick the second law, any law that you want to cover as well?
Yes, I mean, we must mention Coway's law.
Let's say like organization ship systems have copied their communication structure, which means like your organization shape your software architecture.
So if you have four teams that build compiler, they will build compiler in four passes.
So the organizational chart shows up in their architecture.
In modern frame, when we are talking about microservices, which we mentioned, so microservice boundaries mirror the team boundaries.
And there is this thing called the reversed command maneuver, means that you can change the team's structure first, and then you get the architecture you want.
And this is not changed in AI also, because it can be human or AI agent.
So if you build a multi-agent system with a separate agent, like they have some handoff contracts, the system creates around those handoffs.
the same like microservices bends around team boundaries.
So whoever owns the planner agents versus the, you know, executor agents builds boundaries that mirror their own organization.
So here Conway runs twice, so human organization shape agent topology and then agent topology shape system output.
So we should always start with the question, what actually...
what kind of architecture we need and then when we define this we need to restructure our organization to be in line with that on our project because this designed the ownership and communication structure first and then our architecture will be enabled by that organizational structure.
Yeah so I think Conway's law is Like, I still remember Von Vernon mentioned it, it's like a law of gravity, right?
You cannot run away from it.
So I think especially to me, I think you can only learn it in the hard way, right?
In your project, right?
But I think one of the most difficult thing about Conway's Law, although you mentioned about reverse Conway's Law maneuver, right?
So some people just started with the organization structure like it is, right?
So nobody actually attempt to change team structure because...
It takes a lot more effort, maybe changing the manager, maybe restructuring the team and all that.
It takes a lot more people to be coordinated.
So maybe what would you have as an advice for many, especially the big corporates where they already have a structure, they already build teams, they have managers, but they want to build a new product.
So what would be your advice here?
There is even a word in the HR department actually create architecture because of that.
Because they are involved in creation of organization.
What is my proposal is always to try to include also architects in organizational definition.
So when the manager tries to create its organization that will build software, also include architects there.
because they can also give useful insights on this topic and help to shape organization towards wanted architecture.
We want to, you know.
So this is for sure one good step for everyone.
This is my first time hearing, you know, involving architects, you know, in, you know, organization structure.
But I think, yeah, thinking about it, maybe it's not such a bad idea, right?
So having a software architect to actually help structure the team.
And speaking about AI, many people these days assume the team size will be getting smaller and smaller simply because now we have AI.
And that also means your organization structure will probably shrink.
And maybe any kind of a team will be just a size of, I don't know, like three, maybe two, seven kind of people.
This tends to create a smaller team size.
communicating, coordinating with each other.
Do you think there is such an insight as well about Conway's Law for teams that are kind of like generalists using AI to build products?
Is there something that is worth to mention here as well?
Yeah, I think it's like Amazon two pizza team becomes like Amazon one pizza team.
And I wrote about this in my book, In One of the Laws.
I think the thing will...
be the same as i mentioned with people and also with smaller number of people and with agents whom these people are using to produce software uh it will convey commies law will still hold so because uh everything we do and how we do in our organization will directly reflect to to our architecture so people need to have this in their minds when they start to working.
So this is for anything more than one person company, you know, it will always help.
Yeah.
So I also read somewhere and people talking about applying AI, right?
So think of it as if like you have everything from scratch, right?
And you design with AI.
in place, right?
Maybe thinking about agents, right?
Because if you still rely on your current organization structure, you would end up with the same number of AI agents, maybe, right?
Or AI systems, right?
So I think this is where Conway's law, again, is very applicable to this.
So the next, I would like to pick Goodhart's law.
I think this is also something that is quite timely and relevant to talk about.
So tell us more about Goodhart's law.
Yes, yes it is.
Goodhouse law is always around.
So it says basically that when a measure becomes a target, it stops being a good measure.
And we also see this now as we saw this like 50 years ago.
Before, we saw measures like lines of code that were like really a bad proxy in 80s and 90s.
But it is worse now because you have a model that writes 500 lines in a second.
So, the moment you measure AI output, people optimize that metric, not the outcome if you want.
So, it is important when you create some metrics in your organization to always pair it with some kind of a counter metric.
So, for example, speed against ability.
And then, you know, to always to check, can someone gain this, you know?
and would this game behavior still produce useful work?
So if that gaming produces garbage, the metric is dangerous.
The things that won't be the ones that generate the most code, I would say.
They'll be the ones whose structure isn't fighting their system, or who measure outcome, not output, which actually good hard flow said to us.
When we talk about AI, we also saw this in this token maxing, where some companies try to, you know, say like more tokens better for you, and then of course people always try to align their work toward that metric, they try to produce more and more tokens, but the real outcome, the real quality was not there, so they didn't achieve what the organization wanted, they just optimized on that a particular target.
Yeah.
So, I mean, yeah, talking about good hard slow, definitely we may have seen it from time to time, you know, in the software development world, maybe thinking about velocity, right?
You know, we used to talk about story points, lines of code always.
a classic kind of example people talk about Dora metrics as well and these days it's about token maxing right I think when we had the model like cheaper than today I think token maxing is like a very very applicable thing many people are like just ask developers to spend as much as possible on tokens but I think there's a little bit of pause simply because the AI model cost is rising at the same time right so I think good house law definitely is very important especially for leaders right Because leaders sometimes create these, I would say, like, I don't know, KPIs or part of the performance review, a metrics, right?
You mentioned about having a counter metrics or counter balance.
Any kind of a good examples that maybe leaders can use these days?
Maybe kind of like a best practice in the industry now.
Like, is there such thing?
I think we should always start from like, what kind of outcomes we want to focus.
So the focus should always be outcome, so not output.
We are constantly trying to measure outputs, you know, all these things we're now talking about are outputs, lines of code, number of tokens.
So, and what really surprised me with this token marketing is that like, no one remembered this good hard flow, obviously, because every time when we had such thing, it bounced back.
in the history of software.
And this is one of the reasons why I wrote the book.
So, we cannot measure things in software like this.
So, in number of things, you know, number of things produced will never produce a good value.
What will produce good value is like what outcome we want to achieve.
And did we meet this outcome or not?
We can say also, we meet in a timely manner with the right resources and in the budget and all other things, but not by measuring the number of futures, tokens, whatever.
This should always be in mind of especially leaders, as you say, because they defined and shaped this KPI structure and the whole organization.
Yeah, so definitely, right?
I think focusing on outcome is definitely this.
the most important thing, right?
But talking about it, right?
Because it is such a common thing in the industry, right?
Such anti-pattern that people always follow, right?
I think one of the difficulty, right?
It's just like people find it hard to actually measure outcome.
Maybe sometimes it's also a lagging thing, right?
You can only measure it after certain times, right?
And that's why people focus a lot on maybe output or proxy metrics.
Right.
So, yeah, this is probably one of the dangers because it's easier to just quantify and measure it.
So especially some tools actually also produce this out of the box.
So you can just use that.
Right.
So I think focusing on outcomes, maybe tell us like what kind of outcomes that is, you know, like we should measure.
Is it like business outcome?
Is it like technical outcome?
It can be either.
So I would always, like we should always start from impact.
What kind of impact?
we want to achieve.
So, okay, we want to be like the best company in the world in this way, or like we want to have like 5,000 users per month, you know, or we want, you know, whatever, what impact we want.
Then we translate this to outcomes.
What kind of outcome we need to achieve?
And for example, OPRs are good to define and measure the outcomes.
And of course, then comes outputs, you know, because they are connected to these outcomes.
They're fine, there could be like just indicators.
So, okay, I listen for these indicators, like these outputs, okay, we spent like this, we created this number of futures, etc., etc., but this should not be the key thing, you know, the key thing should be like what impact we achieved and this impact.
was actually the thing we wanted to achieve, you know, with what we did in our project.
Yeah.
So for any of the leaders who are listening currently, right, always remember this Good Heart's Law because once you set a certain kind of like metrics, right, people will just follow.
I mean, there's this phrase, right, people behave as to how they are measured, right?
So definitely, especially metrics that can be easily gamified.
I think in the industry, classic examples will be like code coverage, right?
Where you can exactly create 100% code coverage, but without testing anything, right?
Same thing with, I don't know, like with Dora metrics, you know, Agile, Velocity and things like that, right?
So always remember picking the counter metrics, right?
The kind of things that make sure the...
there's a check and balance between one metric and the other.
So I think definitely very classic Goodhart's law.
I always remember this whenever I become a manager, right?
So that I don't pick the wrong metrics to choose.
So I think looking at the list, I would like to cover the Hofstadter's law next because I find it quite interesting to discuss with AI.
So yeah, maybe tell us about Hofstadter's law.
Yes, Hofstatus Law was always with us, especially when Scrum started, because it directly impacted the whole thing regarding planning, estimations, story points, because it says it always takes longer than you expect, even when you account for the Hofstatus Law.
Why is this?
Because the software is a complex thing, you know, it's in the area of very complex things to build and we cannot, you know, know everything that will happen.
And it also goes in line with this rule called the 1990 rule.
Why?
Because, you know, let's talk about it now.
You have AI that...
like can generate or 90% maybe of code, that's the easy part, but then that 10% that you haven't thought about maybe in details are like integration, edge cases, testing, maybe writing docs and similar stuff, which could actually took the same amount of effort.
So if you planned like three days, it could be easily six days because you thought, okay, the biggest thing is creating this I will like, I need like two, two and a half days and then this half day for the rest.
But that rest could be the same size and same amount as this first part.
And this is exactly this 90-90 rule which nicely connect to host added law.
So we are not good at estimations and we need to take this into account, especially when estimating the complexity of software.
And of course, there are some countermeasures that we can do here, especially this to try to have this in mind when we plan and to have all of these buffers and things that could happen and that maybe happened in the past that could happen in the future.
But we need to have this in mind when we plan things or when we say that something will, you know, last for that number of time and etc.
Yeah.
So yeah, I think this is also again classic, right?
So I think it's quite funny.
It always takes longer than you expect, right?
Than what you estimate is quite typical, right?
And you mentioned like people, like you mentioned software is a complex thing, but many people actually assume software is easy, right?
Especially the so-called non-technical people, right?
And now these days, especially when people think about AI, they think it's even easier for, you know, writing or producing software.
Some people even think like you can just easily, you know, reduce number of people, but you can still produce a lot of things, right?
So tell us, is it still kind of like applicable about this law with AI, right?
Because now it seems like once you can churn out so many agents working at the same time, maybe you can have things faster.
You can be faster, but I think it's even worth that in force because you now...
cannot know, for example, especially with people you talk about, white coders, they cannot anticipate, you know, what will happen after they, you know, white cod something or when they create something.
How much time the other steps will take?
Because when you hit the wall where, like, maybe AI cannot longer help, maybe you can need to contact some people, need to do something manually, then these things, will hit hard, you know, hard back.
So, always, for this law in particular, I always say, like, we should always have these contingency buffers in our schedules, and don't be overly optimistic in planning.
So, we need to acknowledge that there is happens and the factors that goes into timelines and our expectations.
I find out that...
developers are always optimistic.
It will always be fast.
Now they are even faster.
But the things will have their stops in that timeline and then we need to try to anticipate those things and plan accordingly.
Developers are always optimistic and also try to delay everything almost to the deadline.
This is talking about maybe another law.
I forgot what's the law.
I think it's like Like when you have a deadline, right?
Everything will just finish closer to the deadline.
I think you have it as well in one of your chapters.
It's 92 year old.
Yeah.
Yeah.
So I think definitely this one, you know, when you make estimates, right?
Always have buffer, right?
So things will somehow go wrong.
Especially, I think, very importantly, right?
AI currently just focus a lot more on the producing the code part, right?
But like you mentioned, right?
There are other necessary things that happen when you want to, you know, produce.
software that works for external users or working in production.
So it could be integration testing, building deployment, security stuff, and all that, right?
Always remember there are so many aspects that you need to think about.
So maybe if we pick the last law, what will be the last law that you think will be great for us to cover?
Let's talk about Dunning-Kruger Factory.
It is like from the biases or behavioral section.
It's not like about the project times and estimations.
Maybe it would be interesting for people to know about it.
It says like basically that people with low ability have tasks overestimated while experts underestimate themselves.
And when we bound this to the thing we talked about AI code generation, people now ship like convincing looking code.
They can't evaluate because the tool hides the gap in their competence.
What we can do for sure is that we produce something.
So we produce some code, but we are not sure is that code good and how this thing will work when it hits real users or real infrastructure and the real world.
So we need always to take this into account and...
to be, especially when we are, you know, we don't have a lot of competence about something, don't be ignorant about some signals you are getting, you know, because our awareness grows faster than a skill.
So, learning initially reduces confidence only to rebuild it.
So, we need to, when you saw someone who is an expert in some field, you will see that someone is always talking about, you know, trade-offs, probabilities, like it depends, you heard about this probably, not confident about everything.
So, you know, and I think we have the same thing with AI.
I see a lot of people who say, I would say in the proper way, we still don't know what is the best practice, how to work with this thing, but On the other side, I see a lot of people who are like, okay, I just started to build this thing and I'm the world expert in that and I know everything about that.
And this is probably not true, because we are still new in this and we need some time and experience and production scars to understand these patterns, what works, what don't work.
And then we can confidently say what works properly and what don't.
Yeah, when you mentioned about that, I remember a few examples like on social media, right, where people talk about using AI, like especially if the tagline, right, see it's simple, right?
I can use AI and it just runs by itself, right?
Even they are selling costs for people to make money just by using AI running autonomously.
I think I remember this example for some reasons.
Yeah, this is probably quite applicable, right?
So people who probably less expert in a certain area, they think to, like, they overestimate what they can do.
AI definitely amplifies this a lot, right?
Because people assume things will be easy.
But yeah, speaking about experts, sometimes they also kind of underestimate.
Simply they want to know more details and get more confidence before deciding on something.
So I think definitely this is kind of like a bias, cognitive bias thing probably that happens in our mind, right?
So speaking about, you know, like...
maybe the software engineers who have been doing this for a long time, right?
And AI is kind of like a new thing.
What do you think, what will be your advice for so-called these experts, right?
Like people who are more competent about software engineering now that facing the challenge of, you know, learning AI.
Obviously, people will think, okay, I don't know anything about AI.
Is there any good tips that you want to give with the angle of this Dunning-Kruger's effect?
Yeah.
I think I see the other part of this story, it's imposter syndrome.
I would say a lot of people who learned, as I learned, and probably a lot of people in some past life, I would say, how to do this.
We now feel like imposter.
This is all new, we don't know how to work, and we maybe feel that we don't provide value now like we provided before.
But I think...
If we learn these things properly, like this thing we mentioned, the best practices, how to work with that, and taking into account some things that are here to be for a long time, like Lindy Effect talking about this, that will be for the next 50 years probably with us, like they were like 50 years behind us, your knowledge and value will be even more important to companies than it was before, because that knowledge don't disappear, you know, it just changed, and I would say even amplified with AI, because now we have the same thing that we had, but now we can even produce more, you know, we can produce more things in that same domain, but we still keep the roots.
like on the same way like we did before.
Yeah, so for people who don't know about Lindy Effect, right, it says like the longer something has been in use in the maybe software industry, right, the more likely it is continued to be being used, right.
So we're talking about, you know, maybe fundamentals, technologies that has been around for many, many, many years, right, I think it will still continue to be applicable, right.
So I think for those...
who have been around in the industry don't get disheartened, you know, whenever all this new AI craze happening, right?
So one thing for sure is like we have to pick it up and learn.
But also don't forget all these fundamentals, including the laws that Milan, you know, wrote in his books, right?
So, so far, all the five laws that we have covered seems like it is still applicable in the AI world.
How about the others?
Are there laws that become less relevant?
Is there such thing that you have found?
I wouldn't say.
So when I wrote the book, like I wrote it during the AI era and I tried to reflect in almost all of them how they, you know, tackle it.
Of course, there are some laws like that are not directly connected to producing software, like these behavioral things and some others which are...
you know, not directly, so they are not directly connected to AI, but I would say AI is present in a lot of them and even amplify some of them with this because I'm afraid that even people who knew some of this will forget them because of AI and things like, okay, this agent will create everything for me, I don't need to care about anything anymore.
I think they're wrong.
And this will bite back later if you skip it.
Yeah, so I think, yeah, just what you mentioned, right?
I think people seem to be in this AI mode now, right?
We seem to forget such things exist, such laws exist, right?
And we also probably think this is a new disruptor that is totally new that will definitely change things for good, right?
That's like different, totally different altogether.
But I think just like what we covered, right?
All these laws are probably timeless, right?
It's applicable over a long period of time.
And yeah, maybe looking forward to see new laws being created when we talk also about AI.
So you mentioned about Lindy effect, right?
So I think this is quite important for any software engineers because people now these days, some of us are actually quite disheartened when we talk about software engineering.
We think the profession will be gone.
We don't need so many software engineers.
So what do you think?
Is this going to be true or is this going to be like a fact?
Any thoughts about this?
I think Stoffer Engineers will be even more valuable than before, but people are mostly talking about counts, how many people we need.
And this thing will change.
For example, you mentioned maybe on this project we will not need 10 people, maybe we'll have three people.
The other things will be even more valuable because engineering world is not only code production.
I remember seeing the best software engineers I met writing one line of code per year.
So their main thing they did for our company was not...
writing code, they are solving problems.
So I basically believe that software engineers are problem solvers.
Writing code is of course our main thing how we solve problems, but not the only thing.
If you can solve problems without coding, that's the best thing.
So, you know, no code, no problem, because any amount of code you have, and nowadays you will have, it's expensive to maintain, to run it, you know, you need to pay for that in production.
So, should we always like, you know, try to be simpler and I think the things will restructure them and the companies will become maybe different, maybe more agile in this regard.
But the judgment call is still here.
As I said, we produce a lot more code but I didn't saw that new great software that was created in the last few years.
I don't remember anything new and big we are now using.
Although maybe some of these AI frontier models will say differently, right?
Because they will say, okay, we have come up with this new model that can solve, I don't know, even a certain kind of like role, right?
Maybe content finance software engineer, right?
I think there's always this debate in the industry I always find.
But I think you mentioned something that is also, I would love to mention it one more time, right?
Lesser code is actually much better, right?
So these days it's very easy to produce code.
And it's also very easy to lose track because it takes a lot of effort to actually even to review AI produced code, right?
And maybe we can talk about, you know, building the evals, building all these guardrails and all that.
But I still think it's...
probably not humanly possible if you continue churning code using AI, especially multiple AI agents at the same time, right?
To actually understand what's going on with the code, right?
So I think engineers definitely need to watch out about this.
How about the juniors, right?
Juniors who just started, I heard so many times that they found it even difficult to get the job in the first place.
Any advice that you know from your parts of the world there?
Yeah, I mean, we complain a lot, but for juniors it's even worse, because they cannot find any job so easily.
On the other side, what I've heard also from companies, this Dunning-Kruger effect is hitting hard, because they start to wipe code and they think like, okay, I knew everything now in a very short time, which is not true, and then hit the wall later.
So, for them it's even harder than what was before, but you know, I think there is no magic recipe.
They need to, you know, to learn things properly, they need to learn these fundamentals, which we mentioned with the Lindy effect, like algorithms, system design, databases, because this knowledge will be needed even with AI here.
Then, of course, AI technologies, and then...
What I find much more important than just this coding story, which is not often mentioned, is domain knowledge.
I think domain knowledge is something much, much more important than just knowing how to code something, because this is something that is hard to gain.
you know and expensive to lose people and bus factor is talking about this you know do you have people who have enough knowledge and how much so we need to think more in this direction so these people who want to learn and want to work and who has good skills.
And when we talk about skills, there are also people skills, which are very much important, maybe even more important than technical skills, than, of course, technical skills, to focus on this ownership and domain knowledge learning, because this part will be needed for many years to come.
Yeah.
I always find it quite difficult for them, right?
Empathize them, this kind of situation, right?
Because definitely when you went out of school, right?
You don't have much experience, right?
Probably what you learned also quite limited, right?
My other advice would be just getting more hands-on, right?
Build more things, right?
Maybe, you know, learn about some technologies and also learn about fundamentals, right?
You mentioned about fundamentals.
And I like, like, in your recent post as well, maybe in your newsletter, in your Substack, you...
cover about these must-read books for any software engineers.
Maybe talking about also classic books.
Any kind of books that you would want to advise us all to read, right?
Maybe if you can pick top five, what would be those books?
Yes.
Well, I'm the avid reader, you probably know, and I write a lot about books.
Why?
Because I think books are important.
They're still important.
Maybe people think they are not, but...
A lot of these books I talk about are actually those books that held the Lindy effect, you know, low there.
They're like, they're writing about things which are like, which were held for many years to come.
And of course, when we talk about this, like the best books, I always recommend Pragmatic Programmer because this is book actually talking about good habits we need to have when...
working in this area, how to become real software engineer, and this is something everyone should read, like, as the first book.
It is old one, but there is no release, like, 20th anniversary edition.
Then, I would also recommend CleanCode.
Some people don't agree about this, but I think CleanCode still have a lot of good insights on how code should look like, how good code should look like.
And together with philosophy of software design by Professor Osterholt, they are good pair on how the good code should look like.
And when AI produce some code, you can review it, you can check, like, does this make sense or not?
Maybe sometimes it will not have sense.
Then, of course, some of the books regarding algorithms, like gropping algorithms, which are, you know, basis.
to learn about how things really works and of course one book I wouldn't like to skip is designing data intensive applications, there's now a second edition, I wrote a detailed review like last year about this and this is important book for anyone working with distributed systems.
who want to know more about advanced data concepts, databases, data models, transactions, replications, consistency, all of these things where AI can help, but you still need to understand what's happening there.
So, and of course, as a bonus, my book, I think it will go well along these ones.
Yeah, I like the bonus part, right?
So definitely read books still, right?
Some people actually think these days, I mean, we all kind of like, getting very little time these days, right?
And we prefer to use, I don't know, maybe last time it was like audio book, right?
Maybe there are some product that also summarise book.
And these days you have AI that can summarise books quite easily as well.
Yes, yes.
I mean, you can use that.
And I mean, this is the reason why I held my book, I would say short, because every log has like two to three pages, four at most.
and you also have key takeaways on the start.
So it's easy to grasp every of these laws.
There is also an audiobook.
Yeah.
So one thing that I also learned about, even when you use AI and book, right, for those people who read a lot, you will benefit a lot when using AI, simply because first, obviously, you need to craft the prompt.
That's the given thing.
But also you need to read what AI is outputting, right?
So if you are an avid reader, definitely it gives you a good competitive advantage when you use AI, because you love to read and you can make sense of stuff faster rather than those people who don't love to read.
Yes, exactly.
My way of working with AI, I wrote, I think I published this today, is that I mostly focus on the research and planning part, because I do this part, especially when doing some bigger things.
I tend to focus more on there, not on the implementation stuff, because if we research things properly and plan things properly, the implementation will don't get us surprises, you know.
So try to focus more on this thing, creating plans and reviewing plans, discussing this with AI or, you know, with other people, and then when you have concrete implementation steps, AI is good at that part to just spit out the code.
Yeah, I think this is a pro tips for everyone who use AI, right?
Always start with plan mode first, right?
Always research first rather than jump into the implementation, you know, vibe code stuff or one shot thing, right?
So I think definitely you need to think a lot more.
And don't forget, I think I like what you mentioned earlier, right?
Think about the outcome that you want to achieve, right?
Not the exact output that you want to produce with AI, right?
So think about the outcome, what you want to achieve, what you want to do, and then use that with AI, right?
Milan, I think we have covered a lot of things.
Is there anything else that you think we should cover before we wrap up to my last question?
Yeah, maybe just briefly to mention how I would use these laws in my daily life.
So try to name forces and then think like when you read the book, of course, which laws apply here?
There are probably usually three to five laws.
Then rank the constraints.
Which constraint is the...
right in this point of time.
For example, two-week deadline of course beats the scaling worries that you have.
And then check also the opposite.
So for each law you will find where it breaks.
And this is some kind of algorithm that works well when working with software.
And by applying these laws you will just go much faster from the issue that happens to the right answer you need for that situation.
Yeah.
And I would like also to mention that you also have the website, right?
Maybe a companion website for this book, right?
Yes.
Where you can easily filter based on certain category or if you just want to jump to a certain law straight away.
I think that is kind of also helpful, right?
So yeah, encourage people to check out this book because this is a timely thing.
Coming back to the Lindy effect, the fundamentals that we talk about, software engineering.
And I think many of them, if not all, are still applicable even though we are dealing a lot with AI these days.
So Dr.
Milan, thank you so much for your time.
It's a great pleasure to have you again.
If you still remember last time, I have one tradition that I will ask for my guests.
I call this the Three Technical Leadership Wisdom.
Maybe you can share a version today, new, right?
Maybe with some loss, I don't know.
Maybe if you can share that would be great.
Yes, three leadership wisdoms.
I'll just try to summarize our talk a bit because I think we said everything important.
So the first thing is name the force before you fix it.
So most technical problems are actually organizational.
So the team can name what's pulling it.
solve that faster.
So this is the spine of my book.
The second thing is like optimize for judgment, not output, you know.
Especially now, the cheap part is producing code, but the valuable part is knowing what's good.
And this will be amplified in the future.
And the third thing I think it's important to mention is the right thing down.
So the knowledge your sandras has is your most fragile assets and bus factor talk about this.
So the whole book exists because writing beat this problem of constantly rediscovering things by new people that are here for, you know, for so long.
And it will, there will be for many times.
Yeah.
Wow, I think it's very good.
I find this kind of like law also, right?
It is kind of a bit applicable, right?
I like that optimized judgment rather than optimized output, right?
So I think definitely it's a good advice for us, especially in this AI era.
So Milan, thank you so much for the conversation again.
If people want to check out more about, you know, your book, your stuff, maybe if you can advise some place that can reach out to you online.
Yes, they can check the website of the book called the laws of softwareengineering.com and they can filter and check all the laws with filters, grouping and even by seniority.
They can also check the book there and they can contact me on LinkedIn, Twitter or my personal website to stay in touch.
I'm always open to hear.
what people will say to hear for feedback and anything interesting.
Yeah.
And not to mention, you also have this popular newsletter, right?
I think Tech World with, you know, Milan, right?
So I think please do check it out, right?
It is quite, it has been around for quite some time, right?
So I think it's quite popular for people to also follow.
So again, yeah.
Tomorrow will be interesting.
Tomorrow will be interesting thing.
in my newsletter with one of Google Principal Engineers and my recommendation is to read it.
It is about the future of software engineering and it tackles a lot of things we talked about today.
Nice.
Yeah, so again, thank you so much.
So thanks for writing this loss.
I think, again, it is a timely reminder for all of us in the industry, right, about some things that probably don't change often, right, and they are kind of like the most...
I would say that one of the most important things that people should know in the software engineering industry.
So thanks for writing and summarizing these laws.
Thank you, Henry, for the support and invitation to talk about this today.
I hope this talk and my book will be valuable for people in our industry.