Contract Rollercoaster

Dude, for real, contract work is just crazy. I’m starting to feel business is only stable when your not in sales or strategy. I don’t know how my dad does his own thing. In my case, I spend about 95% of time perfecting my craft, and re-learning it based on new technologies and R&D. The rest is marketing and followup… which still accounts for a lot of time, but spread really thin.

Anyway, jacked. Will I ever learn it enough to know wtf I’m doing?

Now, BellSouth’s contract, but that’s friggin’ easy. I go through a recruiter, and I’m technically working there, so that doesn’t really count.

Company X who f-d me out of $4k out the blue calls me back, negotiates release of source code, and pays me, and the check clears. Rock!

I then get another check today (2 of 3) for another job I did months ago. Rock!!

Then, another job I started back in… I think December of last year, I just got a call from the client. He wants some additions to the prototypes to get it near a working version, which so far is miniscule work so the project is no longer on ice. Considering this weekend is no school, timing couldn’t be better. Schweet!

I dig freedom of chioce, but damn… this stuff is more volatile than mutagen.

13 Replies to “Contract Rollercoaster”

  1. My worst self-employed fault is multiplying. When a prospect talks about a job, I count it (as money in the bank). While I write down my hours, I count it. When I bill the client, I count it. Then, when I finally get the check, I count it. Obviously, I’m counting the same thing multiple times.

    Anyway, here are my unsolicited pieces of advice:
    –say yes to every potential job no matter how busy you are… you can always back out or delay or a client may delay later.
    –do more than one thing. For me that means writing, teaching, and programming.
    –don’t do too much research without charging for it. Okay, so I figure I spend at least 25% of my time just learning… but when a client wants me to do something I haven’t done before, I don’t go research it for free. I figure all my other experience helps that client… and if I have to learn a bit (and charge for that time) then no biggie.
    –take on work that’s just a little beyond your experience or comfort level. This is more of a beginner’s tip but it helps you grow.
    –be a jerk when a client doesn’t pay. Stop any existing work for that client; call them EVERY DAY; next time they want you to do work make sure to get them to pay in advance. I’ve only done this twice but just seeing the accounts payable person hand over an advanced payment check against their will was worth it.
    –if it sounds bad, don’t do it! This is the biggie… listen to your gut. Every time I’ve done a job that sounded fishy or funky I’ve regretted it.


  2. This may be off topic: what sort of contractual agreements do you usually work under to retain intellectual property of the code you write for “X” client?– or do you? For example if you write SomeClass while under-contract on a project what do you have contractually to retain rights to reuse that code on other projects. Typically I just have had it as a line item stipulation. However their have been times when this has caused problems.

  3. Well, typically I don’t retain contractual ownership of the code. I’ve actually only had one client who wanted to the source code; the rest are extatic with the results of just the SWF’s. The others were FLA’s, but they contained SWC’s. The rest are designed FLA’s, so code really doesn’t come into play on those.

    I’m not sure about the re-using classes. I’ve reused data and event classes all the time, but most components that I make that are distinct to the project aren’t really re-usable elsewhere. Their GUI is so distinct to the project, and most data is aimed at the project at hand. Things that are non-distinct, like the WebServiceConnector, aren’t mine anyway, nor the client’s, but rather come with Flash. Granted, I have to distribute the base classes, but I’ve never actually had to because I don’t modify the base framework, only use it.

    Most of the code changes anyway, so even if the client said they retain ownership of it, it’s fine, but what I’m re-using would never threaten any of my client’s in anyway. Most of it is so distinct to solving a problem on a per project basis, and the design is distinct as well; I’ve never ‘re-used’ a design, either, because those who’ve hired me always have a phat designer on hand to lay the funk that I code to work.

    Bottom line is, I’ve never had a contract that was that strict. The only client that ever wanted the source code didn’t define to the nth degree what classes I couldn’t use. If it did, I wouldn’t do that work, that’s ridicolous; you’d code yourself out of a job, hehe!

    Now, BellSouth on the other hand is different. I’m not on top of it all, but anything I create or develop here down to (up too?) an idea is owned by BellSouth. That’s fine with me as I’m working for them. It’s a waayyyyy larger scale, but by the time I finish a project, I usually code it differently so much so that if I did it again, you could definately tell them apart. Again, though, I really don’t think that’s down to the class level either.

    Sorry man, most of my clients have been cool about that kind of stuff, and contracts were NDA’s more often than not.

  4. “say yes to every potential job no matter how busy you are…”

    i don’t agree with that one, you might wind up with a reputation as somone who says yes to everything even if your over loaded and are not so fun to work with and a let down. While maybe taking 1 more then you can handle knowing the probability of ALL of them working out is not very high. THat might be a more modest way to go about it.

  5. I agree with Jesse. Unless you come up with the paperwork for them to sign that states that you own everything, it’s considered a work for hire. Of course, if you did come up with that sort of a document, you probably wouldn’t get much work. Oh, and if anyone out there thinks that their coding is so “special” you probably need to relax. Yee haw.


  6. Mine’s definately not special. It is for about the first day, and by the end of the project, I feel like it’s a failed prototype, and I’m already planning version 4. It was cool when I thought of it, and the client likes it, but at the end of every project, I know exactly how to make it better. By that point, it’s definately not special.

  7. I totally agree with you. Contract work is just crazy as it usually comes in all at once, and not only that, they all want it done ASAP.. I’ve got to say though that this is where I really value the project management training I’ve received. It’s absolutely invaluable.

    I definitely agree on the point of never saying no. There is always a way to do something. You never know when you can or can’t do something, whether you have done it or not. There are so many variables in life, you just have to do your best in planning and always have a backup plan.

    Just on an after-thought here, I always think of lulls in work an absolute blessing. It gives me a chance to sit back and do stuff that I want to do, pick up some books from Amazon or something and really sit down and learn something new, or just plain get better at something I do now. It’s almost guaranteed that just as you are getting into something really really cool, that another huge load of work comes piling in, which starts the unending revolution of contract work rolling again.

  8. Well, on occassion, I have been too busy to take on work–and I’ll be upfront when that happens. I just say no to enough of those projects that sound bad that I’ve never found it an issue (and I’ve been contracting almost ten years). Usually, it’s not the programmer who slows a project down anyway. Way more often it’s a client flaking on an entire project. If I had a penny for every project that fizzled out before it started I’d be rich.

    I always thought it only counts as “work-for-hire” if the contract says that explicitly. That is, by default it’s NOT work for hire. In any event, I agree with Jesse. While it would be nice to have all this code that easily recycles into the next project that’s largely a fantasy. I’m not an idiot–so some code is easy to recycle. But, really, the time consuming part of my projects is not hard-core programming… but planning and “design” (and I’m not just talking about the graphic design because I don’t do that part). If you do it right, I believe, programming per se is only 10% of the whole project. When I tell programmers this they freak out–but think about it. A well planned and executed project should not involve mainly programming.

    Oh, I always give my clients all the code unless I have a very good reason not to. I figure I charge enough for them to want this… plus, they won’t have to bug me later if I can’t maintain their project. And, it’s a good form of backup. Again, I know many disagree with this but I just don’t get all that attached to my old code. (I look at stuff only 6 months old and it’s embarrassing) Actually a good reason not to release code is that it can reflect on you poorly. I just remember a client dissing my work (to a friend they interviewed to rev it) because I didn’t comment it. That’s the last thing I need: someone who hires me for my expertise telling me I’m not an expert.

    Bottom line: good business is when two parties have a good understanding and respect/value each other.

  9. With everything I’ve read, and it’s been a while so I have no proof, if anything goes to court work-for-hire wins. For me this is the “good understanding” that Phillip refers to.

    Also, is it not true that the projects where you hear the client talking about ‘getting going’ and ‘knocking it out.’ Are the ones that stall about 1/3 of the way through? Aarrrgh!


Comments are closed.