4 ms·

My first (Rails) job was not advertised as looking for Rails dev, and I didn't touch any Rails code for probably the entire first year. Hiring manager was look

by yebyen 8y ago

My first (Rails) job was not advertised as looking for Rails dev, and I didn't touch any Rails code for probably the entire first year. Hiring manager was looking for a Ruby developer without tons of experience, or strong opinions about which gems to use. It was common for me to receive an assignment with instructions to complete it without downloading any gems. Most of my projects, were not web apps. ETL type things. When it was time for me to develop something with a web front-end, we still did not use Rails. Sinatra and (pick any template language off the shelf.) Ruby and Rails are both large skills that take lots of experience and maybe even training to become competent at using. When hiring junior developers, I think based on my experience at least, a hiring manager would do well to defer them from learning Rails until the latest possible moment. Better to learn one major skill at a time. (Then again most HN readers are probably not trying to get hired as a junior developer anywhere.)

briandear 8y ago
Totally disagree. Rails first learning means that junior devs are immediately productive. And writing code without using any gems? What the hell for? Most of the major standards are MIT, so it couldn’t be for licensing reasons. Not using gems is just wasting effort reinventing the wheel. Ruby on Rails isn’t a major skill that takes lots of experience. It takes experience to master it, but a junior dev could easily become productive in the framework almost instantly.
- yebyen 8y ago
  Ruby is a language, and maybe if you already know 10 languages then it's a very easy language to pick up, but... how do you expect to know where Ruby ends and Rails begins, if you never separate the two? I don't see this your way. Junior devs are immediately productive? What kind of fantasy land is this? Junior devs need to walk before they can run. Everyone should know enough Ruby to parse them some CSV, if that's going to be part of the stack. Then, they can pick up a Gem library for parsing CSV and never do that again. But having the experience of working around the edge cases and knowing enough core language features to know what parts are easy without any gems, is going to make you better able to spot "using the gem wrong," or even "the gem is doing it wrong" (which also totally happens!) In my company, CSV was something we needed to have as a core competency (customers sending us data files, and bad data files, all of the time, ETL pipeline shaping them up and making them loadable into our custom schema...) and there were just two of us devs, so nobody's got time for pair programming. You're honestly going to ask a junior developer to start with "rails new" and then somehow trust what they produced, putting it on the internet? A junior dev could easily become productive with a handful of gems too, and practically understand every part of what they did. That's the point. You don't keep all gems out of the picture forever, just long enough to learn what hard problems look like without having them solved for you. If I'm a hiring manager and you're my junior dev, I want to start by seeing how you think, and I want to see you thinking with first principles so I can tell you where you're going wrong. I'll help you figure out the hard parts if you're struggling with something. But I do want you to struggle with those parts a bit, and I want to see it. If 95% of the work is done for you by a gem, then I might as well let you ask Rubocop and Brakeman what else you're doing wrong, and there's probably no point in having me here at all.
  - busterarm 8y ago
    I'm really confused by some of what you're saying. For one, CSV is part of the standard library. just "require 'csv'". No gems required. Two, nobody without a really good reason should try implementing their own CSV parse library. RFC4180 doesn't even remotely reflect reality. It's several hundred lines of code to do right (about ~700 in Ruby currently, down from a bit over 2000 in earlier implementations). I hope they're good at RegExp.
    - yebyen 8y ago
      > just "require 'csv'". No gems required. Seven years ago, at the time I was starting the job I mentioned, this was not a thing. The gem was called 'fastercsv' and it was made a standard library in 1.9 – we were mostly working on 1.8.7 when I started, and 1.9.2 when I did the CSV implementation(s). It was a brand new standard library and it did not do all things for all people. Almost like they just picked a pretty good one off the shelf! It still does not do all things for all people... today, you also have other competing implementations, say 'smartercsv' with most recent commit activity 4 days ago. It's an implementation of CSV. If you know your CSV is pristine, you can parse it in a lot less than 700 lines. We had a utility that would output "pristine CSV" dumped out from whatever garbage the client sent us, in whatever Excel or other columnular format, and we had another utility that would only accept this "pristine" format. Sometimes things went wrong. More often than you expect maybe, and we'd fix them ... or sometimes we'd get the clients to fix their shitty files, and leave it the way we thought it should work. Depending on what you need to do with the CSV, or how many ways you're planning on handling CSV, one could argue that you will be better served by a minimal implementation that you know exactly what it does and does not do, because you told it what to do. If it's making a mistake, that's yours. You own it! That's another boon, when the quality of the data is not guaranteed. The standard library I remember has some great idiosyncrasies that you'll know if you've ever used it to work on bad CSV. So do all of the CSV libraries. I don't work on CSV anymore and my memory of it is not so good, so I can't tell you the war stories in perfect detail, but... suffice it to say there are several CSV libraries with different strengths and weaknesses. We mixed and matched parts that served the specific need we had at any given time and place, until I was a total CSV expert. It was not a perfect ecosystem, and 7 years ago `require 'csv'` was simply not a thing. You had to pick one off the shelf, or roll your own. I'm really not sure what's different today. (Probably not much! Parsing CSV is not a core competency of either Ruby core team, or Rails.) We had our reasons though, to be sure. The one I remember in particular was a bit that converted your CSV rows and columns and then turned them into arrays of hashes, or converted arrays of hashes into CSV, and then another piece that expected the hashes to be identically ordered. If you used all of the standard pieces, this worked great! I think it took multiple libraries to do this, actually, and some of them were not so standard. But wait... hash keys are not ordered at all, and that's a property of hashes that is standard and well known. But in some cases the hashes do come back with their keys in a particular, consistent order, and in a perfect walled-garden use of the particular CSV library configuration that was expected by the people that wrote this crap, yeah everything worked. Well, everything worked until you do get a CSV with an uneven number of columns in some of the rows. Like I said, CSV was supposed to be a core competency for us. We would not have been successful if we just picked one CSV library and stuck with it. Or, that CSV library would have got a lot of free labor from us, I'm not really sure which. I'm not sure which is worse, either. I don't do that anymore though.
