Lessons Learned in a Year of Freelancing
Lessons Learned in a Year of Freelancing
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
A year ago, doe-eyed and excited, I pranced into the business registration office in Ljubljana. It was time to stop messing about and become a proper freelancer.
Five minutes past 1 pm on a Thursday. Closed.
You can only open a business in person Mondays and Wednesdays before noon or after 1 pm but before 5 pm; on Tuesdays and Thursdays before 1 pm and on Fridays and days before a national holiday until 1 pm. I am not making this up.
Initial holy-fuck-this-is-the-real-world-now setbacks aside, on September 24th, 2012 my sole proprietorship was officially registered and I became a business. I had an accountant, a business address, and a business bank account. I even had my first client.
Since then my rate has grown by 100%, my availability has dropped to essentially zero, and last week I hired my first intern. Life is good.
Well, I say I already had my first client back then, but it took them another three weeks to sign the deal. Lesson 1.
A Week is Nothing
When you’re just starting out as a one-man business you’re a rocket. You’re essentially twiddling your thumbs so turnaround times are zero. Everything can be done immediately, you can start a new client yesterday, and you can get anything done in a week or two.
Of course you feel everyone who doesn’t work at the same pace is lazy. What do you mean it takes a week just to get back to me on the contract? What do you mean you need a few days to assemble the stuff I need to get work done?
After a few short months, you understand. You’re busy. You have plenty of work. Oh, a new client has a cool project? You might have time in a month or two.
If anything takes more than an hour, it will have to wait for tomorrow. Then you will need to think about it. Then you might have to check with somebody. Then a week has passed.
Congratulations, you’re just as slow as everyone who seemed super lazy two months ago.
Only Accept Exciting Projects
The more work you have, the easier it becomes to focus only on projects that pique your interests. Maybe it’s a product you want to use yourself, maybe the project opens interesting opportunities, maybe the tech side tickles your inner nerd.
Whatever the heuristic, it’s important to only work on projects that are fun.
Explaining this to your friends and family will make you look like a spoiled brat, but it is of vital importance for the health of your business. When work is fun, it doesn’t feel like work.
This will generally make you a happier person, which leads to better work. When work is a slog, quality suffers.
And remember, you’re building a brand now. What sort of projects do you want to be associated with?
My office... eventually
The More You Charge, the More You Work
Another side-effect of focusing on exciting projects is you can charge more with a clear conscience. You’re getting so much done and you’re so very productive, why not charge more?
Yes, I know. It doesn’t work like that. As long as your lines-of-code or features-implemented productivity isn’t horrifying, your clients don’t care. But it does help with that nagging engineer conscience that keeps whispering in your ear “Dude, you’re not really this productive. You can’t justify this price.”
But here’s the funny thing, the higher my rate has become, the more and the better work I get.
When I was starting out my rate was too low and clients treated me as an extension of themselves. They were making all the decisions, I was just the bloke that coded it up. Even though I did everything I’ll explain in the last section, they still treated me as one of those just-a-coders.
Essentially, they didn’t trust my judgment.
But the more I raised my rates, the more they did trust me. The more they leaned on me for advice, the more they talked to me as an expert rather than a goon.
I think early on I even lost potential clients because I wasn’t charging enough and failed to send a “I am an expert. Promise!” signal.
Part of becoming treated like an expert was moving away from an hourly rate.
The problem with hourly rates is it sets up the wrong incentives both for yourself and the client. It puts you in the territory of somebody who swoops in, pokes around for a bit, then goes back on the shelf until internal engineers need your help again.
On your end it sets the incentive for padding hours. That you should work unreasonable hours, that you should fit in just one more hour here or there. Just that one more hour before I go to bed, it’s like, worth a lot of money.
Then you have to charge two more hours the next day because you fucked up when you were half asleep.
Don’t be that guy.
When the smallest unit of time is a day, clients won’t call you up when there’s something small to do. You will get to implement whole features, work on real refactoring. You’ll be a valued member of the team. Internal engineers will know who you are.
Incentives are better aligned. A day is a day. You have a lot more room to do quality work and clients don’t feel paranoid you’ll be padding hours because you can’t just sneak a whole day in there without justification.
You can also go for coffee with a friend without worrying how much it affects your bottom line. Life is better.
Figuratively many clients
Only One Client at a Time
Part of the reason a daily rate works so well is that you can’t work on more than one client per day.
Context switching between projects is hard, especially when they use completely different technologies, have a whole different team attached, a different set of problems, a different market, different everything.
Imagine how stressful changing jobs is.
Now imagine doing that more than once a day. Work a few hours for client A, then a few hours for client B. A few hours for client C, God forbid.
If you want to pull it off with any semblance of quality work, you’re going to need at least an hour or two to switch your brain too. Time you could spend having fun.
Switching every few days is easier. I used to do two or three days for one client, then another two for another.
But even this got exhausting and I noticed the quality of my work deteriorating. Nowadays I try to block off at least one whole week for a client and I no longer try to have more than one client at a time.
There’s no need to hedge bets. If you do good work, your clients will treat you well and there will never be a problem.
With my next contract I am officially switching to a weekly rate.
Coding is the Least Important Part of the Job
The most surprising thing I’ve learned over the past year is that coding is the least important part of my job. Clients don’t really care about my code past any trouble I create for their internal engineering team.
They care much more for my experience in the web startup space, ability to help them specify what they want built and so on. I summarized it well in a HackerNews comment recently:
Usually clients have a hard time explaining exactly what they want and our visions might differ. When I turn in results, they are often different than what the client first imagined they’d be, but through iteration and conversation I can help the client clarify what they want or realise something else 90% of the time.
Time is another big problem. When you want something done in X time, I will do my best to catch that time. Sometimes this means discussing with the client until the feature list is cut down to a deliverable size. Other times it means sacrificing future flexibility of the code. I always try to get the best balance between “speed – quality – price” for what the client needs, but it’s easy to miss.
Almost always, clients have an unreasonable expectation of what is possible.
I’d say at least 70% of my job is helping the client decide what they even want me to build for them.
In fact, posting that comment created a solid lead. I had to pass the project on to a friend because of lack of time, but clients obviously care about things other than coding.
Published at DZone with permission of Swizec Teller , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.