Dr Milan Milanović

We've never experienced this level of low quality in software

Everything we did was to fight to improve the quality

Now, all of a sudden, everyone is chasing more lines of code with AI, everything is broken, and no one is disturbed due to that

Weird times to be alive

Kubernetes killed more startups than server crashes ever did

You don't have Spotify's scale. You have 8 engineers and a single server that's running fine

But you watched a KubeCon talk, and now you've got 23 YAML files, a Helm chart nobody fully understands, and engineers debugging pod evictions instead of buildinga product

Your "cloud-native infrastructure" is just a cloud bill with extra complexity

A $50/month VM can handle millions of requests. Your startup will run out of money debugging networking issues long before you need horizontal pod autoscaling

The best infrastructure decision is often the simplest one

Most of the people who think that AI will replace developers are:

- Managers who don’t code
- Investors and startup founders selling it
- People outside tech

Developers: "It's helpful."

Software developers are lifelong learners

Not because we're curious. Because we have no choice

The tools change. The frameworks shift. The best practices from last year have become antipatterns today

You either keep learning or you become obsolete.

Read more code than you write. Build things outside your job's stack. Learn one new language every 2-3 years. Follow people who challenge what you think you know

The learning never stops. That's the job

📚 It's here! The first copies of "Laws of Software Engineering" arrived!

After so much time working on it, seeing the first physical copies of my new book is something special.

You may wonder why did I decide to write it? Most of what I learned during my career already had a name, but I didn't know it yet. Brooks's Law for the team, where adding people made us slower. Conway's Law for the architecture that is shaped by our org chart. Hyrum's Law, for where every undocumented behavior became something a customer depended on.

People had been studying these laws for fifty years, but no one had handed me the map so I can learn it. Because of this I decided to write one for myself and others.

Inside is 300+ pages, 63+ laws and principles, across seven parts:

• Architecture & Complexity
• People, Teams & Organizations
• Time, Estimation & Planning
• Quality, Maintenance & Evolution
• Scale, Performance & Growth
• Coding & Design Principles
• Decision-Making & Biases

Rebecca Parsons (CTO Emerita, Thoughtworks) and Addy Osmani (Engineering Director, Google Cloud AI) wrote the forewords. Their work shaped how a lot of us write software. It is still surreal that they said yes.

In the first three weeks of launch, 1000 copies had already been sold, and the book is the Amazon Best Seller in its category.

Where can you get it:

📘 eBook (PDF + ePub): https://lnkd.in/d2BfwQFr

📔 Paperback, Hardcover, Kindle: https://lnkd.in/dsQisg49

I hope you will find it valuable too.

#softwareengineering #programming #leadership

AI writes code faster than you ever will

But it can't decide what problem to solve, which trade-offs to accept, or when the architecture won't hold

The keyboard was never the bottleneck

Your thinking was

And still is

If you're a developer who ships code daily, remember these:

- First, make it work; nobody cares how elegant broken code is
- Then make it fast, slow code that works still frustrates users
- After that, make it pretty, so that your teammates read code more than they write it
- Add tests that actually catch bugs, not just boost coverage metrics
- Refactor when you finally understand what you're building (usually the second time through)

Perfect code on the first try is a myth.

Fast iteration beats slow perfection every time

Be a software engineer, not a developer

AI can write code now. That part of the job is shrinking fast

Developers ask: "How do I code this?"
Engineers ask: "Should we build this at all?"

AI handles the first question better every month. The second? Still 100% human

System design. Architecture trade-offs. Understanding the business. Making it work in production

That's engineering. And it's not getting automated

The question isn't whether AI will replace developers. It's whether you're still just a developer

Friday Developers Fun 🤣

Cloudflare announced a new service recently

#developers #softwareengineering #meme

How to detect that the company doesn't know what it's doing:

They say "we are becoming an AI-first company"

Walking is the best debugger

Your brain works better when you stop trying

