[LA.pm] contrasting London and LA

[Adam Pisoni]

Ben,

I concur on Perl being best for teams of really smart people.  In my  
experience, one junior programmer can more than do his/her weight in  
damage for a long time to come.   We just fixed a bug on our site  
last week caused by an engineer who was let go of 2 years ago.     
That's why its even MORE important when hiring Perl programmers that  
you hire very skilled engineers (even if their not Perl gurus).

Do we know anyone who's worked in a team of Ruby, Python and/or PHP  
engineers to see if they have similar sentiments?

Thanks,
Adam


On Aug 17, 2006, at 3:49 PM, Benjamin J. Tilly wrote:

> "Adam Pisoni" <apisoni at shopzilla.com> wrote:
>>
>> I gave up using knowledge of Perl as a filter for engineers a while
>> ago.    I found that the vast majority of people responding to our
>> add for Perl engineers did not have a firm enough grasp of OO
>> architecture and design.   So now I basically use general engineering
>> and OO proficiency as my main filter.
>
> We use general engineering and database instead.  Basically replace  
> OO design questions with database design questions.  Same general  
> goal.  Perl is a lot easier to teach than intelligence and good  
> design sense.
>
>>              That said, people with a firm
>> grasp of OO often use Perl as a way of filtering out us.   Obviously
>> I have to tell them they will be learning and working with Perl.
>> Its hard to find people who are passionate about OO, but are also
>> interested in learning/using Perl.    The hardcore OO people moving
>> away from Java or C++ tend to be moving towards languages like Python
>> and Ruby.
>
> We are up front about using Perl so don't have any sense of how  
> many get filtered out.  But we've been told that people who go  
> through our interview wind up convinced that they will be working  
> with a bright team that they will learn from.
>
>>   I have no problem teaching someone Perl, but it takes far
>> to long to turn a functional programmer into an OO programmer.
>
> And this is the only thing I really wanted to respond to.
>
> When you say "functional programmer", I think of someone who is  
> used to using things like higher order functions.  Think MJD's  
> Higher Order Perl.  I have yet to meet someone at that level of  
> skill who had any problem using OO techniques.  The reverse is not  
> true.
>
> What I think you meant is that it is not easy to turn an imperative  
> programmer into an OO programmer.  This I would agree with.   
> Furthermore I would say that there are lots of people who think  
> that they are OO programmers but who are just doing imperative  
> programming with a slight OO facade.  There isn't really anything  
> wrong with this - it gets the job done - but it misses the point of  
> what OO means.
>
> Ah heck, since I'm responding, let's wander off to talk about a  
> question that Nicholas raised.
>
> About mentoring new programmers.  One problem with Perl in  
> particular is that Perl is very well suited to working with small  
> teams of very good people.  You want your team size to remain small  
> enough that communication overhead doesn't destroy productivity,  
> and also small enough that you can depend on everyone having enough  
> personal discipline to avoid doing some of the spectacularly stupid  
> things which Perl allows you to do.  However such teams have very  
> little room for including and mentoring junior programmers.
>
> By contrast a language like Java is geared towards having larger  
> teams of less productive people.  In that kind of environment you  
> simply cannot insist that each and every person be top notch.  And  
> once you've accepted that fact, it is much easier to work junior  
> programmers into your team, and therefore is easier to mentor  
> them.  Oh, and a side benefit, there wind up being more Java jobs.
>
> Incidentally this is not meant as a slam against Java - it seems to  
> be a deliberate design decision.  If you're going to have a large  
> team work together, you need to limit the damage that one bozo can  
> do.  Those barriers also limit productivity, which in turn pushes  
> team size up.  And, of course, once team size reaches a certain  
> point, you need to organize it to avoid having too many lines of  
> communication out of self-defence.  (Else, as Brooks noted, people  
> wind up wasting more of each other's time than they can personally  
> contribute.)  At which point productivity drops even further.  But  
> now you can scale pretty well - add enough people and you can get a  
> lot of throughput.
>
> In Perl teams that I've worked on, by contrast, the goal is to get  
> as much done as possible with a small team.  This philosophy is  
> *great* for a startup since a good small team of highly paid people  
> is a lot cheaper and faster than a large team of less well paid  
> people.  I haven't personally experienced it in the context of a  
> large company, but if I stay at Rent long enough, I'm sure I'll  
> find out.
>
> Cheers,
> Ben
>
> PS Like everyone else, we are looking to hire another Perl engineer  
> and another QA person.