OKRs
The Beatles never set OKRs.
The Beatles never set OKRs.
I once wrote a blog post entitled Less is more. It did fairly well on Hacker News, and two people commented on the blog platform itself. I was pretty excited. (The comments weren't migrated to this platform.)
Years later, I read the following article from the Washington Post, which dovetails nicely with it. I recommend giving it a read:
We instinctively add on new features and fixes. Why don’t we subtract instead?
I know I'm late to the party, but Cory Doctorow's essay on “enshittification” is brilliant.
Here is how platforms die: first, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die.
—Cory Doctorow in Tiktok's enshittification
The Helix text editor fascinates me.
Vim has been my primary text editor for more than ten years now. (Technically, I've been using Neovim for two or three years, but for the sake of simplicity, I'll use the term Vim generically in this post. The two editors aren't that different, in the grand scheme of things, and their differences aren't relevant here.)
I think of Vim as an IDE that one builds themselves. That can be good and bad. I have a deep understanding of my editor's capabilities, for example, because I enabled many of its features myself. It's also completely free and it supports just about every popular programming language out there. However, configuring it takes time and handling conflicts between plugins can be annoying. I also find that it's difficult to keep abreast of the state of the art in text editing this way. It took me a while to discover that other people were using multiple cursors, for example, because that feature wasn't added to my editor automatically. I'm sure there are lots of other useful features I could add to Vim, if only I knew they were common in other editors. I don't know what I don't know.
Ultimately, if I were just starting out today, I'm not sure that I'd make the same investment in Vim. When command-line editing is truly required (my original motivation), Micro is a great choice, being much easier to use and more than powerful enough for most tasks. For everything else, JetBrains IDEs are pretty magical, if occasionally overwhelming.
Helix seems to sit somewhere in the middle. It's console-based, with modal editing and Vim-like keybindings, but with Everything Everyone Wants built-in: LSP, tree-sitter, fuzzy-finding, etc.
I'm not sure which editor I'll be using in ten years. Maybe I'll still be using Vim because it's comfortable, or JetBrains because it's straightforward. I'll add Helix to the list of contenders, though.
I support Signal's decision to drop support for SMS and MMS. Software maintenance can be incredibly challenging and time-consuming. This decision will likely free up time for more important work.
John Carmack is rumored to have said, “Focus is a matter of deciding what things you're not going to do.” I'm not sure if the attribution is correct, but it doesn't matter. It's a good point.
Contrary to the opinions shared on Hacker News, the world is not going to end. (Hacker News readers often forget that they are not the target market.) If anything, it might be easier to convince others to use Signal now. “Use this app to have private conversations with other people who use the app. It doesn't change how anything else on your phone works.” In a world that remembers rouge software crashing computers, that fact is more important than it might seem.
Besides, abbreviations rarely correlate with usability. Signal needs to reach normal people. Let's keep it simple.
Last week, I read the bizarre story of Governor Mike Parson of Missouri vowing to prosecute local journalists who notified his office of a data leak in a state website. In a press conference, he claimed that the reporters “decoded” the site's HTML in a “multi-step process,” struggling to pronounce the unfamiliar abbreviation and testing the credulity of his technologically-literate audience. (Does clicking View source involve more than one step? Perhaps among those who find mice to be confusing.)

As someone who started a career by clicking View source, I couldn't let this weird, funny, aggravating news story go. After calling the governor's office to call his actions, “respectfully, moronic,” I decided to create a change.org petition asking him to apologize, which I have copied below.
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.