Interviewing Ruby Programmers

by Steve Yegge

Now that Ruby's begun its march towards global domination, it's appearing on increasing numbers of resumes. That puts most tech companies (including yours, I'd venture to guess) in a weird position, because they don't know how to evaluate Ruby programmers. Not yet, anyway.

We've been here before, haven't we? Remember back when CGI appeared on the scene, followed almost instantly by CGI.pm, and suddenly every company wanted people who knew Perl? Same thing with C++, Java, C#... a good litmus test for programming-language popularity is whether people bother putting it on their resumes. And for a while after a new one shows up, nobody can tell the wizards from the poseurs.

This is a key juncture for Ruby. If companies start hiring people with "Ruby" smeared all over their resumes, and those people go on to produce brilliant software and generally kick ass, then Ruby gets modded way up. If said Rubyists turn out to be (on average) a bunch of do-nothing kneebiters, Ruby loses big. Rubyists are out there right now, getting set up on blind dates with tech companies, and these first impressions don't just matter for them; they matter for all of us.

What's the worst-case scenario? Well, I used to have this friend who worked at a tech company we'll call "FooCorp". This is a true story: at FooCorp, the HR department decided to hire a lone cowboy programmer to write a new performance-evaluation tool for the company. The programmer they hired — who had no interaction with the rest of engineering — went ahead and decided to write it in Ruby. With much ado and fanfare, they rolled it out, and with even more ado, a thousand people spent hours entering in their performance reviews. And then, with a truly enormous amount of ado — I mean enough ado to fill several football stadiums — the shiny new Ruby-based perf tool went on a rampage and ate up everyone's performance reviews. Forever.

Was that Ruby's fault? Of course not. In fact I, er, that is, my friend met with the cowboy afterwards to figure out whether the disaster could be undone, and the cowboy announced: "WELL, YOU KNOW, WHEN THE SYSTEM GETS ENUFF CHAOS GOIN' IN THERE, PRETTY MUCH ANYTHING COULD GO WRONG." And I can't say he was wrong, either.

Needless to say, Ruby got a bad rap at FooCorp for a little while.

I'd like the Ruby community to start thinking proactively about this problem. I don't think I'll come even close to solving it in this blog. Ruby is exceptionally easy to learn — far more so than Perl, C++, C#, Java, or even PHP. Oh hell, I'll just say it: it's easier to learn than Python. And that's quite a feat. It means Ruby's inevitably going to become a magnet for people who can't program any other way. Tech companies need our help here. Let's figure out some ways to differentiate the good eggs from the bad ones.

I'll offer a few of my own ideas here, but obviously I can only barely scratch the surface in a single blog. I'll start with some approaches that should work regardless of the language you're testing for, and then talk about some Ruby-specific tests.

42 Comments

James Britt
2006-03-12 10:05:57
"Compare and contrast Ruby with your second-favorite language."


Oh, but of course! I've interviewed people for Java jobs, and got into the habit of asking people to compare Java to some other languange. It helped me see if a) they even knew another languuage (many didn't; points off for lack of curiosity); and b) they knew enough about Java to describe the differences.


And, yes, I also asked them to explain what they didn't like about Java. Surprsing (and sad) the number of people who said, "Nothing."


One other general interview technique was to inquire about development tools. The more the candidate used the commandline/cmd shell, the more points (roughly speaking). I mean, you shouldn't have to launch an IDE to recompile code or make a WAR file.


And you you spelled "Io" wrong.


:)


Phil Tomson
2006-03-12 11:50:57
Ruby is exceptionally easy to learn — far more so than Perl, C++, C#, Java, or even PHP. Oh hell, I'll just say it: it's easier to learn than Python. And that's quite a feat. It means Ruby's inevitably going to become a magnet for people who can't program any other way.


