Attackmonkey Blog

I've been thinking about this some more since I wrote the last lot, so I've decided to add some more!

16. Be flexible

As a freelancer, hopefully you'll get to work with a lot of different companies. Each of those companies will have different work processes. Some might use Git, some SVN and some TFS *shudder*. Some may not use any source control at all. Some clients have a very rigorous set of procedures that must be followed to the letter, others are more freeform. You need to be able to slot in to a new client's team without too much fuss and hassle, so you have to learn to be flexible. It can be hard to learn, especially if you're used to doing things a certain way, but its a very important mindset to master.

17. Be upfront about costs

Unless you're one of those offshore outsourcing shops, the chances are you're an expensive resource. Make sure you're totally upfront about your costs. What's your hourly rate? Do you charge expenses for on-site/travel? If so, how much? Do you charge for late payment, if so how much and at what point? Do you do project rates? Will the client need to fork out for licenses for anything that you're building? No-one likes hidden surprises, so make sure you're client knows exactly how much they're paying, and what for.

18. Be Transparent

Keep your clients updated. Let them know how their project is going (if you're not in-house). If you're going to miss a deadline, let them know, as far in advance as possible, and tell them why. If you use third party frameworks for their site, let them know what you're going to use.

19. Hourly vs Project rates

There are two main ways you're likely to get paid as a freelancer. By the hour (the easiest one to manage) and by project. Hourly is less hassle, and you get paid for all of the hours that you work. Yay! Sometimes though, people will want you to cost a project and charge a project rate. This is harder and takes a lot of practice to get the balance right. To start with, make sure you have a decent spec to work from, that details ALL of the functionality of the site, IN WRITING. Draft up a functional spec of exactly what you are going to build, and you'll be able to use that as a basis for your pricing, and as a deliverables list for the client. Don't forget to include leeway for testing, bug fixing, and the inevitable project creep. Also watch out for clients trying to sneak extra stuff in without paying. If it's not in the spec, it's extra (unless you're feeling generous).

20. Get to know your clients business

If you're going to help a client with their website or we based systems, you need to take the time to find out about what it is they do. What are their current systems? What are their frustrations with the current website, what do they want the website to DO for them? Taking a bit of time to really get to know a client can be invaluable, and provide you with additional ideas and suggestions to help them get the most out of their sites.

21. Get it in writing

ALWAYS get it in writing. Agreeing something important over the phone or face to face is great, but make doubly sure you get them to email it to you as well so you have it in writing. If you don't, I can GUARANTEE that at some point it'll come back and bite you in the arse. The same goes for you too, make sure that everything important is communicated in a way that can be referred back to later. That way, you can minimise problems later on when the client is adamant that you said something that you didn't.

22. Learn to communicate to with non-techy folk

Some of the most successful freelancers I know are the ones who can communicate complex technical issues in a way that will make sense to your average client or account manager. If you go in blazing with your hardcore technical explanation, your average person is just going to glaze over and stop paying attention. They'll just start to hear WONK WONK WONK like the kids in Peanuts. It can be a hard skill to master, especially if you're not used to client facing, but it's VERY important.

23. Testing is not optional

If you've come from a large company with it's own dedicated testing teams, you might feel like testing is beneath you. As a freelancer, it ISN'T. You need to master the art of breaking stuff, and master it well. If you're lucky, your client might have a testing team, but in most cases they won't. Try and think like a normal user of the site, rather than the guy who wrote it and knows what the user is SUPPOSED to do. You can always get your boyfriend/girlfriend/husband/wife/gran to have a bash at your sites if you're feeling brave.

24. Resist the urge to use cool stuff just because you can

When you find cool new technologies, there's always the temptation to shoehorn it into your projects so that you get a chance to play with it. Unless there's a legitimate business reason why the site you are working on needs to use the technology, resist the urge. Your client isn't paying you to use their site as a cool experiment with the latest hot Node.js based gizmo, they're paying you to build a solid site that does exactly what they want. I've seen projects get badly derailed because someone thought it would be fun to use some new technology because it seemed fun, only to find out it wasn't as suitable as they thought halfway through development....... That isn't to say you should NEVER use new stuff, you should just be careful to use it when there's actually a need to do so.