Stuck on a problem? Walk away. Take a shower. Sleep on it. Your conscious mind steps aside, and something else takes over

The subconscious doesn't work linearly. It connects patterns you didn't see while staring at the screen. It runs in the background, rearranging pieces until something clicks

Then the answer arrives, fully formed, obvious in hindsight

You can't force insight. But you can create the conditions for it. Movement helps. Distance helps. Boredom helps

Next time you're stuck, close the laptop. The solution finds you when you're not looking

Junior and mid-level engineers can no longer push AI-assisted code without a senior signing off at AWS

After a few recent incidents in production at AWS, particularly the latest one where they spent 13h recovering their own AI coding tool, they decided to reduce the trend of "high blast radius" caused by "Gen-AI assisted changes".

Folks from Amazon concluded that "novel GenAI usage for which best practices and safeguards are not yet fully established".

Source: FT

Clean code is too clean to make money

Clean code optimizes for maintainers
Money optimizes for customers

Customers don’t pay for elegance
They pay for speed, reliability, and outcomes

Ship a thin slice that solves one painful problem
Measure usage
Fix what breaks
Refactor what earns

𝗥𝗲𝗮𝗱𝗮𝗯𝗹𝗲 𝗰𝗼𝗱𝗲 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗹𝗲𝘃𝗲𝗿𝗮𝗴𝗲 𝗲𝗾𝘂𝗮𝗹𝘀 𝗵𝗼𝗯𝗯𝘆 𝗰𝗼𝗱𝗲

Where do you draw the line: “clean enough” or “clean forever”?

Someone builds a project management tool with Claude Code over a weekend. Ships it. Tweets "just replaced Jira."

The app works. One user, happy path, localhost. Then two people edit the same record simultaneously, and the data is silently corrupted. They don't know what an optimistic lock is. They never needed to before.

The prototype is maybe 1% of what makes software actually work. The other 99% is what you find after real users show up: race conditions, failed transactions, sessions expiring at the wrong moment, a payment webhook that fires twice and charges someone double. AI didn't cover any of that. It built exactly what you asked for.

And the confidence is the worst part. "Just need to adjust a few things before we go live." The few things you need to adjust are the product. That's like laying a foundation and telling people you basically built the house.

Vibe coding works. For personal tools, throwaway scripts, and prototypes you'll never put in front of paying users, it's genuinely fast and good enough. I use it. But there's a hard ceiling, and it shows up the moment the stakes get real.

Agentic engineering is a different discipline. You're not prompting for code. You're decomposing problems, designing system boundaries, writing specs precise enough that the agent doesn't go sideways. You review everything it builds, because it will make mistakes that only look wrong if you know what correct looks like. You guide it. You catch what it misses.

If you don't know what a distributed transaction is, the agent won't save you. It'll generate something broken with complete confidence, and you won't know until production.

The hard part of software was never writing the first 200 lines

It never was

Friday Developers Fun 🤣

Claude and I at 3 am

#developers #meme #fridayhumor

The best software engineers I know don't obsess over the latest framework

They obsess over solving the actual problem

They write code that humans can read 
They ship working software over perfect architecture
They delete more than they write
They know the best code is the code you don't have to maintain

Your users don't care about your stack. They care that it works

That's the only metric that matters

𝗪𝗵𝘆 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆 𝗮𝗹𝘄𝗮𝘆𝘀 𝗯𝗲𝗮𝘁𝘀 𝗺𝗼𝘁𝗶𝘃𝗮𝘁𝗶𝗼𝗻

Do you know a story about two teams that raced to the South Pole in 1911? They had the same goal. One team made it back, but the other didn't.

Norwegian explorer Amundsen's rule was simple. March 15 to 20 miles a day. On good days, he stopped at 20 to save the team. In blizzards, he still pushed to 15. The pace didn't change.

