Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] QQ - consider it a poll (TDD)



On 2021-12-11 18:09 +0900 (Sat), Stephen J. Turnbull wrote:

> Curt J. Sampson writes:
> 
>  > I know of various groups that sit down to "study" things, or talk
>  > about them, or whatever. I don't know of any groups that regularly
>  > get together and do real programming on real programs on a regular
>  > basis.
> 
> They're called "open source software projects," no? ;-)

Well, I've yet to see one where pair-programming is even a regular thing,
much less the norm.

>  > On 2021-11-14 03:48 +0900 (Sun), Stephen J. Turnbull wrote:
>  > 
>  > > It takes a couple of senior people with serious volunteer spirit
>  > > to onboard the newbies rather than dive right into the hacking,
>  > > but in my experience work gets done and people have a lot of fun.
>  > 
>  > Honestly, I'm not sure that things wouldn't work if instead of
>  > significant "onboarding" you instead had the newbies "trail"
>  > developers doing actual work and pick up what they can.
> 
> I'm pretty sure it doesn't work that way.  I've done sprints as
> "senior" with GNU Mailman and as "junior" with Python core and a
> couple of other random sprints.  A lot of "real work" has to do with
> "our way of doing things" and "how to get the source code," and that's
> not something you pick up by trailing the core developers for whom
> "our way" is second nature and "the source" is already in a local git
> repo.

I'm not sure I see why you wouldn't pick that kind of stuff up from
trailing a developer experienced with that project, so long as they're
actually doing those things.

The "how to get the source code" (and unmentioned but even more vital, "how
to build the source code") bits are fairly easily covered by starting not
with the checkout you've been working on for ages, but pulling down a new
checkout on a fairly "clean" system (ideally, the trailer's system) that
doesn't have all the random external dependencies already installed.

In my world, all you need to do is `git clone ...` and then `./Test` in
that repo, and that top-level build/test script will fetch and build any
dependencies needed or at least inform the developer in some reasonably
comprehensible manner what she's missing. Having senior developers
regularly deal with getting a "fresh" build running will encourage them to
make their build systems work like this so that it's easier for new
developers to get going. The biggest issue with most build systems, I feel,
is that when something's missing developers often do whatever local hack is
needed to get things working (e.g., go talk to Joe who says "go install
this thing on your development system") and then move on, without ever
getting that information back into the repo itself.

As for "our way of doing things," that's exactly what you see as you follow
someone doing actual work on the code, is it not?

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch


Home | Main Index | Thread Index