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

["Curt J. Sampson" <cjs@example.com>]

On 2021-11-11 04:26 +0000 (Thu), David Blomberg (dblomber) wrote:

> I was wondering if anyone here has been part or used TDD (coding Dojo)
> and/or hack-a-thon type of environments as a way to bring together
> beginner, middle, and experienced programmers to learn and practice
> programming skills.

Yes. Many years ago I was at a couple of Tokyo Rubyist hacking events that
did this. The two things I learned were that a) you do _not_ do well when
you pair English-only speakers with Japanese-only speakers, and b) not one
single industry programmer from a fairly large sample had a clue how to
write a parser (ouch!).

As for "practicing programming skills," I don't think this really happens
when you have mixed-level groups. What you get is either the juniors
absorbing whatever they can as the senior folks actually do some learning
or the senior folks becoming teachers. (Having to each _can_ help an
experienced person learn more about what she does, but I don't find that
the "pair program for a couple of hours" thing really does that.)

>    If so how do you think the general buy in would be for this? Do you
>    see an attrition issue as being a serious problem?

I'm not sure what the experienced folks get out of it. Remember, software
development is not like being a musician or an athelete where you repeat
and refine certain actions to get better: you become more productive by
programming a computer to do repeated things, so the main "skill" you need
is to continue doing new original work that you've not done before. (Well,
I'm sure that there are lots of programmers out there who just want to do
the same thing over and over again, but that's not the kind of thing we
want to be teaching to beginners.)

What I think might be useful is to have junior developers pair with senior
ones on actual programming projects where actual development's being done.
Sure, this puts many of the juniors in "absorb" mode, but in my experience
there's a _lot_ of stuff that cannot be taught at all through telling or
explanation but only through showing how it's done many times until the
general idea starts to sink in. ("Reference to the Dreyfus model of
learning--drink!") One example would be, "A series of commits should tell a
story." That's easy to say, but getting there, especially since it usually
involves a lot of rebasing, means that even if you have seen several
examples of the final result you're not likely to have gotten from that any
idea of how to get there.

> Keep it short (make sure not to exceed an hour stretch)

I think you could do a couple of hours without problems, too. But more
important for the juniors, I feel, would be to spend a good number of hours
(ideally a dozen or more, but of course spread out over many days) working
on one project. Software development is not a disconnected series of katas
or other small actions, and it's being able to make sure you're at least as
productive (if not more) a month or two from now as you are now, and
continuing to maintain or increase productivity, that distinguishes the
good software developers from the bad ones.

> Or, does anyone know of any active groups doing this right now? (why
> reinvent the wheel)

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.

I have a backlog of a half dozen Python (or should-be-Python) applications
that want work, if you're interested in that kind of thing.

On 2021-11-12 22:39 +0900 (Fri), Edward Middleton wrote:

> I understand the idea of Coding Dojo's but it always felt to me like you
> could get the same experience working on problems that you really cared
> about rather then contrived problems designed to fit the format.

I think it's a very different experience if you're working on actual
software meant for people to use. I also think that's more valuable.

> I spent a lot of time prepping for the silly coding tests they give you as
> parts of job interviews and while I got pretty good at doing interview
> questions they aren't really useful skills that transfer to anything other
> then interviews.

Bingo!

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. This goes back to replacing explanations of
what we experienced people think happens (which we all know we actually
just make up) with letting the junior watch what _actually_ happens. And
that's how the Dreyfus Model of Learning (drink!) works, too: especially at
the early levels you need to tell beginners, "just do this." (The idea
being that after they've repeated the action a half dozen times without
understanding, only then does the understanding start to come to time.)

> ...said she never understood for loops until she made the lights blink
> different colors.  (insert WTF emoji here) I have no clue how she can
> feel that way :-)

That's simple. She hadn't yet been indoctrinated into the modern
programmer's screwy orthodoxy and, being naïve, didn't understand that
simple recursion was to be treated as a terrible thing to be feared and the
far more complex and less general "for" and "while" loops must be hailed as
the "easy" thing.

> I wonder if Curt (or any other of the folks who do hardware whether as a
> product or retrocomputing) have similar stories?

Not really, no. Understanding all the layers of hardware has been
incredibly valuable to me, and really honed my intuition for what's going
on, but this doesn't seem a parallel situation. After all, on the hardware
itself, in machine-language, we don't have "for" loops; we have "goto" and
"if ... goto", and that's it. All that "for" loop stuff is a bunch of
software performing magic to turn the former into the latter.

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

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