milanm081

Thank you all for the valuable feedback! I'll review each comment and improve what I can on the website.

Fixed

Fixed

Fixed, thanks!

For years, I kept notes on patterns I saw in software projects, architecture, planning, estimation, testing, scaling, and team design.

I pulled those notes into a browsable site with 56 laws, grouped into categories, with short explanations and separate pages for each one.

The goal was simple: put these ideas in one place, so when you want a quick refresher on Conway’s Law, Brooks’s Law, Gall’s Law, Hyrum’s Law, or Goodhart’s Law, you can find it fast.

I’m more interested in criticism than praise. Which laws are missing, which ones feel overstated, and which ones get misused most often in real work?

When I first picked up Software Engineering at Google, I expected another Big Tech flex, with practices that only make sense if you have a billion users and 30,000 engineers. But I was wrong. The lessons in this book are universal and apply whether you’re on a team of 5 or 5,000. It draws on 2 decades of experience from an organization that runs 2+ billion lines of code and changes 25 million lines per week.

The book isn’t about programming, per se. It’s about the good engineering practices that Google has used over the years and decades to keep a healthy codebase.

In particular, it is about what happens after you write the code: how you evolve it, share it, test it, and eventually delete it.

Have you ever noticed how certain people manage to navigate obstacles with ease while others get stuck at the first sign of resistance? Some people seem to always find a way forward, even in challenging conditions.

This fundamental difference often boils down to a single trait: High Agency.

I love books. When I look at the 5000 books on my bookshelf, I see more than paper and ink; I see a personal board of mentors I never had. Over the years, as an avid reader, these books have quietly reshaped how I approach coding, leadership, and even thinking itself.

Early in my career, I assumed improving my skills was all about writing more code or learning the latest framework, like everyone else. But the most significant improvements in my growth came from hours spent flipping pages in some of the best books out there.

There’s something tactile and deliberate about reading, scribbling notes in the margins, dog-earing pages, that forces me to slow down and reflect.

Here, I want to share five books that influenced my journey from engineer to CTO the most. Each of these books contributed beyond just technical knowledge; they challenged my assumptions, introduced new mental models, and ultimately changed how I work and lead teams.

A practical guide to Architecture Decision Records (ADRs)

Technical debt has haunted development teams for decades, yet remains surprisingly difficult to explain. Everyone has their definition of Technical Debt. You will probably get three different answers if you ask three people what it is.

Google recently faced this challenge at scale – a substantial percentage of its engineers reported being blocked by “unnecessary complexity and technical debt” in internal surveys. In a paper titled “Defining, Measuring, and Managing Technical Debt,” Google Engineers Ciera Jaspan and Collin Green systematically understood this concept that slows down even the most talented engineering teams.

They tried to answer the following questions: How do you measure something so intangible? And once you identify it, how do you manage it without halting new development?

This research matters because technical debt is often blamed for productivity issues, but rarely defined or measured with precision. Google's work offers concrete strategies that any engineering organization can adopt.

Have you ever pressed play on Netflix and wondered what technology ensures your video starts instantly and plays without interruptions? Simply pressing play triggers a global technological symphony that delivers content to over 301 million subscribers in 190 countries.

Behind this massive operation lies one of the world's most sophisticated distributed systems architectures.

This article explores the technical decisions and architectural patterns that make streaming on Netflix effortless. It also discusses what software engineers and architects can learn from this extraordinary-scale system.

Microservices are popular for their scalability but come with complexity and operational overhead. They have become a big hype in the industry, and you can see microservices everywhere. On the other side, modular monolith offers a middle ground—keeping the simplicity of a monolith while allowing for future scalability. Here’s why it might be the right choice for your next project.

A modular monolith enables teams to build and deploy a single application while keeping the code clean, maintainable, and modular. It allows for quick development cycles while ensuring long-term system evolution, making it an ideal starting point for many projects, especially for startups.

Have you ever wondered what the biggest productivity killer for developers is? There are many, but one stands out—and it’s often underestimated.

