I was laid off last week. Officially, I was impacted by “significant restructuring”. I never expected to become so conversant with corporate lingo. It's one of the lesser skills I acquired during my 8 years at Mozilla, mostly after Firefox OS was announced as a priority. Another lesson: companies change.

Driven by COVID-19 and the resulting economic downturn, the layoffs affected fully 25% of all employees, including long-time teammates and friends. As in the previous round of layoffs, some of the people affected were among the most passionate and talented people I have ever known. It's unfortunate that they could not all be retained.

I have come to appreciate ESLint very much in recent years. A robust and reliable JavaScript linter, ESLint can be used not only to detect common programming mistakes, but also to enforce a consistent code style. Its utility cannot be overstated. Your teammates and your future self will thank you for using it.

I recommend that ESLint be enabled before any code is written, but what about existing projects? A developer who runs ESLint on an existing codebase will certainly be overwhelmed; it will warn about scores of issues which had not been noticed until that point. Is there any way to gradually adopt its recommendations? More importantly, is there any way to prevent the number of problems from growing? Running the linter on CI is no solution. It will simply fail and annoy others.

I recently started work on a project at Mozilla which I’m calling Ensemble. Ensemble will be a minimalist data-sharing platform. It will allow data scientists to quickly and easily create public dashboards with no web development experience.

In the process of writing a project README, I realized I had accidentally written something like my software development manifesto, the distillation of my thoughts on creating valuable software. The document does discuss some specifics of this project, but the broader points apply more generally.

When writing software, we should approach our own ideas with skepticism. We have more ideas than users have needs.

Features do not guarantee success. If they did, we would line up to trade smartphones for punch cards. Myspace would acquire Twitter. Picasa would be the new Instagram. This doesn’t happen. The history of software is the history of simplicity and elegance winning. We succeed when we attend to what really matters, not when we build every feature imaginable.

We use Optimizely on the Mozilla Developer Network to build and analyze split experiments. We find that the tool helps us move forward with confidence, understanding how changes affect user behavior. We care about accuracy and user experience, so we were concerned when we discovered a problem in a recent experiment that could have affected both.

Update: This technique no longer works because the Twitter favicon is no longer hosted from the twitter.com domain and the ?redirectafterlogin query parameter only works with resources on the twitter.com domain.

In Detect if visitors are logged into Twitter, Facebook or Google+, Tom Anthony explains how to determine what social networks your users are logged into. The approach Tom recommends still works today, but the Twitter code needs to be modified to work as expected.

I often recommend that software developers become familiar with the fundamentals of usability — we are all designers, whether we know it or not. But this takes time. When we are not able to design usable interfaces ourselves, then, it can be wise to rely on frameworks, conventions, and other resources that make design decisions on our behalf. What happens when those resources lead us astray?

The HTML5 specification allows developers to add new items to the context menu. This ability can be useful, especially as the line between web application and native application becomes blurred. But the specification is silent on one very important consideration — placement of custom menu items. Only the following guidance is offered to implementers: