Contractors: Setting Up a Limited Company is not "Tax Efficient"

Over the last few months I've made the transition from full-time employment, to self-employment, and finally to working through my own limited company. If nothing else, this should make my next tax return particularly interesting.

Forming a limited company to invoice through is fairly common practice for contractors, not least because there is a perception that it's more tax efficient to do so. In fact it's more than a perception: it's a widely-held belief, which is repeated time and time again. It's also completely and utterly untrue.

Let's get this straight: for the average contractor there are absolutely no tax savings to be made by forming a limited company.

Bonus Schemes Should Be Handled with Care

I was recently chatting with a colleague about bonus schemes, and it occurred to me that every single company I've worked for (that's four, if we're counting) has implemented at least one such scheme, and the outcome is always the same: pissed-off employees.

There seems to be a kind of unquestioned assumption that employees want bonus schemes, and that employers are being good employers by introducing them. Such schemes are, without exception, described as being a "benefit". After all, who doesn't enjoy receiving a bonus with their pay cheque? What could possibly go wrong?

I'd like to argue that bonus schemes can go wrong. In fact, they are harmful more often than not, and should be handled with care.

Some Thoughts on Testing Developers

For reasons I can't quite fathom, I've been thinking a lot about testing developers recently. That's testing developers as part of the hiring process, as opposed to developer testing (which I do bang on about rather a lot, to be fair).

I say I can't fathom the reasons, because we're not actively recruiting right now, nor am I looking to be recruited (though if you have your air conditioning switched on you may be in luck).

So anyway, it's fair to say that before you hire a developer, you want to find out if they're any good at developing, right? And therein lies the problem: how on earth do you measure the candidate's skill level?

I've seen, and used, a few approaches myself, so I'll go over a few of them and see what drops out the other end.

Hint to Employers

Here's a handy hint to the employers and facilities managers out there, which shouldn't really need stating:

Do not expect your developers to be happy and productive in an office heated to 28° or 29°: they won't be.

A corollary to this rule is:

Don't rent offices from Regus.

Luckily, we're moving in a few weeks' time.

Herding Cats

For as long as anyone can remember, the term "herding cats" has been used as an analogy for the challenges involved in managing developers. The implication being, of course, that developers tend to be smart, wilful, single-minded folks. Personal experience suggests this is often the case.

The analogy was reflected in the title of a book named "Herding Cats: A Primer for Programmers who Lead Programmers", written by the impressively named J. Hank Rainwater. I mention it because this is a decent read for anyone who develops, or who works with developers - whether in a management capacity or not. It's not in the same league as "The Pragmatic Programmer", but I'm getting off the point now.

So anyway, I came across this video via Yahoo MySQL guru Jeremy Zawodny's blog. It's so slickly made that you're not surprised when it turns out to be an ad for a big expensive professional services company. But I liked it.

Can anyone lend me a beginner's C++ book and a house in California?

I'm mildly flattered to have been sort-of-headhunted by Google's US technical staffing team today. Apparently my...

experience at Pitch and strong educational background make [me] an excellent fit at Google.

Cool, thanks Google. But I'm not sure that you've researched me too well.

Never mind. Should I feel the urge to up sticks and become a C++ programmer in Mountain View, California (a mere 5,431.51 miles from home) I'll give you a ring :)

...and keeping them

I'm finding more and more excellent, and very pertinent, content on Rob's site. In Nine Things Developers Want More Than Money he raises a few issues that will make a huge difference to a company's rate of developer 'churn'. And once again he hits several nails square on the head.

He doesn't mention chairs, but I think Joel has that one covered.

Still, I wonder how Rob finds developers who have stable family lives and yet are willing to work until sunrise...without being asked and without extra pay!

Finding them...

I enjoyed Rob's definition of Web 2.0 companies as being the ones that show up in your browser every time you mistype a domain name. I don't know what you would have to type wrong to find either of our portals, so I guess we're not Web 2.0. But I can live with that.

Anyway, it's from a great article called Personality Traits of the Best Software Developers, which I found particularly interesting, since we're recruiting right now. I can see myself in at least a couple of those (I shan't elaborate!) so maybe I'm not doing too badly.

I am Not a Resource, I'm a Free...Oh Wait...

For a while now I've been taking exception to programmers being described (by management, by recruiters) as 'resources'. "We're hoping to take on a PHP resource", "I hear you're looking for a PHP resource?".

No, I'm really not looking for a resource, I'm looking for a programmer. Programmers have brains and ideas and solve problems and rarely stop thinking about creative ways to do complex things. They're not interchangeable programming units. At least, not here in Great Queen Street. To misappropriate something Martin Fowler said:

"that would be true if the hardest part of programming was typing".

Which, of course, isn't the case.