"Freelance" summary (long)
Patrick M. Ryan
ryan at sjuphil.uucp
Tue Oct 17 09:00:12 AEST 1989
Many thanks to all who responded to my query about freelance programming.
I received many lenghty messages containing some very good advice. To the
best of my ability, I have summarized below the responses I received.
pat ryan%sjuphil.sju.edu at bpa.bell-atl.com
------------------------- cut & paste ---------------------------
>From milliken at sjuphil Fri Sep 29 08:07:53 1989
Depending on the size (finances) of your employer, the difficulty of the
program, and your estimated time of involvement, you determine an hourly
rate with a "time and best effort" sale. In other words, do not put a price
on the program, only on your time and best effort (law calls it "good
faith"). Four years ago, the company I worked for was paying $50.00 per
hour to each of two Ph.D. candidates from Drexel for designing databases in
Unify with some shell scripts for user friendliness. Average project was
about 15 hours.
Advice, make no promises or guarantees, only your best effort. Get
everything they expect in writing, even details. Take notes at all
meetings. Give signed and dated copy of each set of notes (whether from
meetings or phone conversations) to employer. For example, if you are in a
design meeting and say a certain script can be written to accomplish a
purpose, make sure you send a copy of your analysis notes to the person in
charge of the meeting to ensure that you understand what he wants and he
understands what you are committing to.
NEVER guarantee a result such as how easy the application will be for the
users, or that the program will definitely meet their needs, or that you will
provide indefinite telephone support, or that you will continue to modify
what you have written until they are happy. ALL agreements should be
definite and close ended with the option of an extension based on successive
negotiations. In other words, get or create a written description of the
job and contract for a set number of hours toward that job leaving a clause
for renewal of the contract if necessary.
>From bpa!dsinc!lll-winken!riacs!rutgers!cis.ohio-state.edu!lwh Tue Oct 3 17:42:44 1989
>
> 2) What kind of things should I be sure to have in a contract?
Get a WRITTEN contract!!!!!!!!! (Sorry, I'm in a legal fight right now.)
Be certain you have the stupid stuff:
1. Agreed wage
2. Method of accounting (how do you prove you worked 48 hrs/wk.?)
3. Cover of consumables (who pays for disks and paper?)
4. Due date (when do you deliver?)
5. Late penalties (...and if you're late?)
6. Specifications (what EXACTLY is the program to do!!!!!)
7. Minimizations Policy (...what if it isn't feasible?)
8. Alteration Policy (...what if they change specs?)
9. Maintenance Policy (...what about bugs and misunderstandings?)
10. Payment date (When are you payed? Weekly is appropriate.)
11. Equipment available (What do they have? What do you use?)
>From bpa!cdin-1!uunet!bungia!sialis!quad!dts Wed Oct 4 01:39:57 1989
In article <1989Oct2.211050.1865 at sjuphil.uucp> you write:
> 1) What kind of salary should I expect?
Consulting is generally hourly. However, a "freelance" programming
job isn't necessarily the same thing as consulting, so they may have
a weekly salary in mind, or even a lump sum (given the limited time of
the job).
As far as pay scale, if you'll be paid hourly you'll commonly get a
bit more than if you're paid over a longer term period. $50 is a
little high for someone without five or more years of work experience,
at least in this burg. Maybe it's different in other parts of the
country. I'd guess at your getting $20 or a bit more hourly, based
on your education and work experience. (I don't have a degree, but
have about 3 1/2 years of fulltime experience, and I've been pulling
$25 for the past year working from my home exclusively, so maybe you
can extrapolate something useful from that.)
> 2) What kind of things should I be sure to have in a contract?
Reading any license on commercial software should tell you a lot about
that principle. The point is to make your legal position clear; you
will make all reasonable efforts to have the program work as expected,
but that you will not be held financially liable for problems arising
out of bugs or deficiencies in the program, regardless of the source
of those problems.
As far as things to have in your contract, they vary widely. It also
depends greatly on the employers with whom you are negotiating. My
own contracts are very informal, as the employers and I have trusted
each other not to take advantage... and it's worked better than any
tightly binding contract could have. Also, whether you are an hourly
consultant or on a temporary salary will influence greatly the form a
contract will take.
If we assume that this is to be an hourly position, and you will be
responsible for your own taxes, then you'll want to have clauses
which specify the amount of renumeration you are to receive, how
you will bill for your time, and at which time/how soon payment
will be expected. You may also want to have someone in the
contract about where and at what times your work will be performed
(particularly if you won't be 9-to-5-ing it at the employer's place
of business).
>From bpa!dsinc!lll-winken!riacs!rutgers!gatech.gatech.edu!stiatl!rsiatl!jgd Wed Oct 4 23:41:10 1989
In article <1989Oct2.211050.1865 at sjuphil.uucp> you write:
>
> 1) What kind of salary should I expect?
With a few exceptions, your degrees are not worth diddly in the contract
world. A track record is what counts. Unlike direct employment, most
clients expect you to produce product the first week in. IN fact, I
structure my projects so I DO have some kind of deliverable at the end
of the first week. It may only be a specification outline but it is
something tangable in return for the big bucks.
A good rule of thumb (after you gain a few years experience) is that
you must roughly double your direct employment hourly rate to break
even. You have to pay your insurance and retirement and disability
expenses plus a self-employed individual is taxed at a higher rate -
especially for social security - than a regular employee. If you
are salaried, then divide your salary by 2080 (the number of hours in
a standard work year) to get your rate.
> 2) What kind of things should I be sure to have in a contract?
First and foremost, a contract must have your pay rate, minimum duration
of employment and payment terms. My payment terms are simple. A check
every friday by noon. I've come to that policy at great expense and
hassle after being beaten out of fees by a few clients. Clients
tend to view contract programmer as disposable resources and treat
you as such. Some clients complain about this payment schedule but most
conform. And I won't work for those that refuse.
It is mandatory that you have a "liquided damages" clause in your
contract. This means that if the client (or you, looking from the
other direction) violates any of several enumerated terms, they
must pay a defined penalty as the total liability. Liquided damages
protect both parties. You do NOT want to possibly be at the vagrances
of a judge to compensate you for a crooked client. I once sued a
client for about 20,000 in overdue recievables. I "won" the case
but because I had not specified liquided damages, the judge was
free to give me what he wanted to - in this case, $5000 dollars and
no legal fees (which were > 15,000 bux).
If the client will allow it, you need language in your contract that
states that the contract will be interpreted under the laws of your state
and will fall under the juristdiction of your local court system. Other
wise, you might have to travel to BumFuck Egypt to defend yourself or
prosecute a collection action.
For short term work, I usually opt for a fixed rate per diem to cover
expenses as opposed to billing for actual expenses. What is typical
is a per diem that allows the IRS limit for meals plus a lodging
rate for an average motel in the area. You will be living out of
a motel most likely. Per diem does 2 things. First, you are less
likely to scrimp on your food or lodging since you have ample
money. Second, you don't have to hassle with receipts. Since
contract work typically involves long hours, bookkeeping is the
last thing you want to hassle with. Insist on per diem in advance.
Don't let the client float a short term loan on you by holding off
on per diem payments.
My last advice is "cover your ass". Contracting is a cutthroat business.
Lying to consultants (and vice versa) is almost a tool of the trade.
Don't trust even large corporations regarding credit. I've discovered
that may money managers in large companies string out receivables
to small companies in order to make quarterly results look better.
Remember "a check a week keeps the repo man away".
>From bpa!cdin-1!uunet!ssbell!grego Thu Oct 5 00:32:13 1989
In article <1989Oct2.211050.1865 at sjuphil.uucp> you write:
>
> 2) What kind of things should I be sure to have in a contract?
Are you an employee or a sub-contractor? If you're an employee
your employer has to pay taxes on your income. If not, you need
to worry about it. Since you are a full-time student, that income
may be negligible, but I'd still consider this. Also, DON'T, WHATEVER
YOU DO, DON'T RELY ON VERBAL AGREEMENTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
GET EVERYTHING IN WRITING!!!!!!!!!!!!!!!
I realize you talked about getting a contract above, but I can't
stress enough how important this is.
OK, so I'm a little over-enthusiastic about this, but I've got a
friend who got burned by this twice. The latest time he got burned
he took a project where his boss said he would be paid a certain rate,
then if the project was completed he would be re-imbursed for the
difference as if he had actually got paid a higher rate. e.g.
$8.00/hour, if the project gets done we'll give you $12.00/hour
(re-imburse the $4.00/hour difference over the hours you worked)...
Well...his boss lied, he didn't have it approved. When he asked
management they just said tough....he quit at that point in the project
to cut his losses.
THINGS TO GET IN WRITING:
Salary / Pay rate
If the Pay rate is hourly, how do you 'clock' in?
Pay Schedule(Every two weeks? When project's done? When they feel like it?)
Does he provide the equipment (software and hardware) to use?
If his machine is down, or there is a problem while working in his
office that delays you, do you have to eat the costs?
(On a contract I worked on I had to sometimes wait for the guy
to get off the stinkin' phone so I could ask a question, and he
would sometimes sit and bull-shit with me (when I wanted to work),
and after this wasted time, he would say "how many hours did you
work tonight? excluding our little 'chat time'?"
Bonuses or overtime-rate for more than 40 hours per week?
Finally, if you do get a contract, see if you can get a lawyer to
look at it. I think there is some free legal help available, and it would
be a good idea. If there is anything in the contract that you do
not approve of, ask if you can cross it out. Explain that you do not
agree with it, and do not want to sign the contract if that clause is in
there. This happened one of my projects; the had a really strange
clause that said something like anything I thought of while I worked
for him was his intellectual property. Even if I developed it on my
own time. Now for the company I work for now I would ask them first,
but if I was on a contract, I don't think so....
>From bpa!rutgers!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!mcsun!hp4nl!star.cs.vu.nl!condict Thu Oct 5 17:47:59 EDT 1989
In article <207600048 at s.cs.uiuc.edu> mccaugh at s.cs.uiuc.edu writes:
>
> First - as to salary - for a BS in CS, the lower range you mentioned ($15 to
> $20 per hr, if that) seems more realistic.
> Secondly - and more important for your own protection - is to ensure that
> you get ACCURATE specifications for a job PRIOR to programming, and I mean:
> IN WRITING. In my own experience and most of my colleagues, that has proved
> to be the main problem in getting tasks done to everyone's satisfaction.
I don't know where you've worked as an independent, but in the metropolitan
New York City area, someone with a B.S. in C.S. would get between $30 and $35
dollars/hour under the typical assumptions that:
(1) No consulting company is in the middle between programmer and
client, nor is the programmer an employee of the client
("freelance" implies this, of course).
(2) The client provides office and computer facilities to the
programmer.
(3) The programmer has at least a couple years experience.
(4) The work is full time for at least 6 months (smaller contracts
tend to be for higher hourly rates).
(5) The client is not a University, which pay notoriously low
wages.
>From bpa!dsinc!lll-winken!riacs!rutgers!chem.ucsd.edu!bang!friedl Sun Oct 8 10:24:59 1989
First, it is helpful to know what the customer is buying.
If it is a programming shop looking to farm out some work, then
you can be "just a programmer" but if it's some kind of local
business needing application programming written it is a
different story. In the former case they are just buying
technical talent, but in the latter they are buying a warm fuzzy
feeling. This means that you need to consider some kind of
professional air about you so that they don't think you're some
crazy hacker student. I was this kind of person for a long time
and it really limited what I could do. If you present yourself
professionally you will find that you will get many referrals.
Second, if you are freelance you will be paid gross pay
(i.e., N hours * X per hour = $N*X). This give you a wonderful
paycheck but you mustmustmust tell yourself that *it's not your
money*. If you plan on doing any amount of this kind of work,
open a second bank account and set aside a minimum of 33% of your
income for taxes. You are required to file quarterly estimates
of your income along with a check for that amount, and if you
don't plan on this you will be in very deep bandini. Be assured
I speak from experience on this one :-(.
Third, you have to be careful how you are classified by them.
They probably want you to be an independent contractor, which
means they can just give you gross pay and not deal with benefits
or withholding or umemployment insurance and all that. This is
clearly in their benefit, but in many cases it is wrong.
Congress made this kind of work very difficult recently with [I
think] section 1706 of the tax code where "technical
professionals" are almost always considered employees even though
the arrangement defines you as a contractor. "Technical
professional" is virtually defined to be exactly what you want to
be doing, and the IRS can come in later and deem you to be an
employee, rendering the "employer" liable for back taxes and all
that. It turns out that your customer has more to fear from this
than you do, but you should know about it in case things get
ugly.
With respect to a contract, this depends on the kind of work
to be done. If you ever do a fixed-bid (say, "$5000 for the
entire project") you really have to have it extremely well
specified up front or have incredibly easy-to-deal-with
customers. In this kind of arrangement, you will have a natural
tendency to say "That change is out of the specification so there
is an extra charge", and this kind of thing can get ugly very
quickly. If you are working on an hourly basis then this kind of
thing does not present itself much.
If you do sign a contract, it is really a good idea to have
an attorney look at it first. Standard contracts will usually
give the buyer full rights and ownership to the code and forbid
you from using it on your own. This is usually reasonable, and
it does not really prevent you from using (say) some clever
internal routine that you want to stick in your library.
Watch out for non-competition clauses, where you are barred
from working for a competitor for some time period. One year is
usually fair, but sometimes people get really aggressive on this.
If you want this to be a short-term project, make sure your
customer knows that at the end of the term you are *done*. If
they want support -- even for bugs -- after some defined date,
they have to pay for it. If this is not defined up front then
you might end up being stuck with this project for the rest of
your life.
Freelancing can be really fun if you can deal with the lack
of job security (I heard "We just lost our biggest customer, so
we are stopping all development as of today" from *my* biggest
customer three months ago). I wish you the best of luck with
this, and you're welcome to write if you have any more questions.
>From bpa!dsinc!lll-winken!riacs!rutgers!jade.jpl.nasa.gov!morris Tue Oct 10 13:43:06 1989
Suggest that you contact the:
Independent Computer Consultants Association
PO Box 27412
St. Louis, MO. 63141
314-997-4633
Personal recommendations:
1. Define a set of items to be completed. Get a written agreement that
each is completed _to their satisfaction_ as they are done. If there
is an argument later about unfinished work, or inadequate <whatever>,
at least some of your ass is covered.
2. Get them to cast the wish list in concrete, and agree that any changes
release you from the timetable. You cant hit a moving target with code.
3. If you are being paid by the hour, prove your hours somehow - with a
timecard, send e-mail to your supervisor (timestamped, of course),
if you are working on site, or something. If you are working at home,
_don't_ have a by-the-hour contract - there is no need to ask for
a dispute. On a home contract use the "completed item" form.
4. Get it in writing who has rights to your code. If you have to deliver
source, are you permitted to keep a copy? My contract is written
(at least for unclassified projects) that I may keep a
"reference" copy "to assist the provider in supporting the customer
at a future date". I explain that I can frequently
solve problems over the phone, if I can pull a printout from my file
cabinet. Naturally, I take home a printout, _and a floppy_. Especially
if I come up with a handy function/subroutine/etc. that I might have
to reinvent at some future date.
5. Have in writing what your hours will be. If you have better
equipment at home (specifically thinking about a friend that has a
30mhz 386, with a 100+mb drive, VGA, HP Scanner, "D" size
plotter, Telebit modem, etc. And a Sun workstation.), can you
work at home?
6. You say that this is your first job: If the contract says that you
must deliver a given item on a given date, bust your butt and get the
first couple done _and signed off_ early (not too early, or they'll
try and revise the schedule). Remember: The first 90% of the job
takes 10% of the schedule, and the last 10% takes 90% of the schedule.
ALWAYS PAD THE SCHEDULE. I "guesstimate" a schedule, and then double
it, if not triple. If I come in early, I'm a damn genius, if something
goes sour, I've got padding in the schedule to fix it. I've also
got time to take the completed project and QC the entire system as
a whole. And do the documentation a little better.
Reputation is everything in this racket. Nobody ever remembers the
good jobs, just the exceptionally good or the major fuckups.
Unfortunately, the good jobs are never talked about, but make up 99% of
them. So you've got to plan ahead to look super good on every job.
7. Bosses come and bosses go. The one you worked for may not be there
when you need a reference 2 years later. If you're trying to get
a job with an aerospace company 5 years later (or a civil service
job, or anywhere that they are liable to try and verify any claim
you make on your resume), and that can't verify your claim that you
worked for XYZ co on the fargle project, your resume may be round-filed.
If the fargle project got eliminated in a budget cut, and the records
warehoused, and the personnel person retired, there may be no record
of your employment 5 years later. SO.... Cover your ass:
When the job is done, if the boss thinks that you are the best
programmer since Babbage get a letter of recommendation - while the
glow is still there. If you play your cards right, he;ll have you
write it, or at least rough-draft it. Mention in passing a start date:
"Terry Cleancode has worked for me since January of this year and has
written all the code in our fargle product - and not one bug has been
reported from the field - in fact 2 years later we are still shipping
Version 1.0". Or something to that effect - but don't have every
letter in your portfolio look the same! Grab any printed stuff
on your project: A friend of mine that wrote a major part of the code
that runs a Lockheed C5-A trainer has some 4-color glossy sales
brochures for it that shows some of his screens. It's a real
impressive addon to his portfolio. If it's a sexy product, bring
in a camera and shoot pictures of your screens - even if you have
to do it at 3am. If you are working at home, it's even easier.
If a user guide or a manual is part of the contract, write into
it that you get no-charge copies of the final version - have one
in your carry-around portfolio for interviews, and a few more in
your file cabinet in case some dumbshit interviewer spills coffee
on it.
--
patrick ryan "geez. i guess
ryan at sjuphil.sju.edu we'll need
ryan%sjuphil.sju.edu at bpa.bell-atl.com more fbi guys."
[princeton|burdvax|bpa!drexel]!sjuphil!ryan
More information about the Comp.lang.c
mailing list