The British party led by Robert Falcon Scott ran its expedition on foot. Big pushes when the weather was clear, sometimes 40 miles in a day. Long rests when it wasn't. His team burned out, fell behind, and died on the way home.

Scott trusted motivation, but Amundsen trusted the plan.

Most of us run our work like Scott. We sprint when we feel like it, stall when we don't, and call the whole thing effort. Then we wonder why nothing compounds.

Motivation is a mood. It shows up some days and disappears on others. Consistency is something you decide once and stop renegotiating with yourself every morning.

The engineer who ships something small every week will pass the one waiting to ship something perfect in six months. Every time.

So pick your daily mile and walk it. Especially on the days you don't want to.

That's how you reach the pole.

𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀 𝘀𝘁𝗶𝗹𝗹 𝗰𝗮𝗻'𝘁 𝗯𝘂𝗶𝗹𝗱 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗳𝗿𝗼𝗺 𝘀𝗰𝗿𝗮𝘁𝗰𝗵

Meta, Stanford, and Harvard just released 𝗣𝗿𝗼𝗴𝗿𝗮𝗺𝗕𝗲𝗻𝗰𝗵, which hands an agent a compiled binary plus its docs and asks it to rebuild the program from scratch. They tested 9 frontier models on 200 tasks, from small CLI utilities to FFmpeg, SQLite, and the PHP interpreter.

Across all 1,800 runs, no model solved a single task end-to-end.

Here is what the data shows:

𝟭. 𝗧𝗵𝗲 𝗯𝗲𝘀𝘁 𝗺𝗼𝗱𝗲𝗹 𝗽𝗮𝘀𝘀𝗲𝗱 𝟵𝟱% 𝗼𝗳 𝘁𝗲𝘀𝘁𝘀 𝗼𝗻 𝗼𝗻𝗹𝘆 𝟯% 𝗼𝗳 𝘁𝗮𝘀𝗸𝘀

𝗖𝗹𝗮𝘂𝗱𝗲 𝗢𝗽𝘂𝘀 𝟰.𝟳 hit that 3% mark, with Opus 4.6 close behind at 2.5% and Sonnet 4.6 at 1.6%. Every other model scored zero, including GPT 5.4 and Gemini 3.1 Pro. The benchmark runs on 𝟮𝟰𝟴,𝟴𝟱𝟯 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝗿𝗮𝗹 𝘁𝗲𝘀𝘁𝘀.

𝟮. 𝗠𝗼𝗱𝗲𝗹𝘀 𝘄𝗿𝗶𝘁𝗲 𝗺𝗼𝗻𝗼𝗹𝗶𝘁𝗵𝗶𝗰 𝗰𝗼𝗱𝗲, 𝗻𝗼𝘁 𝗺𝗼𝗱𝘂𝗹𝗮𝗿 𝗰𝗼𝗱𝗲

𝟲𝟬% 𝗼𝗳 𝗺𝗼𝗱𝗲𝗹 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻𝘀 𝗹𝗶𝘃𝗲 𝗶𝗻 𝟭-𝟯 𝗳𝗶𝗹𝗲𝘀. Median directory depth is 1, against 2 for the human-written code. Models keep 10-29% of the original function count and make each one 𝟭.𝟬𝟴𝘅 𝘁𝗼 𝟭.𝟲𝟮𝘅 𝗹𝗼𝗻𝗴𝗲𝗿. We tell engineers to break code into small, focused functions. Models go the other way.

𝟯. 𝗠𝗼𝗱𝗲𝗹𝘀 𝗼𝗳𝘁𝗲𝗻 𝗮𝗯𝗮𝗻𝗱𝗼𝗻 𝘁𝗵𝗲 𝗿𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝗳𝗼𝗿 𝗣𝘆𝘁𝗵𝗼𝗻