Sure, Ruby is easy to learn in order to attain a certain acceptable level of productivity. However, Ruby is much deeper than Python and you can actually learn new things over the years that you hadn't realized. When you start getting into metaprogramming in Ruby you can get into some deep waters. I've been programming in Ruby for about 5 years now and I'm still learning new things about it.


Hiring based on syntax trivia is the last, desperate resort of a weak interviewer. Just say No.


Thank you. I can't remember how many times I've had a C++ interviewer ask about some arcane, dusty corner of C++ syntax (and there are so many). I always want to say "I have no idea, but I've got at least six C++ books I can reference in addition to the web - you do have web access here?".


And frankly, I don't think it matters, because the traditional 1-hour interviews conducted throughout our industry are a pretty random way to figure out how well someone is going to work out in the months and years ahead.


Amen. Even 6 or 7 traditional 1-hour interviews aren't all that effective. How about a 2 or 3-day 'audition'? Candidate comes in and works for 2 or 3 days. Candidate gets paid, of course, so it's not used as a way of getting free labor. Some people are just not good at being interviewed (and I raise my hand; I'm one of 'em) so some actual work might reveal much that wouldn't come out in an interview.

Steve Yegge
2006-03-12 13:30:02
And you spelled "IO" wrong.


And you spelled "Surprising" wrong. :)


OK, dammit, you caught me bluffing. Their website was down all day last week when I was trying to finally learn the dang thing. Argh! Did I fail the phone screen?

peter
2006-03-12 14:32:22
while i can agree with most of the points, it's also very important to know what the target field is.


if the field is web development for example, i would not dismiss ruby on rails experience and would care a little less about some obscure language features, also i would rather pick someone who does not have a favorite technology/language but has an understanding of the problem domain he/she has to deal with(scaling, HA, remoting, database efficency, session managment, various UI stuff, different approaches in web frameworks like event-driven, request-driven etc.) and used different technologies to solve these issues.

Steve Yegge
2006-03-12 15:34:24
Well, yeah. Everything I said here is (necessarily) a gross oversimplification. Rails is cool, but wielding it effectively still requires you to know a LOT about web development, in all its crufty glory.


When in doubt, ask them about what you care about. After all, you have to work with them if you hire them.


2006-03-12 17:08:42
"Will they complain that it doesn't have static types like Java or C++? (Red flag!) Will they whine about its performance? (Probably not hired!) Will they go on about how they really miss IntelliJ, and hate having to use Emacs for all their Ruby coding? (Definitely not hired!)"



I love your writings, but I think you're still in a bit of a honeymoon period with ruby. I know I was for about a year with python a few years ago.
Ruby and python are sometimes an order of magnitude or more slower than statically typed languages. For typical web development, it really doesn't matter so much, but it simply cannot be ignored in some other areas of development. New languages are trying the make the area between ruby and java more gray, with things like type inference and optional static or dynamic typing. It would be nice if ruby would move toward embracing this gray area, too someday. Also, IntelliJ type IDEs are not really that evil. They just compensate for the headaches of using most overly-verbose statically typed languages. Having a form designer and code completion isn't always necessarily evil.

Alex
2006-03-12 17:25:55
Gods, I would hate to work for you. Even though I agree with a lot of your standards, it seems that you want some freakish authoritarian control over the culture of employees. You're screening for trendiness over talent. Why can't a good programmer prefer static over dynamic typing, or a graphical IDE over Emacs. Because that doesn't suit your personal tastes? Maybe if an applicant complains about Ruby's performance, it's because Ruby *is* slow compared to almost any other major language, and for some tasks that can be a serious problem. Programming language snobbery is really stupid and shallow.
James Britt
2006-03-12 18:04:17
You're screening for trendiness over talent. Why can't a good programmer prefer static over dynamic typing, or a graphical IDE over Emacs. Because that doesn't suit your personal tastes?


I think the issue is that the candidate should have varied experience, be able to explain his or her preferences, and make choices best suited for a particular task.



