Finding smart people is not that easy either, but it's a bigger pool than only hiring senior people.

There is a lot of truth to that. Certainly it would be possible to pass our tech interview with a very small amount of Perl and a lot of programming skill.

When I look around at the good Perl people that I know, most of them did not start in Perl. Good programming translates pretty well from one language to another.

However there are catches. One that was brought up on LA.pm is that good OO programmers who program in Java are generally more interested in remaining Java programmers than they are in becoming Perl programmers. So while there is a selection of good people, they aren't all available for a Perl shop.

If you don't go for experience but just go for smart people, there are two problems. The first is that they will become good but they have a learning curve ahead of them. How do you shorten that learning curve and avoid the pain of some of those mistakes? Hopefully without detracting too much from the performance of your small team?

The second problem is, of course, how to identify them. For instance we have a relatively straightforward CRUD application. So our tech interview hits the skills that you need for that - you need algorithmic common sense, basic knowledge of Perl, to come up with a reasonable database schema for a concrete problem, be able to query that schema, understand OO, and get along with the existing group. The test is fairly language neutral, people both can and have passed our interview with flying colours even though they were very rusty on Perl. But it is not programming neutral. You could be very, very smart and flunk it. You could even be very, very smart and very, very good at Perl yet flunk our interview.

I don't see how to come up with a good test of intelligence that is useful for programming that doesn't share this flaw. Certainly it is known that interviewing is a horrible way to pick them. You could give a general IQ test, but that isn't going to tell whether they have the concentration, personality or motivation to be a programmer. (OTOH I have a horrible personality for a computer programmer, yet I seem to get by.) If you gave me 50 candidates, and there are 5 great ones in that list, I have no confidence that I'd be able to correctly identify any of them.

But suppose that we have a reasonable solution for this problem. How would you propose organizing a Perl team to take advantage of Perl's strengths, yet have room for the mentoring that a smart junior programmer needs?

How would you propose organizing a Perl team to take advantage of Perl's strengths, yet have room for the mentoring that a smart junior programmer needs?

Having the least experienced team member pair program with the most experienced has worked well for me, with pretty much zero drop in productivity of the team in general (over the team sans the inexperienced programmer that is.)

I could have sworn that I'd read a study that backed up my opinion with some vague attempt at research - but Google has failed me.

good OO programmers who program in Java are generally more interested in remaining Java programmers than they are in becoming Perl programmers

Sure, but not everyone is so loyal to a language. I know I'm not loyal to Perl and have taken jobs that didn't involve it. Opening your doors wider is bound to improve your odds.

The second problem is, of course, how to identify them.

All the standard interviewing advice applies. Getting candidates to talk about how they solve problems is usually the gist of it. You try to find people who are interested in programming, rather than just looking for a paycheck.

How would you propose organizing a Perl team to take advantage of Perl's strengths, yet have room for the mentoring that a smart junior programmer needs?

The usual things seems to work: code reviews, scanning the checkin e-mails from Subversion, holding regular meetings, letting people choose what they want to work on, paying for books and conferences, encouraging participation in open source projects, etc.

Both theory and experience lead me to believe that people who learned in the small company environment will have a bunch of really, really bad habits that they will never realize are bad habits because they have never worked with anyone who could set them straight. This is the old "big fish in a small pond" problem.

In a number of fields I have found that people who think they are good generally think that because they've never met anyone who is good. And as a result they are really bad. Because no matter how much talent they have, they simply aren't going to figure out on their own enough to be better than people who have exposure to the wider world.

About the "group shop" issue. I'm in a team of under 10 people. (How big the team is depends on how you count it - for instance I mostly do reporting these days, so I'm not part of the core team.) Is that a group shop in your eyes? Yet every member of this group is at least decent by my standards, and my standards are pretty high.

It's not really the work environment that matters. The people I really consider good programmers work in very small groups. However, the work group isn't everything. With Perlmonks and other online things, even a lone programmer can learn a lot from senior people. Indeed, I went out of my way to meet other people doing Perl so I could have someone to talk to. Don't be satisfied with what you find at work: check out a Perl Mongers group, read as much as you can online, try out new things, and so on.