Models stick with the original language only 50% of the time. 𝗣𝘆𝘁𝗵𝗼𝗻 𝘄𝗶𝗻𝘀 𝗼𝘃𝗲𝗿𝗮𝗹𝗹 at 36% of runs. 𝗚𝗣𝗧 𝟱.𝟰 𝗽𝗶𝗰𝗸𝘀 𝗣𝘆𝘁𝗵𝗼𝗻 𝟳𝟵% 𝗼𝗳 𝘁𝗵𝗲 𝘁𝗶𝗺𝗲, even when the original is Rust or C/C++.

𝟰. 𝗦𝗼𝗺𝗲 𝗺𝗼𝗱𝗲𝗹𝘀 𝘄𝗿𝗶𝘁𝗲 𝗰𝗼𝗱𝗲 𝗶𝗻 𝗼𝗻𝗲 𝘀𝗵𝗼𝘁, 𝗼𝘁𝗵𝗲𝗿𝘀 𝗶𝘁𝗲𝗿𝗮𝘁𝗲

𝗚𝗣𝗧 𝟱.𝟰 𝘄𝗿𝗶𝘁𝗲𝘀 𝟵𝟲% 𝗼𝗳 𝗶𝘁𝘀 𝗳𝗶𝗻𝗮𝗹 𝗰𝗼𝗱𝗲 𝗶𝗻 𝗼𝗻𝗲 𝘁𝘂𝗿𝗻. Sonnet 4.6 takes the opposite path: 𝟴𝟲𝟴 𝗰𝗼𝗺𝗺𝗮𝗻𝗱𝘀 𝗮𝗻𝗱 𝟭𝟴.𝟯 𝗳𝗶𝗹𝗲 𝗲𝗱𝗶𝘁𝘀 𝗽𝗲𝗿 𝘁𝗮𝘀𝗸 on average. Neither approach produces a working program.

𝟱. 𝗖/𝗖++ 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗮𝗿𝗲 𝘁𝗵𝗲 𝗵𝗮𝗿𝗱𝗲𝘀𝘁

C/C++ tasks land at 𝟮𝟳.𝟳% average pass rate, against 38.5% for Rust and 38.4% for Go. FFmpeg, php-src, and DuckDB stay unsolved. The wins are on smaller tools like nnn, jq, and gron.

Agents can patch existing code. Building it from scratch is a different problem entirely.

The fear isn’t that AI will replace developers

The fear is that AI will replace the software development process we’re used to

Code is becoming cheap
Decisions are becoming expensive

AI can write functions all day, but it can’t decide what should be built, how it fits the system, or why it solves the problem. That part still sits with people who understand architecture, trade-offs, constraints, and consequences

The shift is simple:

Developers who only implement tasks will struggle
Developers who understand the product, the domain, and the system will thrive

AI reduces typing, not thinking. It accelerates engineers who treat code as leverage, not output. It exposes shallow understanding and rewards clarity, reasoning, and ownership

Small teams will ship things that once required entire departments.
The bar moves from writing code to shaping it

AI won’t replace developers
But it will replace developers who don’t grow beyond writing code

And if this transition feels uncomfortable, that’s normal. Every major shift starts that way. What matters now isn’t fear, it’s staying curious, learning fast, and leaning into the parts of engineering that AI can’t automate

I'm proud of my dad, who passed away two years ago, that his books are still sold (in Serbian)

These books are on embedded/low-level programming + electronics

More on his work: http://vojo.milanovic.org/

Who remembers this from the 1990s, before the Internet?

It was a Wikipedia before Wikipedia

Three algorithm books from MIT Press. All are free to read online.

Mykel Kochenderfer and team published a trilogy that covers ground most engineers actually need:

1. 𝗔𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺𝘀 𝗳𝗼𝗿 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻 (2019)
Linear programming, convex optimization, surrogate models, population methods. The math behind every search and tuning problem you've touched.

2. 𝗔𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺𝘀 𝗳𝗼𝗿 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻 𝗠𝗮𝗸𝗶𝗻𝗴 (2022)
Probabilistic reasoning, sequential problems, reinforcement learning, and multi-agent systems. If you're building anything with AI agents, start here.