2006-03-12 19:54:45
You're screening for trendiness over talent. Why can't a good programmer prefer static over dynamic typing, or a graphical IDE over Emacs. Because that doesn't suit your personal tastes? Maybe if an applicant complains about Ruby's performance, it's because Ruby *is* slow compared to almost any other major language, and for some tasks that can be a serious problem.


Remember, presumably I am interviewing for a *Ruby* programmer ...
presumably for the kinds of things that Ruby is good for (not near real
time graphical simulations of protein folding). Someone who comes to me to
interview for a Ruby job and 'whines' about Ruby's performance isn't going
to get far. And it's perfectly valid for an interviewee to prefer static to
dynamic typing ... really! But if you tell me that dynamic typing is an
inherent fault or weakness of a dynamic language, I'll find it hard to
take anything else you have to say very seriously. I mean, c'mon, Ruby has
faults all its own ... if all you can come up with is simple derision of a
whole class of programming languages then we'll both certainly be happy
that you won't be working for me :-)


Phil Tomson
2006-03-12 20:02:02
Alex: Why can't a good programmer prefer static over dynamic typing,


I don't think Steve is saying that he's preferring static over dynamic typing when he says that he would dismiss a candidate who suggests that Ruby needs static typing. Most people come out of a CS program these days with only experience with statically typed languages and they go on to only work with them. When a person like this finds a dynamically typed language like Ruby one of the first things they ask for is some static typing (they feel uncomfortable without the seatbelts, even though they could use the airbags of unit testing ;-). We see this all the time on comp.lang.ruby. So if someone suggests that Ruby needs static typing (not that static typing is the only way) then it suggests that they're probably not yet comfortable with Ruby's dynamic typing. And if they're not yet comfortable, then it's likey that they haven't fully groked Ruby yet or had the 'AHA!' moment related to 'duck typing'.

Andrew
2006-03-12 20:14:18
I know I wouldn't do well in such an interview, because it seems to focus too much on the interests of the interviewer and sets up a competitive atmosphere that I dislike. I'd be inclined to decide the job wasn't for me based on an interview like you described.


Maybe I'm just a bad fit for your company, but I think its better if the interviewer sounds out the interviewee for his(/her) interests and then asks questions about those. Better than fumbling around with stuff that might not be have been at the front of the candidate's thoughts recently.

Steve Yegge
2006-03-12 20:16:07
I, for one, am glad someone finally expressed a dissenting opinion. Thank you, Alex! Interviewing is a really tricky business, and nobody's opinion is going to be completely valid, least of all mine.


But as some other folks noted, I *was* talking about interviewing Ruby programmers. IntelliJ's not going to get them very far if they're doing Ruby programming. It's a nice IDE for Java development, but not for Ruby.


You're right; it's perfectly OK to miss your IDE and static typing. It just doesn't strike me as the best thing to say for showing off your Ruby expertise during an interview, is all. YMMV.

Keith Wright
2006-03-12 20:50:43
Mr. Yegge, I have run into many of your essays recently (thank del.icio.us) and have really enjoyed reading the opinions of someone who has taken the time to try learn so many different languages.


But I have to ask what is so wrong with wining about Ruby performance? Looking at the programming language shootout it seems that Ruby has a habit of coming in dead last, often 100 times slower than the leader, and it certainly isn't the only interpreted or newly developed language in the race. Looking at it performance results, I have to ask if there is something so fundementally wrong with how it maps to assembly that doing anything terribly computational is unwise. Even web apps have to worry about not hogging the CPU too horribly. Does a good Ruby programmer need to have C in his back pocket?


OK, that sounds like a troll, but that is my honest thoughts as someone who still writes client applications, doesn't give a damn about writing web apps, and would like to not have to write in C++ anymore. (Don't suggest Java, it just isn't different enough for me to get excited about)


I know from your other writings that you have programmed in assembly and C/C++ and have worked real jobs where performance matters, so I wonder how you really feel about Ruby performance in the real world.