- jstarfish 8y ago
  Some environments are designed for isolation/security to such an extent that you dont have internet access to external repos.
  - yebyen 8y ago
    That is true! And it's also true that some environments require full code reviews of everything that isn't already certified. Hypothetically speaking, I don't know how you get around the fact that Ruby has way more code in it than any of the gems you'll want to pull in, but ignoring that, what's easier... getting a new gem certified, or writing just the parts you need and putting them through the normal review process? The answer is not going to be the same each time you ask it.
pmontra 8y ago
I started using Rails probably at 1.0 and it didn't have any learning curve worth telling back then. However I've been doing web development since 1994, including some CGI programs in C (nightmare), CGI.pm (Perl), Struts (Java) and occasional PHP (real garbage back then, better now) so I knew what's in a web framework. I only have to learn the way it implements what any web application has to do. There aren't many surprises, some occasional disappointments when a framework overengineers something (my general feeling with Python and Django and of course with Java.) Rails isn't very complex even now, especially if you separate the front end (a JS SPA) and the backend (an API Rails project). You can develop two different projects in two different repositories and forget all the asset pipeline. However you must know the frontend really well or the sum of the two projects is going to be much tougher than vanilla Rails views.
- yebyen 8y ago
  > I started using Rails probably at 1.0 > I've been doing web development since 1994 > some CGI programs in C, CGI.pm (Perl), Struts (Java) and occasional PHP I said junior developer, didn't I? :) and also mentioned that this was my first ("permanent") job (after college)? Getting to know what's in a web framework, is exactly the learning curve I'm talking about. People complain about magic in Rails. I just wrote an ERB view "index.html.erb" and declared an empty method "index" in my controller. Add in a route definition, and now somehow they are all connected. What is actually happening? Why does that even work? If you've never used any web framework before, that's inscrutable magic. If you know what a correctly designed controller method looks like (it should maybe fetch some values, then render a view... and probably nothing else) then it's obvious. Getting over that hurdle is ... definitely not the kind of shit my first boss hired me to do. I'll say again, most of my assignments for the first year had nothing to do with "on a web page."
  - busterarm 8y ago
    The magic isn't really magic if you have a basic understanding of how Active Record works, which really just means you know SQL and what kinds of queries all of those named relationships and parameters generate. This is like the critical piece to groking Rails and we minted too many "Rails developers" who don't know this. The only missing piece then is how internet requests are routed. Basic knowledge of how HTTP and TCP/IP work. My stance on this (and how I did it as a junior) is to have someone implement a toy implementation of Active Record's basic relationships using Ruby meta-programming and to implement a basic request-response server. This is part of the curriculum of some bootcamps even. If your junior developer can't do this, they shouldn't be touching your production Rails application. Your immediate goal on hiring them is to train them to be able to do this.

