This is a response to an email I received yesterday. I am trying to reduce the number of times I say things by just blogging about them.
This is my straightforward response to someone with a Master in Computer Science from India regarding his query about career prospects in Ruby on Rails and how to start as a freelancer.
In the past, I've seen good opportunities and let those slip away because of several reasons. I did nothing about them.
It's a work-in-progress and I have yet to continue working on it this weekend. You can join.
Before you actually go out seeking freelance work, ask yourself first if you are fit to be a freelancer.
I know some people who are actually seeking Ruby on Rails contractors but both of them no longer seek contractors from India for some reason. I think it's unnecessary discrimination. Whatever traumatic experience they have gone through, I do not think that the contractors are the sole reason for failure.
I have some few practical notes to share. Most of them are simple and obvious but repetition helps us remember:
Don't be confined to using Ruby on Rails
I use the framework only because it is most sensible to me but I am also learning other frameworks and other languages. At the moment, it is very stable and you can use it for your projects. Many companies everywhere are hiring Ruby on Rails developers and finding work isn't a problem as long as you're not too picky. Developing your skills and being devoted to self-improvement is key.
This is important: don't use Ruby on Rails if you can't do optimization work and can't afford a good web host
Whatever you do affects your country
No matter what you do or what they say, be fair to yourself and to your client. Get things done but set limitations.
Know the scope of work and make sure you don't work for clueless clients who are still figuring out what they want to do and how they will monetize. I can work with these kind of people but as a freelance developer without equity in the company, I am only limited to the "getting things done well" part. You have to know those "things" first beforehand.
Someone made a comment on this and I agree you have to help your clients figure out some features sometimes but I disagree with the idea that as a consultant who's focused on development work you have to figure out how a client will monetize and grow their business especially if they can't meet your expectations.
Admit and fix your mistakes. Don't run away like a fool. That way you won't bring your country down. You can run away if they are not paying you right however. And this might be funny but just be aware that there are a lot of people with personality disorders and psychological problems. If you don't like dealing with those, leave.
Don't work fixed price if the client doesn't say everything you should know and it's quite rare that they do
An estimate is based on fixed set of features that are well-defined. If a client hasn't given any well-defined set of tasks then there is no way you could have made an estimate or agreed to an estimate. Have a contract. Set expectations.
Here's an example of a bad client: "Can you clone stamped? We need it done in 3 months."
Ripping off is bad. Read between the lines. Three months for an existing project which was probably done for years by a team of people.
Work with a team
Don't work alone. If possible, choose to work with the best. Code review and pair programming is good and helps you improve.
But if you should and you can work alone, increase your hourly rate.
This website might be interesting to you:
Multitasking is a sin in the long run. Claiming to be all things is a big lie. Even if you have done it before and your confidence level is very high, your mind is only truly limited to doing one thing well at a time.
Have a break
People could misconstrue this and dismiss this is an advice of a lazy person. But by having a break, I mean taking time to consider "programming for fun, charity and profit." Working for people often suck the life out of you no matter how small or large the company is. No drama. Just do what you should then do what you want.