SteveYegge
2006-03-12 21:04:30
> Does a good Ruby programmer need to have C in his back pocket?


Or hers.


No sense letting this thread devolve into a performance war. You folks should know that.


-steve

Greg Jorgensen
2006-03-12 21:30:48
Let's say you're trying to hire a Java programmer. Well, you've already made your first mistake! Why? Because setting out to hire an "X programmer" for any value of X is probably going to land you a dud.


I think you're perpetuating a mismatch between what programmers are interested in and what companies that hire programmers need. There are some jobs that really need programmers who are experts at languages and computer science, but the majority of jobs for programmers are in application development. Programmers succeed at those jobs because they understand (or at least care to learn about) things like inventory, logistics, accounting, databases, etc. Expert programming skills are always desirable in a candidate, but if they don't know about the business, and don't want to know because they spend their days online arguing about continuations and why Java sucks they aren't going to do what I need them to do.


Your interview questions would be good if I was looking for a programmer to write, say, an embedded Ruby interpreter and runtime system. They would not be good questions if I was looking for a programmer capable of hooking up my ERP system to a supplier's system over HTTP. That's a job Ruby would be well-suited for, but the programmer needs some business domain expertise.


I have interviewed and hired and managed programmers since 1980, almost always in business application development positions, and while I try to avoid untalented programmers, I've never seen a project suffer a major failure because a programmer didn't how to support tail recursion. I have seen lots of projects fail because the programmers didn't understand the business problem, and didn't care to learn about it. I may be interested to talk about what features should be taken out of or added to Ruby, but as a manager I'm more interested in whether the programmer understands the difference between receivables and inventory.


Alex
2006-03-12 23:09:17
Steve,
I understand that a potential Ruby coder ought to feel comfortable with the "Ruby way", and I'm certainly not arguing for the use of IntelliJ and static typing (which I've happily escaped from and don't plan to go back). But it seems to me that you're looking for a certain Ruby "elite", which (like Greg Jorgensen said) would be great for implementing a programming language, but you end up excluding a lot of smart/competent coders who aren't programming language nerds. Also, I'm a bit embarassed over how abrasive my last post was, sorry about that.
Shanti Braford
2006-03-13 00:58:04
Keith (and fellow Ruby performance detractors) - I think you'll find it's far easier (and cheaper) to throw additional $500 linux boxes at the problem than write your apps in any language that remotely performs 100x better than Ruby.


Your mileage may vary, but just look at what 37 Signals was able to do in the early days with one programmer + Ruby and what was to become Ruby on Rails.


Of course, it wouldn't hurt to have some performance improvements in future versions of Ruby and FCGI.


Great post, Steve.

Herb
2006-03-13 01:04:51
"Using Rails to build a web application is not an impressive feat, because Rails makes traditional web development essentially trivial."


That strikes me as a little bit disrespectful.


Sure, Rails makes alot of things easier. But there are alot of things that we have to know well to be good RoR programmers:


Ruby (sure!), TestDrivenDevelopment, DB Migrations, MVC, XHTML, CSS, often custom javascript, and most importantly, if we want to take care of the hosting, Linux (+ Capistrano).


It's not that trivial to do a good, solid website with RoR. It might be trivial to make a website with scaffolds, and show it off on a local PC.


Also, often the built-in helpers do not suit what you need for the client, so you need to get back to custom coding.


RoR is not all heaven.

