Advice

When you're a kid, you do what adults tell you. This makes sense. They know more than you.

The problem is that many people never stop. They keep looking for someone to tell them what to do. It feels safe. If you follow the expert's advice and it doesn't work, at least it wasn't your fault.

But here's something I've noticed after a decade and a half of building software: for every piece of advice, there's an equally credible person saying the opposite.

Topic	For	Against
Agile	The State of Agile	Why Agile and Scrum are Terrible
Microservices	Microservices	Goodbye Microservices
Strong Typing	Strong Typing: Hill to Die On	Why Dynamic Typing Is Not a Genuine Issue
Remote Work	GitLab's All-Remote Handbook	Elon Musk: Remote Work is Morally Wrong
Testing	Test Driven Development	Stop Writing Tests
Functional Programming	Why Functional Programming Matters	Why FP Will Never Be Mainstream

These aren't random bloggers. Martin Fowler helped write the Agile Manifesto. He also champions microservices. And yet smart, experienced engineers call both ideas disasters.

So when someone throws an article at you in a debate - "See? This proves we should use microservices!" - remember that there's always an equally credible article arguing the opposite. The link isn't evidence. It's one data point from one context. You can find a prestigious source to back up almost any position.

So who's right?

They all are. And none of them are. It depends on the situation.

When Fowler advocates microservices, he's describing what worked at specific companies with specific constraints. When Twilio writes "goodbye microservices," they're describing what failed at their scale. Neither is lying. They're just talking about different contexts.

This is the thing most people miss about advice. It's not a rule. It's a case study.

The person giving advice had a particular team, codebase, deadline, and set of constraints. You have different ones. When they say "always do X," what they really mean is "X worked for me in my situation."

So what do you do with advice? You don't follow it. You don't ignore it either. You extract the reasoning.

Why did microservices help company X? Why did they hurt company Y? What's different about my situation? You're not looking for answers to copy. You're looking for variables to consider.

This is harder than following rules. You have to actually understand your own context. You have to think.

Most people don't want to do this. It's uncomfortable. What if you're wrong? Much easier to point at the expert and say you were just following best practices.

But the people who do the hard work of thinking for themselves tend to end up better off. Not because the advice was bad, but because their situation was different in ways the advice-giver couldn't have known.

This isn't just true in software. It's true in startups, careers, life. The "best path" everyone recommends is the best path on average. You're not average. You're a sample size of one, with a specific combination of skills, circumstances, and goals that no one has ever had before.

The advice is useful. It tells you what's possible and what traps others fell into. But you can't take it literally. You have to figure out your own path.

That's the part no one can do for you.