Very nicely put, Matt. I share your view completely. This all boils down to having the right mind set, but unfortunately the person who's looking for the team may not be ready to assess if the mind set is right. That's why in many cases people are looking for "the rule of the thumb" -- to simplify the problem of choice. I wouldn't use the fixed set of tools as a criteria, but would talk to a candidate for 20 minutes and figured whether he's the right kind. By that I mean whether he's passionate, flexible, disciplined and eager to learn at the very least. These are way more important than any specific technologies.
- Aleksey On Jan 23, 4:37 am, Matt Jones <[email protected]> wrote: > On Jan 21, 5:12 pm, Aleksey Gureiev <[email protected]> wrote: > > > You guys are surprising me. So you are looking for developers and you > > don't know what you need from them. Given that someone said it's, for > > example, RSpec that they need to know well, how would you to assess > > the prospective developer? Does anyone around you know RSpec well > > enough, or will you take his word for it? > > Here's a better list: > > 1: ability to rapidly pick up new tools and methods > 2: ability to communicate effectively with both technical and non- > technical staff > 3: passion for quality, readable code > 4: the three programmer's virtues: Laziness, Impatience, and Hubris > (seehttp://c2.com/cgi/wiki?LazinessImpatienceHubris) > > None of these are HR-drone checkoff points, and that's for a good > reason: you can't measure developers that way. Traits like #1 > eliminate the need for an exact skillset match; if I was hiring a dev, > I'd be less concerned with specific knowledge of a particular testing > framework than a general understanding of the *idea* and *purpose* of > testing. > > Why emphasize generals over specifics? A quick example: Cucumber is > the new hotness at the moment, but less than 16 months ago it DIDN'T > EXIST. I doubt you'd find many people who would bet that the Cucumber > of today will be exactly the same as May 2011's Cucumber. So the > ability to adapt to change is vastly more important than how many > pages of RDoc one can memorize. > > #2 and #3 are closely related, just in different arenas of > communication. A programmer who can't write documentation, or who's > code is unreadable to anyone else on the team is a massive liability. > This is especially important in languages like Ruby where freedom is > balanced with responsibility; you don't want to spend two weeks > finding out that Very Clever Programmer Guy has redefined + to mean - > on *some* objects returned from a method but not documented it > anywhere. > > --Matt Jones -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
