[LRUG] Perm vs contract

[carlos]

Thanks for the considered reply, Paul. Loads of points! To reply to some of
them:

> I don't think there are many jobs anywhere left that are busy work.

"Busy work" is of course a very subjective concept. I feel like I've done
my fair share of it! That said, it's probably less prevalent in the Ruby
world than in more 'enterprisey' technologies.

> All developers learn, every day.

True, but organisations vary in the extent to which they encourage focused
learning - eg spending work time working through tutorials, or watching
Railscasts, or technical blogging, etc.

> planning a meeting is tricky if you want to wake up in the morning and
spend the day playing guitar.

Heh, well, I was thinking more in terms of a half-hour break for guitar to
be fair. As for planning meetings with remote workers and so on, the
'Remote' book goes into some useful detail on that. Core hours seem like a
good idea - although I'd hope to use them more for pairing than for
meetings :-)

As for the trust thing, well, our experiences are different. I've worked
with several managers who simply assumed that the developers would mess
around all day if they worked remotely.

> To a non-developer senior manager Github is utterly useless and means
nothing

Yup, but to a lead developer, tech director or CTO it should be a fairly
rich source of information about the quality of somebody's work.

> My experience is that in permanent jobs you are far more likely to get
that input [product engagement, etc] than you are in contract jobs.

Agreed, that was the point I was making.

> Think carefully before dismissing it, because you could be missing out on
a great opportunity.

Funnily enough, I thought I was being quite positive about the idea of perm
roles! But the fact is that every Ruby shop I know is finding it extremely
difficult to find permanent employees, so IMHO it's worth exploring what
organisations can do to attract people to perm roles. For the record, in
terms of developing really great software, I think putting together a
cohesive team of engaged, committed, in-it-for-the-long-haul people is
pretty crucial.

Cheers
c



2014-06-26 16:49 GMT+01:00 Paul Robinson <paul at iconoplex.co.uk>:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140626/a0862525/attachment-0003.html>