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. -- Posted via http://www.ruby-forum.com/.
Mike <no@...> writes:> > 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. >>From my limited personal experience and from knowledge of a couple other railersin 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?
At 1/18/2006 09:33 AM, you wrote:>Mike <no@...> writes: > > > > > 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. > > > > >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?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 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 -- Jarkko Laine http://jlaine.net http://odesign.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2363 bytes Desc: not available Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060118/094e00e4/smime-0001.bin
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). -- Posted via http://www.ruby-forum.com/.
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. -- Posted via http://www.ruby-forum.com/.
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. :) -- Posted via http://www.ruby-forum.com/.
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 1/18/06, thila thila <isputnik_98@yahoo.com> wrote:> 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. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
That was an excellent suggestion....-->> Rails does make things easier, so make sure you get paid per project, > and not per hour. :)-- Posted via http://www.ruby-forum.com/.
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
Obie Fernandez 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 > > ObieI 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 -- Posted via http://www.ruby-forum.com/.
On 1/18/06, thila thila <isputnik_98@yahoo.com> wrote:> > That was an excellent suggestion....--> > > > Rails does make things easier, so make sure you get paid per project, > > and not per hour. :) > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.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. -- Nicholas Van Weerdenburg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060118/40def5bf/attachment.html
> 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.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 root@turingstudio.com http://www.turingstudio.com 2600 10th street, suite 635 berkeley, ca 94710
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 -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of alex black Sent: Wednesday, January 18, 2006 11:23 AM To: rails@lists.rubyonrails.org Subject: Re: [Rails] Re: Pay rates for Rails developers> 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.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 root@turingstudio.com http://www.turingstudio.com 2600 10th street, suite 635 berkeley, ca 94710 _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails
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.-- Posted via http://www.ruby-forum.com/.
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: rdm@cfcl.com, +1 650-873-7841
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. -- Posted via http://www.ruby-forum.com/.
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 18-Jan-06, at 12:45 PM, Amr Malik wrote:> Obie Fernandez 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 > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
>> I am British but live in Canada. I have asked for and receive $100 /hour So would that be CAD$100/hr ? On 1/18/06, Bruce Balmer <brucebalmer@mac.com> 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. > > 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 18-Jan-06, at 12:45 PM, Amr Malik wrote: > > > Obie Fernandez 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 > > > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060118/9228593a/attachment.html
On Jan 18, 2006, at 4:25 PM, Bruce Balmer 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 Mornini
On Jan 18, 2006, at 4:20 PM, Steve Ross 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 mannerAbsolutely!> 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 Mornini
On Jan 18, 2006, at 1:05 PM, Rich Morin wrote:> 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.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
This might be a little of the original topic, but I think it is related. I have read about agile development and it definately sounds very productive. One question I have always had is how do you estimate the schedule and budget for a medium-large size project? For example, if the client says "We need an e-commerce site to sell our widgets", how do you come up with an estimate? It seems with Agile Dev, you just sit down and say, well, we know you are going to need a shopping cart, so lets do that first, then you do one interation, and then move on to the next, etc. Another way of putting it. Client says "I need an e-commerce site ready for the holiday season". If it can''t be ready for the holiday season, they don''t want it. They don''t want it partially done. How can you tell if you will be able to develop all the features in time, if you are just working iteration-by-iteration? On 1/18/06, Rich Morin <rdm@cfcl.com> wrote:> > 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: rdm@cfcl.com, +1 650-873-7841 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060119/26c4882d/attachment.html
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 1/18/06, Scott Willson <scott@butlerpress.com> wrote:> > > On Jan 18, 2006, at 1:05 PM, Rich Morin wrote: > > > 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. > > 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 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060119/9b9f9bc4/attachment.html
On Wed, Jan 18, 2006 at 09:34:15PM -0500, Paul Barry wrote:> This might be a little of the original topic, but I think it is related. I > have read about agile development and it definately sounds very productive. > One question I have always had is how do you estimate the schedule and > budget for a medium-large size project? For example, if the client says "We > need an e-commerce site to sell our widgets", how do you come up with an > estimate? It seems with Agile Dev, you just sit down and say, well, we know > you are going to need a shopping cart, so lets do that first, then you do > one interation, and then move on to the next, etc. > > Another way of putting it. Client says "I need an e-commerce site ready for > the holiday season". If it can''t be ready for the holiday season, they > don''t want it. They don''t want it partially done. How can you tell if you > will be able to develop all the features in time, if you are just working > iteration-by-iteration? >The short and difficult answer is: experience. Estimating time, particularly on larger projects, is hard. Sometimes the client''s wants and needs change, sometimes new things are discovered (this is why fixed price contracts can suck). Sometimes bad things just happen. The only way to become accurate with estimation is to do it. Know yourself and your capabilities. Start with liberal estimates, keep track of what you estimated and how long it ended up taking. Sometimes you''ll be over, sometimes under. I like estimating in terms of iterations, like you describe above. The less you have to estimate, the more accurate your estimate will be. Eventually you''ll be an estimation pro. And then something else will come along and radically change the way you work and you''ll be on some other list asking this very same question ;) -Scott
So in order to estimate how long the whole project will take, you have to come up with an estimate of the number of iterations there will be, and then estimate how long each estimate will take? On 1/18/06, Scott Barron <scott@elitists.net> wrote:> > On Wed, Jan 18, 2006 at 09:34:15PM -0500, Paul Barry wrote: > > This might be a little of the original topic, but I think it is > related. I > > have read about agile development and it definately sounds very > productive. > > One question I have always had is how do you estimate the schedule and > > budget for a medium-large size project? For example, if the client says > "We > > need an e-commerce site to sell our widgets", how do you come up with an > > estimate? It seems with Agile Dev, you just sit down and say, well, we > know > > you are going to need a shopping cart, so lets do that first, then you > do > > one interation, and then move on to the next, etc. > > > > Another way of putting it. Client says "I need an e-commerce site ready > for > > the holiday season". If it can''t be ready for the holiday season, they > > don''t want it. They don''t want it partially done. How can you tell if > you > > will be able to develop all the features in time, if you are just > working > > iteration-by-iteration? > > > > The short and difficult answer is: experience. Estimating time, > particularly on larger projects, is hard. Sometimes the client''s wants > and needs change, sometimes new things are discovered (this is why fixed > price contracts can suck). Sometimes bad things just happen. The only > way to become accurate with estimation is to do it. Know yourself and > your capabilities. Start with liberal estimates, keep track of what you > estimated and how long it ended up taking. Sometimes you''ll be over, > sometimes under. I like estimating in terms of iterations, like you > describe above. The less you have to estimate, the more accurate your > estimate will be. Eventually you''ll be an estimation pro. And then > something else will come along and radically change the way you work and > you''ll be on some other list asking this very same question ;) > > -Scott > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060119/d02fb4af/attachment.html
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 -- Posted via http://www.ruby-forum.com/.
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 Jan 18, 2006, at 6:35 PM, Paul Barry wrote:> 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 1/18/06, Scott Willson <scott@butlerpress.com> wrote: > On Jan 18, 2006, at 1:05 PM, Rich Morin wrote: > > > 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. > > 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 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On Jan 18, 2006, at 6:54 PM, Scott Barron wrote:> On Wed, Jan 18, 2006 at 09:34:15PM -0500, Paul Barry wrote: >> Another way of putting it. Client says "I need an e-commerce site >> ready for >> the holiday season". If it can''t be ready for the holiday season, >> they >> don''t want it. They don''t want it partially done. How can you >> tell if you >> will be able to develop all the features in time, if you are just >> working >> iteration-by-iteration? >> > > The short and difficult answer is: experience. Estimating time, > particularly on larger projects, is hard. Sometimes the client''s > wants > and needs change, sometimes new things are discovered (this is why > fixed > price contracts can suck). Sometimes bad things just happen. The > only > way to become accurate with estimation is to do it. Know yourself and > your capabilities. Start with liberal estimates, keep track of > what you > estimated and how long it ended up taking. Sometimes you''ll be over, > sometimes under. I like estimating in terms of iterations, like you > describe above. The less you have to estimate, the more accurate your > estimate will be. Eventually you''ll be an estimation pro. And then > something else will come along and radically change the way you > work and > you''ll be on some other list asking this very same question ;) > > -Scott > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/railsAnd I would add: use simple measures to track your iteration estimates and how well you meet them. Graph and adjust. Don''t go overboard with the details -- a small amount of visual feedback improves your estimation skills remarkably. The other Scott
On 1/18/06, Paul Barry <mail@paulbarry.com> wrote:> > So in order to estimate how long the whole project will take, you have to > come up with an estimate of the number of iterations there will be, and then > estimate how long each estimate will take?As background: I am by no means an agile expert, however, I have been the team lead on a large-scale software project (J2EE), working with about 12 engineers geographically distributed between Chicago, Minnesota, North Carolina, New York and London. The project went from version 0.0 to version 2 (soon to be released) over the course of 2 years. Version 2 will be our 3rd major release with several smaller patch releases in between, effectively giving us one release every quarter. Here''s (very roughly) what we do - it''s a mish-mash of practices that are based on agile ideas. At the beginning of a release cycle we sit down with the product manager, marketing and sales people (we consider these people our "customers" since we don''t have direct contact with clients), and figure out what features are required. We don''t go into a lot of detail, just enough to get a sense of the functionality. Then we take each feature and break it down into stories ( http://www.extremeprogramming.org/rules/userstories.html). A story at this point is either small, medium or large. Small is less than a week of development, medium is about a week or so, and large is 2 weeks. Anything that will take longer to implement we break it down further. In any case, a story must result in tangible, testable functionality that the customer can experience first hand. Next we estimate our velocity - how much work we can get done in a 2 week iteration. For example, if there are 10 engineers, then we can get 10 large stories done in an iteration. Then we cut the estimate in about 1/2 to allow for learning, unplanned activities, non-development tasks, etc. This will give us a target date. If that date is too far in the future, we remove stories from the release cycle and put them in a pile for another release. We don''t put any hard and fast rules about what story goes into what iteration, but we generally have an idea of what we want to accomplish when. Every 2 weeks we have an iteration planning meeting ( http://www.extremeprogramming.org/rules/iterationplanning.html) and we flesh out the stories, identify tasks, and generally figure out if we were off on our estimates. Sometimes we are, but usually we''re pretty close. We make sure that the stakeholders are a part of this meeting so they understand what is happening next. At the end of the 2 weeks, we have an iteration review where we demonstrate the functionality completed and make the product available for internal use (product managers, marketing, qa, etc). Every iteration should result in a workable product. Then we lather rinse and repeat until we are done with the release cycle. This process has worked well for us, has allowed us to be proactive and communicative with our customers, has provided early feedback and qa, and has resulted in on time delivery (or very close to it) every quarter for 2 years - starting with only an idea. Of course, I haven''t mentioned acceptance tests, unit testing, pair programming, etc. Those things are all a part of this as well. All in all, I''m sold on agile methodologies. For us they have worked quite well. -- Lance Ball http://lance.langwell-ball.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060119/a803accb/attachment.html
Yes. On 18-Jan-06, at 2:39 PM, Ed C. wrote:> >> I am British but live in Canada. I have asked for and receive > $100 / hour > > So would that be CAD$100/hr ? > > > On 1/18/06, Bruce Balmer <brucebalmer@mac.com> 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. > > 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 18-Jan-06, at 12:45 PM, Amr Malik wrote: > > > Obie Fernandez 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 > > > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060119/fc4be1de/attachment.html
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 18-Jan-06, at 7:16 PM, Bruce Balmer wrote:> Yes. > > > On 18-Jan-06, at 2:39 PM, Ed C. wrote: > >> >> I am British but live in Canada. I have asked for and receive >> $100 / hour >> >> So would that be CAD$100/hr ? >> >> >> On 1/18/06, Bruce Balmer <brucebalmer@mac.com> 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. >> >> 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 18-Jan-06, at 12:45 PM, Amr Malik wrote: >> >> > Obie Fernandez 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 >> > >> > -- >> > Posted via http://www.ruby-forum.com/. >> > _______________________________________________ >> > Rails mailing list >> > Rails@lists.rubyonrails.org >> > http://lists.rubyonrails.org/mailman/listinfo/rails >> >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060119/4a363c40/attachment.html
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 1/18/06, Jeff Pritchard <jp@jeffpritchard.com> wrote:> > 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)? >-- Andrew Semprebon * http://www.eqsystems.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060119/194a368f/attachment-0001.html
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. ;) -- Posted via http://www.ruby-forum.com/.
On 1/19/06, Mike <no@spam.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.
Gokhan Arli
2006-Jan-19 17:07 UTC
[Rails] Re: Re: Re: Re: Re: Pay rates for Rails developers
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 Arli www.sylow.net -- Posted via http://www.ruby-forum.com/.