denanda
2006-03-13 05:16:20
i'm having one of these US phone screens tomorrow (not over ruby, possibly python but we dont do it quite like that in europe). i'm happy being just above average coder. if i saw it on reddit i'd probably print an article on pros and cons of tail call optimizations and read over lunch. it is interesting read. and so is an articel on bird flu. with help of my excellent memory, one article might fool an inteviewer but i really dont care about that topic at all.. i coded business applications for 15 years without knowing much about it. ok it was a ruby interview. i come from static land and have just recently begun to see the dynamic light but i'm just too lazy to remember any in-depth detail of any langauge i claim to know in my cv (4 languages i think). i know java and i like java, (and i like ruby too 4 different reasons but it's not on my cv) but i have not implemented my own jvm to amuse myself or boost my ego. i have a life ;o) i just code by way of osmosis :o) and the thing i liked most on this blog was that xcellent coders dislike/hate all languages. grain of truth there. i love my work in software dev but am sick and tired of language this language that. i just use whatever(almost) language i need. i (claim) to know 4 and with those i'm able to fit in somewhere...but i know alot more about infrastucture and producing quality code than kool feature code in trendy languages. just my obeservation. hope they dont BBQ me tomorrow...
peter
2006-03-13 07:05:39
It's not that trivial to do a good, solid website with RoR. It might be trivial to make a website with scaffolds, and show it off on a local PC.


herb, that was my point too.

Steve Yegge
2006-03-13 09:13:21
Sorry peter and Herb, but you're missing the point. There's very little Ruby code in a typical Rails application, even after the scaffolding is gone. Sure, there's a ton of html, css, javascript, and "Railsspeak", to coin a phrase for the DSL that Rails has created, in Ruby, for doing web programming. But you only need to know the basics of Ruby in order to work effectively with Rails. And this isn't an article about hiring web devs. (*That* is a nontrivial skill set, but it's not what I'm talking about.)

2006-03-13 09:17:47
Phil Tomson wrote:
"When a person like this finds a dynamically typed language like Ruby one of the first things they ask for is some static typing (they feel uncomfortable without the seatbelts, even though they could use the airbags of unit testing ;-). We see this all the time on comp.lang.ruby. So if someone suggests that Ruby needs static typing (not that static typing is the only way) then it suggests that they're probably not yet comfortable with Ruby's dynamic typing. And if they're not yet comfortable, then it's likey that they haven't fully groked Ruby yet or had the 'AHA!' moment related to 'duck typing'."


That's the same kind of FUD I've heard on the python list for years. I'm very comfortable with both python and ruby, and I do appreciate the power of dynamic typing, and esp. ruby's metaprogramming, closures, etc.
How hard is it for language fanatics to accept the fact that for some applications their language is slow, and sometimes even unacceptably so.


Like I said, it is possible to bridge the two worlds. There is a gray area in between that can be utilized via things like type inference and optional static or dynamic typing we are seeing emerge in other languages. I personally do not like how Haskell and O'Caml are doing it, but there are other options that have already appeared or will appear in the next few years. And I'm afraid they are going to beat the shit out of ruby and python one day unless there are less users like you :)

romain
2006-03-13 12:02:11
"I may be interested to talk about what features should be taken out of or added to Ruby, but as a manager I'm more interested in whether the programmer understands the difference between receivables and inventory."


+1

Danno
2006-03-13 15:12:54
Hrmm... I dunno, I don't think I want to get a job as a "X Programmer". I'd think I'd rather have a job solving interesting problems, preferablly being allowed to use one of the languages that I don't despise.
Luv da FUD
2006-03-13 16:34:08
"...things like type inference... there are other options that have already appeared or will appear in the next few years... going to beat the shit out of ruby and python one day..."


Sounds like someone's talking about C# 3.0 maybe? No one knows FUD like MSFT. ;-) Although, they are talking about continuations in future versions of C#. It would be a sad day if they are able to beat the Rubyists to that punch.

Steve Yegge
2006-03-14 03:04:04
No worries, Alex! I have my share of stupid and shallow moments, like anyone else. And I don't mind being called on it once in a while. Cheers!
Danno
2006-03-14 11:47:02
Luv Da Fud: Err, Ruby already has Continuations.


To be perfectly honest though, I don't think Continuations are ever going to light the world on fire. I mean, they're awesome for doing backtracking and implementing generators and things like that, but they still feel a whole lot like Gotos, even if they are a whole lot safer to use.


