DEV Community: Andrew Petro

'Agenda bash' defined

Andrew Petro — Fri, 05 Nov 2021 14:12:45 +0000

Agenda bashing is when a group creates or updates the meeting agenda at the beginning of the meeting.

Why this post

I'm convinced "agenda bash" is an existing term of art. However, when I tried to cite a reference defining it, I didn't immediately find a clear definition of it online to reference. Googling a bit, I do find usages of it in e.g. IETF slideware and meeting notes. The usages seem to take it as a term of art already understood by the audience.

Therefore I'm writing a post defining "agenda bash". Be the Web content you want to see in the world, as it were. (Or maybe this is citogenesis.)

Agenda bashing does not preclude prior agenda drafting

Note that the agenda bashing practice doesn't preclude already having an agenda for the meeting. Coming into the meeting prepared and with shared expectations is usually a good thing. Where there's already an agenda, the bashing is more about validating that the agenda is still valuable, that the gathered people are prepared to engage that agenda fruitfully, and triaging whether there's something urgent or relevant that should be slotted into the agenda.

Agenda bash with caution or not at all

Of course, agenda bashing is more or less appropriate in different situations. In public service, open meetings, Roberts Rules kinds of situations, changing the agenda may be a terrible idea. If someone not at the meeting relied upon that agenda in deciding not to attend, or if people would have prepared differently had they known the agenda would be different and that missed preparation opportunity is important to them, then bash with great care or not at all.

Sometimes the thing to optimize for is fulfilling expectations and following the plan, even if the plan is no longer ideal. Surprise can be unpleasant.

Agenda bash with joy

If it's a working session, a conference gathering, something less formal, then maybe the thing to optimize for is doing the most important/urgent/ready work available at that time. Do the work that seems to benefit most from the immediate collaboration of the people present.

It might be that the time you know most about what you're prepared to do in the meeting, is the time of the meeting.

Surprise can be delightful.

Cover image credit: Benjamin Child on Unsplash. Text description: photo of a modern-looking meeting room emphasizing chairs.

Authoring commit messages

Andrew Petro — Tue, 31 Mar 2020 13:44:55 +0000

Great writing is intentional. It considers the needs and expectations of the reader.

Commit messages are writing.

Commit messages are great when they're intentional, considerate of the needs and expectations of the reader.

Who's the reader?

The reader is future you. Or future me. It is colleagues reviewing a Pull Request. It's a release engineer trying to verify and summarize the changes that will go into a release. It's someone troubleshooting trying to find when an unexpected change may have been introduced. It's a team member try to catch up on changes to a product.

Write great commit messages.

That automatic message stub that GitLab generates for you? It's not great.

Update Deployment.md

Don't focus on what file you changed. That's apparent from the substance of the commit, from the diff. Rather, focus on the meaning of what you changed and why you changed it.

Better:

Add checklist step to post in Service Operations channel

This post is less about directly telling you how to do this, and more a place where I can collect annotated links about this.

Succinct advice about writing commit messages: A Note About Git Commit Messages
Reinforcing the present-tense imperative norm: Writing Git Commit Messages
Advice on writing commit messages, and also more generally about composing git commits: How to make good Git commits

Cover photo credit: Photo by NihoNorway graphy on Unsplash

31 character password length limit in Mojave

Andrew Petro — Fri, 10 Jan 2020 17:06:44 +0000

Today I learned that Mojave has a 31 character password limit.

In general I like long random passwords managed in a password manager.

However, there are a few passwords that I find I have to type frequently. The password to access the password manager itself. The single sign-on paasword. These I like to be long passwords easy to remember and type but difficult to brute force.

While the single sign-on system at issue generally supports a longer maximum password length, it turns out using a length longer than 31 characters is a way to lock myself out of my Mac. Trimming the password down to 31 characters fixed it.

Mostly leaving this post as a note to myself for next time.

Cover image credit

To a new, ill colleague

Andrew Petro — Wed, 16 Oct 2019 14:05:48 +0000

It takes courage to rely upon humane culture, especially when vulnerable.

Alice,

Feel better soon.

Thanks for taking the sick time rather than dragging yourself in.

Culture is what we do. The way to strengthen a culture of supporting people resting and recovering when they're sick is to do it. I appreciate it can be especially uncomfortable to be new, and I appreciate your taking care of yourself (and minimizing spread of the plague) anyway.

When you are well and back in, I hope I'll have opportunities to help you bounce back here at work.

As ever,

Andrew

(Alice is a pseudonym).

Post cover image credit: Kelly Sikkema via Unsplash

Hi, I'm Andrew Petro

Andrew Petro — Mon, 03 Oct 2016 20:41:40 +0000

I have been coding for a number of years.

You can find me on GitHub as @apetro

I live in Madison, WI.

I work for UW-Madison.

I mostly program in these languages: Java.

I am currently learning more about Clojure and Rust.

Nice to meet you.