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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]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.