As a counter-example, I've met a lot of really bad programmers in big shops. These are the sorts of people I would never hire. Really big companies have seats to fill and they take what they can get. Often, even though the company is large, they work in very small groups that don't talk to each other. I'm constantly surprised how compartmentalized a big company can be. Given a relatively senior bad programmer training the new hires can have the same disasterous results as the lone programmer who never talks to anyone.

The trick, no matter the work situation, is to talk to as many people as you can, or at least read the answers other people give to problems. You'll quickly figure out, for instance, about strict, warnings, and PERL vs. Perl.

We have a part to do in this too. The Perl community can be very unforgiving (and I'm not talking about Perlmonks necessarily, which happens to be on the more friendly side). The hapless newbie comes in looking for help and reassurance, but is often immediately attacked for lack of strictures, etc. We want people to get better, but we tend not to nice enough that they want to listen to us.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

That fits in with my experience. It is very difficult to judge your own skill accurately unless you have sufficient exposure to other programmers. For years I worked either solo or with one other developer, and all along I thought I was a damn good perl programmer. Mostly because I was the only perl programmer I knew that understood globs and tie.

A few years ago I realized that I was an ok perl coder, but a horrible engineer. I wrote clever and unmaintainable code, and not a single test case. I then adopted the policy of being maintainable instead of clever.

My most recent awakening came from taking part in discussions on perlmonks. I have learned more from answering questions here than I have from many of the books on my shelf.

That's certainly true, about bad habits, tilly. Ego is another issue that can be poisonous. My personal experience is that the need to solve problems on multiple levels does more good -- by a large measure -- than the bad habits do harm, and I'll comment more about ego down below.

My definition of greatness (or 'senior programmer' status) is based far more on one's ability to gauge what parts of a problem are worthy of more applied brilliance than others. That does not appear to be yours, though. You seem more concerned with ability to work to an API defined by a team and write elegantly maintainable code. These are admirable traits in my book also, but (honestly) I've never worked much in group development environments. I am, I suppose, much more a rough-and-ready programmer with lots of odious habits. ;-]

As for your 'group shop', if we turn it around, how many kids are you (collectively) mentoring? We all know that you can generally write code faster than you can explain menial coding tasks suitable for learning experiences. If you're not supporting some, you're making my point: that small-to-medium groups cannot support mentorship opportunities, and big ones are not worthy learning environments. I heartily agree with another responder who said that many bigger shops have dead-end programmers who can't shine a dog's @ss. One of the reasons I rarely get in to larger shops is that those are the ones who get chosen to give interviews. ;-]

Be that as it may, I don't disagree with anything you've said, but I stand on my case that anyone sharp enough to survive the hot seat is capable of learning to code defensibly and in a shared environment. The ego is the sticking point. They can, but will they? It took me a lot of years to learn humility. I never wore my ego on my shirt, but it was definitely riding on my shorts. I "knew" I could solve anything in programming, given tools and time. Now, at least I know that not all problems are made of bits and neither are all solutions. :D

I never really had a mentor, because I was a better coder and analyst than anyone I worked with, but I did have some good (non-programming) teachers who were proud to point me towards the prize rather than the competition. I guess that's the real key in integrating a team member: is the achievement worth more to him than the race?

Now, I'm getting to the point in my career where the young guys are definitely better coders than I am. Here in Austin, they grow up speaking C at the breakfast table and C++ at tea. (Perl, of course, takes up Saturday afternoons out in the garage). However, I'm still valuable because of that early seminal training in recognizing the prize. It isn't really about how much syntax you can crunch before noon, but rather how much closer you get to release by 5.

Don Wilde
"There's more than one level to any answer."

Both theory and experience lead me to believe that people who learned in the small company environment will have a bunch of really, really bad habits that they will never realize are bad habits because they have never worked with anyone who could set them straight.

I'm not sure, it seems unlikely to me that you can get a great programer from a single great mentor. I think a programer who could become great has to look outside their local environment Netnews, books, blogs now and "community websites" for different opinions/approaches, and think about them.

In fact, I'd say that one of the major points of greatness is "one size doesn't fit all" / "everyone or everything is wrong some of the time" and you can't learn that from a single mentor, almost by definition.

--
And-httpd, $2,000 security guarantee
James Antill