3. 𝗔𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺𝘀 𝗳𝗼𝗿 𝗩𝗮𝗹𝗶𝗱𝗮𝘁𝗶𝗼𝗻 (Preview)
Safety analysis, verification, and robustness testing for autonomous systems. The part most teams skip until something breaks.

I've been going through the Decision Making one recently. The treatment of POMDPs and game-theoretic methods is well worth your time.

Link: https://lnkd.in/dTUjF_xe

Pre mesec dana je izašla moja knjiga "Laws of Software Engineering" na engleskom. Postala je #1 bestseler na Amazonu. Predgovore su napisali Rebeka Parsons (bivša tehnička direktorka u Thoughtworks-u) i Edi Osmani (Direktor inženjeringa u Google-u).

Sada konačno dolazi i na srpski.

Na srpskom se zove "Zakoni softverskog inženjerstva", a izdaje je Kompjuter biblioteka iz Beograda. 63+ zakona i principa, u sedam celina, na oko 300 strana.

Konvejev, Bruksov, Gudhartov, Hajramov i mnogi drugi, zakoni koje iskusni inženjeri znaju iz prve ruke, najčešće zato što su se na njima jednom opekli.

U pretplati je sa 40% popusta (1.500 umesto 2.420 dinara): https://lnkd.in/d_T7qdvJ

Ovo izdanje mi posebno znači.

Friday Developers Fun 🤣

Software Engineers, after giving a 30-second demo

#developers #meme #fridayhumor

𝗠𝗼𝘀𝘁 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗱𝗼𝗻'𝘁 𝗿𝗲𝗮𝗱 𝗮𝗻𝗱 𝘁𝗵𝗶𝘀 𝗶𝘀 𝗽𝗿𝗼𝗯𝗮𝗯𝗹𝘆 𝗺𝘆 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 𝗽𝗿𝗼𝗳𝗲𝘀𝘀𝗶𝗼𝗻𝗮𝗹 𝗮𝗱𝘃𝗮𝗻𝘁𝗮𝗴𝗲

So when people ask me for book recommendations, I don't give the same ones as others: Clean Code, The Pragmatic Programmer, and DDIA. Those are fine, of course, but you've heard about them many times.

In the new issue of Tech World With Milan newsletter, there is the list I actually gave people in 2026. Some old, some new.

A few that earned their place:

- 📘 𝗔 𝗣𝗵𝗶𝗹𝗼𝘀𝗼𝗽𝗵𝘆 𝗼𝗳 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗗𝗲𝘀𝗶𝗴𝗻 by John Ousterhout. I read it late and wished I hadn't waited. Best explanation I know of why complexity is in and how to push back.

- 📕 𝗗𝗲𝘀𝗶𝗴𝗻𝗶𝗻𝗴 𝗗𝗮𝘁𝗮-𝗜𝗻𝘁𝗲𝗻𝘀𝗶𝘃𝗲 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀, 2nd edition, by Martin Kleppmann and Chris Riccomini. The rewrite adds AI data systems. Still, the book I reach for most on distributed data.

- 📘 𝗔𝗜 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴, by Chip Huyen. If you're putting LLMs into production, this is the one.

- 📓 𝗧𝗵𝗲 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿'𝘀 𝗚𝘂𝗶𝗱𝗲𝗯𝗼𝗼𝗸, by Gergely Orosz. The career stuff nobody teaches you. We usually learn it by experience the hard way.

- 📔 𝗥𝗲𝗳𝗮𝗰𝘁𝗼𝗿𝗶𝗻𝗴, by Martin Fowler. Changing code without breaking it, which is most of the actual job.

My own book is on the list too. 𝗟𝗮𝘄𝘀 𝗼𝗳 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴: 63+ laws and principles every engineer learns from experience and fails. I collected them so you don't have to.

Link is in the comments.

Friday Developers Fun 🤣

