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.

In reply to Re^3: Where are future senior programmers coming from? by Corion
in thread Where are future senior programmers coming from? by tilly

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.