Another important way of finding good people who haven't found the way to Perl yet is offering internships or other cooperations with a university - that way, you get to see a lot of young people who possibly haven't seen/used Perl but who still are capable of learning. They also are the very definition of Junior Programmer. You can't expect a great turnover on successful conversions, but then, you don't have to endure them that long either. If there's a good one among the bunch, you'll find them and indoctrinate them with your framework, which is a great way to ensure they'll stay with you or will later come back to you when they're looking for a summer job or are finished with university/school.

Could you clarify how a Perl shop should be organized to be able to do this without suffering undue pain?

The structure that hardburn described, which I'm also familiar with, is one where every single person is senior and nobody holds anyone's hands. Adding a junior person to that structure is problematic because rather than getting a developer, you lose a bunch of developer time without getting much back, and you're pushed closer to the size limit where communication overhead forces you to reorganize in a less efficient manner.

To make it work, you need developers who are true team players and recognize the future value of a good programmer. If your developers hate being bothered and think passing on knowledge to the younger generation, or think of it as pain, then you're pretty much already in a bad situation.

I've found that in these situations, the developers are always under the gun and suffering from a lack of time. I've also often found that they suffer from a dysfunctinal development process and several other self-defeating set-ups which suck up all of their time.

The time to teach other people anything isn't losing productivity since it should make both sides better. If you're just counting lines of code or time at the keyboard, you probably don't realize how much you're actually losing by creating information silos. If you can't come up with a way to effectively integrate a new person into your group, you'll be hurting when you lose key people (like I once did when he drove his sports car into a tree).

Every situation is different, so it's difficult to perscribe anything that works everywhere. Good developer docs (which means, not just the APIs, but how to use them), good task tracking, can help. Start new people off with small tasks, maybe related to wish list items or tool smithing, and gradually bring them up to speed on the whole project. Let them sit in meetings, etc. If you want a good programmer, you probably also want to keep them for a long time. A transition time of even several months sure pays off more than several short term bad programmers over the same time period. I've seen both situations.

The communication problem really isn't that bad. Give every new hire a sponsor: someone who you trust to be a good programmer (not necessarily the best), who can take the newbie under his wing for a while. Of course, this sponsor also has to have some skills at managing that, which a lot of programmers lack. Programmers, as employees, need to be more than just code slingers. A "senior programmer" who just slings code isn't really worth the title.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

I'm not sure about the "undue", but there will be pain. I think that's the cost you have to bear as an investment into finding/training good people.

The way I know (in a much larger work scale, but within small teams) is, that a person is joined to a project of limited time. It takes time and effort on part of the project lead/mentor to identify a task that is useful and reasonable to perform. You need a screening process or early-out if the person doesn't match your needs, or at least a way to reassign the person to where they can do less harm.

Setting up a "curriculum" to bring the person up to speed with "everything" is very important. I can imagine the following (which is how I started):

1. One week of assisted self-learning of the language. This means you need to provide study material that is good enough for your purposes and somewhat geared in the direction of the actual later application. For example, if you're going in the Tk direction, the PerlTk book might be appropriate, possibly together with a quick introduction to Perl. Other pointers to whatever resources you need should be provided, either up front or on demand.
2. After one week of "toying around" (which here also gets wasted by getting the email account, Windows account and various other permissions set up, so nobody can do much useful work within the first week anyway), the person should be ready to get a quick tour of your framework by looking over the shoulder of somebody else. "Framework" can mean a lot of things, from the distinction of dev/integration/production machines to the directory layout you use, to the program framework like Mason, Jifty or whatnot. The important parts of whatever you use to do the real work that aren't explained in any book.
3. Then, that person should be given a task at which they can work "at their own pace", that is, a non-critical task. The mentor will have to be available for questions and the task will have to be of the right scope, and maybe even introduce the person actively to some key concepts of your environment, but only these concepts that are well documented and obviously also well known to "everybody". This task is mostly to familiarize the new person with the environment so they don't have to ask about the totally trivial things.
4. That task should then be reviewed together, either at the end or at some milestones however you set them up. If you have a vast Java-ish class library or other opaque API which works with much magic, like a predefined workflow which is clear to everybody in the business, but opaque to anybody fresh, I think you'll need more milestones and/or some introduction into the business that relies on whatever software is programmed.
5. After that, the person should know enough of the framework/API to be pair programming with somebody who uses and knows the API without annoying them too much with their questions about the API.

