Re: work times & accommodation @tokyo, WAS: Re: [tlug] Embedded linux dev wanting to find work in Tokyo.. Seeking advice.

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2008-07-26 16:29 +0900 (Sat), Stephen J. Turnbull wrote:
 > 
 > > This is a perfect example of why I keep questioning your opinion on
 > > large tasks.
 > 
 > But you might consider: [...] I've put my professional reputation
 > on the line, especially because it will be compared directly with a
 > previous Java version. That should tell you a lot.

Nope, tells me just about zero, *because AFAIK you haven't done it as
a Google employee*, or similar large enterprise.  We're talking about
large tasks (cf what you quoted from me).  I certainly do trust your
judgment about what's good up to the "surgical team" scale that Brooks
describes, and I know enough about Haskell to believe your out-of-
context quotes are a fair representation of the article.  I've
recommended your services to friends that in the past I gave a bum
steer to, that's how much confidence I have in you.

But once you go past that scale (and large scale is what we've been
talking about), management starts to matter.  But so far your
principles of management boil down to "hire good people" (which we all
stipulate Google does at lesat try to do) and "give them good tools"
(which Google can certainly afford to do in terms of money, including
training).  There's something going on here besides "Google doesn't
know how to manage a pack of programmers as well as Curt Sampson does."

 > You're screwed. As long as you put poor programmers on a task, you'll
 > get poor results. The solution is to increase the productivity of your
 > good programmers so you don't need to start hiring poor programmers.

That's a stopgap at best in a growing shop.  Employment tends to grow
exponentially, but productivity (of programmers as individuals) grows
sublinearly.  So at some point it's just not possible for productivity
growth to keep up with the need for installed code.  (Hel-lo,
Mr. Malthus!)

 > > It's not.  I don't know of an "Elements of Style" book, but Python
 > > people are always concerned with what's good style, and there's a
 > > rough consensus about the applicable principles of style, both for the
 > > future development of Python and for ongoing development in Python.
 > 
 > You miss my point here: Python *is* in the same situation, because there
 > aren't a pile of books out there about good Python style.

How about if I rephrase this to "You are about to take on a task that
requires you to double your team from 4 to 8 members.  How do you
teach the four newbies good Haskell style?"

[BTW, maybe there's a need for textbooks for "Java Programming Style
Seminars" where 4-letter financial firms send their coders in 20-man
teams at $2500/seat.  Agreed, that isn't needed for Python (yet, and
maybe never) or Ruby (I assume).  However, a lot of effort in the
Python community is expended on teaching style, and it's pretty
effective (at least at the level of the folks who post on Python-Dev,
who pretty much agree on everything that isn't actively controversial,
ie, new features proposed for the language but not yet implemented).]