I’m trying to find Ruby developers. Rails developers, really (though preferably Rails developers who actually know Ruby). I’ve got work for them.

However, they’re hard to find in my neck of the woods, (i.e., approximately Phoenix, AZ). And, based on calls from folks out of state, I’m not alone.

It’s not that there are no Ruby people around here; there are some. The Phoenix Ruby User Group meeting gets around a dozen people on average (plus there are some who can’t, or don’t want to, partake in the group’s monthly edutaintment festivities).

But I regularly get calls from people looking to hire Rails developers, and I’m having a hard time finding people who are available, qualified, and reliable.

It’s a funny sort of problem. Apparently (at least around here), if you are already a Ruby consultant, you’ve got plenty of work. So busy you don’t return calls or answer E-mail. If you’re a client looking for a Ruby developer, though, you may start questioning the wisdom of that choice. To make things worse, I’ve gotten calls from people who had a Ruby shop looking after them, but have gotten the nudge to go find someone else to look after their project. There could be all sorts of reasons for this; a client starts asking for more attention than expected, or a contractor or consulting shop finds more lucrative clients so they give the heave-ho to some existing ones.

The upshot to this may be that clients start questioning the practicality of having their apps built on Rails. I used to scoff when people suggested that picking Ruby as your business technology was risky because you might end up with trouble hiring skilled people, but there seems to be some truth in that. And not only might it be hard to get Ruby people to look after your project, but even if you find one they may lose interest and you’ll be on the hunt again.

All this, of course, is anecdotal. It might be exactly the same for people looking for Java or PHP consultants (whom are in abundance here). Maybe it’s just how the market plays itself out. My sense, though, is that market ebbs and flows are more of a problem when there are fewer players. These shifts just matter less when there are a lot of people skilled in Foo and a lot of people looking for Foo hackers.

For busy Ruby consultants the current balance is great. But we can’t be short-sighted. If you’re asked to take on some work, but don’t have the resources, make an effort to find someone who does. Pass on names and numbers. The last thing you want is to pull your head up after the end of some engrossing project only to find that no one is calling you anymore because they’re tired of getting burned or tired of relying on a scarce resource and went down the PHP|Java|ASP.net path.

In any event, if you’re in the Scottsdale/Phoenix area, and you’re good with Ruby, and you’re looking for some work, drop me a line: james+jobs@neurogami.com. Or if you know someone who might be interested, have them get in touch with me. I’m at the point where I feel awkward encouraging people to bet their business on Ruby, but I’m also optimistic people will prove me wrong.

And if you’re a local Rubyist not looking for work, please make the time to come to the monthly meeting, help support the community, and help each of us keep up-to-date on who’s doing what.

add to del.icio.us. look up in del.icio.us.   add to furl

The next Phoenix Ruby User Group meeting, September 13, will have a triptych of talks on core JavaScript, jQuery , and jQuery UI .

I’ll be covering JavaScript, while Greg Furmanek and Naum Trifanoff will handle jQuery and jQuery UI.

If you’re doing any sort of Web development, Ruby or otherwise, you want to know about these topics.

add to del.icio.us. look up in del.icio.us.   add to furl

shenheng对《系统复杂之路》评论道：
连自己也维护不了的代码，难道可以靠神一般的咨询师？玩笑开大了吧，咨询师的到来，与葬礼上的神父无异！

咨询师会带来天翻地覆的变化，这样的期许本身就是不现实的。

其实，我也不喜欢咨询师。

做咨询之前，我一直想不通，有什么问题自己搞不定，非要请咨询师。founder_chen说，如果大家都像你一样，咨询就没活干了。

可惜，世界上还有很多咨询师，后来，我也成了一个。

做咨询一段时间，我常困惑于我到底可以给客户带来什么。

于今，我释然了。我只不过关注着一些那些人不曾关注过的东西，比如软件设计，比如Clean Code，比如重构，比如TDD，比如如何做程序员，比如如何做事。而在客户那里，我所做的，只是把这些东西以他们习惯的方式展现给他们。

我只是打开一扇门。

做了个培训，结尾，有人问，怎样才能保证设计的一些东西在后续的开发过程中不被破坏。

好问题，保证不了。

真正保证设计不被破坏的是团队，而不是软件设计本身。团队里需要有人知道代码应该写成什么样子，需要有人清楚系统架构是什么样子，需要有人有正义感，在有人无心伤害时，敢于出来喊一嗓子。

在原有的环境下，这样的人对于其他的工作方式知之甚少。不是他们不努力，很多时候，他们只是不知道自己不知道。我所能带给他们的就是，让他们知道另一片风景的存在。

add to del.icio.us. look up in del.icio.us.   add to furl