This quickstart approach leaves out some programming key concepts that not everybody can learn within one week - for example, if your programming style heavily relies on closures and you get a C or Java programmer, it might be beyond them to get a quick grasp of how and why this works, so you need to prepare for that specifically in step 1.

A totally different approach or maybe accompanying approach is to give talks about your framework. That way, you prepare introductory material and also maybe attract people who like the mindset of your framework through the talk. But of course, you have to get people to come to your talk at all, so maybe you need to give those talks in a university setting, to attract people outside of your usual stomping grounds.

I think that we have better ways of teaching new Perl programmers now. When I started, I got "Learning CGI Programming with Perl in 21 Days". I don't recommend this book to anyone. If I ever find where I put my copy, I will likely burn it in effigy. Though it got me started in Perl, it also took years before I shed myself of its bad habits.

These days, we can point new programmers to some of merlyn's books. Many of the entry-level classes for Perl are teaching 'use strict' as if it's what you always put at the top of every Perl file along with the shebang line.

After those initial classes, though, there's still a big learning curve. They'll have a better start than I did, but most places that write good Perl code still wouldn't hire them, simply because those places know that they can only hire the top 10%.

That's a huge problem, and I'm honestly at a loss on how to solve it. The best solution I've come up with is to get hired by a company that has garbage Perl code, hang around PerlMonks a lot, and then jump ship to a good company as soon as they can. But that seems like a cop-out solution.

That may be a cop-out solution, but it is the one that I suspect is most likely to happen. And the Perl community has a good selection of books for those people to learn from. Getting real-world experience is still problematic, but you've at least made the path to competency more direct.

Another solution is to steal people who have learned in another environment and train them in Perl. And indeed a large fraction of good Perl programmers cut their teeth in languages such as C/C++, Smalltalk or Lisp.

A third solution is to create a company culture of disciplined code reviews. Of whatever level of formality, down to pair programming. I suspect that a company like that could get by with a few smart juniors. Their mistakes would be caught by whoever worked with them, and the environment would ensure that they didn't stay junior for very long.

However I can't actually name any companies off of the top of my head who train new Perl programmers that way. However Geoffrey Young (of mod_perl fame) said that he learned in an environment like that at Anderson Consulting (now Accenture) and seemed to have a positive impression of it.

Something that I'm wondering is how good a job various Perl training courses do in jumpstarting the process. We have very good people (eg merlyn, Dominus and TheDamian) teaching these courses, and they put a lot of work into making them good. Does anyone have positive (or negative) testamonials to how well they work?

I think training is the way to go. That includes training interns and programmers from different programming languange. It is not easy and not for everyone, but I think training is needed in any company culture that values continuity of its business.

Being able to teach stuff to other people has benefit me a lot. I learned from teaching that people have different way of thinking and different speed in acquiring new knowledge. That has helped me in growing from a junior programmer to the technical lead in 2 years of my first job.

So I guess, when a senior programmer becomes a technical lead, he needs to be able to pass on his knowledge to their underlings, whether they are experienced Perl programmers, experienced Java programmers, interns, or any junior programmers.

In many of my own experiences, I have seen companies treat Perl programmers with disdain, and regard them as a "necessary evil" until a "real" programmer fixes the problem in Java, C#, C++. Their perception was that Perl programmers are tinkers/sysadmins trying to hack together a "quick fix" to a problem. And many a shellscript writer, sysadmins among them, have come to Perl as another major tool to augment their use of grep, sed, and awk.

Yes, I think Perl is a great language, and I can one-off a lot of stuff with it, but it is also a powerful programming language, and many companies treat it as a low-end scripting language, or as a temporary RAD fix.

I've also noticed that many companies see Perl programmers as being grown organically, rather than resources that they can send to "Perl camp" to become instantly proficient, much as they do with C++ and Java.

Currently, I'm lucky to be blessed with being part of a team of Perl programmers, working with Perl as the language of choice for a complete project. Some of us are new to Perl; others are not. We work by sharing, reading, studying, and just trying out different techniques. This is how we're building the next generation of Perl programmers.

