Hacker News Reader

Comment by functionalfoo | Hacker News Reader

The truth is not nice, but here it goes:

A lot of companies got burnt on ruby related projects. Especially anything rails related. There is a steady pipeline of work right now for skilled developers to migrate services and code from ruby to go, Scala, java - basically anything else except ruby.

I have earnt quite well doing such gigs, although I tend do more erlang/elixir stuff these days.

I would always ask the clients what happened, and why they want to migrate rather than maintain or even build out their ruby code bases, and the answer was always the same - the developers in the ruby space were mostly sub-par. Often several degrees below java developers in terms of skill and ability. I would say it tallies with my experiences too.

It is also for this reason they are not using node js - because it was seen as the next shiny, all the half-devs from ruby jumped onto it, and the risk of crap codebases from the same amateurs is ever present.

View on HN

This has been my perception too; over the past couple of years we've been inundated with recruitment agencies trying to pass on these Ruby/Rails devs like its the new hot shit and all I've ever seen in my experience is spagetti codebases and sloppy work. Node is the same. It used to be PHP devs were this class (we refer to them as "enthusiastic ametuers" but the "brogrammer" name also equally applies; people who are just starting a career in development who dont know they dont know anything, or simply dont care in the case of brogrammers).

It's my understanding that the mood is simply that rails/ruby/node is toxic; its the same with what used to be SEO, they've all become UX snake oil salesmen.

As a Go dev, I'm crapping it that Go may be the next bandwagon jumped onto :( It kinda makes me glad when I see all those comments complaining about lack of generics!

If that's the case, then there is still hope for Ruby enthusiasts. PHP has come out the other end, mostly by splitting into separate communities that only have the language in common.

The issue with Ruby is that it is so tightly associated with simple architecture of Rails. Nothing wrong with Rails in itself, but for many complex projects that require architectural solutions Rails doesn't support, Rails + inexperienced devs usually results in spaghetti code.

Ruby is fine, but RoR is toxic.

> Ruby is fine, but RoR is toxic.

A language without its framework is like a hammer without a nail.

okay so...Sinatra, Padrino, Lotus?

So for someone who is working with ruby but technology agnostic and trying to land a gig as a junior dev, what do you suggest?

I feel like switching stacks before actually getting work might do more harm than good and at this stage I'm not looking to contract.

Don't switch stacks. He's expressing an opinion about code from Rails developers which is about as broad as opinions go this side of saying "black people are like X" or "Asians are like Y." On the bright side he does leave the door open that Rails developers could write solid code though most don't in his opinion. The best thing you could do is continue working on Rails but read a variety of opinions on good code in different languages, read Coders at Work and similar texts on coding, and remember not to blindly follow coding trends. Generally keep your code simple and work to find abstractions to fit your domain.

I'm not saying anyone here is incorrect in their generalizations of Rails developers. I've obviously never seen the code they are criticizing. But they also aren't providing any useful information. Keep that in mind above all else. There will always be politics and disagreements. You're never going to make everyone happy and it would be a disaster to try to.

This is probably the soundest advice and agree wholeheartedly; the market appears to be saturated with inexperienced developers. This means, at somepoint (probably about now actually) there will be a very real need for good/great rails/ruby devs to come in and sort out all this mess. Not everyone will be able to dump and rewrite their projects; some will need tidying and new features added. You could make a killing there is your disciplined (think of Y2K and all the old experienced cobol devs coming out the framework to fix stuff)

Ok let's be serious what does burned mean? My impression is that most people use Rails because it allows you to be very productive very quickly. Presumably that means you know you're trading performance for productivity. Maybe you'll have to do a re-write of parts of your app in another language for performance reasons or because you need to perform some operations concurrently, but you know up front you're not choosing the language strictly because of its technical performance but instead because of business constraints.

Keeping that in mind, were those companies really burned by Rails or were they making lazy decisions and not being honest about what their plan was for their software?

I don't think it's about performance. It's about the glut of inexperienced, underskilled Ruby devs landing seemingly simple gigs where they patch together unmaintainable Rails spaghetti - ultimately saddling clients/employers with a heap of technical debt and hobbling future devs who come to these projects.

This is a case of getting what you're willing to pay for. Great work is expensive because it takes a lot of experience to do, and there are a lot of opportunities for those with a lot of experience. But if you're willing to sacrifice the "great work" part, there are plenty of people out there with less experience doing (potentially) less great work for less cost. Everybody would like above market work for below market cost, but it doesn't tend to work that way.

I see what you're getting at but when Ruby/Rails was all new and shiny a couple of years back I knew an awful lot os junior/inexperienced devs who quite permanent jobs to go freelance/consulting for ruby/rails jobs because the money being paid was way above that for other similar level devs. It was pure hype, and to be fair to everyone who did this, the saw the writing on the wall and rode the wave. I even knew one SEO Exec who switched to ruby/rails contract dev work; if that isn't a warning sign, I don't know what is!

Just to note, I'm a PHP dev who works in SEO, and have done for years, during the great SEO boom, so I know bad code and I know snake oil salesmen. But I think in about 12/18 months time, once all the charlatans have moved on, the ruby/rails devs left will be experienced, battle hardend legacy devs, and the respect will begin., much like the SEO industry now.

Most executives at non-webdev companies don't know anything about Rails, except what their staff and consultants tell them.

If a fair number of those executives learn too late about the technical limitations of Rails, they probably do feel burned, and word gets around.

Burnt in the sense that businesses hired people who claimed to have solid development experience, who claimed they could build robust maintainable systems, who claimed they could solve real business problems, who then turned out to be a lot less spectacular or solid than first thought, who believed the solution to every problem or design phase was to simply add more gems into the mix, who changed the whole state of the codebase because one luminary in the ruby world posted a blog article about how the hot thing on that day was to use pattern x instead of pattern y for designing your models vs controllers.

Most businesses are technology agnostic - they don't care what we use, if, if we deliver robust technically sound solutions. But when they trust developers, who fail to deliver, they mark the technology choice as well, to avoid getting similar problems in the future.

Conversely, I have had a lot of work from companies switching from Java to Ruby due to the high costs and relative slow speeds of such developments. As someone who started out mainly working in Java, but now works mainly in ruby/rails I think the whole "rails == amateurs" argument you are making is oversimplistic. All languages are tools and there are always situations where one is more appropriate than another.

This is my experience as well. I have seen horrible code bases on rails projects and horrible projects in java and .net etc.

Funny thing is a lot of the projects that were a mess because the devs could not manage the pressure the businesses put on them which made for some real bad decisions. The devs themselves were actually pretty good and knew the code base had gotten out of hand.

So now whenever someone says "oh this company wont use X because they got burned by those programmers" my internal alarms instantly start going off that the problem is more than likely the managers of the business.

That might be true in London, but in Toronto essentially every major success story is Rails, Python, JS, and Go. Roughly in that order. The few Java code bases I've seen were horrendous.

Anecdotal evidence on both sides is anecdotal.

Ruby is past it's hype and others are taking up the space. Node.js is very good at replacing Ruby for quick development and Typesafe's Play works better for Java shops.

Reply on news.ycombinator.com