Comment by throwanem
5 days ago
> That job turned out to be shoddy, ancient, flaky tech all the way down, with comfortable, long-tenured staff who didn’t know (and did NOT want to hear) how out of date their tech had become.
Every time.
I don't care about your stack; obviously I have taste and preferences but I'm a professional, I'll work with whatever, as long as it isn't Rails. (Because there is no good work in that world.) But it will not take me a full day with access to your repos before I know whether there's anything you can do for me past signing the checks.
genuinely curious what your take is here, I have been in security engineering for 5-6 years, then most recently a startup that's using rails. It honestly does not seem that bad even though we're using an ember frontend.
What is your thought process here? Is it the notion that you can ship as fast as possible, and that creates a shitty environment given that you're a hamster on a wheel getting measured by output since "you should be able to ship fast?"
If you mean about Rails specifically, it's that the total lack of discipline in both language and framework makes it impossible to build a product maintainable by more than one person, so every "successful" project has one or a few covert empire builders running it, usually with more political than technical success. That's not a kind of project that pays enough to be worth the trouble, even before we talk about opportunity cost, and the framework itself is a dead end that peaked in 2011 and has had about as many "renaissances" since then as there've been years of the Linux desktop. If I want to go live under that kind of rock, I'll do it with Salesforce, where the pay is better and no one thinks they're cool for poking at a keyboard all day.
Strongly disagree. I've seen bad code or maintenance in all the languages. Sure, some ecosystems seem to attract worse practices, but the absolute best software engineering principles I ever learned in my multi-decade career were at a Rails shop. Everything was extremely well maintained, tested, CI/CD were great even before that was a thing. Not to start flame wars about refactoring or what it means to maintain code more, but that place was absolutely full of people who cared and kept those projects at the highest of caliber grade. You can find good, bad, and ugly in every ecosystem but I personally don't think Rails was ever even remotely bad. You can have an amazingly well-maintained setup and still be super productive. It's really about the people and the company spending the time, money, and energy to care. (Edit: typo)
1 reply →
One of the largest codebases I've ever worked on, generating billions in revenue every year to this day, is in Rails. Over a thousand hands have touched it, and none of the original people are still around to hold an empire.
I'm with you on the general lack of discipline enforced by Rails; this codebase isn't fun to maintain, precisely for that reason. All the same, I don't think your critique is fair or even that accurate.
But that's from my POV working at bigger companies. Maybe it looks different as a freelancer for smaller shops.
4 replies →
First, props for your candor. It’s refreshing.
I do wonder if Rails is so bad compared to other frameworks that it deserves such a distinct treatment.
Over the decades I’ve worked with at least half a dozen popular frameworks that fit this description, is the same for you or is Rails truly unique in this regard?
7 replies →
This must be a god level troll post.
7 replies →
Hard disagree. I work on one of the largest Rails codebases out there. Millions of lines of code running in a monolith. I have learned more in this shop about scaling, observability, mature system designs, zero downtime upgrades, deploys, etc…
I been in this field for almost 30 years and have worked with whatever tech the job required. Still I learned more at a Rails shop with more than 200 engineers all working in the same monolith shipping to production multiple times every day.
5 replies →
Can confirm, I'd charge a laaaarge premium to ever work on an existing Rails codebase again.
Did it several times over a period of 15 years and they were always a wreck and unreasonably painful to work with. Every single time.
I'd start a green field one, no problem, provided I get veto on gem choices ("Let's use some twee fucking template language that's a ton worse-performing than the default and doesn't let you programmatically control nesting levels / end tags because it's terribly designed" yeah how about we don't do that because it's going to make my life a living hell) without charging a premium. But no more onboarding to rails codebases without enough money to make it worth my hating every second of work for the (assuredly short) duration.
... and I like Ruby!
Ruby is only just now getting static typing and Rails has a lot of "magic" as part of its value prop. If you're trying to launch something of low to medium complexity quickly and stay on the happy path of the tools in the ecosystem then it works great. The lack of rigor from dynamic typing and latitude afforded by Ruby's expressive syntax can quickly become a footgun though.
My pet theory is that LLM coding is going to give the upper hand to more verbose languages like Golang or Typescript because more of the execution flow will end up explicitly in the LLM's context. Convention over configuration-type frameworks ruled when one-person code bulldozers shipped MVPs but Continue is upending this paradigm.
I wouldn't really call it a pet theory at this point; HN's front page daily further shows that LLMs suck at magic and excel at boring code, seeming quite immune to boredom. But I would argue what makes the difference for LLMs is not verbosity but locality, whether syntactic or analytical ie whether the type is just written here or you have an LSP server to query for it, the distinction is, being able to point to an arbitrary symbol and get lots of rich context about it.
It's a game changer for human devs also, and not really one I would expect a serious Rails habitué to necessarily evaluate in a way that's reliable. What did someone call that once, the "Blub Paradox?" Silly name, but that's this industry for you.
I've worked with Ruby. It was a delight. But it has to be maintained, dynamic typing loses upfront safety & allows for a mess where you have to analyse the whole program to have any idea what some function is expected to take in & put out
I'm glad static typing came back
Ruby is a fine toy and an awful tool, the other Perl that Python killed.
Rails should have incurred some kind of criminal indictment.
I wish I hadn't mentioned either, because now no one will talk about anything else.
Analyze the whole program? I steadfastly refused to ever attempt do that. "method(:foo).source_location" from the Rails console and I've got the only answer that matters. Most functions were monkey patched at least once anyways, so you'd never know by searching for the implementation where it was.
2 replies →
Came back? Everyone and their cousin is falling over themselves to get on the AI train[1], and spending incomprehensible amounts of energy trying to "lint" their way to sanity as if the python ecosystem isn't fighting tooth and nail to "be dynamic"
So, yeah, I look forward to the cycle tacking in the other direction but today ain't it
1: to say nothing of the fact that model servers exist so why the fuck are you writing business logic in a language that DGAF just because your data scientists have a hard-on for pytorch
As evidenced by the other replies by OP, it’s a hyperbolic and bad take. There’s plenty of companies doing just fine with Rails codebases. Many of which are a decade or more old now and have done just fine with the inter generational transfer that happens due to natural employee attrition and haven’t been held hostage by one or two all-knowing engineers.
I said "empire builders," not "engineers." Nor did I say "held hostage."
My perspective on this is that of a working engineer who made a deliberate choice, now nearly 15 years ago, to avoid ending up stuck in the same decreasing-radius career spiral I saw Rails leading me toward - so I went and did some other things, then spent a decade building modern TypeScript instead, mostly on Kubernetes, without losing the ability to knock out a quick one-off script or architect a system top to bottom as I need. It's worked out splendidly for me! I suppose I might have done as well if I decided differently, but I admit I don't see how.
I dunno; maybe I'm hopelessly naïve or out of touch, but I'd pay attention to the compensation, benefits, work environment, and colleagues to know whether this is a place I'd actually like working at long before I pay attention to whether this is a job that always uses the latest cutting-edge tech so I can make sure my resume has the best words in it for the next job I look for...
Unless desperate, why would I have accepted an offer or taken a contract if all of those didn't already seem in line? Why would you have?
The thing is, people can lie about all of those, but whatever social problems exist in the environment will invariably be evident in the code.
What's the old saw about how if you have four teams working on a compiler, you'll get a four-pass compiler? Conway's law [1], that's the one. That one works in both directions. When you're reading code that seems like it would be 0.1x as complicated if any of the people involved in writing it ever spoke to one another, the wise engineer new to this environment begins asking, why do these people never speak to one another? But not too loud!
[1] https://en.m.wikipedia.org/wiki/Conway's_law
......and the tech stack is usually obvious in the job posting.
If it's that vitally important to you to only work at jobs with tech stacks that will "advance your career" beyond that job, why would you even apply to a job that doesn't show one you consider worthy?
1 reply →
Rails is so good that all the issues become political until you get to stupid large scale.
Such an insightful comment and the most underestimated feature of Rails.
It does cause serious problems if you ever start needing engineers, though, unless you're a better politician than people who imagine themselves skillful politicians almost ever are.
3 replies →
> That job turned out to be shoddy, ancient, flaky tech all the way down, with comfortable, long-tenured staff who didn’t know (and did NOT want to hear) how out of date their tech had become.
Yeah, yet their job listed a bunch of shiny "modern" cloud stuff they were doing, but they actually have three busted serverless functions and some dusty Java IBM Websphere things floating around running the whole business, while the job description listed 432 different things they were "looking for".
Can you expand on why you avoid Rails? I'm legitimately curious!
Edit: I see your other replies, nvm!
I found a correlation between Rails and lower salaries. Not sure why though. I was actively looking to move to Rails for a change of scenery, until I realised it comes with a tax.
What country were you searching in? I'm an American work-from-home Rails + React engineer (admittedly with 12 years of experience), and I'm in the 96th % income bracket for individuals of my age (mid-40s). And I just started this position a month or two ago, so it's not like I got this job during the time of ZIRP.
IMO it completely depends on the company you're working for. I've seen job ads targeting my skill level offering $200k/year, and others offering $130k or even less. There will always be companies out there either trying to lowball people, or who genuinely don't operate in a vertical which is profitable enough to pay top-band salaries.
3 replies →
I mean, if you want to tie your fortunes to one team and company forever, then sure, it can make sense.
I've had decades like that in my career, which began in the nineties. It would be nice to have another such decade; I don't enjoy always keeping one eye on the exit and my back to the wall, rather than being able to count on a given environment to stay stable enough long enough with enough upside to really repay my investment.
This doesn't feel to me like such a decade, though. Too much is changing too fast.