Just my $0.02,
-v.

I've been very lucky, and my company supports new programmers. We're a very small company, and the need for Perl arose, I was the only person who had any exposure at all, and that wasn't much. I was going to "fill the gap" until we could find more experienced Perl people. Guess what - we couldn't find any!

I learned from every source I could find, including the kind Monks here, from books and web sources. The one thing I couldn't find was a class. I'm located in Connecticut and the only local class I could find was cancelled three times because I was the only person who registered.

My company believes in education and is more than willing to pay for classes, and encourages team participation. It has been almost a year, and we now have a team with one of the best Perl Programmers I have ever had the pleasure of working with. And the best part is that he is willing to share his knowledge, explain what he does and how and why he does it. I am still the nubee, but I'm improving. With his mentoring, I've learned a tremendous amount!

I'm glad you're improving. However your "best Perl Programmer" comment reminds me of a story.

A woman I know recently moved from a large city to a much smaller one. She has a job, and her boss complimented her by telling her that she was the best programmer she had seen. She was depressed about this because she realized that he was probably right, and thought this was sad. You see, she doesn't think of herself as a good programmer because there are so many others she knows that she thinks are better. But she admits that she's probably the best that he's seen.

So the moral is that while you should try to learn from this person because he is the best you know, don't treat what he says as gospel. There are a lot of people out there who are a lot better than he is, and if you want to continue improving, you're going to have to figure out a way of learning from them.

(Random suggestion: have you considered doing a non-local class? From Connecticut you can commute to Boston or New York, both of which have plenty of classes to sign up for.)

(Random note: my wife interviewed for residencies not long ago, and Yale liked her quite a bit. I already didn't like the idea of living back east, but what clinched it was that I looked at the local job market and saw fairly poor pickings. After discussion we ranked Yale fairly low and didn't wind up going there.)

At a prior job, I'd lobbied to hire more junior people. It was an extremely small team of senior guys and we actually needed junior people.

The rationale from management (as best as I understood it) was that the senior people need less direction and can work faster and be more productive. So you can hire 1 senior person and get more work out of them than 2 junior people, in addition to the fact that they can do more things than 2 junior people can.

The problem was that they wanted the senior guys to be constantly fixing bugs, nuisances, tracking down obscure issues in old crappy code, and other piddly stuff. Important stuff, mind you, but usually not the sort of thing that senior guys like to do. You reach a point where you feel like a senior developer and you want to do senior level things (mentoring new people, leading projects, building software (instead of just patching it) and so on) and trying to shoehorn those people into junior roles wasn't good.

So my plan was to bring on junior people and give them all the little irritating things to do. The senior guys give them direction and training and get to work on bigger projects, and the junior guys get exposure and training. The senior guys spend some portion of their time mentoring the junior people, reviewing their work, and helping them out, but the work's actually getting done. The rest of their time, they're working on bigger projects. I think it's a net-win, because otherwise they tend to spend time procrastinating the piddly little things that "aren't fun".

Long term, the junior guys advance to become mid-level and senior guys. You bring on more junior people to go under them. Or the original senior guys leave to go onto bigger and better things and the original junior guys step up into their position.

You end up with a developer factory. You give people a way to advance their skillset and careers (hopefully moving the seniorest senior guys into more team or project lead roles (or whatever)), you get more work done, and everyone can see the utility. It's not just advanced people spinning their wheels doing things they already knew how to do before they started.

That's my theory, at least. Alas, I could never convince anyone above me to try putting it into practice.

I have some sympathy with you here jimt.

Although I have been largely self-employed for nearly 30 years, I did spend a couple of years working as a Senior Design Engineer with a microwave communications company (that is really my love but jobs dont pay so well) in 1998-9. While there I suppose my time was 20-25% administration, co-ordination and technical writing, 50% design and the balance spent essentially mentoring the junior guys. The latter was possibly the most rewarding part of the job and actually helped the entire project run much more smoothly.