25. You won't always get to do the fun stuff

You're at the end of the big project, the management organise a huge all expenses paid piss up, and you're not invited. You shake hands with the team, and you're on your merry way. Cue the Incredible Hulk music as you stride wistfully off into the sunset. There are some clients who go out of their way to make you feel like part of the company, even when you're not, and they should be cherished. But equally, there are a lot that just see you as a resource, you come in, do the thing they needed doing, then they send you on your way (albeit with a bunch of money, yay). The fact is, you're probably getting paid considerably more than the in-house team, so don't feel too bad if they don't take you on the company retreat to Aruba :P

26. Find your balance

This is another one I learnt the hard way. As a freelancer, especially early on, you're terrified that the work will dry up, or you REALLY want to make a name for yourself, so you work yourself HARD. 18+ hour days become the norm, your skin takes on the pallor of marble, and your friends and family start to wonder if you're still alive. I cannot stress enough how important it is to get a good work/life balance. Spend some time doing cool stuff with your family, go snowboarding for a couple of weeks, hell, go climb Mount Fuji, I did. If you can get the balance right, you can enjoy being a freelancer, and still get to do fun rewarding stuff. You'll be less stressed, you won't nuke your relationships with your friends and the world will seem like a happier, brighter place. It took me getting SERIOUSLY ill to get this one right, now I think I have a pretty good balance.

27. Write Good Specs

If you're working directly for a client, be sure to write a proper spec for the project. It gives you something to work from, it lets the client know exactly what they're getting and if you're working with a designer, it helps them to design the site properly. I can guarantee that AT LEAST 50% of your clients won't read the spec, but as long as they sign it off, you have more bargaining power when they come back asking for extra features for free. A good spec should contain a sitemap, detail things like target browsers, mobile strategy and any frameworks that will be used. It should also explain all of the different page types and how they will work, along with any additional behind the scenes integration work, for example forms being sent to a CRM.

This year I'll have been freelancing for 7 years. Prior to that I worked at agencies for 8 years. I get to work with all sorts of people, and something I often get asked is "what's the secret to being a freelancer?". Honestly, it's just hard work. Being a freelancer can be harder work than some peple think, but if you're prepared to put in the hours, it can be hugely rewarding. I haven't looked back since I quit my last full time job.

Here are some useful bits of info that I've picked up over the years that have helped me (not all of them are things I've done, some are things I've come across in my travels).

1. Love what you do

Sounds obvious, but if you don't have a passion for web dev, you'll never progress very far. This industry is VERY fast paced compared to others, you need to keep on top of current trends and technologies. Doing that is much easier if you actually enjoy reading up on cool new CSS tricks and server side technologies. It'll also come across when you're talking to clients, enthusiuasm is infectious!

2. Open source tools are your friend

Regardless of whether you're a PHP, ASP.NET, Rails or even Coldfusion kind of person, open source software and frameworks can be invaluable. I use a lot of open source tools for my work and they save me a lot of time during development. Make CMS websites? Find an open source solution that floats your boat, and use it. I switched from home brewed CMS systems to Umbraco (and occasionally a few other systems) a few years back, and I haven't looked back. You'll spend less time wrinting tedious CRUD code, and more time making the website work EXACTLY how the client wants. Tools like Grunt can be invaluable time savers during dev as well.

3. Focus Up

As a freelancer, you need to be able to focus on work, especially if you work from home. Make sure your work area is free from distractions. If you keep wondering off to play on the Xbox, or hopping on to Warcraft, you're not going to get much work done. I have a separate room at home for work, so I can concentrate without interruptions.

4. Learn to say no

Early in your career, you'll be tempted to say yes to everything that gets thrown your way. Unless the wolves are literally massing at your door, don't. Some jobs just aren't worth it. If a client/job looks like it's going to be a nightmare, consider saying no. Be polite and professional about it. Warning signs include things like clients changing their mind every 30 seconds, poorly defined specifications, clients constantly trying to get extra functionality for free, ANYONE who asks you to build Amazon in a few weeks and my own personal favourite "I can't afford to pay you, but you can have a share of the awesome profits".

5. Remember the rainy days