by yebyen 8y ago

briandear 8y ago

Totally disagree. Rails first learning means that junior devs are immediately productive. And writing code without using any gems? What the hell for? Most of the major standards are MIT, so it couldn’t be for licensing reasons. Not using gems is just wasting effort reinventing the wheel. Ruby on Rails isn’t a major skill that takes lots of experience. It takes experience to master it, but a junior dev could easily become productive in the framework almost instantly.

yebyen 8y ago
Ruby is a language, and maybe if you already know 10 languages then it's a very easy language to pick up, but... how do you expect to know where Ruby ends and Rails begins, if you never separate the two? I don't see this your way. Junior devs are immediately productive? What kind of fantasy land is this? Junior devs need to walk before they can run. Everyone should know enough Ruby to parse them some CSV, if that's going to be part of the stack. Then, they can pick up a Gem library for parsing CSV and never do that again. But having the experience of working around the edge cases and knowing enough core language features to know what parts are easy without any gems, is going to make you better able to spot "using the gem wrong," or even "the gem is doing it wrong" (which also totally happens!) In my company, CSV was something we needed to have as a core competency (customers sending us data files, and bad data files, all of the time, ETL pipeline shaping them up and making them loadable into our custom schema...) and there were just two of us devs, so nobody's got time for pair programming. You're honestly going to ask a junior developer to start with "rails new" and then somehow trust what they produced, putting it on the internet? A junior dev could easily become productive with a handful of gems too, and practically understand every part of what they did. That's the point. You don't keep all gems out of the picture forever, just long enough to learn what hard problems look like without having them solved for you. If I'm a hiring manager and you're my junior dev, I want to start by seeing how you think, and I want to see you thinking with first principles so I can tell you where you're going wrong. I'll help you figure out the hard parts if you're struggling with something. But I do want you to struggle with those parts a bit, and I want to see it. If 95% of the work is done for you by a gem, then I might as well let you ask Rubocop and Brakeman what else you're doing wrong, and there's probably no point in having me here at all.
- busterarm 8y ago
  I'm really confused by some of what you're saying. For one, CSV is part of the standard library. just "require 'csv'". No gems required. Two, nobody without a really good reason should try implementing their own CSV parse library. RFC4180 doesn't even remotely reflect reality. It's several hundred lines of code to do right (about ~700 in Ruby currently, down from a bit over 2000 in earlier implementations). I hope they're good at RegExp.
  - yebyen 8y ago
    > just "require 'csv'". No gems required. Seven years ago, at the time I was starting the job I mentioned, this was not a thing. The gem was called 'fastercsv' and it was made a standard library in 1.9 – we were mostly working on 1.8.7 when I started, and 1.9.2 when I did the CSV implementation(s). It was a brand new standard library and it did not do all things for all people. Almost like they just picked a pretty good one off the shelf! It still does not do all things for all people... today, you also have other competing implementations, say 'smartercsv' with most recent commit activity 4 days ago. It's an implementation of CSV. If you know your CSV is pristine, you can parse it in a lot less than 700 lines. We had a utility that would output "pristine CSV" dumped out from whatever garbage the client sent us, in whatever Excel or other columnular format, and we had another utility that would only accept this "pristine" format. Sometimes things went wrong. More often than you expect maybe, and we'd fix them ... or sometimes we'd get the clients to fix their shitty files, and leave it the way we thought it should work. Depending on what you need to do with the CSV, or how many ways you're planning on handling CSV, one could argue that you will be better served by a minimal implementation that you know exactly what it does and does not do, because you told it what to do. If it's making a mistake, that's yours. You own it! That's another boon, when the quality of the data is not guaranteed. The standard library I remember has some great idiosyncrasies that you'll know if you've ever used it to work on bad CSV. So do all of the CSV libraries. I don't work on CSV anymore and my memory of it is not so good, so I can't tell you the war stories in perfect detail, but... suffice it to say there are several CSV libraries with different strengths and weaknesses. We mixed and matched parts that served the specific need we had at any given time and place, until I was a total CSV expert. It was not a perfect ecosystem, and 7 years ago `require 'csv'` was simply not a thing. You had to pick one off the shelf, or roll your own. I'm really not sure what's different today. (Probably not much! Parsing CSV is not a core competency of either Ruby core team, or Rails.) We had our reasons though, to be sure. The one I remember in particular was a bit that converted your CSV rows and columns and then turned them into arrays of hashes, or converted arrays of hashes into CSV, and then another piece that expected the hashes to be identically ordered. If you used all of the standard pieces, this worked great! I think it took multiple libraries to do this, actually, and some of them were not so standard. But wait... hash keys are not ordered at all, and that's a property of hashes that is standard and well known. But in some cases the hashes do come back with their keys in a particular, consistent order, and in a perfect walled-garden use of the particular CSV library configuration that was expected by the people that wrote this crap, yeah everything worked. Well, everything worked until you do get a CSV with an uneven number of columns in some of the rows. Like I said, CSV was supposed to be a core competency for us. We would not have been successful if we just picked one CSV library and stuck with it. Or, that CSV library would have got a lot of free labor from us, I'm not really sure which. I'm not sure which is worse, either. I don't do that anymore though.
