I’ve been using OmniFocus for task management for at least a decade. In all that time, I’ve struggled with getting a key part of GTD right. The intention behind any task management system is that you put all your stuff in there so that at the exact moment you need it you find it. When it works, it’s the kind of magic that leads to having a truly “trusted system”.

I am diligent about putting items in the Inbox, tracking them, moving them into projects, setting defer dates, and reviewing regularly. But, until recently, I didn’t have a good answer for how I figure out what to work on next. Ideally, I’d have a view that shows me everything that’s “On Deck” and from that I can choose from the most important or the items I have the capacity to work on. But every time I tried to make something like this work with Custom Perspectives, I’d find myself falling back to going through all of my projects one-by-one hunting for things.

The magic of important items floating to the top just wasn’t happening. But after some experimentation, here’s what I’ve landed on. My primary perspective:

• Shows me the critical projects. I start with projects within my “Work” folder or a handful of hand-selected projects that I know I want to see.
• Only shows me stuff that’s marked as “Available”. I get a lot of use out of defer dates to keep things that I can’t act on out of my head. This is also an easy way to push something a few days or a few weeks forward if I know that I’m just not going to deal with it right now.
• Shows me due soon or flagged. I want to see these no matter where they are in my system. I don’t want to feel like I might miss something, so anything with a due date coming up needs to be in my focus.
• Only shows me projects that have actions in them. I want things that I can do something about right now. For projects that have no actions, I’m counting on regularly reviewing them in the Review perspective to make sure I’m moving forward on them. But, when I’m working, I’m in a different mode than trying to figure out how to break down a project.

This perspective has also taught me the value of something that I seem to have been missing for years of working with OmniFocus. Because I’m so used to going into each project hunting for actions, I’ve missed out on the ability that OmniFocus has to show you multiple projects at the same time. I don’t know how I’ve really devalued this so heavily.

I was looking at all of my projects individually, one at a time:

But with OmniFocus, you can look at the and modify whole group!

This means that if you get the perspective right, you end up with a heads up display of everything you need to accomplish. I’ve always thought that the way to get the benefits of working across projects was with tags, but this view coupled with the perspective above, is finally a good fit.

I’m a big fan of larger frameworks like Django or Rails or UIKit. I know there’s a bit of a war between the folks who like the out-of-the-box kitchen sink frameworks and those who want to mash together their own framework from a series of libraries. I find that most projects (even in the microservices world) approach a size and scale quickly that makes the larger frameworks worth it. Otherwise, I often end up reinventing stuff that has been done better by people way smarter than I am.

However, I recently got a reminder that sometimes small tools built from libraries can be elegant.

I just moved this blog from blog.benjohnson.ca to benjohnson.ca. And in the process, I need to properly handle HTTP redirections for SEO and to generally be a good web citizen. But, I host my blog at micro.blog, and they don’t have redirection logic built in. I figured it wouldn’t take long to spin up a small redirection service that I could host at the old domain to send traffic to the new one, and that Express might be the right fit.

It took 5 minutes and 9 lines of readable code:

const { URL } = require("url");
const express = require("express");

const app = express();

app.get("/*", (req, res) => {
  res.redirect(301, new URL(req.url, "https://benjohnson.ca"));
});

app.listen(process.env.PORT);

I’m sure I could solve this with a shorter Nginx config or do it with a bigger framework, but it’s hard to beat the simplicity of 9 lines of readable and understandable code that can be run with node index.js in a Dockerfile. I even took an extra few minutes to add tests.

JavaScript has never had a great kitchen-sink web framework (though some have tried). There’s a bazillion libraries on npm and most people in that community are in the Libraries Are Better™ camp. I tend to give the community side-eye for this attitude, but this small project has been a good reminder that, of course, everything in programming has tradeoffs.

As much as we’re all going to need to watch our subscription counts, I’m looking forward to the world of subscription publishing Ev describes here.

Anything that increases the quality of journalism is something to be excited about. The resurgence of the Washington Post after Bezos’ purchase is, I think, evidence for the power of what stable revenue can do for publishing. Technology isn’t a good replacement for a lot of talented and motivated reporters.

That said, I don’t think it’s likely that this does much to address media polarization. Maybe with better journalism we get more of the rational middle, but if I had to bet I’d put money on these content bundles and subscriptions coalescing around political extremes.

This also doesn’t do much to prevent the death of local news. Though, maybe at scale that is a problem technology can solve.

RescueTime suggests that peak programmer hours are on average between 2pm and 6pm. This aligns with my experience that we need a solid ramp up period before being productive developers.

Once programmers have gotten going, interruptions are incredibly destructive to the tune of at least 15 minutes to ramp back up depending on memory load.

The ramp up period is so important and the cost of interruptions are so high that it’s important to find ways to defend your uninterrupted time. Book periods of work on your calendar, put up Do Not Distrub signs, get out of the office, etc.

It’s also really important for managers to monitor and defend their report’s time. If your manager isn’t doing a good job with this, it’s a good idea to talk to them about ways that they could help.

Of course, the relevant comic.

There’s been a bunch of discussion about Mark Gurman’s article on Apple working on a single user experience for iOS and Mac apps. We’re not entirely sure what Apple intends here, which is leading to a lot of concerned speculation. One take (summarized well in John Gruber’s article on the subject) is that this will cause developers to port their iOS apps directly to the Mac, resulting in a mass influx of poorly designed Mac apps. “Write once, run everywhere” has never gone well.

I’d like to propose a possible middle ground suggested by React Native:

It’s worth noting that we’re not chasing “write once, run anywhere.” Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. We call this approach “learn once, write anywhere.”

React Native allows developers to write cross-platform iOS and Android apps, but it suggests that developers ship a different UI for each platform. It aims for parity of framework feel over parity of user interface. With a set of tools and frameworks that feel similar regardless of platform, developers can be productive and apps can easily share underlying code that is not exposed to the user interface (business logic, network code, etc.).

Maybe this is what Apple intends. Underlying framework parity (UIColor is UIColor) and a set of UI frameworks for the Mac that feel like developing with UIKit but don’t easily allow for a direct port. It might let them keep what’s great about the Mac but open up the field to more developers.