[Baypiggies] Perot at NASA - Sr. Python Developer

Tue Jun 30 08:47:47 CEST 2009

taken from RFC 2119 ( http://www.ietf.org/rfc/rfc2119.txt ):

  In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

   Note that the force of these words is modified by the requirement
   level of the document in which they are used.

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

Perhaps the job postings on this mailing list SHOULD use this criteria ( or
a similar version ).

-Isaac

On Mon, Jun 29, 2009 at 10:50 PM, Alex Martelli <aleax at google.com> wrote:

> Not that I'm really interested (wallowing in the joy that is working
> at Google), but I think it might help you to see why somebody like me
> might not qualify by the silly standards you set out...
>
> > Our client is developing a cloud computing infrastructure.  This has the
> > backing of the federal government and they want to make it the flagship
> > (standard).  Cloud Computing is their next generation datacenter with
> > automated load following and virtual space all mapped together.
>
> Considering that I've spent the last 4+ years of my life building
> Google's cloud, one might suspect I'm qualified, but...
>
> > Python development (at least 3 years)
>
> Check, 10 years should do.
>
> > Direct experience with highly-scalable web applications (minimum 5M+
> monthly
> > unique visitors or the ability to scale to that level)
>
> 5M pageviews per month is what we *give out FOR FREE* on the Google
> App Engine (built on top of the cloud I helped build)...
>
> > Leadership experience (managing developers in a highly collaborative R&D
> > environment)
>
> Having spent most of my time at Google as Uber Tech Lead (responsible
> directly or indirectly for up to a few dozens of developers when I had
> to, though that was only when we lacked director-level personnel -- my
> boss, a senior VP, was way overloaded, so I took the people management
> load off his shoulder even though I'd much rather have been
> hacking!-), I think I could check this one
>
> > Experience with Social Media and Social Networking on the API layer
>
> Ah, that's the killer bit: while I've built clouds and managed large
> groups of brilliant developers doing so, I have ZERO experience on
> this "Social" silly thing (Google does have Orkut, which runs in part
> on infrastructure I helped build, but I nevertheless have ZERO
> experience with its APIs). So, since this is a MUST, even if I _was_
> looking for a job I would never apply for this one.
>
> In fact I'm quite loath to link my future to this "social networking"
> craze, to the point that I've repeatedly resisted facebook's insisted
> headhunting (prompted in part, I believe, by friends and ex-colleagues
> of mine who work there -- they've experienced what it means to work
> closely with me, even though I have ZERO "experience with social"
> ANYthing "on the API layer", and must have pressed their recruiters to
> keep badgering me even after several refusals on my part).
>
> It's fortunate that your conditions include this "social blahblah"
> experience as a MUST, since it means I of course won't apply and you'd
> immediately discard me if I did (or else it means you don't know what
> MUST means, which should steer ANY sensible person off this
> organization, of course).
>
> > Experience defining, implementing and refining data-driven APIs
>
> Got that (BOY do I ever), but doesn't matter since I lack your
> (idiotic IMHO) "social" `MUST`.
>
> > Experience in open source, both as a developer and an active community
> > participant
>
> Got that, in MANY projects, but again it doesn't matter given the
> meaning of "MUST".
>
> > Agile development in full product life-cycles
>
> AND that -- one of my hottest-burning passions, actually.
>
> > Nice to have:
> >
> > Development of Complex, N-tiered systems, utilizing loosely-coupled
> > components based on a message-passing architecture
>
> Got that and then some, pity it doesn't matter.
>
> > Familiarity with OAuth, OpenID and other open standards for
> authentication
> > and identity
>
> Ditto.
>
> > Familiar with EC2, AppEngine, and basic cloud computing infrastructure
>
> And ditto squared.
>
>
> So -- one single, incredibly silly MUST condition about "social mush"
> would stop ME from applying for this job even if I was LOOKING for a
> job (which, let me repeat, I ain't) -- even though I'm WAY qualified
> or overqualified on EVERY other 'MUST' _and_ 'NICE TO HAVE', *AND* a
> lot you don't even bother to mention.
>
> That's what MUST HAVE ***means***.  If I SELECT * FROM ... WHERE
> 'social' IN experience AND ... -- it doesn't matter how incredibly
> well every other aspect matches: if 'social' is *NOT* among the
> 'experience' set, the row will be entirely and totally discarded no
> matter what.
>
> My best guess is that you, and the people who hired you to post this
> job offer, are so incredibly clueless that you placed among the "MUST"
> a condiiton that's actually, at best, "very nice to have" -- not
> realizing what a HUGE difference that makes to any engineer who
> actually thinks and behave like an engineer.
>
> Good luck -- compared to the job offer you SHOULD be posting, you'll
> either get a small or mediocre set of candidates, OR people willing to
> completely ignore what you CLAIM is an "absolutely MUST have
> condition", OR... lie through their teeth. Looks like you deserve each
> other.
>
>
> Alex
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20090629/47787e8c/attachment.htm>