Me to Claude: "Make no errors."

#developers #softwareengineering #meme #fridayhumor

Friday Developers Fun 🤣

When we Vibe code it.

#developers #meme #fridayhumor

I wanted to understand how GPT works, so I ported Karpathy's microgpt.py to C# from scratch. No frameworks and NuGet packages, just plain math in ~600 lines of code.

It builds a tiny GPT that learns from 32K human names and invents new ones. Every piece is there: autograd, attention, Adam optimizer, the works. Just at a scale you can actually sit down and read.

I also wrote a prerequisites guide that walks through all the math and ML you need, starting at a high school level. If you've ever wanted to peek under the hood of ChatGPT without drowning in linear algebra textbooks, this might help.

With time, one thing became clear:
People either respect you, or they don’t

You can explain, justify, and prove, but it won’t change much

I stopped trying to win everyone over

I focus on people who value my work, my time, and my presence

Everything else is noise

I've reviewed 1,000+ resumes as a hiring manager

Most get rejected in 6 seconds

Here's what separates the ones that land interviews:

𝟭. 𝗢𝗻𝗲 𝗽𝗮𝗴𝗲. 𝗣𝗲𝗿𝗶𝗼𝗱.

If you can't distill 10 years into one page, you don't understand what matters. Senior roles included.

𝟮. 𝗟𝗲𝗮𝗱 𝘄𝗶𝘁𝗵 𝗶𝗺𝗽𝗮𝗰𝘁, 𝗻𝗼𝘁 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀

❌ Bad: "Responsible for maintaining authentication service."
✅ Good: "Cut login failures by 40% by rebuilding authentication with Redis caching."

Metrics tell me you understand business outcomes.

𝟯. 𝗦𝘁𝗿𝗼𝗻𝗴 𝘃𝗲𝗿𝗯𝘀 𝗮𝘁 𝘁𝗵𝗲 𝘀𝘁𝗮𝗿𝘁 𝗼𝗳 𝗲𝘃𝗲𝗿𝘆 𝗹𝗶𝗻𝗲

Recruiters scan in an F-pattern. They read the first 2-3 words per bullet.

✅ Use: Built, Led, Reduced, Scaled, Architected
❌ Avoid: Assisted, Helped, Worked on

𝟰. 𝗞𝗶𝗹𝗹 𝘁𝗵𝗲 𝗯𝘂𝘇𝘇𝘄𝗼𝗿𝗱𝘀

"Visionary leader driving transformational initiatives with cutting-edge AI solutions" = noise.

Just say what you did and what changed.

𝟱. 𝗧𝗼𝗽 𝟭/𝟯 𝗴𝗲𝘁𝘀 𝟴𝟬% 𝗼𝗳 𝗮𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻

Polish your first section obsessively. That's where hiring decisions happen.

𝟲. 𝗧𝗮𝗶𝗹𝗼𝗿 𝗳𝗼𝗿 𝗲𝗮𝗰𝗵 𝗿𝗼𝗹𝗲

One resume for all jobs = one resume that fits none. Match your bullets to the job description.

𝟳. 𝗡𝗼 𝘀𝗽𝗲𝗹𝗹𝗶𝗻𝗴 𝗲𝗿𝗿𝗼𝗿𝘀

If you can't proofread when it matters most, I won't trust you with production code.

___
👉 Want the template I give to my coaching clients? Grab it in my Premium Resume Package: https://lnkd.in/dqZ2m-fb

LinkedIn today, 99% slop posts straight LLM outputs

Every post has the same pattern

Same hook, same bulleted points, same “agree” at the end

Most of the comments are either bots or people adding comments just to increase their own visibility

Really wierd to witness this

SQLite might be the most underrated database

~700KB compiled library, embeds in your app, no server

On phones, browsers, and cars

Small full-time team with strict C API + file format backwards-compatibility rules

Meanwhile, your microservice stack needs 12 containers

Check sqlite.org