Alternative sources of Perl programmers
Hi, We're advertising for a Perl programmer again, and once again we are struggling. It's a shame because we've got quite a lot of development work in the offing, mostly using Catalyst, DBIx::Class, Moose and the like. I spoke to the agent today and asked why so few people are coming forward. His view was that there aren't many Perl vacancies about at the moment, and even fewer people are interested in them. What are other companies doing about this? We've got several PHP projects on the go as well. It's easier to get local PHP programmers and when we can't, there seems to be a constant supply of good Eastern European programmers. Why isn't there the same stream of Eastern European Perl programmers? A second possibility is to cross-train experienced programmers from other languages into Perl. However, Perl has got itself such a reputation for being difficult to learn that the CTO winces whenever I suggest the idea. How have other companies got on when they've said that they will take experience in Python/Django or Ruby/Rails or whatever in lieu of experience in Perl/Catalyst? Was anybody interested and did they succeed? The third possibility is just to move some of the projects ear-marked for Perl into the PHP camp. I don't really believe that they can't be done in PHP, but it's a pity because they sit nicely with similar successful projects we've done in Perl. (A Catalyst-based system of ours won an industry-wide prize for Best Digital Initiative a couple of months ago.) All the best. Duncan
Re: Alternative sources of Perl programmers
On Monday, May 13, 2013, Duncan Garland wrote: We're advertising for a Perl programmer again, and once again we are struggling. The question I ask anyone who has problems hiring for any IT position is have you considered telecommute? Mark
Re: Alternative sources of Perl programmers
I second this. Every YAPC::EU I chat with the sponsors there but none of them are particularly welcome to telecommuters. Is there a pattern in responses to that question, Mark? I find that it's mostly wanting to have an in-office representation, especially when it comes to meetings. Job On Monday, May 13, 2013, Duncan Garland wrote: We're advertising for a Perl programmer again, and once again we are struggling. The question I ask anyone who has problems hiring for any IT position is have you considered telecommute? Mark
Re: Alternative sources of Perl programmers
The management challenges for telecommute jobs are different to those for on site. But it does increase the pool of potential candidates a lot. Does anyone have any useful experience about managing mixed on-site/offsite staff? On 14/05/2013, at 8:13 AM, Job van Achterberg wrote: I second this. Every YAPC::EU I chat with the sponsors there but none of them are particularly welcome to telecommuters. Is there a pattern in responses to that question, Mark? I find that it's mostly wanting to have an in-office representation, especially when it comes to meetings. Job On Monday, May 13, 2013, Duncan Garland wrote: We're advertising for a Perl programmer again, and once again we are struggling. The question I ask anyone who has problems hiring for any IT position is have you considered telecommute? Mark
Re: Alternative sources of Perl programmers
Telepresence robots are all the rage these days... On 13 May 2013 23:27, Kieren Diment dim...@gmail.com wrote: The management challenges for telecommute jobs are different to those for on site. But it does increase the pool of potential candidates a lot. Does anyone have any useful experience about managing mixed on-site/offsite staff? On 14/05/2013, at 8:13 AM, Job van Achterberg wrote: I second this. Every YAPC::EU I chat with the sponsors there but none of them are particularly welcome to telecommuters. Is there a pattern in responses to that question, Mark? I find that it's mostly wanting to have an in-office representation, especially when it comes to meetings. Job On Monday, May 13, 2013, Duncan Garland wrote: We're advertising for a Perl programmer again, and once again we are struggling. The question I ask anyone who has problems hiring for any IT position is have you considered telecommute? Mark
Re: Alternative sources of Perl programmers
We're advertising for a Perl programmer again, and once again we are struggling. It's a shame because we've got quite a lot of development work in the offing, mostly using Catalyst, DBIx::Class, Moose and the like. Are you certain that the agency or agencies you are using are actually talking to perl developers and others who could be perl developers? Has the job been posted to places like jobs.perl.org? Jason Clifford
Re: Alternative sources of Perl programmers
You're not alone in facing this, and as a rule it isn't a perl-specific issue. Perl's just at the leading edge of this. 1. There are fewer perl programmers than PHP programmers. There are many reasons for this, they really don't matter that much. In the end, perl doesn't get as much exposure and it becomes a vicious circle where fewer and fewer people learn perl. 2. There are fewer programmers than there is demand. This is only going to get worse. If you think it's bad now, wait 5 years. 3. The telecommute issue, which has already been brought up. The biggest blockers to this are general fear of the unknown, and a poor understanding of how to manage remote employees. It's really very different to managing local ones. Have you considered hiring existing programmers and teaching them, or giving them time to learn perl? You should. Or you'll have to massively up the price you're willing to pay for someone (either an existing perl dev, or someone who will be able to learn enough perl quickly and well). Simple supply and demand. Again, it'll only get worse. I'd encourage every company to hire more junior people and give them a lot of training. Go ask your HR / recruiting departments how much it costs to hire someone. Don't be shocked when they come back and tell you the number is over £20,000 *just to find someone*. Spend that time and money on training instead - you'll help yourself and everyone around you. On Mon, May 13, 2013 at 4:22 PM, Duncan Garland duncan.garl...@ntlworld.com wrote: Hi, We're advertising for a Perl programmer again, and once again we are struggling. It's a shame because we've got quite a lot of development work in the offing, mostly using Catalyst, DBIx::Class, Moose and the like. I spoke to the agent today and asked why so few people are coming forward. His view was that there aren't many Perl vacancies about at the moment, and even fewer people are interested in them. What are other companies doing about this? We've got several PHP projects on the go as well. It's easier to get local PHP programmers and when we can't, there seems to be a constant supply of good Eastern European programmers. Why isn't there the same stream of Eastern European Perl programmers? A second possibility is to cross-train experienced programmers from other languages into Perl. However, Perl has got itself such a reputation for being difficult to learn that the CTO winces whenever I suggest the idea. How have other companies got on when they've said that they will take experience in Python/Django or Ruby/Rails or whatever in lieu of experience in Perl/Catalyst? Was anybody interested and did they succeed? The third possibility is just to move some of the projects ear-marked for Perl into the PHP camp. I don't really believe that they can't be done in PHP, but it's a pity because they sit nicely with similar successful projects we've done in Perl. (A Catalyst-based system of ours won an industry-wide prize for Best Digital Initiative a couple of months ago.) All the best. Duncan
Re: Alternative sources of Perl programmers
When you're employing a builder, if the house is steel framed, you might want to employ someone with experience with the framing system. If you're building a steel framed housing estate, you will need to familiarise your crews with the technology, but that's a small amount of overhead compared to the effort of delivering the project. On 14/05/2013, at 11:49 AM, Avleen Vig wrote: You're not alone in facing this, and as a rule it isn't a perl-specific issue. Perl's just at the leading edge of this. 1. There are fewer perl programmers than PHP programmers. There are many reasons for this, they really don't matter that much. In the end, perl doesn't get as much exposure and it becomes a vicious circle where fewer and fewer people learn perl. 2. There are fewer programmers than there is demand. This is only going to get worse. If you think it's bad now, wait 5 years. 3. The telecommute issue, which has already been brought up. The biggest blockers to this are general fear of the unknown, and a poor understanding of how to manage remote employees. It's really very different to managing local ones. Have you considered hiring existing programmers and teaching them, or giving them time to learn perl? You should. Or you'll have to massively up the price you're willing to pay for someone (either an existing perl dev, or someone who will be able to learn enough perl quickly and well). Simple supply and demand. Again, it'll only get worse. I'd encourage every company to hire more junior people and give them a lot of training. Go ask your HR / recruiting departments how much it costs to hire someone. Don't be shocked when they come back and tell you the number is over £20,000 *just to find someone*. Spend that time and money on training instead - you'll help yourself and everyone around you. On Mon, May 13, 2013 at 4:22 PM, Duncan Garland duncan.garl...@ntlworld.com wrote: Hi, We're advertising for a Perl programmer again, and once again we are struggling. It's a shame because we've got quite a lot of development work in the offing, mostly using Catalyst, DBIx::Class, Moose and the like. I spoke to the agent today and asked why so few people are coming forward. His view was that there aren't many Perl vacancies about at the moment, and even fewer people are interested in them. What are other companies doing about this? We've got several PHP projects on the go as well. It's easier to get local PHP programmers and when we can't, there seems to be a constant supply of good Eastern European programmers. Why isn't there the same stream of Eastern European Perl programmers? A second possibility is to cross-train experienced programmers from other languages into Perl. However, Perl has got itself such a reputation for being difficult to learn that the CTO winces whenever I suggest the idea. How have other companies got on when they've said that they will take experience in Python/Django or Ruby/Rails or whatever in lieu of experience in Perl/Catalyst? Was anybody interested and did they succeed? The third possibility is just to move some of the projects ear-marked for Perl into the PHP camp. I don't really believe that they can't be done in PHP, but it's a pity because they sit nicely with similar successful projects we've done in Perl. (A Catalyst-based system of ours won an industry-wide prize for Best Digital Initiative a couple of months ago.) All the best. Duncan
Working from home (was: Re: Alternative sources of Perl programmers)
On 13 May 2013, at 23:27, Kieren Diment dim...@gmail.com wrote: The management challenges for telecommute jobs are different to those for on site. But it does increase the pool of potential candidates a lot. Does anyone have any useful experience about managing mixed on-site/offsite staff? Can't speak about management per se, but I can talk about how a team with off-site developers can work. In a nutshell: as soon as even one member of the dev team is, or could be, out of the office, you need to do everything important off-line. Otherwise you'll end up discriminating against the off-site people, wittingly or unwittingly. At UK2 we've historically had a mixture of off- and on-site developers - me in Glasgow, and some guys on-site in London. I come down to London once a month for three days to get face time with the other devs, but otherwise things get done over IRC, email or GitHub pull requests depending on what's most appropriate. We've had the occasional tele-conference via Google Hangouts to discuss upcoming projects and releases, but I'm not sure whether they were that useful. (That might be more useful for one-to-few discussions, rather than manglement + entire dev team.) We started ramping up hiring a couple of years ago, and while we found a few people in the Greater London area, after a while we hit a brick wall. Because we already had some people working from home, and the group as a whole had developers in Ukraine already, it wasn't a massive cultural shift to hire people from Foreignstan - currently we have a handful of people in Ukraine, a guy who's effectively a Senior Developer in Russia, some people in India or somewhere (I'm not entirely sure where they are - I only know them from their online handles, and I've never met them), and another developer in Australia. One interesting thing about this whole process is that a number of the guys in the London area started working from home as well. After all, if the important stuff is done via IRC and email, and we don't expect people to work 9-5 because they live in different time zones, then why should you struggle through rush-hour commuter traffic to go to an office with electricity, wifi, a desk and a chair if you have perfectly good electricity, wifi, a desk and a chair at home? (I think we might actually not have enough desks in the office any more, because we don't expect the entire team to be in on any given day.) As a general rule, most of the London developers only come into the office once a week. On weeks when I'm down, we try to schedule everyone on the same day so we can go to the pub; some of our best ideas have come from there. Obviously, there are caveats and exceptions. Some people prefer to work in an office, probably so there's a clear demarcation between work and not-work (living close to the office is a contributing factor for this). Others may think they can work from home, but end up procrastinating instead, so while you'll have a much larger pool to hire from, be aware that some of them might not work out. Employment contracts may need a bit of sprucing up - one of mine told me the company provided me a place to work, but reserved the right to search my desk and personal possessions, which I thought remarkably keen. A decent union will tell you that if you work from home, your employer should make sure your equipment is ergonomic and up to standard; if you live alone or your spouse works, you're entitled to claim a fraction of your utility bills, on the basis that your home wouldn't be heated otherwise. And so on - I suspect most telecommuters don't press such matters because, after all, they're no longer paying for their weekly season ticket, but it's something to bear in mind. The people in HR might be concerned about how easy it would be to enforce penalty clauses against employees in distant lands also. We have a guy in Russia who is socially a Senior Developer, but legally is a contractor, presumably because we can't legally employ non-resident non-EU citizens. Finally, if you want regular face-to-face meetings (which are absolutely useful), you need to budget for the expense of moving remote employees around. Having said all of this, one of the reasons I've stuck with UK2 during bad times and good is that, if you can cope with working from home, it's bloody marvellous. Working from home effectively means flexitime, which is a big plus for me (look at the timestamp on this email ;-) ); it lets people say I need to take the dog to the vet or knocking off early, I have a bunch of Russian people around and I need to barbecue things and drink vodka with them. or brb, kid's vomiting. And it means that you don't have to worry about an employee saying things like hey, I have a house in France now, I'm going to spend a couple of months there every summer or I'm thinking about moving to Mexico, is that OK? - as long as they have an Internet connection,
Re: Working from home (was: Re: Alternative sources of Perl programmers)
Very similar to my experience except I work as a contractor with a bunch of other contractors across three or more continents to develop and support a reasonably high profile high value product in it's domain. I meet a subset of the people I work with face to face once every couple of years (but was doing that before this work started anyway), and I've never met the principal in person. We talk on the phone up to 4 times a year, but generally it all happens through IRC, bug tracker, wiki and git repo. For big companies where slacking or low value staff are a problem I don't think telecommuting is a great option (hence Marissa Miller's recent proclamations), but could be solved with an organisational culture turnaround. The very nice thing about perl from my experience is it seems to attract people from a greater diversity of social and educational backgrounds than other programming communities (in my experience), but you've got to make the working conditions good to take full advantage of that. On 14/05/2013, at 12:40 PM, Sam Kington wrote: On 13 May 2013, at 23:27, Kieren Diment dim...@gmail.com wrote: The management challenges for telecommute jobs are different to those for on site. But it does increase the pool of potential candidates a lot. Does anyone have any useful experience about managing mixed on-site/offsite staff? Can't speak about management per se, but I can talk about how a team with off-site developers can work. [snip]
Re: Alternative sources of Perl programmers
Indeed. -- Ciao Richard Foley http://www.rfi.net/books.html On Mon, May 13, 2013 at 05:48:39PM -0400, Mark Fowler wrote: On Monday, May 13, 2013, Duncan Garland wrote: We're advertising for a Perl programmer again, and once again we are struggling. The question I ask anyone who has problems hiring for any IT position is have you considered telecommute? Mark
Re: Alternative sources of Perl programmers
I had a contract role in Switzerland where the client was happy for me to come on board in a (largely) remote capacity. That meant some on-site work to familiarize me with the team and the project and then shift off-site for the majority of the work. This suited both parties. The agency stepped in, (they'd been unavailable during the telephone interview), and said there was no way I was going to work remotely for this client, and scotched the deal. Both the client and the contractor were screwed, and this had nothing to do with the practicalities of remote working, or problem solving of any kind. This was simply a power broking intervention. Solution-1: ditch the agent, work directly with the client/contractor, save everyone some grief, and some money at the same time. Solution-2: look at how some groups of people are trying to raise the current and future profile of the Perl programming language instead of resting on dusty laurels. Yes we you can learn another language, but would you really want to ?) Solution-3: do both solution-1 and solution-2. -- Ciao Richard Foley http://www.rfi.net/books.html On Mon, May 13, 2013 at 10:22:05PM +0100, Duncan Garland wrote: Hi, We're advertising for a Perl programmer again, and once again we are struggling. It's a shame because we've got quite a lot of development work in the offing, mostly using Catalyst, DBIx::Class, Moose and the like. I spoke to the agent today and asked why so few people are coming forward. His view was that there aren't many Perl vacancies about at the moment, and even fewer people are interested in them.
Re: Alternative sources of Perl programmers
On 05/14/2013 12:09 AM, Richard Foley wrote: I had a contract role in Switzerland where the client was happy for me to come on board in a (largely) remote capacity. That meant some on-site work to familiarize me with the team and the project and then shift off-site for the majority of the work. This suited both parties. The agency stepped in, (they'd been unavailable during the telephone interview), and said there was no way I was going to work remotely for this client, and scotched the deal. Both the client and the contractor were screwed, and this had nothing to do with the practicalities of remote working, or problem solving of any kind. This was simply a power broking intervention. how did the agent scotch it? what motivation did they have (other than no ethics and lots of stupidity)? it may sound sappy but i am very happy when i place a perl hacker and all three parties (candidate, client and me) win. it does happen quite a bit IMO. my first placement was a grad student in germany and he moved to nyc for this job and he still has it 8 years later. that makes me happy. :) and i can't scotch things as i like c_ognac better! uri _