Maybe it's just me, but I feel like I'm reading a book about time travel when I look at code with continuations in it.

Phil Tomson
2006-03-14 13:53:01
The best reference or analogy for grok'ing continuations is:


To get some understanding of continuations, see "Run Lola Run"

Steve Yegge
2006-03-14 15:45:40
Folks, I didn't say Ruby doesn't have continuations. Read it again!


The problem is, continuations almost completely useless in Ruby because the interpreter doesn't implement TCO -- which is surprising, given how straightforward it is to implement. So you can't use continuation-passing style without worrying about running out of stack space; you have to use hacks like "trampolining" using an extra no-arg function, which makes them even slower than they already are in Ruby.


And Ruby doesn't allow syntactic extensions -- you can accomplish some simple ones with eval tricks, but there's no interaction with the lexer. So most of the uses of continuations involving implementing nice new control structures are simply not possible in Ruby.


Continuations still have *some* uses in Ruby, and you can even find an example of a use in the the Ruby standard library (generator.rb). But even there, the comments say:


# Note that it is not very fast since it is implemented using
# continuations, which are currently slow.


Frankly, I think Ruby has to get serious about improving the continuations support. Everyone just says "Ruby has callcc!" as if it's some sort of checklist item, so they can claim it's a little more like Scheme than other interpreted languages. But without tail-call elimination, better closures support, and some sort of macro system, having callcc in the language isn't doing anyone any good.


You need TCO, (better) closures, and macros, and not just so that callcc will perform better. You also need them so you can hide the fact that continuations are involved from the user of the API or macro. This is a fundamental design issue, and Ruby got it wrong. Or didn't get it "right enough".


Continuations may be tricky to understand, but not any more so than threads, or asynchronous i/o apis, or any other stuff we really do need occasionally. And having *good* support for continuations puts more control in the hands of your library writers. And that's a Good Thing.


Man, I really need to write a real blog about this sometime.

Ryan Davis
2006-03-14 18:36:55
Steve, the fact that you posted this the day after I interviewed at... um... FooCorp makes me want to kick you in the shin. :P


And I totally botched it with the first person too, because she insisted I answer in C (which, with emacs and a book or two I do just fine with, but on the fly BS interview questions? not so much). I'm actually quite irritated with FooCorp's interview process being as unenlightened as it is. *shrug* oh well. If I go to round two, great... if not, I know why.


2006-03-14 21:07:35
I found the following questions in the phone screen section to be very very poor interveiew questions (A good interview question is not entirely open-ended, has a distinct answer or direction in mind and above all, its not philosophical. An interview question makes sure that the answer is amenable to grading).


