Reflections

softwaredevelopment

The best design is invisible.

In most music apps, I inevitably leave shuffle mode on for longer than I'd like. I might enable it when listening to a playlist. When I later listen to an album, I might get halfway through before realizing shuffle is still enabled and the songs are playing out of order.

This never seems to happen on Spotify, however. Spotify seems to automatically disable shuffle whenever it's no longer wanted. I don't know what heuristic Spotify uses to determine when shuffle should be disabled, and as a user, I don't really need to care. All I know is that shuffle never seems to be on when it shouldn't be.

#SoftwareDevelopment #Technology #Usability #UserExperience

The Beatles never set OKRs.

#Business #SoftwareDevelopment

I once wrote a blog post entitled Less is more. It did fairly well on Hacker News, and two people commented in situ. I was pretty excited. (The comments weren't able to be migrated here.)

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?

#Business #PersonalDevelopment #SoftwareDevelopment #Technology #Usability #UserExperience

I've been using Android for more than ten years now. I originally chose it in an ethical commitment to open-source software, but it's become less open over time.

Some people might be surprised to learn that I think Apple makes better products. Apple understands usability and user experience better than almost any software company, they pay exceptional attention to detail, and they've done genuinely important work on privacy. Still, they're not perfect. I think Apple too often prioritizes form over function, with the overuse of gestures being a good example, they lock users into their ecosystem, they position their products as status symbols, and they don't play nicely with others. In my opinion, they also market privacy more effectively than they actually protect it.

As an aside, I'm disappointed that Apple has become “the privacy company” when Mozilla should have claimed that title long before them. In hindsight, Mozilla may have been mistaken not to strike while the iron was hot in June 2013. Of course, it's easy to play Monday morning quarterback; it's harder to be in charge. At least Mozilla is doing great work on privacy today.

In any case, I'm considering making my next phone an iPhone, but switching now would be a hassle. Vendor lock-in is real and Google is almost as guilty as Apple. Interoperability matters.

#Business #SoftwareDevelopment #Technology #Usability #UserExperience

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.

#SoftwareDevelopment #Technology #Usability #UserExperience

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.)

Read more...

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.

Read more...

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.

Read more...

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.

Read more...

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.

Read more...