dimiro1's notes

I recently got criticised for my tech choices on a few projects. The criticism wasn’t necessarily wrong, but it missed something crucial: context.

It’s easy to look at a project from the outside and think “why didn’t they use X?” or “this would be better with Y.” But when you’re not inside the constraints, when you don’t know the timeline, the team size, the actual problem being solved, or what success looks like, those judgments often miss the point.

Every project has its own shape

Here’s what I’ve learned building things at startups: each project needs you to look at it from different angles. A rule engine for transforming invoices has completely different constraints than a real-time AI agent or a B2B dropshipping platform.

What worked yesterday might not work today. The “right” technology isn’t absolute. It’s right for this problem, this team, this moment.

Sometimes that means choosing Go because you can deploy a single binary and move fast. Sometimes it means Clojure because the problem is about data transformation and you need the flexibility to let business analysts modify rules. Sometimes it means boring, proven tech because you need to ship tomorrow, not in three months.

Good developers adapt

The developers I respect most aren’t attached to a single stack. They can be effective in any reasonable environment. They learn what they need to learn. They make things work.

If you can only be productive in one language or one framework, that’s a limitation worth examining. The ability to assess a problem and choose appropriate tools, even unfamiliar ones, is more valuable than deep expertise in whatever’s currently popular.

Don’t let the market choose your stack

There’s a tempting trap: choosing technology mainly because it’s easy to hire for.

Yes, hiring matters. But don’t let it be your primary decision. Good developers can pick up new technologies. If you’re the kind of person who learns what’s needed, finding work won’t be your problem.

Context is everything

When someone criticizes your technical choices without understanding your constraints, it says more about them than about your decisions. People feel uncomfortable with what they don’t understand. They stick to what’s familiar.

That’s fine. Use PHP, JavaScript, Clojure, Rust, whatever makes sense for your situation. Maybe you’re experimenting and learning. Maybe you’re moving fast and need something you know. Maybe the problem really calls for specific capabilities.

The important thing is to solve the problem with the right balance for your situation: performance, developer happiness, maintainability, time to market, team capability. These trade-offs change with every project.

Understanding this, really understanding it, is what separates experienced builders from people who just have opinions about technology.

The other day I overheard two “vibe coders” talking about their project: “No, we need to build the backend first, and then the frontend will communicate like this and that...” Listening to them, I was reminded that the hardest part of software development isn't actually writing code. It's managing complexity.