Freelancing
This is for those who have freelanced, or who are currently freelancing:
I'm thinking about freelancing, but I want some accounts first:
What website do/did you use?
Were there requirements other than knowing how to program?
What was it like? Was it easy, hard, and was the pay very good?
How often did you get a contract?
What were some mistakes you may have made?
What was the hardest thing you did?
what was the easiest thing you did?
This sounds like a lot, but I just want some primary accounts from people who have freelanced, because I don't want to be ignorant going into this. I just want an idea on what this kind of work is like in terms of workload, time, skills, etc...
I'm thinking about freelancing, but I want some accounts first:
What website do/did you use?
Were there requirements other than knowing how to program?
What was it like? Was it easy, hard, and was the pay very good?
How often did you get a contract?
What were some mistakes you may have made?
What was the hardest thing you did?
what was the easiest thing you did?
This sounds like a lot, but I just want some primary accounts from people who have freelanced, because I don't want to be ignorant going into this. I just want an idea on what this kind of work is like in terms of workload, time, skills, etc...
Last edited on
Well I don't program professionally but I do freelance contract work as a Sys-Admin from time to time and since your questions seem to pertain to the process more then the specific job so I'll give you my input.
- As for what websites to use, all of them. Seriously there are postings for this stuff everywhere and absolutely no reason or excuse to restrict yourself to just a handful resources. Remember that you are the one ultimately deciding what jobs to take so as long as you aren't a complete ding-dong then you won't have to worry about over scheduling yourself. You would think that a company looking for contract labor would look everywhere at once but they don't. The only times I've seen jobs posted to multiple sites are when a headhunter firm is the one doing it.
- The requirements for any job are going to be so widely different that this is impossible to answer. I always insist on having a walk through on-site before taking a contract, so maybe you can insist on seeing some of the code and the environment you are to be working on?
- For me it's usually easy, but then again I'm not doing dedicated programming and I've been doing this for years. The pay is absurdly high compared to a normal 9 - 5 on-call kind of job. But then again I wouldn't bother doing this (essentially working a second job) if it wasn't :p. ALWAYS REMEMBER: You'll be the one doing your taxes, so pay attention and don't get stupid and screw yourself over.
- I pick up short term contracts whenever I think I can fit it into my life. This won't apply to you but it is usually disaster recovery stuff, a company has an off-site location and they don't want to drive down from Toronto or someplace just to replace an HDD.
- As for mistakes I've made, I'm a professional. That means I've made far FAR too many mistakes in my career to list here. My biggest piece of advice here I would have to say is to "know your client". Something as simple as offering to pay for their coffee at the interview can blow your chances due to cultural differences.
The last two don't really apply but the hardest thing you'll ever have to do is clean up after the guy before you. Unfortunately it seems to be the one constant in this type of work as well.
- As for what websites to use, all of them. Seriously there are postings for this stuff everywhere and absolutely no reason or excuse to restrict yourself to just a handful resources. Remember that you are the one ultimately deciding what jobs to take so as long as you aren't a complete ding-dong then you won't have to worry about over scheduling yourself. You would think that a company looking for contract labor would look everywhere at once but they don't. The only times I've seen jobs posted to multiple sites are when a headhunter firm is the one doing it.
- The requirements for any job are going to be so widely different that this is impossible to answer. I always insist on having a walk through on-site before taking a contract, so maybe you can insist on seeing some of the code and the environment you are to be working on?
- For me it's usually easy, but then again I'm not doing dedicated programming and I've been doing this for years. The pay is absurdly high compared to a normal 9 - 5 on-call kind of job. But then again I wouldn't bother doing this (essentially working a second job) if it wasn't :p. ALWAYS REMEMBER: You'll be the one doing your taxes, so pay attention and don't get stupid and screw yourself over.
- I pick up short term contracts whenever I think I can fit it into my life. This won't apply to you but it is usually disaster recovery stuff, a company has an off-site location and they don't want to drive down from Toronto or someplace just to replace an HDD.
- As for mistakes I've made, I'm a professional. That means I've made far FAR too many mistakes in my career to list here. My biggest piece of advice here I would have to say is to "know your client". Something as simple as offering to pay for their coffee at the interview can blow your chances due to cultural differences.
The last two don't really apply but the hardest thing you'll ever have to do is clean up after the guy before you. Unfortunately it seems to be the one constant in this type of work as well.
| As for mistakes I've made, I'm a professional. That means I've made far FAR too many mistakes in my career |
This made me smile
Thanks for the reply, Computergeek01. I do have one question regarding thing:
Computergeek01 said:
I don't have much experience, but I imagine that if I were running the company, I wouldn't feel comfortable knowing the code from my IT department is being shown to prospective contracted programmers.... Can you elaborate on how this might be done?
Computergeek01 said:
| I always insist on having a walk through on-site before taking a contract, so maybe you can insist on seeing some of the code and the environment you are to be working on? |
I don't have much experience, but I imagine that if I were running the company, I wouldn't feel comfortable knowing the code from my IT department is being shown to prospective contracted programmers.... Can you elaborate on how this might be done?
| Can you elaborate on how this might be done? |
It's almost guaranteed that you'll sign some sort of NDA before they allow you to poke around their code. You'd be signing one anyways before you start any work.
The NDA is a good bet, even I have to sign them and I hardly ever even see anyone's DB data. But like I said, I don't code professionally so I can't say for sure. Maybe you could ask them for a model, or a flow chart of their ideal paradigm? That should be enough to tell you what kind of design pattern they are trying to use, and you could get an idea of the "trouble spots" based on the presenters reaction to going over them. For all I know though my suggestions in this particular post could be anywhere between anathema and objectively useless in the professional world. This is the bullet point where I feel that our professional settings diverge the most and I'm afraid that I can't be much help with it.
Thanks for the replies. I believe I have a good idea what freelancing entails now (in terms of seeking out job contracts). Thanks for the input.
Topic archived. No new replies allowed.