What to know as a first time contract programmer?

Question

I'm a college student who's had several internships and consider myself a decent programmer. I have a friend who does consulting work and who wants me to help him with one of his projects. Since I've never done any contract work before, what are things I should be aware of and watch out for?

Answer 1

Whoo boy. Down this road lurks madness.

The most important piece of advice given your situation: define everything in writing. The most important information you need is as follows:

• How much are you being paid and by what metric? If it's hourly you still need to know when you get your actual check. Is it after the project launches? What happens if the project fails? Do you still get paid?

• Are they handling the payment of your taxes or are you? (The answer is almost always that you are.)

• Is there a maximum amount of billable hours you can rack up? What happens if you reach it and aren't done?

• What equipment will you be coding with? If they aren't providing computers then run. You should not be using a personal computer for professional development; it creates all kinds of ownership muddiness for the other code you write on your own time.

• What software will you need? Don't use personal copies of software to do professional work. Especially not if it's your cracked version of visual studio or whatever.

• Who will provide graphics, layouts, etc? Are you expected to create graphics and layouts? If so, with which software? Be careful of systems that include google-image-searched widgets, etc. You could end up co-liable for infringing software.

• How will support for the product be handled? Are you required to provide knowledge and training? How will you be paid for said knowledge and training?

• What are your liabilities? If something goes wrong with the code or it turns out to have a bug 3 months down the road, are you required to fix it? What are the support parameters? You don't want to end up getting sued by a company in 6 months. Make sure your friend is liable.

• You need a clean design spec for the code you're writing. It's not enough to know what it's supposed to do. I repeat, "I want a shopping cart to sell my shoes online" is not a design specification. You need a solid feature set explained in detail. You need your part of the work clearly delineated, and you need solid documentation of any greater frameworks, etc. that your code has to work with.

And this is just a start. Welcome to the world of contracting! This is what it's like when you aren't work-for-hire under a corporation's legal umbrella! :-D

Answer 2

Invaluable advice: learn to say NO.

Many times you'll find yourself in a position in which a customer asks for some extra features or many projects to quote at once. A good book I'd recommend is The power of a positive No.

You must learn to say NO when appropriate: if you can't take more jobs because the day's just 24 hrs long, then decline them or clearly specify you could do them starting in, say, 1-2 months time; if some client insists in you doing something out of scope, say NO (unless it's a very important client and you see further opportunities through him, of course).

Consider what you'd gain and what you'd lose by accepting and rejecting jobs, clients, etc. That way you'll see clearly what to do each time.

Finally, charge what you should, no more no less, and for every single piece of work. If you're a good programmer and are good at understanding clients' needs, they will value that more than the money they pay.