Last year I wrote a post for the Shopify engineering blog on the subject of Modelling Developer Infrastructure Teams. I figured I should link to it here as well. I’ve had several industry peers reach out to me to exchange notes on building dev-infra teams, so it seems the topic resonated with some people!

The last Raspberry Pi that I bought (the one that powers my ledweb setup) came with a remote control intended for media servers, one of the official OSMC remotes. I thought it would be fun to use it to do something involving my LED panel, like switching between different modes or something. I couldn’t find any information on using this remote outside of OSMC, however. I’ve never done any programming that interfaced directly with a USB device either....

Something I regularly tell my daughter, who can tend towards perfectionism, is that we all fail. Over the last few years, I’ve seen more and more talks and articles about embracing failure. The key is, of course, to learn from the failure. I’ve written a bit before about what I learned from leading the MozReview project, Mozilla’s experiment with a new approach to code review that lasted from about 2014 to 2018....

I’ve discussed and linked to articles about the advantages of splitting patches into small pieces to the point that I don’t feel the need to reiterate it here. This is a common approach at Mozilla, especially (but not just) in Firefox engineering, something the Engineering Workflow group is always keeping in mind when planning changes and improvements to tools and processes. Many Mozilla engineers have a particular approach to working with small diffs, something, I’ve realized over time, that seems to be pretty uncommon in the industry: the stacking of commits together in a logical series that solves a particular problem or implements a specific feature....

This is the last post in a three-part series on A Vision for Engineering Workflow at Mozilla. The first post in this series provided some background, while the second introduced the first four points of our nine-point vision. The Engineering Workflow Vision (continued) 5. Reviews are straightforward and streamlined The Engineering Workflow team has spent a lot of time over the last few years on review tools, starting with Splinter, moving into MozReview, and now onto Phabricator....

In my last post I touched on the history and mission of the Engineering Workflow team, and I went into some of the challenges the team faces, which informed the creation of the team’s vision. In this post I’ll go into the vision itself. First, a bit of a preamble to set context and expectations. About the Vision Members of the Engineering Workflow team have had many conversations with Firefox engineers, managers, and leaders across many years....

The Engineering Workflow team at Mozilla is happy to announce that Phabricator and Lando are now ready for use with mozilla-central! This represents about a year of work integrating Phabricator with our systems and building out Lando. There are more details in my post to the dev.platform list.

The OED’s second definition of “vision” is “the ability to think about or plan the future with imagination or wisdom.” Thus I felt more than a little trepidation when I was tasked with creating a vision for my team. What should this look like? How do I scope it? What should it cover? The Internet was of surprisingly little help; it seems that either no one thinks about tooling and engineering processes at this level, or (perhaps more likely) they keep it a secret when they do....

Having taken advantage of a Black Friday sale at BuyaPi.ca and picked up a Raspberry Pi 3 Model B, I then needed something to do with it. I’m not sure how it popped into my head, but at some point I realized my bar absolutely needed a Times Square zipper-type LED display. I mean, it seems so obvious in retrospect. At first I thought about making one but then I thought “hahah yeah right no”....