What’s the point of this meeting?

I’ve been trying to “reconfigure” some of the meetings for my team recently. Since I took over our primary web team, I realized there’s been a lot of things that I was maintaining but for no purpose. These were usually outdated processes that were started by someone that no longer works there or because of some rule that was assumed to be in place that actually wasn’t.

When I started looking into why some of these rules (e.g. “we can only deploy on Fridays after 6”) were there in the first place, I discovered that, for the most part, these processes were just utterly nonsensical. Taking the time to take a step back and evaluate whether or not we could improve these processes, I discovered that almost universally, we could.

This sort of Intentionality in running a team has proven so far to be beneficial. So, naturally, I applied it to meetings.

We’re a small team and all in the same room. We’ve got some customized Jira dashboards that tell us status and who’s working on what. All of us are aware of what’s going on with others, and blockers get brought up as they happen instead of the following day. Scrum’s not useful for a team for our size, so it’s out.

Pull Request reviews are good, but we can take some time on our own to review the PR before we meet. This way, a 20-minute discussion on the benefits of (a) => a+1 vs a => a+1 occurs asynchronously before the meeting instead of during it.

Sprint Reviews are theoretically useful, but questions like “so, what are your thoughts this week?” are not. Asking more pointed questions (largely inspired by the “Start, Stop, Continue” approach) like “Did you do anything new this sprint that worked well?” should help with making reviews more useful.

Changing meetings so that they are more likely to yield a more consistent result should be the goal of every person who runs meetings. No one wants to sit in a room for 2 hours arguing over the finer points of blue vs cyan when you just want this design approved. Think about the intentions behind meetings and how the questions and topics work towards those intentions. And maybe drop that meeting that doesn’t seem useful.

KeySmith: A New ActionScript 3.0 Keyboard Manager

Every time I need keyboard input in a flash application, I have three options:

  1. Use the built-in event handler
  2. Use what’s supplied (usually only for certain programming assignments)
  3. Make my own

Option 1 is not an option if I need to do anything better than check if it’s down at all. I can’t use it for anything to detect a simple button press (up this frame and down last frame) or anything more complicated than detecting if a button is down or released.

Option 2 is usually not much better and only available on a few assignments. Usually it’s only slightly better than normal and functionality can vary widely from program to program. I want a certain degree of consistency.

Option 3 has so far been the best, but is usually time consuming. I had one that I would reuse, but it was very limited without having to go and touch the base code. As the programs got more complex, it became more cumbersome as I had to work around the limitations.

I decided to make another keyboard manager, and this time with every feature I could ever practically seeing myself needing. I’ve made it as extensible and optimized as I could make it and made sure to fully document it as well.

I would like to present the KeySmith Keyboard Manager.

You can download and use it on my Projects page. It’s free for anyone to use under a Creative Commons license.