Monday, 15 October 2012

Modern Perl and the lack of "great" programmers

I'd like to collect some opinions about the following things. I am referring to some of the recent posts on linked-in, about recruitment and the lack of "great programmers".

A bit of history in my (possible distorted) view:
When OO appeared there were debates on the fact that has certain disadvantages over procedural like speed and being more verbose (over the advantages of allowing abstraction and allegedly being better for organizing huge code).
Then, in Perl's world, there were voices saying that one should not bother to learn OO perl because it is not a real OO, it is more a set of cumbersome conventions than a proper OO implementation.
Finally Moose appeared and practically defined a sub-language, a lot of "sugar" to overcome the base language OO limitations.

Now everybody jumped happily in Moose's boat and no-one talks about procedural Perl and, more important, they don't accept anymore procedural at interviews.
Like OO Perl is more than just another way to structure Perl code.

I call "There Is More Than One Way To Do It" in my support. True, I read somewhere: "Because TIMTOWTDI, don't assume that you can do it any way you want" but I tend to disagree for most of the situations.
In my opinion, the main purpose of any application is to meet the specs and also to be done in the allocated time. If you think of the application as a black box, and you managed to make it work as expected and tested it thoroughly from any angle, I really don't understand why would anyone would care *how* it is inside the black box. Is like, you can hit a nail with a hammer or with a pair of pliers and to a certain extent the outcome will be the same, depending of the wood's resistance.

Of course, when it is about interacting in a team and if there is a defined programming style, the applicant should converge to it, to respect the house rules. Still, it doesn't mean that procedural Perl should be a reason to reject a candidate at technical interview time.

It seems that only few companies are still willing to allow time for learning and they all ask for guys that can "hit the ground running" (again, mind you, we talk about a style not about core programming skills). But no one can know everything needed at the new job already. If (s)he knows everything, there is a chance (s)he might be tempted to look somewhere else for a challenge.

I think that's why a lot of recruiters/companies complain about the fact there are not many "great" programmers on the market. (BTW: Define "great". How? By compiling a list of technical questions that all "great" programmers should know? This might be a wrong approach. See
I bet there are lots of good Perl programmers but they get rejected (and possibly going to other languages) because they were considered as not fitting the target company's programming style. The companies are incredible picky these days about the style, and the middle layer (agents) is escalating this much more by not knowing what's really about.

And then the advertised job stays on the market for 6 months or more and the agents and companies, at unison, lament about the fact that "great" perl guys are a scarce resource. Maybe giving a chance to any Perl programmer that can do the application no matter the style, would be more beneficial for the company. Put in balance the 6 month fishing for the "great" programmer versus few month a "regular" guy can learn the new environment's specifics, style, etc.

Maybe it is time to admit that we're not so many out there,  therefore you need to be more flexible. Otherwise, wait.

I'm not trying to diminish the importance and role of OO Perl or Moose. I would just love that the recruitment wouldn't be so exclusive about it nowadays, because things can be still done very well and fast, the procedural way. Besides I don't think that it'd take more than few weeks for someone to adjust from procedural to OO style of the company. Not to mention that OO design sometime is a separate job in many companies, and in the end the programmer ends up writing code inside the same class, not needing to know the big OO picture.

So, how hard you think it is for an "regular" perl programmer to switch from procedural programming to Moose?

Sunday, 14 October 2012

Modern Perl recruitment - cont'd

This is in response to some recent posts on linked-in, some of them leading to

I think compiling a list of questions for the recruiters to ask for when filtering candidates is wrong and irrelevant for few reasons:

First of all, the weight of each question in the list should be judged in the context of the particular job requirements. No-one knows everything about Perl (maybe with few exceptions, see below the "top N").

Then, the weights of two questions could appear comparable to the recruiter and the candidate could get rejected based on wrong assumptions. Take these 2 examples from the list:

"What's the difference between == and eq?"

-- versus --

"Where do tests go in a standard CPAN distribution?"

