<div dir="ltr"><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">
On 26 June 2014 15:25, carlos <span dir="ltr"><<a href="mailto:djmutiny@gmail.com" target="_blank">djmutiny@gmail.com</a>></span> wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>- 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. </div>
</blockquote><div><br></div><div><br></div><div>This is why I turned down interviews in the finance sector. Moving money around to make more money didn't appeal.</div><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>- LEARNING. A culture where the human instinct for learning and creativity is respected and embedded, and considered as a basic need for all employees. </div>
</blockquote><div><br></div><div><br></div><div>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. </div>
<div><br></div><div>I have never worked somewhere where learning was not considered a basic need, and I've worked in public sector...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>- 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. <br>
</div></blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Being available to colleagues in a predictable pattern is non-negotiable in most firms.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div></div>
<div>- 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. </div></blockquote>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The thing is that most good developers actually *want* to do good work, and the focus should really be on facilitating that. </div>
</blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>If they also want to look at Facebook sometimes, well, what of it? </div></blockquote>
<div>
<br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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. </div>
</blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>As a developer the onus is on you to show you're getting stuff done (hint: ship working product quickly). </div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Github doesn't lie ;-)<br></div></blockquote><div><br></div><div><br></div><div>It really, really does.</div>
<div><br></div><div>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).</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div>
<div>- PEOPLE. Inasmuch as you have to spend the bulk of your waking life collaborating with other human beings, they should at least be awesome. </div></blockquote><div><br></div><div><br></div><div>Do you accept that by the definition of the phrase, 50% of developers are "below average"? </div>
<div><br></div><div>Do you therefore accept asking for environments in which 100% of staff are in the upper 5% is perhaps a bit unreasonable?</div><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>- 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. </div>
</blockquote><div><br></div><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>That's typical for the startup sector. YMMV, but I'm surprised that your experience is so contrary to my own.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>- 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. <br>
</div></blockquote></div><div class="gmail_extra"><br></div><br>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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
</div>