Rails is back isn't enough

30 Jul 2022

The article below is on a topic that has bothered me for a long time — the lack of opportunity for junior Rails developers — spurred by some recent Twitter energy around Ruby on Rails being “back”. I got mentioned in one of the viral threads about Rails being back which jump started my brain into writing this article, but I don’t write it to admonish folks who are excited about Rails and want to bring in more Rails developers with educational content. I love that work, and appreciate the positive energy, and the commitment to building great content. The Rails is back energy just happened to kick off this train of thought about what the long term outlook of the Rails world is when there are few paths for folks to make their living as junior Rails developers.

2022 is an exciting time for Rails developers.

The release of Rails 7 brought Hotwire into the default Rails package along with new asset bundling solutions to get applications off of the dreaded Webpacker. For fans of Redis, the new Kredis gem is a suggested default for Rails 7 applications, offering tools to make it easier for Rails devs to do fun stuff with Redis.

Outside of officially endorsed Rails projects, the StimulusReflex team is steadily making improvements to StimulusReflex, CableReady, and the related set of projects that make building modern, reactive applications in Rails easier than ever.

Despite all of that excitement, folks in the Rails community have gotten used to dealing with “Is Rails dead? Rails is dead.” questions and comments that discourage developers from choosing Rails for their next project.

“Is Rails dead?” questions are silly if you spend any time keeping up with the Rails ecosystem. Rails isn’t dead, it is alive and kicking, just like it has been for nearly 2 decades. Many billions of dollars have been earned riding the Rails and new businesses continue to be built on the foundation that Rails provides.

As a reaction to “Is Rails dead?”, Rails enthusiasts are leaning into a “Rails is back!” narrative — we aren’t dead, we’ve got all this cool new stuff to share!

I don’t think the noise of “Rails is dead!” and “Rails is back” is particularly interesting. Neither narrative adds any value to the conversation. As a Rails enthusiast (and sometime Rails content creator), I love the idea of “Rails is back”, but I don’t think it gets us where we are trying to go. To begin, “Rails is back!” isn’t very helpful because Rails isn’t back. It never left. Its place in the world of web frameworks just changed. No new JavaScript library or gem will fundamentally change Rails’ value proposition or turn back the clock to a time when Rails was the hottest framework on the block. That time has long gone.

Instead of worrying about Rails coming back, I’m more interested in how to make Rails more accessible to new developers. The long term health of the Rails community relies on attracting and nurturing new Rails enthusiasts, not how loudly we yell about the cool stuff you can build with Hotwire (and I’ve yelled very loud about it myself). I don’t see any evidence that Rails is back for junior developers, and I don’t see much indication that it will be without major philosophical shifts from folks hiring Rails developers.

There are very few options for junior developers to get their start in Rails. New web developers are likely to have far more opportunities if they learn React and Node to land their first gig. The Rails world is welcoming and kind (MINASWAN is real, in my experience), but we don’t make it easy for new developers to earn a living. Unless we fix this problem, Rails will eventually lose real momentum — the people leading Rails today won’t be pushing the framework forward in the decades to come.

Speculation time: I suspect that many companies hiring Rails developers are hiring exclusively for senior level roles because companies using Rails tend to run quite lean.

At my last company we built a multimillion dollar SaaS business with a literal handful of engineers. When I left after ten years, we had two large, complex B2B products supported by eight full-time engineers and one engineer manager. We had less than five engineers for the first five years of the company’s life. Our competitors, mostly using the latest JavaScript frameworks (one even built their own, for unknowable reasons), had dozens or hundreds of engineers. To keep up, we had to be dramatically more efficient than them.

Rails let us run that lean, but it came with an obvious tradeoff. When you are running lean, there is very little space to provide a supportive environment for juniors. In my time there, I hired three junior developers — one miraculously figured it out with very little guidance outside of what she could learn by osmosis and became a very talented lead. The other two left because my team didn’t provide the environment they needed to learn and grow at a reasonable pace. After those failures, I did the same thing a lot of engineering leaders have done and stopped hiring juniors. From what I know of other companies in the Rails world, this is a common experience. Hire juniors, fail to support them because there is no time to do so, see the juniors fail, stop hiring juniors.