One one side, if a programmer doesn't know the difference between == and eq, then we might have a problem (still debatable if the guy is coming from lots of years experience in PHP for example).
On the other side even an experienced programmer might have never been in the situation to care about the tests in the cpan distributions: if everything installs correctly and never created a CPAN module, why should one bother?
You can find more pairs of "extremes" in the list to prove this point.

The list also proved its limitations as a lot of people on linked-in already started to ask for clarifications. Assuming that someone really fixes the list's "bugs" as feedback is received, discussed and changes agreed on, probably endless iterations will be needed.

As for the relevance of asking somebody these questions, as the present list's answers can be found in only one book (Modern Perl), if anyone really wants to fool the examiner can do it by just reading this quite small book. Even easier, any perl wannabe can find now the list on the internet and can prepare the answers for potential future interviews.

Finally, knowing everything about perl is quite impossible: everyone has strong areas and weak areas and the capacity (or lack of) to improve in the weak ones if the job requires it.
Not everybody is Larry, Damian or Randal (and the list might continue to a top N). On the other hand not every company would need (or afford) any names from this shortlist. Bothering one of the top N programmers to write scripts for a company that sells ladies bras, briefs and stocks would seem a bit out of proportion, much like using a hammer to kill a mosquito.

Wednesday, 10 October 2012

Modern Perl recruitment

I am currently looking for a job using good old Perl and things seem more annoying than ever before. The frustration came back gradually, and most of it comes from the middle layer: the recruitment agents.

Let me start by clearly stating that not all the agents are the same and not all of them are "bad". However, unfortunately, many fit the description below.

This special breed of people, the perfect salesmen (in their views), is interposing between me and my "happiness" in annoying ways. Here are some things they, and only they, know how to do best:
  • They understand 50% (if...) of what you can really do, but they have the audacity to decide your professional life by not putting you forward to the decision maker, the one that would really understand (as he needs and asked for you skills).
    Sometimes you don't check a skill and, even they don't know what's the real relevance of it or how easy it is to learn it; they just feel that skill sounds impressive. If you don't have it, you're a looser.
    Some other times they don't like you, you'll never know why.
  • They publish their own, "cloaked" version of a job that's already published directly by the hiring company. They leave the same keywords inside 'cause they're unable to reformulate the skill set.
  • They publish non-existent jobs, probably just to motivate their existence to their bosses by pretending they have activity. Moreover, they fish for leads by asking you to provide info about any other interviews you had, motivating that they don't wanna overlap with other agents on the same positions.
    I am sure (!) they don't contact an employer if they know that some other agent is already there :) They do have an exaggerated common sense.
  • They treat us as like... cattle by adding quantities to the job titles, like: "50 perl developers for a big company[...]", "Calling for all perl developers [...]".
    We should just moo-in by sending all resumes to them. It's kinda depersonalizing, you know? What about having a regular posting for the job and selecting how many people you needed, afterward?
  • All the companies they're recruiting for are presented as they are the latest shit on the market, next to Oracle or Microsoft or whatever you consider it's a big shit these days (pun intended :)
    Buzzwords include: "thriving environment",  "exciting", "world leading", "voted as number one expanding", "global footprint", etc.
    Have you thought that I just might prefer a regular sized company that would have obviously many advantages over the corporate, impersonal ones?
  • You need to be psychologically abnormally addicted to work to please them. I mean, why would anyone choose to "dream in LAMP", "eat and breathe Perl", have an "Unquenchable thirst to automate mundane tasks" or be a "Perl junkie" instead of being a regular work-life balanced individual?

Unfortunately there are so many companies that act the same through their HR department.

I have a real example, one that is these days on the Heart Internet, UK. They think is ok to cut all communication with me, *after* I spent few good hours on their programming test. I don't care if my solution was dumb or not to their liking, I just consider I am entitled to an answer, at least as a sign of courtesy after wasting my time.
This job based in Nottingham is present on also cloaked by an agent: Simon Harris, Applause IT (see above about cloaking).
Same communication skills from this guy too. I sent them together about 10 emails until now asking for feedback, no reply.

Say, what about a database with agent names and star rating/feedback? Something similar to but focused on recruitment agents/companies.
Also, it could be extended for any job recruitment agent, not only for Perl.Anyone?