Does anyone have an idea of the rates being charged by Rails developers (or salaries for FTEs)? I'm curious to see whether rates will become comparable to those paid to more experienced Java/.NET developer types, or if rates will be lowered by the free/open source mentality, and the possible perception that Rails makes Web development "easy." Sometimes rates are more dependent upon the client than the technology (i.e., smaller clients typically can't afford higher rates), but the platform is also a factor.
on 2006-01-18 16:16
on 2006-01-18 17:11
Mike <no@...> writes: > (i.e., smaller clients typically can't afford higher rates), but the > platform is also a factor. > >From my limited personal experience and from knowledge of a couple other railers in the area, we're seeing typical rates between $30-50/hr for contracting here in Central Florida. I don't know about salaries. We have discussed some of the same concerns... fighting the open-source mentality and the notion that rails is "easy". Rails is definitely more productive, but to me that means rails is of high value. I can offer better code, more features and easier maintenance in less time, so my actual value per hour should be higher, right?
on 2006-01-18 17:17
At 1/18/2006 09:33 AM, you wrote: > > >that rails is >"easy". Rails is definitely more productive, but to me that means rails is of >high value. I can offer better code, more features and easier maintenance in >less time, so my actual value per hour should be higher, right? I suppose you've all read this post: http://www.relevancellc.com/blogs/?p=92 I have no problem quoting the same rate for Rails work as for any other (but the client is getting more value/hr with Rails ;-) -Rob
on 2006-01-18 17:20
On 18.1.2006, at 16.16, Mike wrote: > Does anyone have an idea of the rates being charged by Rails > developers > (or salaries for FTEs)? > > I'm curious to see whether rates will become comparable to those > paid to > more experienced Java/.NET developer types, I think if something the hourly rates should be higher. If the client is paying by the hour and gets the same system made much sooner, they'll save both time and money, even if they pay, say, 25% higher rates. Being a Rails developer does not mean being an inexperienced developer, quite the contrary. Most of the early Rails developers have been using a wide set of tools and languages before and come to Rails because they weren't satisfied with what they had. That alone shows a certain level of pragmatism that you would want to see in a programmer you hire. > or if rates will be lowered > by the free/open source mentality, and the possible perception that > Rails makes Web development "easy." I think this is a very dangerous way of thinking. Being open source doesn't devalue the work done. Nothing can make web development "easy", because it is inherently a demanding and multifaceted task no matter what framework/language combination is used. What Rails does is it makes more of the work done contribute to the end product (as opposed to circumvent language quirks), and gives more pleasure to the programmer (totally subjective opinion). Therefore, an hour spent on Rails is IMHO much more valuable to the client than an hour spent on most other frameworks. That said, I think the rate depends heavily on the level of the programmer. If you want top-notch, be prepared to pay top salaries. There is probably going to be shortage of good Rails developers as it's reaching the tipping point, and people aren't going to work on slave salaries anymore just to get to work on the framework they love. The great thing about open source is that you can immediately check what a given programmer has done for the product and the community. Just check the patch lists, discussions and blogs. //jarkko
on 2006-01-18 18:01
Great replies. Thanks! Jason: That rate doesn't sound too bad for Central Florida (not like I know the market or anything!). Rob: Yeah, that's a good link and I hope others will continue to write about this topic. I plan to but I'm not there yet--my goal is to limit or leave behind the other platforms. Jarkko: I agree and hope the market will, too. ;) Higher rates usually come with bigger clients, who are slower to adopt new technologies. So it seems like the projects out there right now are more cutting-edge and with smaller companies who typically don't pay as well, partly because of size and partly because they can take advantage of the fact that Rails is the cool, new technology (as Jarkko mentioned).
on 2006-01-18 18:19
My 0.02 cents.. I think we are shooting ourselves in the foot with Ruby. This is a great language, simplies development; we no longer need smart programmers (no pun intended) to develop in Ruby as compared to c++ or J2EE. As history shows, the easier the tool, the cost will be down since too many people will jump on to the bandwagon. This is the reason that the VB programmers are getting paid less than J2EE programmers. -comments are welcome.
on 2006-01-18 18:28
Conclusion: Learn Haskell, and develop your applications with it. Really concise programs that can be developed fast, and the non-smart programmers will not be able to grok it ;-) Rails does make things easier, so make sure you get paid per project, and not per hour. :)
on 2006-01-18 18:30
That was an excellent suggestion....--> > Rails does make things easier, so make sure you get paid per project, > and not per hour. :)
on 2006-01-18 18:33
I wrote an article which fixed-bid work with Rails in order to best leverage the time/value proposition. Clients have an expectation of how long it will take to do a given amount of scope... charge them based on that expectation then deliver early (and/or) overdeliver based on the productivity benefits of working with Rails... Reap massive profits. Read more at http://jroller.com/page/obie?entry=productivity_arbitrage Obie
on 2006-01-18 20:03
On Wed, Jan 18, 2006 at 05:30:16PM +0100, thila thila wrote: > That was an excellent suggestion....--> > > > Rails does make things easier, so make sure you get paid per project, > > and not per hour. :) I would disagree. In my experience fixed price contracts tend to be a pain. If the project would take you X hours to do in Java and X/2 hours to do in Rails then you need to adjust the hourly rate accordingly. There is value in rapid delivery and if you can deliver a quality product quickly then you should be compensated accordingly. I also do not agree with the previous statement "we no longer need smart programmers [...] to develop in Ruby". This is the part of the "rails is easy!" spiel that I really dislike. I'm not aware of any tool that will convert a non-programmer (or inexperienced programmer) into someone able to pull down $100+/hr for a project. Overall experience is more valuable than specific tool experience. To paraphrase something Jason Fried said, it's not easy, but Rails makes it eas*ier* (for experienced developers). Sure you can find someone to throw together a PHP site for $20/hr but in my experience those projects either fail or are eventually replaced with something done by someone with more experience (and for a lot more money). As Jarkko indicated, top notch Rails developers are bringing in top rates/salaries. I won't post my rates on the list, but I can say that the earlier stated $30-$50/hr is a bit low. There is certainly no shortage of Rails work right now. It is exciting times. Good luck to everyone endeavoring professionally in Rails! -Scott
on 2006-01-18 21:45
Obie F. wrote: > I wrote an article which fixed-bid work with Rails in order to best > leverage the time/value proposition. Clients have an expectation of > how long it will take to do a given amount of scope... charge them > based on that expectation then deliver early (and/or) overdeliver > based on the productivity benefits of working with Rails... Reap > massive profits. > > Read more at http://jroller.com/page/obie?entry=productivity_arbitrage > > Obie I haven't done much Rails contracting,but as a general rule: Know thyself: ie; your proficieny in the toolset Know thy enemy: Scope creep is your enemy Know thy friend: These would be Scope/Deliverables clauses in the contract. Its almost habitual for clients to demand more on a fixed bid contract if you haven't concretely defined deliverables and you deliver 'early' hoping you can take the 'profits' home. Rails may make delivering projects easier, but ask yourself: Can I deliver this project with _this_ scope in _this_ amount of time. Cover your bases with concrete devliverables/scope clauses SIGNED by the client project stake holders. Doing fixed bid contracts is mastered by very few people/companies (I'm not one of them, but I've been burned by deals other ppl did -- read sales team vs. delivery team in a big 5 consulting context). It would be good if there was some kind of a rates list though, right now it seems like nobody wants to share what they're making and this may cause some people to undersell their talent. -Amr
on 2006-01-18 21:52
On 1/18/06, thila thila <email@example.com> wrote: > Rails mailing list > firstname.lastname@example.org > http://lists.rubyonrails.org/mailman/listinfo/rails > This is a really bad suggestion unless you've done several rails projects, are doing similar projects, have very clear requirements and a customer that isn't adverse to change orders when they change the requirements.
on 2006-01-18 22:01
> > -comments are welcome. You get what you pay for. Code is language: Ruby is "easy" so it's easier to sentence write backwards understand so no one can. It's also a good tool for writing coherent, concise sentences. J2EE ensures additional extraneous repetitive extra language communication concepts utilizing ridiculously comically complex language communications conventions in addition to (one times ten times one hundred)s of java programming language lines statements of configuration descriptions values. So: should I underpay an idiot to write me unintelligible ruby with simple constructs, or should I overpay an idiot to write unintelligible J2EE with complex constructs? Neither. I should pay good money to very smart people I respect to write clear, functional, self documenting sentences in a language that helps them do so: ruby. Good code will always cost money, because you need smart people to write good code. :) _a -- alex black, founder the turing studio, inc. 510.666.0074 email@example.com http://www.turingstudio.com 2600 10th street, suite 635 berkeley, ca 94710
on 2006-01-18 22:13
excellent point. that's been my biggest disappointment with ruby, really. it may be a smart language, but it doesn't seem to have made me any smarter :-) _______________________________________________ John McGrath http://fryolator.com
on 2006-01-18 23:20
I don't believe I'm being paid for the lines of code I write. I'm being paid to: 1) Design the best solution that most closely fits the client's needs 2) Create robust, extensible, testable systems that perform to the client's specs 3) Do so in a timely manner My clients don't care if I code in assembly language. They trust me to pick the best combination of platform and technology, development tools, and related technologies (i.e. source code control, deployment). Does anyone really feel they are being paid less because they are using Ruby or Rails? I find I am implementing more and cooler features and having more fun with it. I have happier clients. They are having fun with it. Happier clients tell other people who then become happy clients. I agree with the poster who said charge your usual rates. What you bring to the table is your intellect, your design skill, and your unique knowledge of the available technologies. You use these to do far more than cut code. Anyhow, if you finish early, sign up the next client :) Just my $.02 Mike wrote: > Does anyone have an idea of the rates being charged by Rails developers > (or salaries for FTEs)? > > I'm curious to see whether rates will become comparable to those paid to > more experienced Java/.NET developer types, or if rates will be lowered > by the free/open source mentality, and the possible perception that > Rails makes Web development "easy." > > Sometimes rates are more dependent upon the client than the technology > (i.e., smaller clients typically can't afford higher rates), but the > platform is also a factor.
on 2006-01-18 23:44
The problem of "scope creep" is just one of the problems with fixed-price contracts. Unless the contract is bid so high that minor variations can be ignored, the client and developer will find themselves arguing over details when they should be trying to find the best solution. So, my personal practice is to (a) set a fixed hourly rate and (b) make very frequent (e.g., weekly) progress reports. This ensures that the project doesn't spin off into the weeds (on the client's dime), but gives enough freedom to select and implement the appropriate solution. The use of Agile Development practices (IMHO) makes it even more important to have this freedom. -r -- Technical editing and writing, programming, and web development: http://www.cfcl.com/rdm/resume Contact information: firstname.lastname@example.org, +1 650-873-7841
on 2006-01-18 23:58
I know to a certain extent the answer to my question is "whatever clients will pay" or "whatever the market will bear." That's true when dealing with end clients. I wonder what subcontractors are making, since some of the consumers of Rails development services are part of the community here.
on 2006-01-19 00:02
Alright, I'll open the bidding, by saying what I am charging. I am British but live in Canada. I have asked for and receive $100 / hour for my coding. That said, two factors and one additional piece of information. 1. I am a smart person (well, my mother assures me this is so). So I am comfortable charging reasonably for my skills. I don't feel I am smart until I bump into other people, usually MBAs talking junk, then I am reminded that I am. So each time someone gets an MBA it helps my income. I think that is cute. 2. I have good programming skills but am still at the beginning of my ruby skills. I expect to increase my rate as my skills grow. 3. The other factor is that I don't charge for my learning time. The other day I got stuck 3 times in six hours. Truthfully I got one hour of work done and spent 5 on my education. And being truthful I charged for one hour. Now that sucks. But whose fault is my incompetence? The Clients? I think not. So I charge for coding time not learning time. I think that is fair and the only decent thing to do. 4. I believe fixed charge contracts are a very good idea but I have seen "scope creep". I think fixed charge contracts are like playing Golf. If you suck at Golf you aren't going to have a lot of fun. Fixed cost contract negotiations are a skill. Try not to execute things that require more skill than you have. That is my two cents worth. Bruce PS. I think people sometimes miss the point about clients. There are MANY things clients want and need from programmers. Code is only one of them. There is honesty, of course, there is ideas, there is human interface skills, there is a joyful interaction between human beings. I think a person who sells him/herself as a coder is selling him/herself short. You are there to provide a solution. I recently had an accountant try to overcharge me 4x for his work. Another accountant who deliberately did not disclose to me her rate of $350 / hour when she knew I had made the assumption it was less. I had a programmer a couple of years ago tell me three times that three different projects would take one quarter of the time they did. My philosophy on life is simple, be honest, be wonderful then when you charge what you are worth, you'll be happy with the paycheck.
on 2006-01-19 00:17
>> I am British but live in Canada. I have asked for and receive $100 / hour So would that be CAD$100/hr ?
on 2006-01-19 04:34
On Jan 18, 2006, at 4:25 PM, Bruce B. wrote: > 3. The other factor is that I don't charge for my learning time. > The other day I got stuck 3 times in six hours. Truthfully I got > one hour of work done and spent 5 on my education. And being > truthful I charged for one hour. Now that sucks. But whose fault > is my incompetence? The Clients? I think not. So I charge for > coding time not learning time. I think that is fair and the only > decent thing to do. This is a very decent thing to do, but I think it might lead you to the poor house. The problem with your model is that it assumes that you'll someday reach a level where you know it all, and can charge for everything you do. Of course, if your effective rate for the 6 hour span you discuss above ($16.67/hr) covers your needs, then everything is OK. That said, the real problem with not charging for your education is that more and more (and I mean literally day by day) it's clear that there's new stuff to learn EVERY DAY. This is particularly rough right now in Rails, as the core team is moving quickly, and the framework is not yet mature (not a derogatory remark!). Because of this, it would be easy to say that things will get better. However, having recently read Ray Kurzweil's excellent "The Singularity is Near", and looking over my shoulder at the last few years, I'm pretty clear that the prime challenge of the next 20 years will be keeping up with the fantastic rate of change that is inevitable. IMHO, we'd better learn to charge for learning new stuff, or we'll all be paupers. :-) -- -- Tom M.
on 2006-01-19 04:37
On Jan 18, 2006, at 4:20 PM, Steve R. wrote: > I don't believe I'm being paid for the lines of code I write. I'm > being > paid to: > > 1) Design the best solution that most closely fits the client's needs > 2) Create robust, extensible, testable systems that perform to the > client's specs > 3) Do so in a timely manner Absolutely! > My clients don't care if I code in assembly language. They trust me to > pick the best combination of platform and technology, development > tools, > and related technologies (i.e. source code control, deployment). Mine too. > Does anyone really feel they are being paid less because they are > using > Ruby or Rails? I find I am implementing more and cooler features and > having more fun with it. I have happier clients. They are having fun > with it. Happier clients tell other people who then become happy > clients. Well, I'll say this. From my perspective a majority of people that are looking for Rails programmers right now aren't willing to pay top dollar. It seems that the excitement of the quick development cycle has magically transformed itself into a "Rails is Cheaper" mentality right now. > I agree with the poster who said charge your usual rates. What you > bring > to the table is your intellect, your design skill, and your unique > knowledge of the available technologies. You use these to do far more > than cut code. > > Anyhow, if you finish early, sign up the next client :) We're in total agreement. The key is getting the right client, rather than having them find you...and isn't that really always the case? -- -- Tom M.
on 2006-01-19 05:10
On Jan 18, 2006, at 1:05 PM, Rich M. wrote: > freedom to select and implement the appropriate solution. I agree. An even better (b) is: make very frequent progress -- end of story. Deploy new, usable functionality to the client every few weeks. Make it clear from the start of the project that the client can walk away at any point with a working product. If a client sees continual return on their investment, they will feel that they are in control (they ARE in control) and be glad to continue to invest in your work. Scott
on 2006-01-19 05:13
Progress is good, but how can you tell if you are making enough progress to be ready to "go live" with the product by date X?
on 2006-01-19 05:50
bruce balmer wrote: > Alright, I'll open the bidding, by saying what I am charging. I am > British but live in Canada. I have asked for and receive $100 / hour > for my coding. That said, two factors and one additional piece of > information. I find this thread fascinating, not so much because it is ruby flavored, but because it has renewed my hope of returning to contract programming. I was considering doing just that a few months back and looked at some of the online contract bidding sites like Elance.com and was absolutely appalled by what people were bidding for large projects. It seemed from that small bit of research that people in developing countries were flooding the market with bids that seem insanely low to someone from the U.S. I simply couldn't live on what people were bidding for projects there. Basically like $5/hr or even less! Are there better places to look for projects that will pull "normal" programmer rates? I just figured that the world had changed (for the worse) during the seven or eight years I was away from this game. Where would you go to look for people willing to pay a seasoned programmer/engineer $50/hr or more for contract software work (rails or otherwise)? thanks, jp
on 2006-01-19 05:58
Well, it's more art than science. If you've got the coding experience to tackle the project, you have the experience to estimate it. "Go live by date X." Say that's five months from now. From the requirements and your experience, you should be able to say that it's probably a one-, three-, six-, or twelve-month project. Make your best guess. Spend your energy defining early deliverables (creative thinking required here). Present your proposal and yourself professionally. If you think the client's goals are unrealistic, tell them why. Help them with alternatives. Once you get started on the project -- unless it's different than every other project I've worked on -- the product, the date, and the user audience will change. This is a good thing. Better to find out at the beginning and demonstrate your flexibility and skill, then to find out two angry weeks before launch. It's very, very hard to precisely estimate and plan long-term software projects. It's much easier to tackle small parts of a big project and build a relationship with the client. Now, as I type all these nice generalities, I can think of many specific problems. I am sure you can, too! At least with early deliveries, you discover the problems early when they are cheaper to fix. Scott
on 2006-01-19 08:26
on 2006-01-19 08:56
Let me just reply to the person who thinks I may be in the poor house if I don't charge for learning time. It was an exceptional event. bruce
on 2006-01-19 15:50
Unfortunately, if you have to ask where to find those jobs, you probably won't be able to get them. In my experience, clients are only willing to pay a good rate (lets say $80+ per hour) for people they actually know will be good. How do they know? From previous experiences, or recommendations from other contractors they know. That's how I've gotten all of my contract positions.
on 2006-01-19 16:40
My answer is similar to Andrew's: my current rate using one of The Other Technologies is in that range, but I'm working for an old co-worker who founded his own company. I think that's one benefit of working full-time--you get to know people in your community and if they like working with you (talent is often of lesser importance), sooner or later your phone's going to ring. So I'm a subcontractor, and that's why I'm curious about subcontractor rates. End-user clients may not care about the technology and your earnings are largely based on what they can afford, but I believe the situation is somewhat different in the subcontractor world because you're dealing with clients who are themselves developers. BTW I'm impressed with the polite tone of the posts here. Where are all the angry people? I hope the Ruby community's as nice as it seems. ;)
on 2006-01-19 18:27
On 1/19/06, Mike <email@example.com> wrote: > > BTW I'm impressed with the polite tone of the posts here. Where are all > the angry people? I hope the Ruby community's as nice as it seems. ;) When you use Rails, you see butterflies and rainbows everywhere. It's hard to stay angry in that environment.
on 2006-01-19 19:44
In netherlands hourly rate for any project starts from 40 euro = around 50USD per hour (lots of tax and social security payments we have here) I plan to increase my rate to 50 euro when market here grows a little bit more for rails. Gokhan A. www.sylow.net