Unless you're lucky enough to have a long term regular contract, there will be periods where you aren't working. Don't forget to save for those occasions. Also, don't forget that you don't get sick pay, a lesson I learned the hard way when I was diagnosed with Cancer a few months after going freelance!

6. Get organised

If you've ever seen the first episode of Black Books where Bernard does his tax return, you'll know what I'm talking about here. Organise your freelance work properly and you'll make your life so much easier. Keep track of expenses and payments, otherwise, come tax return time, you'll be running round desperately trying to find receipts and you'll end up not claiming back expenses you should have. The same applies to your work load. Make sure your work schedule is well organised and you won't end up overbooking yourself and pulling 20 hour+ days to meet all of your commitments.

7. Code nicely

There's a saying that you should always write your code as if the next person who will work with it is a 7ft angry psychopath who knows where you live. It's true too. NO ONE likes having to work on crappy code, and it doesn't take much effort to format your code properly and comment it if needed. I've seen freelancers (and inhouse guys) who go out of their way to write overly complex code out of the mistaken belief it will make them somehow indespensible. It won't. Other freelancers and your client's inhouse guys will hate you forever, and that means you're less likely to get more work if word gets out you write awful code.

8. Give credit where it's due

As a freelancer, you are often treated better than inhouse guys when it comes to voicing ideas. You can say something that the inhouse team has been saying for years, and the higher ups will listen to you, because you're expensive (I've always found this stupid, but it's happened a few times in my career). If that happens, be sure to make sure the inhouse guys get all the credit. Otherwise you'll get a reputation for being a dick who steals credit/ideas.

9. Share your toys

Don't be precious about your code. If you write something cool, share it with the wider developer community. It's scary sharing your code for the first time, but it can be very rewarding. You'll make new friends and contacts, and in some cases you may even get work out of it. I participate in the awesome Umbraco community and find it very rewarding and dare I say, fun! If the inhouse guys at your clients want to know how stuff works, show them! I got started in the industry picking the brains of a ASP/VBScript freelancer back in the day. He helped me to get into server side programming and the rest is history! People will remember you if you're friendly and helpful and are more likely to recommend you to others. 

10. Approach agencies directly

It's OK to use recruitment agencies, but they charge 25%+ on top of your hourly rates to companies, which makes them expensive. If, like me, you work with design agencies, approach them directly about freelance work. You might not get anything out of it straight away, but by going to them directly, you can sell yourself better than a recruitment agency probably will, and if you get on, you may get work out of it. From a design agency point of view a freelancer they employ directly and have at least spoken to is probably cheaper/better than some random schmo that a recuiter sends over.

11. Don't be a dick

This was sort of covered in #8, but be nice. Sweeping in to a client's office, telling them that all their inhouse guys are idiots and that you are the only one that can sort out their problems makes you look like a total arsehat. People won't like you much, and when they leave, they won't be recommending you when their new boss asks if they know any good freelancers.

12. You WILL end up doing a lot of crappy jobs

Early in my career I got brought into agencies a lot to fix projects that other freelancers had messed up, bailed on, or otherwise not done properly. I won't lie, after the first couple, it gets pretty soul destroying. I had a period of about two years where about 60% of my time was spent sorting out problems caused by the same two or three guys. Get used to it, and use it as a learning tool. I learnt as much about how NOT to do things from those years as I did about coding. I also learnt a LOT about debugging and troubleshooting problematic code. Stick it out, and as clients come to know and trust you, you'll get better work!

13. Chasing payments

This is the really unglamorous part. When you work full time, money just appears in your bank account every month, yay! As a freelancer you have to deal with clients that are crappy payers. They pay late, sometimes by many months, or try to weasel out of paying for stuff. Dedicate at LEAST a day a month to chasing down payments that are overdue, and make sure you get paid. In the UK, you're entitled to charge interest on overdue invoices, so make sure you mention that on your invoices/contracts (also, be VERY clear about your terms of payment, e.g. 30 days). It's surprising how quickly people will pay up when you start issueing invoices with interest on. I also have a very small blacklist of places I won't work for any more, as they've been so bad with payments, I'd rather not waste my time with them again.

14. Learn new things

