Engineering jokes
Everything should be made as simple as possible, but not simpler
When you’re building something customers want, it’s almost never the technology they’re buying. They are buying a solution of the problem, a feeling, a superpower. This is why I rarely write about tech, which, for an engineer, seems to be a contradiction. The other reason is simpler: the technical audience is clever, deeply opinionated, and my rambling makes no sense for them….but
Most engineers grow up in a bubble. They mistake their own narrow experience for universal law. Their arguments are a tiresome loop of opinions based on what worked for them, on their pet projects, or on the last framework they mastered. I have my own opinions, of course, but I try not to confuse them with the laws of physics, and of course I fail every day.
The debate over programming languages is a perfect example of this.
From one perspective, the language doesn't matter. From another, you need it to attract the right people. Everyone thinks hiring from a large talent pool—say, Java engineers—is the safe, logical bet. My experience shows the opposite. It’s a trap. You get a flood of resumes, but you’re filtering for compliance, not for passion.
Hiring from a smaller, more obscure talent pool forces you to be smarter. It filters for curiosity.
So, you’re building on Java? Your first priority shouldn’t be to find a Java guru. It should be to find brilliant misfits who are obsessed with your product and are willing to compromise on their favourite tool to build it. Find the developer whose main gig is in Java but who spends their weekends building oddities in Lisp or Rust. Those are the minds you want. They understand that the tool serves the mission, not the other way around. This doesn't scale if you need an army, but if you're building something new, you don't need an army. You need a commando unit.
Opinionated? Let’s have more fun:
The Illusion of Scale
The other great fetish of our industry is "scale." Engineers love to talk about the profound difficulty of building scalable systems, but for most, this is a phantom menace. Let’s be honest: in an era where you can spin up endless auto-scaling nodes on AWS or GCP with a single Terraform file and plug into databases like Spanner or Aurora, the technical challenge of scaling has been largely solved. If you’re smart enough to separate your transactional and analytical workloads, you won’t face a real scaling problem until you reach a massive user base.
Ping me when you have 10 million customers using your product concurrently. Then you’ll need a bit of engineering.
So if your system is struggling at a smaller scale, the problem isn't the technology—it's the people most of the time. The issue stems from two places: manufactured complexity and a lack of skill in simplification.
The first is CV-driven development, where engineers build overwrought systems for their resumes, not for the customer.
The second is blindly repeating industry mantras—Microservices, DDD, CQRS—without understanding the context. These are powerful tools, but you don’t give guns to children.
The common excuse for all the complexity is the need to "ship faster," as if thinking is a luxury. This argument is absurd.
When you cook a new dish, do you just throw everything into the oven and hope for something edible? Or do you spend five minutes looking up a recipe? Those five minutes of thought save your dinner.
Rushing to implementation without a plan just means you'll have to cook it all over again.
The Real Frontier
Of course, there are genuinely interesting technical questions on the horizon.
Is it finally time for functional languages like F#, OCaml, and Rust to take center stage in the age of AI? (Sorry, Haskell, you missed the train again.)
What would a truly great development workflow look like with AI agents in the loop?
Can we build in-house principal engineer AI bots, trained on all our incident data and pull requests, to review code, participate in all RFC and solve problems autonomously?
These are exciting puzzles. But they are still not the product—unless, of course, you’re building products for engineering teams.
In the end, the customer doesn't care how you ship the software that solves their problem. They don’t care if you hired a thousand people or just ten people armed with an army of AI agents.
What they care about is a fantastic user experience, support that actually helps, and having their problem solved in a way they never anticipated.
It should feel like magic. Technology is almost always just the tool, the plumbing behind the curtain.
But to make the magic work, you have to know your tools inside and out.