[LA.pm] contrasting London and LA

[Benjamin J. Tilly]

"Adam Pisoni" <apisoni at shopzilla.com> wrote:
>
> 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).

I think our policy is to blame all bugs on the person who
most recently left the team.  Right, Eric? :-)

Based on lots of theory, I believe that a good solution to
both problems is to use lots of code reviews - don't let
any code go into production without having it reviewed.
This both limits damage from junior programmers and causes
lots of mentoring to happen.  Which also means that junior
people don't remain junior for long.  There are other
benefits, for instance IBM's research indicates that code
reviews are the most cost effective form of QA.

But as great as the theory is, I don't have much practical
experience with that approach.  And there are drawbacks.
Primary among them being the fact that many programmers
will get upset when their code is reviewed by someone else
in detail.  Plus the visible overhead is hard for a lot of
people to swallow.  Still I'd like that environment.

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

Important caveat.  Do we know anyone GOOD who has worked
in those languages to see what their sentiments are?
There are lots of programmers out there.  Most aren't
very good.  I'm only really interested in the opinions of
the good minority.

PHP in particular attracts lots of bad programmers.  Not
their fault - it comes with being the most popular entry
language for non-programmers who want to do cool stuff.
A few years ago Perl suffered from the same phenomena.
(Still does to some extent, but not as badly.)  That
isn't to say that there aren't some really, really good
PHP people out there.  There are.  But I'm going to
discount anything I hear from a PHP programmer until I
get convinced that they know what they are doing.

In fact we do have someone who can offer an opinion.
Robert, speak up.  I understand that you've been working
in Python at Google.  That's relevant experience.  Say
something. :-)

> Thanks,
> Adam

Cheers,
Ben

> On Aug 17, 2006, at 3:49 PM, Benjamin J. Tilly wrote:
[...]
> > 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.

>