The industry changes very rapidly, as discussed in #1. As a freelancer, you aren't going to get sent on training courses to help develop your career. If you want to learn stuff, you have to do it yourself. Even if you aren't necessarily going to use new technologies, it's worth at least looking into them, so that you can consider them for your projects. Try and spend a few hours a week investigating what's hot in your field of expertise. Don't be one of those guys that still codes in ASP/VBScript because that's "what you know" and never move on. Otherwise you just may find yourself at the point where your skills are all totally useless (that said, I STILL occasionally get ASP/VBScript work, believe it or not).

15. Network!!!

As a freelancer, you're only going to get hired if people know who you are! Go to conferences, if there are local developer meetups try and go so you can meet new folks and network. If you're super ambitious, write a blog and promote the crap out of it, talk at conferences, hell, write a book. It all helps to get your name out there so that people will consider hiring you. I do occasionally go through recuitment agencies, but I prefer to work with clients directly, as you can build up a better relationship that way. Also, I cannot stress enough how important it is to network with account handlers and project managers. They move around a lot more than us techy types do, and if they've worked with you and they liked you, there's a chnace they'll recommend you at their next job!

That'll do for the moment! I hope this proves useful to someone :) I may end up expanding on this at some point in the future if there's any interest.

As a freelancer, I get to work for a lot of different companies and agencies. Which means I spend a lot of time looking at other people's code, whether they be inhouse teams, other freelancers, or folk who used to work there but have sinced moved on.

I find it quite interesting, and over the years I've seen code that's made me weep in awe, and code that's made me claw my eyes out in pure horror. But one of the things I really LOATHE is sites that are massively over-engineered for what they do.

I'll take a site I looked at recently. It's a small (sub 50 page) mobile site, which is almost all just plain text, written in MVC2. The solution for the site is split into 7 projects, uses nHibernate, has all the controllers and views split into separate projects (as well as the models, data access and a couple of generic function projects), and then the admin section of the site is a web forms project!

I'm all for separation of concerns and keeping code portable, but REALLY? 7 projects for a simple site? There's quite a bit of code in there as well, most of which is to do with the separation of the concerns and things like data access, mapping for nHibernate and the like. I'm sure it all made perfect sense to the original developer, but to someone going into it fresh, my initial reaction is one of "why the hell is this simple site done like this? Making changes are going to be pretty time consuming.".

I like to think I use the right tools for the job, and for something like this, I'd probably use either Umbraco, or Perch. I don't really see the point in putting in the amount of effort that must have been involved in setting this bad boy up and testing it, when something much simpler would be far better suited to the task.

It's like the developer wanted to make life difficult for themselves and those who came after.

While it might seem like a cool idea to go crazy with all the latest dev methodologies, and to separate everything out so that you can swap out almost any aspect of the site code, in actualy reality, for a project like this, you won't ever need to.

Another example is a site I worked on a couple of years ago, which was for a car sales company. The site had no transactional functionality, just a searchable list of used cars that you could email sales reps about, and a bunch of content managed pages. It was coded in the style of an ultra complex banking app. Trying to follow the code was a full time job, and what looked like simple function calls would turn out to be extraordinarily complex. I eventually figured out how all the important stuff worked, but noted that most of the people who had worked on the site since the original developer hadn't. In most cases, they'd just written their own code to do the same thing as the overly complex code, and used that instead. Which resulted in as many as 5 different ways of doing the same thing, all of which where used on the site in different places.

It made making changes an absolute nightmare. You'd think you'd changed something, only to discover that one page on the site called something completely different that did the same thing as the function you'd just changed. A list of changes that would have taken maybe two days on any sensible site ended up taking over a week on this system due to its crazy over-engineering!

Again, for this site, I'd have used a decent CMS system, and then written extensions to do the car search part. In fact that was something that WAS done to the site eventually (not by me, it was moved to Drupal/PHP) It's now remarkably trivial to make changes to the site, especially compared to the original monstrosity.......

The moral of the story? Use the right tools for the job, please! Remember that other people may have to work on the site, and that if you use methodolgoes and technologies that make it easy for them to do so, you'll be saving both time AND money in the long run. And please, pretty please, stop using enterpise level architecture for your small/medium sites.

:P