In the 50% I spent doing design work I could still outproduce 2 juniors - and do it with fewer redesigns, but that isn't the real point. By the time the project moved to production I had three good juniors who had been well apprenticed and in fact all of them were ready to move up a good level. So in fact after that we split the two seniors - each taking a new project. I took two of the juniors, the other senior took one and we hired three new juniors across the two jobs. I left shortly afterwards to migrate to Canada and one of my old juniors quite capably stepped into my position. Funniest thing is that I still have contact with these folk, and the same team is still together, sans me, and the owner of the company credits my "apprentice" system for building a really strong team and they still use the same process today. Net result, since 1999 two people left, me to immigrate and one guy went to England with his fiance, but he ended up going back! Over that period the team has grown from 5 to 18 staff, the original three juniors are now the three most senior staff.

The moral? Don't give seniors the scutt work - they don't like it. Let them mentor the juniors and they will all like it. Let them pass on the benefit of their experience and, at least in that case, everybody was a winner.

jdtoronto

Any company that fails to factor into it's business model, the cost of apprenticing the next generation of core competants, is only looking at the short term model. They are looking only to the salaries and pensions of the current generation--maybe 25 to 30 years. They are in business for commodity markets and the short term buck.

And any industry that consists in large part of companies that have short-term business plans is destined to dwindle to niche markets as the commoditisation of the skills involved forces large scale resellers of the product to cut costs by seeking lower labour costs abroad. Look at the histories of the motorcycle, car, shipbuilding, consumer electrics/electronics and many others for the precedences. Whilst is is certainly true that the software industry has significant differences from these manufacturing businesses, there are also similarities.

Software perhaps has more in common with industries like films, music and books news and other 'media' industries, which erstwhile have seen strong resistance to commoditisation due to high profit margins, mass 'star' appeal and carefully regulated distribution channels. But look around at those industries and witness the significant, watershed changes that are becoming manifest as I write.

All the media industries are seeing the writing on the wall and feeling the pinch as the freeing up of the distribution channels begins to bite. DMCA is their last gasp attempt to retain their distribution monopolies and cartels, but history shows very clearly that protectionism doesn't work. Developing nations won't wear it; consumers won't pay for it; the industries cannot police it; the legislative bodies eventually see the other side of the coin and rescind it. Telephony is a good example here.

Google (or someone like them), is destined to become the Warner Brothers or Dell of the software industry. There will be a few 'star' programmers that earn obscene amounts of money and the rest of us will be session musicians or chorus line bodies--if we are lucky.

Sad, and almost inevitable, but like the UK miners, we've only got ourselves to blame.

I strongly disagree about your "any industry" comment. For instance any new industry will be mostly populated by start-ups. And any startup that tries to plan for its 15 year future is unlikely to reach its 5 year future. Thinking about your long-term future is a luxury that you only have when you've reached the point that you're likely to have a long-term future.

Yet new industries routinely come into existence and manage to establish long-term successes.

This is very relevant in the field of software because software so frquently spawns new industries.

As for the compensation structure of programmers, Silicon Valley is a phenomena that has sustained itself for a period of decades now. I rather suspect that it will continue to do so until either the phenomena is reproduced in another country or else Moore's Law slows down to the point that there aren't continually new potential businesses opening up in the field of software. I am not prescient enough to attempt predicting what happens after that, but given the value delivered by good programmers, I suspect we'll get by.

