[LRUG] Perm vs contract

[Tor Erik Linnerud]

Paul, thanks for one of the most insightful posts I have ever seen on LRUG!

On 26 Jun 2014, at 11:49, Paul Robinson <paul at iconoplex.co.uk> wrote:

Context: I was perm for 6-8 years, self-employed for 4, been perm again for
4, 3 of those as a CTO in 2 different businesses.

On 26 June 2014 15:25, carlos <djmutiny at gmail.com> wrote:

- MEANING. The opportunity to work on products that feel like they're
> objectively worth building, as opposed to just being yet more busy-work.
> It's very nice to feel that you're making somebody's life better (even just
> *slightly* better) by doing what you're good at.
>


This is why I turned down interviews in the finance sector. Moving money
around to make more money didn't appeal.

I don't think there are many jobs anywhere left that are busy work though.
Certainly nothing advertised here in the last 6 months springs to mind.



> - LEARNING. A culture where the human instinct for learning and creativity
> is respected and embedded, and considered as a basic need for all
> employees.
>


It's development. All developers learn, every day. I don't think a business
exists where that isn't the case. The only difference is the model and
intensity of focus. Some will coach formally, others will encourage pairing
and peer reviews. Others will just leave developers to get on with it. Most
are a mixture.

I have never worked somewhere where learning was not considered a basic
need, and I've worked in public sector...



> - FLEXIBILITY (time and space). Some tasks lend themselves to
> collaboration between multiple people in a shared space; others lend
> themselves to focused, uninterrupted concentration. I'd like the
> flexibility to be in the right place for the task at hand, as much as
> possible. And sometimes (actually quite often), I'd like to be able to work
> "weird" hours in order to do some or all of the following: pick up my kids
> from school, go for a long run, practise guitar, fix my bike, read a book,
> write lengthy and unsolicited rants to the LRUG mailing list.
>


This is a tricky one, because whether you like it or not sometimes people
need to sit down and talk face-to-face, and planning a meeting is tricky if
you want to wake up in the morning and spend the day playing guitar. Core
hours are the best way I've seen it done: everybody is expected to be
around 10am-12pm & 2pm-4pm for meetings, and the rest of the time is
relatively flexible, assuming you're getting your hours in and deadlines
met.

Developers who think the job is about writing code when and how they feel
like it, and has nothing to do with talking to other people are
unemployable in a permanent position. They are less than desirable as a
contractor, but tolerable if they have the skills you urgently need.

Being available to colleagues in a predictable pattern is non-negotiable in
most firms.



>  - TRUST. As far as I can see, the main thing getting in the way of a lot
> of employers offering flexility around hours and location is that they
> don't trust their employees not to abuse their freedom.
>


I don't think that's true. The main thing getting in the way is that
business requires consensus, communication and planning. All of them are
hard to achieve whilst offering complete flexibility in hours and location
- in some jobs (particularly with operational issues), it is not just hard,
but impossible.



> The thing is that most good developers actually *want* to do good work,
> and the focus should really be on facilitating that.
>


I have never worked for an employer who didn't want to help their employees
do good work. Who have you been working with? I'd like to add them to my
list of firms to avoid in future.



> If they also want to look at Facebook sometimes, well, what of it?
>


I don't recall ever seeing a developer admonished for looking at Facebook
sometimes, or indeed checking email, RSS feeds, etc. I have worked with
dozens (possibly hundreds) of permanent developers and never heard of one
being told off for surfing either.

I have seen developers told off for not doing any work at all, I've seen
sys admins get sent home to bathe (no, really), I've witnessed people being
pulled up for browsing inappropriate material (porn), but never for having
a brain fart and checking their social media accounts or news feeds.



> And at the end of the day, whether they're in the office every day from 9
> to 6 or not, it's pretty easy to work out if the quality and quantity of
> someone's work is unsatisfactory.
>


Actually, for most employers, it isn't. Most employers do not understand
how to assess the quality of a developer's work because most employers are
not developers. As such they measure employees based on what they can see
and measure: hours sat in a chair working, the amount of slacking
off/joking around, etc.

