javascript

The teams I manage at work pride themselves on moving quickly. We release features, adjust UI, and run experiments at a rate where it is difficult to follow everything which is going on. I see one of my responsibilities as a manager to keep up this pace of execution, but in a way which holds a high bar for quality and allows for feedback from stakeholders who aren’t following every design discussion or code review.

We had a problem of the sort where an engineer would make some kind of change and then later on get asked “why did you turn this on?”, “why didn’t you tell X?”, “did you consider A, B, C?”. This was adding uncertainty to the development process - engineers would be uneasy about rolling changes and felt pressure to get buy-in from every stakeholder before shipping even small modifications to the software.

I wanted my team to feel safe following a product development process where they wouldn’t get second guessed or called out if they did things the agreed-upon way. Using my favorite productivity tool prototyping platform (Google Apps), I created a form which would handle collecting the details of planned changes, format things nicely, and notify all appropriate stakeholders. We have an agreement with the team now that engineers are “covered” making changes as long as they fill out the form as soon as possible during the development process. If an engineer uses the form, ships a change, and then someone has a problem with how the feature was shipped or communicated, then I intervene and walk the stakeholder through our tracking process. This has been a great step toward making engineers feel more empowered to ship changes, giving stakeholders a concise summary of upcoming changes, and has the side effect of creating a clear log of everything our teams are contributing.

I’ve gotten some interest in this internally from other teams, and I think it’s a generally useful tool for any team of software engineers. I’m going to walk through how it works and was built, with the hopes that you may find something like this useful in your development process.

I’ve been working on a small interactive iPad experience for my daughter Ada. I wanted to create a world where objects would respond to touch, break apart, and evolve into different forms. She’s limited to a slappy/flailing motion and I wanted the game playable with only these rough moves. Gestures such as pinch-to-zoom or even panning the camera purposefully would not be appropriate. My v1 build therefore added a camera which zoomed to focus the most recently touched item. This worked well with my (more purposeful) testing, but zoomed around crazily once Ada got her hands on it.

Twitter’s Javascript-based third party offerings include buttons and embedded content, which are handy for putting Twitter content into your website. Unfortunately, they break when included in a Chrome extension, due to the use of protocol-relative URLs. Luckily there’s a way to fix the problem, although it requires a bit of extra code.

Since starting my job at Twitter, I’ve spent a lot of time on dev.twitter.com, either reading documentation or posting on the discussion group. I’ve also been Tweeting a lot more, and I tend to switch back and forth a lot throughout the work day. My browsing habits tend to lead to a bunch of open tabs in Chrome, and I realized that I was losing productivity.