Gui Ferreira

Gui Ferreira

@guiferreira.me

Minimalist Software Craftsman ▶️ YouTube: http://youtube.com/@gui.ferreira Ⓜ️ Microsoft MVP

245 followers39 following311 posts

The 80/20 Rule (Pareto Principle) is the secret weapon of the world's most efficient dev teams. Here's why you're likely wasting 80% of your energy.

View full thread

Every line of code you subtract is a line you don't have to debug, document, or maintain. Subtraction isn't "losing" work, it's "winning" focus.

The 80/20 Rule (Pareto Principle) is the secret weapon of the world's most efficient dev teams. Here's why you're likely wasting 80% of your energy.

View full thread

Steve Jobs saved Apple from bankruptcy by applying this. He didn't add new products, he cut the product line by 70%. He narrowed it down to just 4 products, so the team could focus on making them perfect.

The 80/20 Rule (Pareto Principle) is the secret weapon of the world's most efficient dev teams. Here's why you're likely wasting 80% of your energy.

The principle states that 80% of your results come from 20% of your efforts. In software, this means a tiny fraction of your features drive almost all of your user value.

80% of your results come from 20% of your effort. Stop wasting 80% of your time on the features nobody uses. Subtraction is the ultimate productivity hack.

The biggest mistake in tech: Starting with the "How." Dev: "I want to use Rust/Microservices/AI." Lead: "Why?" Dev: "Uh... because it scales?" (This is retrofitting).

View full thread

The biggest mistake in tech: Starting with the "How." Dev: "I want to use Rust/Microservices/AI." Lead: "Why?" Dev: "Uh... because it scales?" (This is retrofitting).

We pick our favorite "toys" (the How) and then hunt for an excuse (the Why) to use them. Simon Sinek calls this the Golden Circle, and most devs have it backwards.

In 2014, WhatsApp had 900 million users. How many engineers do you think it took to handle that scale? 5,000? 1,000? Not even close. It was 50.

View full thread

Because their vision was simple, their software could be simple. And because it was simple, it was reliable. You cannot have 99.9% reliability on a system that no one understands.

High scale doesn't require high headcount. It requires high focus. If your team is growing, but your output is slowing, you don't have a talent problem. You have a focus problem.

In 2014, WhatsApp had 900 million users. How many engineers do you think it took to handle that scale? 5,000? 1,000? Not even close. It was 50.

View full thread

They didn't get distracted by features that didn't serve that mission. They didn't build a social network. They didn't build an ad platform.

In 2014, WhatsApp had 900 million users. How many engineers do you think it took to handle that scale? 5,000? 1,000? Not even close. It was 50.

"What part of 'one click' did we not understand?" - Jeff Bezos. If your engineers are adding "confirmation steps" to your vision, they aren't helping. They're complicating. Hold the line.

View full thread

When we are stressed, we don't reason well. We don't find creative solutions. We just add more "blocks" to the pile, making the system even harder to maintain.

We need to move from "Sprinting" to "Sustainability". Simplicity isn't just about technical elegance. It's about creating an environment where humans can actually thrive for more than two years.

We call it "Sprinting". We do it every two weeks. But if you're always sprinting, you're not moving fast, you're just creating anxiety and pressure. And pressure narrows your thinking.

Software "Sprints" are a lie. You can't sprint every day for 5 years. That's just a recipe for a system (and a team) that eventually attacks itself.

Most developers are addicted to complexity. We applaud "clever" systems and put them on our CVs. But complexity is a liability, not an achievement. Let's talk about why we get it wrong.

View full thread

The problem? We choose the Easy path to get to the finish line faster. But when you avoid the challenges of a design phase, you're just front-loading technical debt. Eventually, you hit a wall where you can't move at all.

Most developers are addicted to complexity. We applaud "clever" systems and put them on our CVs. But complexity is a liability, not an achievement. Let's talk about why we get it wrong.

View full thread

My daughter plays the violin. For her, a new piece of music is hard. For a professional, it's easy. "Easy" is subjective and changes with experience.

"Simple", however, is objective. A recipe can be simple (5 clear steps) but hard to execute (requiring master-level technique). We shouldn't avoid "hard" things if they lead to "simple" systems.

Most developers are addicted to complexity. We applaud "clever" systems and put them on our CVs. But complexity is a liability, not an achievement. Let's talk about why we get it wrong.

We confuse Simple with Easy. Easy = Familiarity. (e.g., Using a tool just because you've used it before). Simple = Clarity. (e.g., An architecture that is decoupled and easy to reason about).

An AI agent is not a chat response. It is a loop. Load context, reason, execute tools, update memory, repeat. Once you design the loop, agentic AI becomes just system design again.

View full thread

The best part: once the loop is designed, adding new tools or capabilities becomes so simple. Your AI agent scales with your architecture.

View full thread

Tool Executor: Calls systems or APIs as needed (databases, REST APIs, knowledge base, vector stores, etc.), returns results to the Planner, and the loop continues.

Building an AI agent should not start with prompts. It should start with architecture. Context diagrams, application boundaries, and component design turn "AI magic" into systems your team can actually build and maintain.