jstarfish 8y ago
Some environments are designed for isolation/security to such an extent that you dont have internet access to external repos.
- yebyen 8y ago
  That is true! And it's also true that some environments require full code reviews of everything that isn't already certified. Hypothetically speaking, I don't know how you get around the fact that Ruby has way more code in it than any of the gems you'll want to pull in, but ignoring that, what's easier... getting a new gem certified, or writing just the parts you need and putting them through the normal review process? The answer is not going to be the same each time you ask it.

pmontra 8y ago

I started using Rails probably at 1.0 and it didn't have any learning curve worth telling back then. However I've been doing web development since 1994, including some CGI programs in C (nightmare), CGI.pm (Perl), Struts (Java) and occasional PHP (real garbage back then, better now) so I knew what's in a web framework. I only have to learn the way it implements what any web application has to do. There aren't many surprises, some occasional disappointments when a framework overengineers something (my general feeling with Python and Django and of course with Java.) Rails isn't very complex even now, especially if you separate the front end (a JS SPA) and the backend (an API Rails project). You can develop two different projects in two different repositories and forget all the asset pipeline. However you must know the frontend really well or the sum of the two projects is going to be much tougher than vanilla Rails views.

yebyen 8y ago
> I started using Rails probably at 1.0 > I've been doing web development since 1994 > some CGI programs in C, CGI.pm (Perl), Struts (Java) and occasional PHP I said junior developer, didn't I? :) and also mentioned that this was my first ("permanent") job (after college)? Getting to know what's in a web framework, is exactly the learning curve I'm talking about. People complain about magic in Rails. I just wrote an ERB view "index.html.erb" and declared an empty method "index" in my controller. Add in a route definition, and now somehow they are all connected. What is actually happening? Why does that even work? If you've never used any web framework before, that's inscrutable magic. If you know what a correctly designed controller method looks like (it should maybe fetch some values, then render a view... and probably nothing else) then it's obvious. Getting over that hurdle is ... definitely not the kind of shit my first boss hired me to do. I'll say again, most of my assignments for the first year had nothing to do with "on a web page."
- busterarm 8y ago
  The magic isn't really magic if you have a basic understanding of how Active Record works, which really just means you know SQL and what kinds of queries all of those named relationships and parameters generate. This is like the critical piece to groking Rails and we minted too many "Rails developers" who don't know this. The only missing piece then is how internet requests are routed. Basic knowledge of how HTTP and TCP/IP work. My stance on this (and how I did it as a junior) is to have someone implement a toy implementation of Active Record's basic relationships using Ruby meta-programming and to implement a basic request-response server. This is part of the curriculum of some bootcamps even. If your junior developer can't do this, they shouldn't be touching your production Rails application. Your immediate goal on hiring them is to train them to be able to do this.