Illustration by Icons 8 from Ouch!

Would you choose a tech stack to pad your résumé? Do you know someone who overbuilds in the name of professional development?

I ask because I’ve been spending a lot of time recently with Kubernetes, the container orchestrator and cool kid of the DevOps world. I’m a longtime fan of containerization (who isn’t), but Kubernetes is a significant step up the ladder of complexity. And it comes with warning signs — like huge companies full of highly-paid developers that have made basic Kubernetes mistakes and caused themselves plenty of headaches (see, for instance, the well-known hacks at Tesla, Capital One, and Aviva). In other words, Kubernetes-land promises some big benefits, but it also adds significant hurdles.

Is it stack-worthy?

When evaluating a technology like Kubernetes, the most obvious question is “Does it belong in your stack?” The same question crops up when you’re looking at cloud environments like AWS and Azure. Or server software like Nginx and MongoDB. Or application frameworks like React and Blazor. You get the idea. The world is full of problems and tools; it’s our job as developers to make them meet in the middle.

The challenge of picking the right tech stack can be a bigger issue than developing the actual solution. Sometimes, there are serious technical reasons pulling you in one direction or another. With Kubernetes, for example, it’s a question of relevance and scale. If you’re building massively trafficked applications — especially ones split into multiple services, developed by different teams and run in containers on different environments — you can’t afford to ignore it. If you’re building tiny boutique websites, you should definitely steer clear. But most projects fall somewhere in between extremes, which means you have a delicate compromise to make. That means asking questions like these:

• Does the shiny new thing deliver additional capabilities that your project requires?
• Will ongoing support require more developer time and resources than you can supply?
• Could you end up building something that won’t be properly maintained, making a serious problem or security vulnerability more likely?
• If you don’t need this technology now, will you need it in the future? (Because you don’t want to be stuck rearchitecting the entire system.)

The wrong way to choose a tech stack

And there’s another issue that developers are less eager to discuss. The tech stack you choose doesn’t just determine the future of a project. It also shapes the skills of the developers who work on it.

Reinventing the wheel for fun and profit

In modern software development, the most common application scenarios (e-commerce websites, content-management systems, back-office reporting tools, and so on) have many established solutions. And every day developers are paid to reimplement these same solutions in new projects.

Seasoned developers know that you can build everything with “classic” technologies, like the LAMP stack and vanilla JavaScript. In fact, fast-evolving frameworks might just create more churn, suck up more resources, and slow you down. New technologies are full of new headaches, just waiting to be discovered.

But then this this happens:

I’ve spent 14 years working for a small agency building these sorts of systems. I kept up with all the cool new stuff that’s come out and played with it but all we ever needed was two load-balanced app servers with a single instance PostgreSQL database, and we ran some pretty chunky systems.

I’m now looking for a new position and this attitude has come up to bite me. I’ve always been dismissive of the new-fangled complexity, but it turns out there are systems out there that churn through so much data that MongoDB makes sense, and large teams of devs where splitting systems into separate services and writing reusable components is required, which is where frameworks and interprocess communication tools come in.

— taotau

If you only build in your wheelhouse, you’re a guaranteed expert. Your development time decreases. Your testing time decreases. Your initial investment is smaller and your MVP is more polished. But you also risk limiting your flexibility to work with the next hot thing. And even if you aren’t a tinkerer that loves new toys, avoiding new tech can eventually put you at a serious disadvantage in the workplace.

Now, every ethical programmer would agree that when speccing a project, your responsibility to the client trumps your responsibility to your own professional development. And most of us have seen at least one overbuilt turkey of a project that should never have been made. Setting up Kubernetes for a small business’s reporting database is a clear-cut case of programmer malpractice. But where do you draw the line when the project requirements are fuzzy? And will you eventually need to reject projects that are in your area of expertise so you can go further afield to develop new skills?

New tech, same old story

Following the crowd or joining a community?

In my professional life, I tend to keep it simple. And when choosing a tech stack, there’s plenty of opportunity to follow the programmer’s commandment of YAGNI (You Ain’t Gonna Need It), or the equally useful ISW (It Still Works). However, there’s a caveat.

Developers don’t just adopt technologies, they adopt the ecosystem that’s built up around those technologies. Yes, there are plenty of old technologies that still work perfectly well, if you know to navigate around their weaknesses and pain points. But the world is moving on. The focus has shifted, and although these technologies still work, the community around them is sparse and quiet. If you need informal support, there are fewer people to help you out. If you need to recruit new talent, their are fewer developers interesting in joining in. New features, tooling, and community libraries aren’t arriving soon — or ever. Instead, they’ll appear in the thriving ecosystems around newer, more popular technologies.

Reasons like these mean that it isn’t always overbuilding to go with the shiny new thing. But what if your need to progress as a programmer outgrows your company or your contracts? Ultimately, you may need to move on. But first, look for other ways to patch the gaps and get some time to work with cutting-edge technology. Join a community that uses the new tech that’s in your domain. Build a hobby project. Even better, contribute to an open source project, where you’ll need to apply the new stuff to a practical piece of living software. Eventually, you’ll find the mapping that translates your existing skill as a developer — solving the familiar problems — to analogous concepts in the new tech. And as long as you aren’t just distracted by marketing hype or taken over by developer FOMO, it’s worth your time. Your growth as a developer depends on it.