It started with a LinkedIn Post

Your company builds a CRUD app that serves 5,000 users. Your interview asks candidates to optimize distributed systems at scale. What are we doing here?

The post details an all-too-common problem, an application that honestly doesn't need to deal with scale, but their interview process (and likely their engineering team) is caught up worried about problems they'll never have.

But it sets the tone, this is how you should be approaching problems. We build for scale, we build to be a billion dollar unicorn (which is a complete engineering misstep and frankly in my opinion: negligent), it doesn't matter that we only make $2m/yr and our growth is 9%/mo. We don't build for what we're going to do, we build for the never-will-be.

That tone carries over to the whole industry.

What ARE we doing here?

Over my 2+ decades of experience I've seen:

• Time-wasting automation: where neither time nor consistency improved (but a job to maintain those scripts was created)
• Microservices: I'm going to come out and say it, for the vast majority of companies, microservices harmed, significantly. Likely if your company isn't shoving 9+ figures of revenue through its doors, this initiative was for job-creation, if you think you'll be a 9-figure company, like every other 9-figure company, fix it when that's on your horizon, not your day-dreams.
• Mediator/Actor models/CQRS/etc: Needed in very specific circumstances, I've seen it complicate and make systems fragile and slow more often than robust and efficient.
• Kubernetes: If I'm lucky a Kubes deployment is kept simple, most of the time they're engineering it to need to orchestrate a thousand servers, no. (Expect me to publish an article about frustration that Kubes is kind of an annoying-but-best go-to, this doesn't apply to those deployments)
• Rewriting Libraries: I've seen many engineers that didn't like how something was done, didn't just sit down and tolerate it, and made a more fragile, more opinionated version that now was the company's problem to maintain.

The gap between the two stacks is the playground.

Why Do Engineers Keep Doing This?

James Anderson from our team put a name to it: "Resume-driven development." It's pretty on the nose, but there are a handful of reasons it happens:

• Padding their resume with "accomplishments" - those accomplishments aren't actually improving your bottom line, but they'll sure improve their resume when they jump ship to a new job.
• Read too much Reddit / lobste.rs / Hacker News - A flavor of "keeping up with the Joneses", other Engineers get to work with cool new toys, I want to also!
• "This is what we did before" - Engineers basically rubber-stamping the same solution their entire career.
• Not actually engineering - A flavor of above, but to a point.

There are so many engineers that just kind of… don't think, they rubber-stamp solutions regardless of how ill-fitting they are.

So How Do We Stop This?

Most of this just comes down to better vetting and better management.

Those are honestly two entire other articles in and of themselves, stay tuned for those.

The bottom line is this: engineering is expensive… mentally - it takes a very concentrated and pragmatic approach to do well, and the best engineers I've worked with weren't the ones chasing the newest pattern or padding their resume – they were the ones solving the actual problem in front of them. Knowing what your business actually needs is what separates an engineer from someone just screwing around on company time.