(But with one big caveat. There is a lot of ageism in IT. Don't expect to see that change, and if you're a programmer, make plans for how you'll deal with that when you get there.)

I strongly disagree about your "any industry" comment. ... because software so frquently spawns new industries.

I rather suspect that we have different definitions of the word "industry".

Supercars (Ferrari, Lambougini, Noble, Koenigsegg etc.) and luxury tourers (Rolls royce, Bentley, Aston Martin etc.), are highly profitable niche markets--but they are all a part of the motorcar industry. Equally, the guys in the IT department at your local supermarket chain consider themselves a part of the software industry, not grocers.

As their careers progress, programmers frequently move between markets as old ones give way to new--but they remain a part of the software industry.

As for ageism, it's rife in many industries: sales; marketing; promotions; financial trading; software is far from unique in that respect. However, on a personal note, you may be adding two & two and coming up with five.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Naturally this would just be a starting point for the employer in their evaluation of a prospective employee, but I think it would be a good start. Of course, my contributions aren't really to the point yet where I'd offer myself up as a candidate based on them :); due to time constraints (current job, family, etc..) but it's something I want to pursue.

If someone asked me for a source of Perl coder job candidates, I would definitely point them to Perlmonks, and tell them to use the evaluation process as I have outlined. What do other monks think?

Part of the problem is that companies are scared to take training risks. Solving that problem requires nothing short of a culture war, so I guess all I can say to that is "pay attention if/when you're part of the hiring process".

The other part of the problem is that we define "good programmer" to be someone with programming experience. It's the age-old moebian problem: jobs require experience, and the only way to get experience is to have a job, so how does one begin?

When I've had opportunity to hire developers, I've had good success by focusing the interview process on finding good problem-solvers who are self-motivated, have an interest in programming, and have excellent language (written, esp.) skills. And when I say "good problem-solver", I mean people who are not only skilled at coming up with logical solutions, but are compelled to try and come up with optimal solutions.

Here's why these types of people end up being highly (and rapidly) trainable as developers:

1. Problem-solvers: development is, at its core, finding logical and efficient solutions to real-world problems. Good problem-solvers don't like re-solving problems unless they can significantly improve on existing solutions. This leads to code-reuse coming very naturally, as a bonus.
2. Self-motivated: people who are driven to learn and who hate leaving things undone tend to be thorough and easy to train. They also tend to be less of a drain on the senior developers, as they are willing to research, read, and try before asking questions.
3. Language skills: learning a programming language is remarkably similar to learning a spoken language. Strong written language skills (both reading and writing) seem to be an indicator of someone who -- if they have the other attributes -- can pick up the syntax and idioms of a given language relatively quickly. It also means they're more likely to be able to learn by reading books, articles, and others' code.

Of course, even with all those attributes, some people just don't "take" to the development world. That said, I've had about an 80% success rate by combining one or two non-programmers with those skills and the requisite interest into a team of experienced developers. More often than not, they end up being much better programmers than I⁰, and occasionally even supercede the senior folks on the team (eventually).

Unfortunately, every organization that was willing to do that has hired me in a management role, so I never got the benefit of being a junior in such a team...

Footnotes:
0: which is no end of frustrating, but makes me proud as their manager and made me realize the importance of hiring people who are smarter than me!

But in the end we will only generate new programmers if the companies that hire have a commitment to do so. You can't go seeking 'experienced' or 'knowledgable' people all the time and expect someone else to do the training for you. Somewhere, somehow, it has to be paid for. I think we should work to encourage companies to add promising non-Perl coders to Perl teams. As has been said here, it is not what you know that counts, it is how you use what you know. Once somebody has some good knowledge in teh fundamentals of programming, they can move to other languages. Not always easilly, we dont need to write FORTRAN in Perl, for example.

The issue then becomes how do we retain these newly minted Perl programmers? In the LA scenario you paint tilly they would likely be hired away pretty quickly. So we also need to figure out how to devise a package that keeps them aro8nd once you have trained them - at least for a while so you can recover some investment!

jdtoronto

One solution is that you don't retain them. You resign yourself to the fact that you'll constantly be hiring junior people, training them, putting them to work while underpaying them, then losing them. This is the principle behind "churn and burn consultancies" and while they are no fun to work for, they can be a good stepping stone to a better job.

For the record, my first programming job was a churn and burn consultancy. While I hated it at the time, it turned out well in the long run. I was there 10 months and my salary went from $33,000/year to $45,000/year. My next job paid me $70,000/year.

If you want that there be more Senior Perl Programmers - re-arrange your goals, desks, and salaries.

The line between To Have Room and Not To Have Room is arbitrary; constraints mostly aren't.

A junior will eat part of the team's cake, for sure. But nourishing the programming skills of a junior is giving back what you once received. Golf a bit to make room. There's no better place for programmers highly motivated in learning than a workshop full of cracks. Laying out your recruitment terms reflecting the reality of your shop - ie. applicants don't earn much at start; they must expect a steep learning curve; have to learn mostly by themselves; income will raise according to usefulness - and you'll get the right ones.

Where did your programming skills come from? Who was feeding you as you weren't taking notes in class? Whose expectations did you betray whilst fixing your self-invented bugs? (if you didn't suffer from this, s/your/others/ :-)

If you don't pass your skills on, who else? Share your memory.

--shmem

long version available upon request

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}