Every time you send someone a “quick” Slack message, it costs that person 23 minutes of productive work, and that's just the beginning of the problem.

I’ve worked with development teams for over a decade, and we consistently underestimate the disruptive nature of interruptions. This article explores why context-switching is so costly and how to manage it effectively.

The foundations of modern software engineering were built on some high-impact research papers. From the algorithms powering most apps today to the databases storing data, many technologies we use daily emerged from academic publications. While these papers might initially seem intimidating, they offer invaluable insights that can transform how you approach software development.

What makes a great team stand out? It’s not just technical skills or years of experience—it’s something deeper. Over two decades, I’ve seen how some teams thrive while others struggle, and the difference often comes down to how people interact, communicate, and support each other. Building a high-performing team requires more than just assembling talented individuals—it’s about creating the right environment for them to succeed together.

Our daily work as software engineers involves creating or utilizing these APIs. Creating well-designed REST APIs is crucial—not only should they be easy to work with and concise, but they should also be well-designed against misuse to prevent future issues.

In this issue, we explore the art of API design through a curated selection of resources, including insightful books, articles, and real-world examples from industry leaders like Stripe and Slack. We'll learn about the proper use of HTTP methods, RESTful URI structures, effective error handling, caching strategies, and the importance of thorough API documentation.

Additionally, we'll present common API anti-patterns that often lead to bigger problems later.

Our daily work as software engineers involves creating or utilizing these APIs. Creating well-designed REST APIs is crucial—not only should they be easy to work with and concise, but they should also be well-designed against misuse to prevent future issues.

In this issue, we explore the art of API design through a curated selection of resources, including insightful books, articles, and real-world examples from industry leaders like Stripe and Slack. We'll learn about the proper use of HTTP methods, RESTful URI structures, effective error handling, caching strategies, and the importance of thorough API documentation.

Additionally, we'll present common API anti-patterns that often lead to bigger problems later.

Delivering quality software quickly is more critical than ever in today's software development industry. Continuous Integration and Continuous Delivery (CI/CD) pipelines have become standard tools for development teams to move code from development to production. By enabling frequent code integrations and automated deployments, CI/CD pipelines help teams avoid the dreaded "integration hell" and ensure a reliable software release cycle.

In this article, we will learn about the fundamentals of CI/CD pipelines—what they are, how they work, and why they're necessary in modern software development. We'll explore the different stages of a CI/CD pipeline, provide real-world examples using tools like GitHub Actions, and discuss strategies for optimizing your pipeline's performance.

Additionally, we'll discuss selecting the right CI/CD platform for your organization, considering factors like cloud-based versus self-hosted options, integration capabilities, and user-friendliness.

Have you ever started a new job and found yourself staring at a complex codebase, not knowing where to start? You're not alone. Many of us have been there—trying to make sense of outdated code that still runs major parts of the business. A 2024 Stack Overflow survey found that over 80% of developers regularly deal with legacy code, so it's a common challenge in our industry. Most legacy software has its worth, as it is still used and has clients.

In the article, we'll talk about the typical problems you might face, like outdated technology, missing documentation, and big piles of technical debt. More importantly, we'll share some practical steps to help you understand and navigate these old systems.

We'll also look at advice from experts like Michael Feathers and explore how modern tools, including AI assistants like GitHub Copilot, can make life easier.

Choosing the right Git branching strategy is more than just a technical decision—it directly impacts how efficiently your team can collaborate, integrate code, and deploy software. With various strategies available, each offering unique strengths, it is crucial to select one that aligns with your team’s workflow and project demands.

This post will guide you through the most popular Git branching strategies, from the simplicity of Feature Branching to the structured approach of GitFlow and the continuous integration focus of Trunk-Based Development. We'll also deep dive into advanced concepts like Stacked Diffs and the distinctions between Git Merge and Rebase.

Whether working on a small project with continuous deployments or a large-scale system with scheduled releases, understanding these strategies can help you optimize your development process and avoid potential problems.

When I started my journey as a software engineer two decades ago, I couldn't have imagined the incredible evolution our field would have. The IT industry has continuously progressed in different directions, from the rise of agile methodologies to the boom of cloud computing, from monolithic applications to microservices architectures, and back.

