4 ms·

Yeah, it's been hard to find Ruby/Rails devs for... as long as I can remember. 2015 at least. Not sure if it's become harder. What about hiring experienced dev

Yeah, it's been hard to find Ruby/Rails devs for... as long as I can remember. 2015 at least. Not sure if it's become harder. What about hiring experienced devs and simply giving them an intro Ruby + Rails course? (which could be as simple as say, giving them 2-3 weeks to go through some self-directed learning) I think companies often do this badly: they hire non-Ruby devs and expect them to learn by osmosis, which usually results devs simply writing a bunch of bad code - for example, Rails code that fights against core Rails assumptions and looks like Java/PHP/etc. However, I also think it's pretty easy to get it right. If the company and developer have a good attitude about getting the dev immersed in Ruby/Rails a bit before turning them loose on the main codebase. I'm implementing a curriculum like that now in my current role.

ayewo 4y ago
> I'm implementing a curriculum like that now in my current role. Will you be making this public or internal it will remain?
- JohnBooty 4y ago
  Well, now that I read my post, "curriculum" probably makes it sound more grand than it is. With the range of Ruby learning options out there we're definitely not planning on reinventing any wheels. Part 1 - We've gone through "The Well-Grounded Rubyist" and listed most chapters as "learn" and some as "skim". The "skim" chapters are things that are not generally useful for Rails development e.g. explicit threading, file I/O, etc. The idea is that the student should simply know those things are there in case they're needed later. Part 2 - Same thing with the Rails guide from "Learn Enough To Be Dangerous" from Michael Hartl. We like this option because there's the book and then there are screencasts. So students can pick one or the other to suit their learning style. Part 3 - Small standalone project of the student's choosing, we have a few suggestions if they don't have any. Something they can finish in a few days. It is mildly "innovative" in the sense that, for whatever reason, most companies don't seem to do this. Companies I've worked at in the past have had generous onboarding periods, and have given devs lists of learning resources, but generally expect the devs to learn as they go. Which is fundamentally sort of broken, because "learning as they go" typically involves "learning by osmosis from an existing fragile production app that has a lot of tech debt."

ayewo 4y ago

> I'm implementing a curriculum like that now in my current role. Will you be making this public or internal it will remain?

JohnBooty 4y ago
Well, now that I read my post, "curriculum" probably makes it sound more grand than it is. With the range of Ruby learning options out there we're definitely not planning on reinventing any wheels. Part 1 - We've gone through "The Well-Grounded Rubyist" and listed most chapters as "learn" and some as "skim". The "skim" chapters are things that are not generally useful for Rails development e.g. explicit threading, file I/O, etc. The idea is that the student should simply know those things are there in case they're needed later. Part 2 - Same thing with the Rails guide from "Learn Enough To Be Dangerous" from Michael Hartl. We like this option because there's the book and then there are screencasts. So students can pick one or the other to suit their learning style. Part 3 - Small standalone project of the student's choosing, we have a few suggestions if they don't have any. Something they can finish in a few days. It is mildly "innovative" in the sense that, for whatever reason, most companies don't seem to do this. Companies I've worked at in the past have had generous onboarding periods, and have given devs lists of learning resources, but generally expect the devs to learn as they go. Which is fundamentally sort of broken, because "learning as they go" typically involves "learning by osmosis from an existing fragile production app that has a lot of tech debt."