Tips for planning a high school reunion

TuHS class of 2006

Having never planned a high school reunion before, here’s a non-exhaustive list of things I wish I had known in advance:

  • Pick a date about 9 months in advance, announce it, and then don’t think about it for 7 months. You don’t need to spend 7 months meeting, discussing, and meeting again. The last two months are sufficient for pulling all of the details together.
  • Convince 5-10 people to volunteer. Even if you think you can do all of the work, getting buy-in from others means there are other people with a vested interest in making the reunion a success.
  • Choose a venue that’s a good fit for a high school reunion. We ended up at On Deck Sports Bar and Grill, which regularly hosts reunions. This was awesome, because it meant they already had some of the logistics covered.
  • Rent a couple sets of cornhole. Ladder Golf and giant Jenga are fun too, but cornhole seems to be the winner for parties.
  • Put conversation starters on the name tags. Make them fun, and not offensive, to make them a good entry point into re-meeting someone you haven’t talked to in 10 years.
  • As a host, put extra effort into circulating, striking conversations with people, and making people feel welcome. Everyone initially feels super awkward about being a high school reunion. If you can help them break the ice, they’ll get into enjoying the party much quicker.
  • Purchase a pony keg to keep the alcohol flowing for those who want to keep drinking after their drink tickets run out. I think offering the pony key was the right balance between not having enough drink tickets, and everyone getting smashed.
  • Put a little bit of effort into decorating to make the venue feel special. We had a banner, “Welcome Tualatin High School Class of 2006”, and some light decorations at every table.

We had a ton of fun last Saturday night. I’m super glad I volunteered to help out (I wasn’t on ASB or anything). And, now I know what’s involved for next time!

 

Post-Mortems at HubSpot: What I Learned From 250 Whys

Post-Mortems at HubSpot: What I Learned From 250 Whys:

This is a somewhat specific detail, but it comes up a lot, so I wanted to pull it out. If you run a bunch of 5 Whys, you’ll find that a lot of times, the developer who made the first-order mistake (forgot to copy configs from QA to Prod, or deployed two apps out of order, or whatever), will say “Look, this was totally my fault, I screwed up, that’s the whole story. I’ll be more careful next time.”

The very short summary of which is: We’re going to fix this problem by being less stupid in the future.

Which, well, you can guess how that’s going to turn out.

Why do some developers at strong companies like Google consider Agile development to be nonsense?

Why do some developers at strong companies like Google consider Agile development to be nonsense? Most points resonate — particularly this one:

10. Simplicity–the art of maximizing the amount of work not done–is essential. – Most teams simply don’t spend enough time on this. A sense of urgency often overrides careful planning. The problem here is careful planning makes things get done faster. During the planning stage it feels like you’re not getting anywhere, but you are setting up for a quick sprint. This setup is often overlooked, and we end up with not only complicated software, but complicated development habits, complicated code, and generally poor software design. This slows down maintenance and new development, as we try to fit into poorly designed structures that become ingrained and impossible to improve.

Malcolm events

Management is the care and feeding of the invisible. You’re doing your best when it appears the least is happening. I love the thrill of the last month of a release as much of the next guy, but I suspect the reason we’re yelling at each other, working weekends, and feeling the depressing weight of compromise is because we’re surrounded by Malcolm events [, seemingly insignificant events that are intent on screwing you in an unlikely way.]

Michael Lopp — Managing Humans