Over time this cycle leads to a dearth of junior and entry level positions for Rails developers. And without junior developers, the pipeline of senior talent eventually runs dry. If there are no juniors slots open, where do you expect the seniors to come from?

Eventually, this has severe consequences for the health of the Rails world, and makes me skeptical of any unqualified claims that Rails is back. If you can’t recruit senior Rails talent to keep up with demand as your product grows, that becomes a business risk. I’ve seen this personally — hiring experienced Rails developers is extremely hard, to the point of being nearly impossible for small companies without large budgets and a well-known brand.

In the future, Rails is at risk of becoming non-viable for new businesses with big aspirations. Not for technical reasons but because recruiting Rails developers is just too difficult. We aren’t anywhere near that yet, but the talent deficit will eventually lead us there. Responsible founders and CTOs will choose other options because they know they’ll be able to build a high quality team faster.

In my current job search (I’m available for engineering and product leadership roles, dear reader) I have heard a version of this story multiple times from CTOs who profess a love for Rails but chose another option for their company because they didn’t think they could hire enough Rails developers to keep up with their growth plans. As much as I love Rails and the power that Turbo, Stimulus, and friends provide, cool new toys won’t fix the talent pipeline problem.

Could the new toys attract new talent to Rails (or bring some developers back to Rails)? Yes, sure. I’ve talked to a number of companies that are reevaluating their options because of the efficiency gains they hope to see from Hotwire; however, those are usually companies that are already using Rails extensively and just want to get away from React on the frontend. That’s not going to move the needle much in the long run.

What do we do?

I’m not sure. I don’t have a grand idea of how to fix the talent pipeline problem. I’m just a guy that ran a Rails shop for a while and now spends a lot of time thinking about Ruby on Rails. Maybe all of my ideas here are wrong!

Maybe there isn’t even a talent pipeline problem and I’m just a huge goof that was bad at recruiting and worse at long-term planning. Maybe I’ve had the bad luck to talk exclusively to other companies that are also bad at recruiting and long-term planning.

Assuming there is a talent pipeline problem, and that the pipeline problem is getting worse, here’s some more speculation and a bit about what might help:

I think the talent pipeline problem is tightly coupled to what makes Rails so attractive in the first place. The Basecamp team has a huge influence on the Rails world, and they showed us that shockingly small, self-funded companies can build large, complex, innovative products that compete and win against established players. That’s really cool! They have had extraordinary success with a very small team. Emulating that success is a huge driver for many folks building companies on Rails, for good reason.

But it is easy to move from “we don’t need a big team to get great results” to a related but less defensible idea of staying extremely lean and only hiring when it really hurts. Speaking from experience, if you can do a lot with a little, it starts to feel like your competitive advantage is your tiny, very experienced team. Go far enough down that road and you will find yourself building a company that can’t support and nurture junior talent (and burns out your senior talent).

With the dangers of the extremely lean ethos in mind, one path to fixing the talent pipeline problem might be reevaluating what building a successful company looks like, and rethinking expectations placed on engineers in Rails shops.

Can you build a great product and get it to market with a few really talented Rails engineers? Yes, absolutely. At my last company, we were doing millions in revenue (and profit each year) with two (2) full-time engineers and one of those engineers was me, fresh out of a bootcamp. Eventually, that masochistic commitment to being lean put tremendous strain on our engineering team, and I suspect our experience matches any other company that takes the extremely lean, self-funded route. It just starts to hurt too much and you cut everything that isn’t shipping code.

As you grow, redundancy, sustainability, and reliability (of systems and people) all become more important than continuing to wear the extreme lean badge of honor. Investing in a pipeline of junior talent, giving your senior engineers time to coach and mentor those juniors, and slowing down your cadence to give everyone room to breathe in those new processes likely leads to a more successful company. It certainly leads to a more sustainable pipeline of talent moving up the ranks from junior to senior and beyond.

A single company rethinking the stay lean or die trying approach won’t fix the problem, but if you are in a position to influence growth plans at your Rails shop, think about what the future looks like on the two paths you can take. On one path, you stay lean, you hire seniors, and you keep struggling to find the 5+ years of Rails experience you require for each new hire. On the other path, you slow down a bit. You hire a mix of juniors and seniors, you invest in those juniors, and you build a pipeline of talented folks at all levels of the engineering org.

Which path feels better for the health of your business, your team, and the Rails world?