* Compare and contrast Ruby with your second-favorite language.
* Describe any two features you'd remove from Ruby to improve it...
[ This is particulary egregious as it takes years of experience on a language]
* Pick any five C++ or Java "design patterns" and....
[ "Five" design patterns? Are you kidding? One is enough, if that. Discounting people because they don't know design patterns is as bad a discounting them for J2EE.]


These were not so bad, probably because I know nothing about the language.
* Describe in detail the name-resolution chain for constants..
* If you were to write a Ruby Style Guide for your company...


The rest of the article is saner.

SteveYegge
2006-03-15 00:38:30
Ryan -- I strongly suspect you and I are talking about different FooCorps. The place where that story happened is not where I work.
A Programmer
2006-03-15 17:46:42
If I want to learn Ruby in half a day as you recommend what specifically should I read or do?
twifkak
2006-03-15 20:05:38
Steve -- love your sense of humor.


"A Programmer" -- depending on your knowledge and initiative:
http://pine.fm/LearnToProgram/
http://tryruby.hobix.com/
http://www.ruby-doc.org/docs/ProgrammingRuby/
http://www.ruby-lang.org/
Now, carry these links around with you, wherever you go, so you can pass the information on to whomever asks you.


2006-03-22 19:55:39
http://poignantguide.net/ruby
Daniel Eklund
2006-03-23 14:39:02
"Ruby is exceptionally easy to learn — far more so than Perl, C++, C#, Java, or even PHP. Oh hell, I'll just say it: it's easier to learn than Python. And that's quite a feat. It means Ruby's inevitably going to become a magnet for people who can't program any other way."


I've been struggling with this interesting conundrum myself -- especially as I am a contractor who A) wants the highest rate/hr, B) wants to program in an elegant language.


The very aspects that make Ruby so nice are the same things that have lowered the barriers to adoption to many a not-so-experienced programmer.


It's elegance and power derives from its simplicity.


So, while I enjoy the gains Ruby has made in the collective mindset, I fear the onslaught of 'me-too' resumes and the static it generates. And, because Ruby has a 'scripting' heritage to live-down, and that low barrier to adoption you were mentioning (recall the flood of VB programmers) Ruby will be doubly challenged to ever be a means for me to make a decent rate/hr.


I mean, for goodness sake, I saw someone post here in the Boston area, a contract position for Rails at $20/hr. That's just amazing. And by 'amazing' I mean 'BS'.


I liked your questions. I probably would have given you a dead-eye stare with the lexer question, but everyone has their bar at a certain level.


For me, the metaprogramming questions would be the primary differentiator. I probably would ask if they had ever created their own attr_reader type 'syntax' and guide the conversation to understand their conception of code=data. The only other thing I could see myself asking is whether they have ever created a method which used a block... (i.e. do they understand the concept of a closure enough to know how to create code that asks for a block)


Still, philosophically, we are going to be at this juncture many more times in the future. We will keep on creating better and more expressive languages/systems (imagine how history would have been different if a Smalltalk or Lisp machine had penetrated the consumer and corporate market) that democratize the skill of programming. Matz is like Prometheus in this regard.


treefrog
2006-04-05 02:06:36
I've been coding in ruby for 5 or 6 years, including metaprogramming, code that writes code, etc. Hell, I'm mentioned in some earlier ruby books as an example of big corporations using ruby.


I couldn't answer half of these questions. I'm not sure that I'm the total klutz though - maybe the stuff I do is generally quite domain specific. But then again, I don't really follow the deep stuff of changes in Constant lookup chains in 1.9, or ruby lexer questions. Why would I really care - I trust other prople who are really interested in this sort of stuff to get on with it. Ruby is and should be a great tool - not a way of life or an evangelical movement!


I'm off to play with my daughter! She hasn't decided on a favourite language yet, but her favourite toy is a heffalump!


regards,

giles bowkett
2006-04-08 10:23:17
I'm a programmer and a musician, and I've noticed something interesting. Your post kind of prompted this little epiphany for me.


The genre of music I've been into for the past couple years is called breaks. It's dance music. Dance music has DJs and producers, and some of them specialize in genres, and some of them don't. So every time a DJ or producer who doesn't specialize in a particular genre committs some energy to breaks, it's seen in the breaks community as a good thing for breaks. Anytime a DJ who spins whatever they feel like decides to play breaks records, that makes breaks more visible in the overall dance music community, and that makes it easier for a DJ who only spins breaks to get booked.


So think about Martin Fowler and his sort of "coming out" in support of Ruby a little while back. That was seen in the Ruby community as a good thing for Ruby. Martin Fowler was seen less as somebody jumping on a bandwagon and more somebody who gave that bandwagon genuine credibility.


So take that and add it up with all this stuff in your excellent post here. From a career management perspective, identifying yourself as any kind of "Language X guy" is career suicide. Language X usually only gets its business dominance over Language Y as a result of fashion trends in the industry. Those fashion trends are partly driven by programmer foolishness, because we hop bandwagons so much it's like we had pogo sticks instead of legs, and partly driven by the fact that all of us have careers which depend on selling stuff to people who don't understand what it is. So these people we sell our code and our time to, they're generally just latching onto various brand names that they've heard, that they're familiar with, and that they've identified with success. This is why it's a lot easier to sell a J2EE project than a Seaside project, even though Seaside is probably much, much better technology. (Of course it's also that they're more interested in the "whole product," i.e., the availability of additional support services such as hosts, third-party documentation, other programmers to maintain what's written, yadda yadda yadda.)