Yet, with this constant change, I've discovered that certain fundamental principles remained. These lessons have stood the test of time and become even more relevant in our increasingly complex world of software engineering.

In this post, I'll share ten critical lessons I've learned over my 20-year career. These principles have helped me navigate many projects, lead teams, and continuously grow professionally.

The lessons are:

1. Don't do premature optimization

2. Think twice before writing code

3. Learn good practices

4. Make things simple and even simpler than that

5. Name things properly

6. Always test your code

7. Keep your time wisely. It is the most expensive thing you have.

8. Communicate, communicate, communicate

9. Don't just learn, do

10. Have a culture of documentation

Have you ever been part of a project where new features seem to pile up daily, deadlines are often missed, and everything needs to be done for yesterday? If so, you're not alone. This story includes the challenges described by the Project Management Triangle—a model that illustrates the trade-offs between a project's scope, time, and quality.

Another important aspect that causes projects to be late is the complexity of software engineering. We'll also discuss different complexities and examine practical strategies for dealing with them.

In the complex software development and management world, the quality of our thinking often determines the success of our projects and teams. Mental models and cognitive biases are crucial in approaching problems, making decisions, and interacting with others.

This article focuses on critical mental models that enhance problem-solving abilities and decision-making processes. We'll also deep-dive into common cognitive biases that can derail even the most experienced professionals. By understanding these concepts, you will become a super thinker and make better decisions.

Last week, Stack Overflow released the results of its annual survey on coding, the technologies and tools developers use and want to learn artificial intelligence, and their workplace experience. Over 65,000 programmers from 185 countries responded to the survey.

According to the workplace satisfaction survey results, as many as 80% of professional programmers are unhappy. One in three respondents actively hates their job, while almost half survive in survival mode. That leaves only 20% who claim to be somewhat happy. Although developers have good salaries, plenty of free time, and often the ability to work remotely, many still need to be satisfied.

When we talk about software today, we should know that its importance is now at the very end of the spectrum of different technologies used. For example, in the aerospace world, the stakes are incredibly high, and software glitches can lead to catastrophic outcomes.

Setting priorities helps you have more clarity and focus, reduce stress, and achieve more in your work and life.

Moreover, you will discover the most practical prioritization methods for individuals, leaders, and teams, equipping you with the tools to manage your tasks effectively and achieve your goals.

Have you ever wondered why some technologies are still with us and some have disappeared? Here is the Lindy effect to explain it. This effect tells me developers will still use C# and SQL when I retire. It is a concept in technology and innovation that suggests that the future life expectancy of a non-perishable item is proportional to its current age. In other words, the longer an item has been in use, the longer it is likely to continue to be used.

The concept was named after Lindy's Deli in New York City, where Nassim Nicholas Taleb popularized it in his book "The Black Swan." According to Taleb, the Lindy effect applies to many things, including technologies, ideas, and cultures, and evaluates their potential longevity.

Databases usually consist of tables with columns and rows. Yet, traditional monolithic databases can become sluggish and cumbersome as they balloon in size. Database partitioning is a powerful technique for wrangling data and keeping databases running smoothly.

Database partitioning is the process of splitting a large table or database into smaller, more manageable chunks called partitions. This allows us to query only parts of the data, making it faster to load.

Technical debt can cause so much frustration and burnout to development teams. Software engineers can be aware of the side effects of technical debt. However, they often need to explain to the product team why quick and easy solutions to coding development are risky.

So, instead of stabilizing the situation, the business keeps adding more features, and the technical debt grows. Because of this, we usually say that technical debt is not a technical problem. For that reason, every software development team must try their best to prevent the technical debt from accumulating so it doesn't result in the worst-case scenario, which is a project halt.

If you're working in a team using the Scrum framework, you use story points to estimate effort on your stories, tasks, etc. Some management also takes this into account and does planning, measures your productivity, and even keeps you accountable when something is done. Yet, they need to learn that software estimations are always wrong.