Share on Facebook33Tweet about this on TwitterShare on Google+5Share on LinkedIn14Share on Reddit12Email this to someone

Ethics is a topic rarely, if ever talked about among freelance developers.

Some of the more successful developers I know definitely have a sense of what’s right and what’s wrong in our business. At the very least, they do the best job possible since their credibility is at stake. But more often our conversations revolve around code and clients, and rarely do we discuss our shared ideas of right vs wrong in business, unless it comes up situationally.

If you are a freelancer and haven’t yet put some thought into what your own personal “code of ethics” is, let me give you some food for thought.

Here are some things I think are good or bad to do as a freelancer. In the end I tend not to think of these as absolute right or wrong things to do; the “good” things are far less likely to have bad repercussions, and if they do, you can stay strong in them knowing that you’re not intending to do wrong to anyone. The “bad” things are risky, potentially selfish, and likely to leave you in the middle of a painful situation.

Bill carefully and accurately.

Clients pay us by the hour, and we tend to cost per hour more than permanent employees. So we owe it to the client to not burn their money unnecessarily. Time spent on anything directly related to the project is billable; time on the phone with your girlfriend is generally not.

Track what you work on.

Nobody likes to receive a big fat bill and not know where their money went. This leads to buyers remorse, or even worse – people not paying their bill.

An itemized invoice (combined with constant communication and expectation setting) makes it far less likely that there will ever be payment disputes. So as you work, take notes on what you’re doing (I use Evernote, but whatever works), and writing up the timesheet will be a piece of cake.

Do a good job (obviously…but there’s more to it).

Write good code, be responsible…obviously. But there’s more to doing a good job than those basics.

I define “a good job” as one which ends with both a happy customer and a happy developer. The client gets something that fills their needs, and you have your integrity and budget intact.

I do not define “a good job” as bending over backwards with no reward. I also don’t define it as building tons of stuff the client doesn’t realize they don’t need. (See the next 2 points below.)

Be honest about what you can and can’t do.

There’s no shame in saying “I’m not sure how to do that,” or “Let me research that a bit before I say yes.” Avoid the trap of saying “yes” to everything, and getting in over your head (related: The Importance of Saying NO).

Note: If you find yourself saying “no” to a lot of things, something is probably wrong. Most likely you either need to spend more time updating your skills, or you’re on a project that just isn’t right for you.

Question whether you’re building the right thing – within reason.

I pride myself on trying to stay in touch with the client’s needs. Sometimes their perceived needs aren’t what they really need (See Don’t Eat the Candy for one example).

If you can spot this, and help them focus your development work on something more valuable for their goals, you’ll score major points with them.

This isn’t always a possibility though, if you have an unreceptive client, or your role on the project is purely to get done technical tasks. Choose your battles carefully, which leads to my next point:

Don’t overstep your role.

On some projects you might be the lead, and directly in touch with the important shareholders (CEO, Product Manager, etc). In cases like this, you have the ear of people that make product decisions. If you feel you’re working on the wrong thing, they will probably be inclined to listen to you.

On the other hand, if you’ve been hired as “extra hands” on a project (for example, an existing team has a huge backlog of features to build, and a tight deadline), and you don’t have access to any of these people, the team might be less inclined to listen unless you can indicate a huge, very obvious time saver. Be very picky about making recommendations.

Don’t be quick to blame the client.

Try to take as much ownership of the situation as possible. True, we’ll inevitably end up in some bad projects with bad clients sometimes. It’s important that we be proactive when we end up in these situations. There’s no shame in saying “this project isn’t for me” and bowing out when you realize it.

In all other cases, try to take as much ownership as possible. Maybe the client picked an outdated technology to work with; if you’ve said your peace on that issue, and taken the project anyway, no more reusing that argument. If you didn’t speak up, maybe you should have. Better late than never.

Either way, the point is this: no matter the situation, there’s usually something you can do to help make things go well. Withhold blame until you’ve really done all you can.

Set expectations, as best as possible, at all times.

I can’t stress this enough: As a freelance developer your whole job isn’t simply churning out code all the time. THE most important part of any project is that you and the client are on the same page, and have a shared understanding at all times. Keep this in mind at the start, in the middle, and toward the end of any project.

Above all, be communicative, inquisitive and honest. In this game, reputation is everything.

What are your thoughts on this? Leave a reply.

Share on Facebook33Tweet about this on TwitterShare on Google+5Share on LinkedIn14Share on Reddit12Email this to someone