Over the last twenty years, I have used over a dozen languages professionally, from C to Common Lisp, from Java to Python, from C++ to Typescript.
I particularly agree with the point at the end about legacy codebases, many of which are powered by PHP and JS:
A legacy codebase means that the product is performing well. It means that I can often make immediate and impactful improvements.
For me, nothing comes close to the pleasure of improving a product with many users.
Sign in or Join to comment or subscribe
I love sensible discourse like this. Basic, imperfect, USABLE, legacy is BY FAR still the norm over serverless/microservices/SPA/GraphQL/“center-stack”….(choose your newfangled poison).
The shills for all this (generally heavily funded) new tech have done a great job drowning out the reality of how MOST tech stacks operate by condescending and shaming…hammering us about some highly-subjective “right way” or how much better their wildly-complicated abstractions are.
They stand on the shoulders of giants, while simultaneously pooping on said giants. Poor giants! LAMP, jQuery, Rails, Django, etc are alive, well, and providing enormous value thankyouverymuch. They just don’t have big, loud mouths (except for DHH maybe)
Thanks for reading! (author here)
Anybody advocating for “the right way” is going to be off. The right way depends on the project and the situation. What strategy to apply derives from the constraints, the goal, the leverage opportunities.
But knowing and learning all the new stacks is very useful. There is value in combining a 15 year old stack with a few serverless lambdas, or leveraging graphQL to move off a slow legacy frontend. As long as you stay flexible and focused on both delivering, and creating a sustainable solution and working environment, anything goes!
oh hi! nice article. I hear you, I’m all for innovation, and adopting technology that makes sense. I’m not a total luddite. I employ lots of “new” tools and technologies, where appropriate. I even use GraphQL, when forced to :P
Largely, I’m raging against highly-paid, exploitative shills for “new tech” that try to undermine old tech (like monoliths) by using shame, condescension, and the human propensity to gravitate toward the “new shiny thing”.
This leads kool-aid drinking tech decisionmakers to shoehorn overcomplicated tech into a solution for a business need (that could be solved in a MUCH simpler way), because they really want to be cutting edge, play with new stuff, build their resume, or because complexity makes them feel smart and important. Once those decisions get made they are HARD to undo.
How many businesses get stuck with a rats nest of Angular/React/Svelte/whatever because their tech lead went whole hog then left…when their site didn’t even need to be state-based to begin with. If they’d just just stuck to the Rails program they wouldn’t be up a creek and hundreds of thousands poorer. Not only have I seen this, I’ve lived it. I’ve made some poorly-reasoned tech decisions and learned the hard way.
I love stories like stackoverflow using a 15-year-old custom-built monolith hosted ON-PREM, and Craigslist still using MySQL and Perl. It’s not that they haven’t truly evaluated new technologies, it’s that they put the questions “what problem are we trying to solve?” and “what is the simplest possible solution” ahead of all else.
Stuff like jQuery or monolith shaming drives me absolutely bonkers. We devs tend to live in some fantastical future and forget how the web actually works today.