56 ms·

>The most in-demand skill was Ruby on Rails, with engineers skilled in this framework and scripting language receiving 1.64x more interview requests compared to

>The most in-demand skill was Ruby on Rails, with engineers skilled in this framework and scripting language receiving 1.64x more interview requests compared to the marketplace average. Ruby on Rails bumped Go from first place in 2022’s report to fourth this year. Woah. That’s an interesting finding. I wonder what RoR is doing to make it so in-demand?

digianarchist 4y ago
Probably advertising skew. I remember Hired being advertised on RoR specific boards and sites.
dcchambers 4y ago
Many of today's big tech cos, which were unicorns in the 2005-2015 era, were built on top of Ruby/Rails. Today those companies have diversified their tech stacks but for the most part the core rails monoliths aren't going anywhere. They need engineers to work on them.
treis 4y ago
It's not necessarily in-demand. It's the ratio of jobs to applicants. Both numbers can be low which anecdotally feels right for Rails. It's not the new hotness anymore but there's still plenty of systems to maintain/expand. Can be hard to hire because fewer engineers want to do it but the systems can't easily be transitioned to a new language.
lbrito 4y ago
Same result as 2021. Must be due to all the "it is dead and forgotten" hate Ruby gets :)
return_to_monke 4y ago
because languages that were popular before but aren't now are always a hit. see COBOL for example.
jcadam 4y ago
Yep, I have RoR on my resume/LN profile from years ago (rails 3.x), and I get recruiters spamming me - mostly for legacy maintenance/modernization/porting to another stack type jobs. I've moved on, not so interested in going back...
phendrenad2 4y ago
RoR enables developers to make a lot of progress on their app in a short amount of time... initially. Most developers have never seen a legacy Rails app, or are still in the self-deluded "this time it'll be different" phase. So they jump wholeheartedly into the Rails ecosystem and build their app the "rails way". Not knowing the pitfalls, they fall into all of them. A few years later, you have a successful Rails app with (1) slow, data-coupled tests (2) spaghetti code in your models and controllers (3) probably dockerized, relies on heavily outdated linux version and no one can update it within a sprint so it never happens. So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now).
- swagonomixxx 4y ago
  I have personally witnessed "legacy" rails apps (were ~4 years old, Rails 5 was around but we were on Rails 3 IIRC) and they are not really unlike normal legacy apps but they definitely let a lot of crap seep in due to loads of contributors and almost zero ownership on the codebase. I wouldn't say this an exclusively rails problem though. Testing was a complete nightmare, and there was so much random middlewares that were "mission critical" but no one knew what they did. And as you said, scaling was horrible. We had like a hundred servers, each running 20 unicorn instances, to serve our API at the scale we had (~5 million users or so, I forget the DAU)
  - ravenstine 4y ago
    > random middlewares The whole concept of "middleware" in Ruby server applications was a huge mistake. Your average Ruby developer has no idea how any of that shit works, and it's an unnecessary abstraction over taking request data and passing it through a function, something that should be simple for even a junior developer to figure out. Somehow it was decided that having a standard for the shape of data wasn't good enough; there had to be a demi-standard for modifying request data before it reaches the primary application code. If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design.
conorh 4y ago
I think there are many RoR projects that continue to run, so probably demand still there - we've been maintaining several RoR projects for 7+ years. Recently we've stepped into several JS projects that have 2-3 competing JS frameworks in the same project. Any project becomes difficult to maintain over time without a continuous and thoughtful investment of time, but at least Rails doesn't have that particular problem of framework churn (even if parts of it may change as a whole it has an upgrade path that is well trodden). We do a lot of React/Next.js etc. work, but for the most part Rails is what we reach for (maybe with a sprinkling of React) when we have a standard web project, ie. most of them.
thebigspacefuck 4y ago
In my experience with Hired there are a lot of companies that started around 2010 that chose RoR and haven’t quite made it yet.

digianarchist 4y ago

Probably advertising skew. I remember Hired being advertised on RoR specific boards and sites.

dcchambers 4y ago

Many of today's big tech cos, which were unicorns in the 2005-2015 era, were built on top of Ruby/Rails. Today those companies have diversified their tech stacks but for the most part the core rails monoliths aren't going anywhere. They need engineers to work on them.

treis 4y ago

It's not necessarily in-demand. It's the ratio of jobs to applicants. Both numbers can be low which anecdotally feels right for Rails. It's not the new hotness anymore but there's still plenty of systems to maintain/expand. Can be hard to hire because fewer engineers want to do it but the systems can't easily be transitioned to a new language.

lbrito 4y ago

Same result as 2021. Must be due to all the "it is dead and forgotten" hate Ruby gets :)

return_to_monke 4y ago

because languages that were popular before but aren't now are always a hit. see COBOL for example.

jcadam 4y ago

Yep, I have RoR on my resume/LN profile from years ago (rails 3.x), and I get recruiters spamming me - mostly for legacy maintenance/modernization/porting to another stack type jobs. I've moved on, not so interested in going back...

phendrenad2 4y ago

RoR enables developers to make a lot of progress on their app in a short amount of time... initially. Most developers have never seen a legacy Rails app, or are still in the self-deluded "this time it'll be different" phase. So they jump wholeheartedly into the Rails ecosystem and build their app the "rails way". Not knowing the pitfalls, they fall into all of them. A few years later, you have a successful Rails app with (1) slow, data-coupled tests (2) spaghetti code in your models and controllers (3) probably dockerized, relies on heavily outdated linux version and no one can update it within a sprint so it never happens. So they hire "senior rails" devs and throw them at the problem (after all, the initial setup speed of Rauls allowed them to be successful and have money now).

swagonomixxx 4y ago
I have personally witnessed "legacy" rails apps (were ~4 years old, Rails 5 was around but we were on Rails 3 IIRC) and they are not really unlike normal legacy apps but they definitely let a lot of crap seep in due to loads of contributors and almost zero ownership on the codebase. I wouldn't say this an exclusively rails problem though. Testing was a complete nightmare, and there was so much random middlewares that were "mission critical" but no one knew what they did. And as you said, scaling was horrible. We had like a hundred servers, each running 20 unicorn instances, to serve our API at the scale we had (~5 million users or so, I forget the DAU)
- ravenstine 4y ago
  > random middlewares The whole concept of "middleware" in Ruby server applications was a huge mistake. Your average Ruby developer has no idea how any of that shit works, and it's an unnecessary abstraction over taking request data and passing it through a function, something that should be simple for even a junior developer to figure out. Somehow it was decided that having a standard for the shape of data wasn't good enough; there had to be a demi-standard for modifying request data before it reaches the primary application code. If you have to tell a middleware what order it's supposed to run in with relation to other known middlewares, chances are the middleware system itself is a poor design.

conorh 4y ago

I think there are many RoR projects that continue to run, so probably demand still there - we've been maintaining several RoR projects for 7+ years. Recently we've stepped into several JS projects that have 2-3 competing JS frameworks in the same project. Any project becomes difficult to maintain over time without a continuous and thoughtful investment of time, but at least Rails doesn't have that particular problem of framework churn (even if parts of it may change as a whole it has an upgrade path that is well trodden). We do a lot of React/Next.js etc. work, but for the most part Rails is what we reach for (maybe with a sprinkling of React) when we have a standard web project, ie. most of them.

thebigspacefuck 4y ago

In my experience with Hired there are a lot of companies that started around 2010 that chose RoR and haven’t quite made it yet.