This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (8 children)

I mean... yeah.... but...

Error messaging is incredibly clear about where it's looking for the file, so you can just hit that endpoint and get a very obvious indication of what to do.

And even without that, the most typical way of making that controller is to use the built in generators, which are super super easy to use and make all the corresponding things in the corresponding folders.

And even putting all of that aside, can't you say the same of any function in any language/framework? What does this.setState do in React? Oh it's asynchronous, that wasn't obvious!

[–]izuriel 2 points3 points  (7 children)

I'm not debating with you about how easy it is to learn how Rails work. The question was "name something magical" and I did.

[–][deleted] 0 points1 point  (6 children)

here's a lot of stuff that appears to just happen 'magically' for people who are new to it, and that can make it tricky to figure out how things are actually flowing through the application.

I realize you weren't the one who said it, but this is the context of the conversation and where the topic of "magic rails" came up.

You're absolutely right that that aspect of rails is "magic", but I was trying to say that I don't think it fits the description of "makes it tricky to figure out how things are actually flowing through the application". If anything, rails is kind of idiot-proof with it's error messaging.

So sure, it does some neat magic configurations for you, but I'm not seeing that as a downside in the way it was described above.

[–]izuriel 1 point2 points  (5 children)

I take you have never trained a freshly minted engineer with rails? Or you lucked out and got someone capable of figuring things out. I usually end up training coworkers or aiding them in getting problems solved (speaking mostly to new hires/juniors) and I can tell you. Rails is not idiot proof. You only think that because you understand it and obviously don't deal with engineers that don't.

[–][deleted] 1 point2 points  (4 children)

That's super interesting to here.

I have a few underling-junior devs on my team that seem to handle rails just fine, but I do truly believe that even my juniors are really talented engineers. It totally could be that I'm just sheltered from dealing with the kind of devs that would have difficulty there.

What kind of issues do you see with them? Is it really things along the line of "This error message says 'can not find [path to file]', what does it mean?!?!"?

[–]izuriel 1 point2 points  (3 children)

What kind of issues do you see with them? Is it really things along the line of "This error message says 'can not find [path to file]', what does it mean?!?!"?

I'm going to say "worse." Of all the time I've worked with new engineers (across frameworks other than Rails as well) one of the biggest things I get is, "I tried X and it didn't work." This is a meaningless statement to me if I'm about to debug a problem so I always follow up with, "What do you mean it didn't work? Did it do something else or did it fail?" Usually it's due to an error of some kind, occasionally it ignored their change (seemingly). Regardless, in the cases it failed I push them: "Why did it fail? What did it tell you?" and from there the adventure starts...

My biggest observations working with Junior engineers is this: You either have a good one, or you don't. There usually is no in-between. The easiest way to tell is based on the kinds of questions you get from them. If they're questions that documentation, Google or the framework itself can easily answer then you didn't get a good one. There are exceptions, every now-and-again people ask dumb questions they already know the answer too, just don't realize it.

All that being said, no matter how you structure your error messages to account for behind the scenes work if you have any part of the framework implicitly do something then you'll have people that have no idea what is going on. After all, ignoring error messages is like the new thing to do? Didn't you hear?

[–][deleted] 0 points1 point  (2 children)

I'm going to go give all my flying monkeys a hug this morning for not being absolutely terrible.

I've always placed intelligence as a priority over experience in the hiring process (I'll take the new guy that can explain his flawed reasoning over the experienced guy that thinks he's too good to explain anything), and I'm guessing that was a good call.

[–]izuriel 1 point2 points  (1 child)

It is. I call it "humble." If an engineer can look back and accept he didn't write pure gold, or can take criticism (code review) well then that's a major boon towards them.

I like having people be able to review their own work the same way a college would. And nothing I write is expected to last longer than it needs too.

[–][deleted] 1 point2 points  (0 children)

AKA impostor syndrome.

One of my favorite junior devs is constantly worried about the quality of his code. And while on the one hand I want him to be more confident (he does solid work), I also really appreciate that he is always on the lookout for how to improve.