A good CTO should provide a shield around this to other senior management.
I know I always try to do this, because I see it coming from a mile away.

It's really, really hard for non-devs to just trust what's going on with
the devs, because its a black box to them.

As a developer the onus is on you to show you're getting stuff done (hint:
ship working product quickly).

The onus is on you to prove to your employer that you're not just burning
(a relatively high) salary. The onus is not on the employer to just trust
you without evidence or feedback loops because you think you deserve it.
It's a relationship, and when you start out with each other, you're not
entitled to the benefit of the doubt: they're paying you, prove you're
worth it. It's not hard.

Developers who don't agree should expect to deal with the consequences:
they will be judged based on hours worked, and they may find it hard to
retain work either as a permanent developer or as a contractor.



> Github doesn't lie ;-)
>


It really, really does.

Github is a bad barometer of how good a developer is for all sorts of
reasons, but to a non-developer senior manager it's utterly useless and
means nothing. Commits/day is about as useful a measure as LoC/day (in
other words: it's worse than useless, and is actively harmful in terms of
assessing productivity).



> - PEOPLE. Inasmuch as you have to spend the bulk of your waking life
> collaborating with other human beings, they should at least be awesome.
>


Do you accept that by the definition of the phrase, 50% of developers are
"below average"?

Do you therefore accept asking for environments in which 100% of staff are
in the upper 5% is perhaps a bit unreasonable?

A healthier attitude is to approach a team with an open mind and learn what
you can, and teach what you can. You should aim to work with people who you
think you can learn from as much as possible - in essence, you should feel
going into a new job that you need to up your game to keep it and fear
being uncovered as useless - but at a certain point in your career (if
you're successful), you're going to have to realise you're the old guy in
the room: you're the one people are there to learn from. Live with it,
embrace it. Some people choose leadership, others have it thrust upon them.
If you don't want it either way, switch careers and become a newbie again.



> - ENGAGEMENT. Roles vary, but in most contracts there's very little
> opportunity to contribute to the growth of a product/team other than in a
> fairly narrow technical way. You are there to churn out code, not offer
> your opinions as to how to improve the process, better engage customers,
> help provide leadership, drive out requirements, etc etc.
>


My experience is that in permanent jobs you are far more likely to get that
input than you are in contract jobs. I hire contractors to contribute
specific skills to specific projects - I don't expect them to weigh in on
product strategy, I expect them to hear what the permies have decided on.

Permanent team members I want to see getting their noses up in all the
business. If a developer doesn't give a damn about the numbers the rest of
us do, they probably don't belong in the team as a permie.

That's typical for the startup sector. YMMV, but I'm surprised that your
experience is so contrary to my own.



> - MONEY. I'm not going to lie, it's a major consideration. Typical perm
> rates for senior Ruby devs in London seem to be around 60% of the
> equivalent income for a contractor. If it were more like 75%, I think a lot
> more contractors would go perm.
>


You're not doing all the maths here, perhaps because you might not be
seeing the bigger picture of cost of sales, utilisation rates,
administrative overhead and so on as a contractor.

I went back to perm in part because I liked knowing how much money would be
in my bank each month, and when. No invoicing, no chasing, no cashflow
management - I could start to plan for the future in a more meaningful way.
My stress levels dropped a notch and I enjoyed being able to commit long
term to a product strategy without context switching every 3-6 months.

I also think perm jobs are at or above the level you indicate compared to
contractors when total working hours and utilisation rates are accounted
for, if not higher.

Everybody should choose the path that is right for them, but your arguments
about the permanent lifestyle seem as odd to me as those arguments my old
friends in Manchester made to me about London when I moved down here: it's
much, much better than you think, and the advantages are considerable.
Think carefully before dismissing it, because you could be missing out on a
great opportunity.

_______________________________________________
Chat mailing list
Chat at lists.lrug.org
http://lists.lrug.org/listinfo.cgi/chat-lrug.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140626/3ac62ac7/attachment-0003.html>