ryan@sjuphil.uucp (Patrick M. Ryan) (10/17/89)
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@bpa.bell-atl.com ------------------------- cut & paste --------------------------- From milliken@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@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@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@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@s.cs.uiuc.edu> mccaugh@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@sjuphil.sju.edu we'll need ryan%sjuphil.sju.edu@bpa.bell-atl.com more fbi guys." [princeton|burdvax|bpa!drexel]!sjuphil!ryan