Anyway, back to the career management stuff. Martin Fowler wouldn't have been able to give credibility to Ruby if he hadn't already obtained that credibility with his contributions to the Java and Smalltalk communities. DHH has said that he learned Ruby after hitting some walls with PHP. And back to my kind of tangent there, the DJs and producers who brought credibility to breaks in dance music brought that credibility with them from other genres where they had already earned it.


It's much, much better to be the person who the technology gets its credibility from than the person who gets their credibility from the technology.


Paul Browne
2006-04-26 07:54:14
Ruby is the new Visual Basic.


By that , I mean that it is incredibly easy to use , which is a plus and a minus.


It's a plus if you have to work with the thing day to day.
It's a minus if you want to get highly paid for what you do , as *everybody* can do it.


Laws of Economics : Loads of supply , means lower prices.

Peter Gfader
2006-04-28 07:16:56
I got an c# quine tooo


http://peitor.blogspot.com/2006/04/quine-in-csharp-c_28.html


cheers

Matt
2006-04-28 11:20:39
Ruby performance...


Ruby performance is a real-world issue. I have problems where I would love to apply Ruby but I can't because the performance is unacceptable, instead I use Chicken scheme (which compiles to C). I've been programming perl and scheme for over ten years and ruby for a couple years. I love scheme but I am much more productive in ruby. BTW: I would completely fail your interview process!

Spyder
2006-05-18 08:09:42
"Ruby's at a tipping point. You can see it in the resumes. Go to Monster.com, or your favorite source of online resumes, and you'll see a LOT more mentions of Ruby today than there were a year ago."


That's perhaps a good "indicator". As a 20-year practicing Comp Sci major, I'd suggest that it's vital to one's career to make good choices of languages to master and use. I recall feeling "inferior" to "Powerbuilder Programmers" in the 90's; instead I chose to use Perl. Turns out that decision demonstrated perspicacity, as it fueled the last 10 years of my career. I'll bet there aren't 100 Powerbuilder guys who can say that.

But like Ruby being at the tipping point, so am I. I'm thinking I'm ready for "what's next", having grown a bit tired of Perl's awkward OO constructs,and thinking Perl is now in a downturn as the web looks for towards more powerful, efficient tools.


So I'm thinking maybe Ruby? Maybe it's the next big wave I can ride? On the other hand, master it, and it goes belly-up, it's too late to change horses, we're pretty much toast as other developers' would have leap-frogged us.


I plan to quietly introduce it here and start some small projects and see how that goes. I've already talked it up in the right circles. I'm thinking we need to get past Perl, but it won't be easy! Of course, it wasn't easy getting past "c" to move onto Perl in the 90's either. But it was decidedly the right decision.


I don't worry too much about the simplicity. There will always be room for the gurus. I'm not talking about the guy who has a lot of detailed knowlege of parser-generator approaches, obscure language features, etc. I mean the guy who can code an elegant solution in 100 lines, in 2 hours, as opposed to 1000 lines in 2 days. The one who studies the language to the point they understand how to get things done quickly and reliably. The productive programmer.


That's what's distinguished my Perl career. I can't answer 1/2 the obscure regex posers in comp.misc.perl , but I know how to use split on a textfile where I see others writing a "java-like" 20 line loop to do the same thing.


I see the same thing with Ruby. Like Perl, lots of folks can get the "Llama book" and start coding tomorrow. But their value to an employer in real terms is perhaps 1/10 of what an expert can deliver.


The trick being how to make employers see that difference? Once inside it's evident, but on a resume we all look about the same..