[Python-Dev] How do we tell if we're helping or hindering the core development process?

[Nick Coghlan]

On 29 July 2015 at 00:17, Ben Finney <ben+python at benfinney.id.au> wrote:
> I've made a clear distinction between the need to *be able to* justify a
> change, versus arbitrary demands to do so by arbitrary members.
>
> The latter is what you're arguing against, and of course I agree. I've
> never advocated that.

The thing we work toward as core developers, and aspiring core
developers, is good design intuition that aligns with the Zen of
Python. That doesn't mean we're all going to be able to perfectly
*articulate* that intuition in every case, and even when we can, those
explanations are themselves generally going to be backed by intuition
rather than rigorous scientific research.

Perhaps we need a new initialism to summarise these kinds of cases in
a way that isn't dismissive of the concerns of folks that still have
doubts about a decision: LTIASHIG (Let's Try It And See How It Goes)

It's important to remember that *having* good design intuition is a
*separate* skill from *explaining* design intuition well. The former
involves being able to bring personal experience to bear on a design
task, and produce a result that a non-trivial subset of people enjoy
using. The latter involves things like learning a lot more about human
cognition, and why certain concepts cause the human brain to get
jammed up, and how the way a programming language models a particular
domain relates to how folks learn about that domain in the first
place.

One of the best engineers I ever worked for (my first full-time boss)
had *brilliant* design instincts, but was substantially weaker when it
came to explaining the rationale for his decisions. Spending a few
years figuring out why the software architecture he designed was such
a good one turned out to be one of the most valuable learning
experiences of my life (and, not coincidentally, was my original
exposure to the "communicating sequential processes" approach to
concurrency and parallelism).

CPython core developers have *real authority* as *individuals* over a
language ecosystem used by millions of people. That's a large part of
why we're relatively cautious about handing out commit bits - it's not
just about the technical aspects, it's about developers' design
judgment, and intuitions on when things should be escalated for wider
discussion *before* making a decision. Sometimes that intuition is
going to tell us "this change is worth the risk, even though I can't
fully explain why I think that, and hearing further opinions without
supporting evidence isn't going to change my mind" . Having someone
willing to make that kind of call is one of the big reasons modules
with an active lead maintainer can more readily evolve than the
collectively maintained modules that don't have an authoritative voice
guiding their API design.

And when we make genuine design mistakes (as we inevitably will)?
That's one of the things the deprecation process is for: if a mistake
is actively causing problems for folks attempting to use a feature,
then we have options to deal with it, rather than having to carry it
forever. In many cases, we can even go with a better approach, where
changing our minds later involves making a *backwards compatible API
change*, reducing the practical long term design risk of postponing a
particular aspect of a decision to near zero.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia