Thanks for the feedback!
I wish I could offer hard-won advice about overcoming objections and trying a new thing.
But as a consultant (or on a coding tour) I’m an outsider.
That means I’m playing “influence people’s behavior” on easy mode.
It was even easier than usual at BREDEX, because Alex had planted seeds of mob programming a while ago, a couple teams had even already tried it, and she had prepared everyone to understand what it would be like and when they’d be doing it.
When people aren’t sure they want to try something, or are sure they don’t, I haven’t found it effective to try to talk them into it.
Listening to them, if they’re willing to explain why not and explain it to me, can help — provided I promise not to try to persuade them, only to try to understand their point of view.
I always want participation to be voluntary.
If what some of us are doing looks fun and effective — and mob programming quite often does — some folks who were on the fence may decide to come watch.
Maybe even try it.
That’s the best overcoming-objections advice I can give, on any subject.

My best advice for introducing a team to the concept:

Remove any feeling of delivery pressure (for instance, by making clear there’s slack in the schedule)

Choose a real problem the business needs solved

Choose one that’s relatively complex, such that most folks on the team would not want it assigned to them alone

Have a whiteboard for writing down whatever you notice as you go (as mentioned above)

Two hours a day is a lot; leave plenty of time to decompress and continue working in other ways

Be ready for what might happen when team dynamics go under the spotlight

Be ready for what might happen when an impediment comes up, because it could block the entire team

Bring in an outsider who’s an experienced facilitator, if you can

Else become one as quickly as you can, leaning on The Mob Programming Guidebook (Pyhäjärvi and Falco) for what to pay attention to and patterns that have worked

I’m probably forgetting something.
Get the book.
It’ll fill in the gaps.
Best of luck, and let us know how you get on!

Very much enjoying this series! Hearing about all the mob programming opportunities is making me very jealous. Thankfully I have my own plans in the works to train some newbies with mob programming. Would love to hear more about how the mob programming went, especially how you overcame objections and tactics for facilitating groups who are new to the concept.

After limping through a few manual Let’s Encrypt renewals —
sometimes too late — I’ve scripted it with
acme-tiny.
Each user that wants SSL creates $HOME/.letsencrypt.
For each site that wants SSL, they create letsencrypt/{cert,service}
subdirectories.
A shared lighttpd config fragment handles the Let’s Encrypt challenge URL.
letsencrypt/service/run looks like so:

Most sites provide only one argument to letsencrypt_create_or_renew.
This service directory is then symlinked into $HOME/service.
Since my system upgrade script runs svc -t /home/*/service/*
(as threatened in the previous comment), these run scripts get restarted
approximately once a week.
If I skip a system rebuild, that’s fine for SSL purposes:
letsencrypt_create_or_renew doesn’t bother talking to Let’s Encrypt
servers anyway, unless the cert is more than 15 days old.
Once a month, a system cronjob restarts all SSL-aware services, thereby
reloading any certificates which may have been updated.
Since Let’s Encrypt certs last 90 days, this is probably more than
enough automation.
I’ll check the logs (and cert expiration dates) in a month to make sure.

When I upgrade my server every week, one of the things I haven’t been doing is to restart all the various site-specific web server instances. Since they started from cron via @reboot entries, I hadn’t given myself a programmatic way to bring the processes down (or back up).

I’m a big step closer, because the crontab entries have been replaced with daemontools. My setup: