My slide into audiophile territory, Part 2

This is the second in a series of posts about my realization that I have become an audiophile. The prior post examined why I think of myself as an audiophile now.

What does it mean, to me, to be an audiophile?

So, I’m an audiophile now. What does that even mean? Am I just an overexcited consumer with enough disposable income to blow a lot of money on headphones? Hopefully there is more to it than that.

A lot of people, when talking about speakers or headphones, preface their comments with “I’m not an audiophile, but…” They do so out of humility, to admit their own limitations of hearing, and their own lack of experience discerning good sounding speakers from mediocre ones. What it is really about, however, is saying that you are not a snob. I used to do that, too. But I’ve given myself leeway to put myself in the audiophile camp, despite my lack of ear training and my lack of sophisticated acoustical measuring equipment. I want to take the term “audiophile” back from the snobs.

I call myself an audiophile now because I love sound. I love sound so much that I listen to music hours and hours each day. I love sound so much that I will listen to types of music I didn’t like before—EDM, hip-hop, country, standards, soundtracks—just because they sound good. I love sound so much I will spend large—but not obscene or unlimited—amounts of money on decent equipment.

My love of sound itself is a relatively new development. While I have loved music as long as I can remember, what drove that love was always the melody, the song structure, the lyrics, and the performance—all the normal things people enjoy about music. The production, on the other hand, was not important to me. In fact, over-produced recordings turned me off, because studio slickness betrayed, in my opinion, the authenticity of the music.

Now, I think differently. I admire the craft of studio engineers in a way I never appreciate befored. Some recordings just sound great, and that is part of the pleasure of listening to them. Similarly, some singers have have beautiful voices, and it doesn’t matter if they are singing the same old songs (ahem, standards): the sound of their voices brings life to the music and helps make it worthwhile to listen to.

To me, being an audiophile is about appreciating the distinction between the sound and the music, and deriving pleasure from it, far more than it is about spending vast amounts of money on expensive equipment, or believing the hokum perpetrated by high-end audio equipment manufacturers and sellers.

SwiftoDo Development Notes, March 2018

Today I released the ninth update to SwiftoDo in about ten weeks. What is driving all these small (but good!) releases? Two main things:

  1. I want the app to get better
  2. I want to have fun

I want it to get better

SwiftoDo is a good app, but it is by no means perfect. There are a lot of things that can be improved. My development task list for the app is a mile long. For a long time, the most important items on that list were also the most difficult for me to implement. To be honest, some of those “most important” improvements feel like they are beyond my current capabilities as a developer—but that doesn’t mean that I can’t make improvements somewhere. The app can still get better.

Sometimes, small things can make the app a lot better. Based on many emails with customers, I have learned that, a lot of times, a simple-to-implement feature, rather than a broad reimagining of a portion of the app, will make a big difference to their enjoyment of the app and the productivity they gain from it. That’s why I have been working on “small” features, such as the full file editor, that merely build on what was already there, but end up making the app more powerful and flexible for users. That is also my rationale behind improving application performance, which has become a much higher priority for me this year. Better performance benefits everybody.

I also decided to release features and fixes regularly and frequently. Every week I ask myself, “How can you make the app better for your customers?” And, on another day each week, I ask myself, “Is my latest commit better than what my customers have?” Once I’m sure the new version is better than the last version, I release it.

I figure that adding small features and fixing small bugs eventually accumulates, and my good app can eventually become a great app.

I want to have fun

I’m working on SwiftoDo because it the app is useful to me and because it is fun.

Coding is fun for me, but certainly not every minute of it. Sometimes I have to fight with UIKit’s quirks or work around its bugs, which can take hours of frustrating work. Sometimes I fail to get a feature working without introducing a crash or breaking something else in the app. Sometimes things just don’t work, and it’s really hard to figure out why. Sometimes I’m stuck, and that’s no fun.

I have decided not to remain stuck for more than a day or two anymore. If something isn’t working, I table the work and move onto smaller, solvable problems for a while. This philosophy has led me to work on features that seem simple, useful, and fun to code, but maybe not as important as the larger, more difficult things that have been blocking my progress. That explains why I’ve been pushing forward on improvements to the task text editor, for example, rather than adding new data providers. As a side benefit, working on those smaller things sometimes clears a way, either in the codebase or in my mind, to tackle those larger, more important items.

So, what’s fun? Racking up win after win, week after week, by pushing a better version of my app out to my users. And knowing, every day, that no matter what is not in the app yet, what is in the app keeps getting better.

Version numbers

SwiftoDo’s version number, currently at 2.9.2, is heading into the weird-looking, double-digit-minor-version-number terrority. The next version I release will be 2.10.0.

As Apple suggests, I’m using a 3-number semantic version numbering system, with my own rules for what increments each component. Architectural changes to the app (such as a total rewrite) will bump the first number. Adding new user facing features will bump the second number. Fixing bugs or enhancing existing features, in minor ways, will bump the third number.

Because I am releasing so often now, and batching fewer new user-facing features together, the minor version number has been increasing rapidly. No one should care what the version number is, as long as it goes up. I don’t really care if it is, eventually, version 2.50.0. I does look a little funny to me, though.

What about the Mac version?

I have not been releasing updates to SwiftoDo Desktop recently. The main reason for that is that SwiftoDo Desktop is, basically, feature complete. Unfortunately, because it is coded in Objective C and relies on cell-based table views (mainly for the inline editing to work), it sits at a technological dead end. A total rewrite is in order.

I have prepared for this scenario. My todo.txt-related code is in a framework that can be ported over to the Mac easily. In fact, I have started and stopped a total rewrite of the Mac version a couple times now, but have never gotten that far into it. The things holding me back are:

  1. I have to update my knowledge of AppKit, which is the Mac’s UI framework.
  2. The desktop app uses a different filtering system, which is a little harder to use than the iOS version’s filtering system, but it is much more powerful. I don’t really want to kill it off.
  3. SwiftoDo on iOS could always use more work, and it represents 70% of my user base.

In June, Apple may announce a new framework that would allow me to port my iOS code to the Mac much more easily. If that happens, my ability to provide an updated Mac version would be greatly improved.

A/B/C testing: August and Everything After, in 24-bit, 96kHz FLAC vs. 16-bit, 44.1kHz ALAC vs. 256 kbps AAC

I’m listening tonight to a “hi-res” 24-bit, 96kHz lossless version of “August and Everything After” through my good headphones, DAC, and amp tonight. I love this album. It helps that I was 15 when it came out, of course. But still, I think it is an emotionally rich artistic achievement. It surprised me when such an earnest, heartfelt record became wildly popular; only in the 1990s would that happen, I guess.

I compared this hi-res version, track by track, with two other versions I have on hand:

  1. my 16-bit, 44.1kHz ALAC rip from my original CD from 1992, and
  2. the 256kbps AAC version available through Apple Music.

Overall, all three versions sound almost identical, which is kind of what I would expect, actually, given that Apple Music’s lossy AAC encodings are of a very high quality, and that the bit rates and bit depths for CD-quality recording and iTunes AAC encodings were chosen very carefully. We are far from the world of mushy, sizzly 128kbps MP3 files now. That said, the lossless versions do sound a tiny bit better. They reveal more detail than the lossy version, notably in the snap of the bass guitar and in the attack of the snare drum. The difference is slight: you have to listen very carefully to hear it, and you need equipment sensitive enough to reproduce the sounds accurately.

The main improvement the hi-res version brings over the CD-quality rip, to my ears, is a lower noise floor. Otherwise, it sounds the same as the CD version. You gain about 1-2% in fidelity at the price of lot of extra bits on the hard drive, and, perhaps, more dollars out of your wallet. This is true even though the 24-bit version was mastered to be a little quieter than the original CD and iTunes versions. You have to turn it up a notch to match the others’ volume. Even with more amplification, the hi-res version’s noise floor is incredibly low, and everything sounds fantastic.

Overall, I would prefer to listen to all my music in lossless quality, in as high fidelity as possible. It can sound better than lossy rips, and, even if I can’t hear the difference on a particular track, why not listen to the best version available? That said, I subscribe to Apple Music, which serves AAC files, rather than Tidal, which has a lossless streaming plan, primarily for convenience. Fortunately, for me, Apple’s 256kbps AAC files are completely adequate substitutes for lossless rips. I do think, though, that if Apple offered a lossless plan at a slight up-charge, I would subscribe to it.

My slide into audiophile territory, Part 1

This is the first in a series of posts about my realization that I have become an audiophile.


I have realized recently that I have slowly but surely slipped from the category of “normal person” to the category of “audiophile”. I never would call myself an audiophile before, so this is somewhat shocking to me.

I always thought that audiophiles were people who threw away thousands of dollars, unnecessarily, on audio equipment–speakers, headphones, DACs, and so on—to “hear” “something” that I could never, ever hear myself, and was probably not even there. After realizing that I spent, probably, $1,000 or more on audio equipment last year, I think I need to brand myself with the “audiophile” label. I am listening to lots of music and enjoying it immensely, but there is something clearly wrong with me. (Just kidding—I think.)

A princely four-figure sum over the course of 2017 netted me some great equipment:

  1. Apple AirPods
  2. Oppo PM3 headphones
  3. an Oppo HA-2SE DAC/headphone amp combo, and
  4. a BeoPlay M3 wireless speaker.

Even with all that great stuff at my listening desk, I am still dying to buy a HomePod (or two, even), open-back headphones from HifiMan, B&O Play headphones of some kind (did they just discontinue all their wired models?), and maybe a HifiBerry or a piece of Schiit to turn one of my old Raspberry Pis back into an AirPlay receiver.

I have no idea why this is. All I know is that the good audio equipment I have now has made all the other speakers in the house sound like garbage to me. In a way, I am glad I don’t have the money right now to buy any of this stuff. I certainly don’t need any of it, and it won’t make my life any better.

What the hell happened?

How did I slip from being a normal music listener to an audiophile or audiophile wannabe? I have a very good excuse—or, more likely, a series of somewhat poor excuses that snowballed into $1,000+ of spending on audio equipment in one year:

  1. I adore listening to music, and spend a lot of time doing so.
  2. I got, for free a couple times, better headphones than the ones I had before.
  3. I started to hear “something” that these better headphones brought out of my music that I never had heard before. The sound of the music became as important to me as the content of the music.
  4. And then, those headphones broke, and I had to get new ones. This has happened multiple times to me over the past five years, which is a bummer and encouraged me to try to buy higher quality headphones each time.

So what?

I thought it would be fun to write about all my gear from one the years, from the first crappy boombox to the amazing headphones and DAV/amp combo I am rocking these days. This is the first post in that series.

Strategies to increase diversity on

Jean McDonald, Community Manager of, posted an essay today entitled “Diversity and Inclusion at Where We Are, Where We Want to Go“.

The question comes up regularly: to what extent is there diversity in the community? We only ask for a name and an email address to register, so we don’t have any demographics on the users in our community. But I do know, based on skimming the names of those who register, that the percentage of users with typically female names is very small. When I look at users whose avatars are photos of themselves, I suspect the percentage of people of color is also very small.

I have been thinking about diversity on the platform since I started using it, the day it opened to the public in December 2017. Jean’s essay inspired me to publish some of my thoughts.

What do we expect?

The service has not been a publicly available for long. At this point, it is understandable that the first wave of users would be primarily composed of fans of its founder, Manton Reece. Manton is an iOS and macOS developer who blogs and podcasts about his development work and the indie web. If you have come across his work online, you are probably very much like him: an iOS or macOS developer, or at least a passionate user; a tech podcast listener; or a passionate blogger or IndieWeb aficionado. This core group is, for reasons related to historical and cultural biases, not a particularly diverse one.

This core group describes me, and certainly does not describe everyone on, but it does describe a lot of the users I found on the service’s Discover page. Manton and Jean have expressed, from the very beginning, an earnest desire to create a safe community of independent micro blogs—”safe” from the abuse that silences disempowered people, women, and minorities on dominant social media platforms. They, along with the users of the platform, have openly discussed how to increase diversity, and the challenges inherent in doing so. I have learned a lot from reading these blog posts and discussions. Like them, I wish for to attract and retain a more diverse user base. The question we all face now is: how?

Here are a few ideas.

Recognize and publicize that community guidelines are intrinsic to the product

Jean McDonald:

No one should feel unwelcome here.

This should be one of the public-facing mantras that applies to the entire project, much like “Don’t be evil” was to Google for many years. Jean’s quote should be atop the “Community Guidelines” page, and a link to that page should be near the top of the “” page.

I think should put a lot more focus on the community guidelines and whatever technology or processes are used to enforce them. It’s a key feature of the platform. People behaving well together is the core of the product for me, and a key differentiator between it and Twitter.

Refine the marketing message

What is, anyway? To IndieWeb people, it’s kind of obvious. To everybody else, maybe not.

If asked, today, to sell it to someone, I might say: “It’s the good parts of Twitter, with none of the bad parts.” I might explain that microblogging is simply sharing something about yourself in public, and that is a safe, respectful place to do so, because it has protections against abuse, and strict community guidelines. If they are unsure why they should share thing in public, I would explain that it is empowering to do so. It is putting your best foot forward online.

Promote on podcasts

Having a simple, concise marketing message is essential, but that message needs to be spread somehow. One of the best ways to market these days is on podcasts.

Manton has a podcast and a microcast, which have brought a lot of people to thus far. I think podcasts are a great opportunity to promote the open, inclusive, but safe nature of While podcast audiences may, as a whole, skew white, male, and wealthy, there are tons of podcasts out there that are hosted by, feature as panelists, and cater to women and minorities. I’m sure that Manton is adjacent enough to other tech podcasters to get some guest spots on tech podcasts that feature or cater to these groups.

Ask users for help users are all, at this point, early adopters, and most of us are especially committed to the platform and want it to succeed. Ask us to publicize the service. Give us some ideas how to do that effectively, and in ways that will increase diversity. Provide incentives for us to sign up new people, such as additional badges (which are free to provide) or free months of hosting (which of course incurs a cost). I’m sure something will come of it.

Closing thoughts

My list of suggestions is by no means exhaustive, and Manton and Jean are likely in a better position than I am to understand what they need to do, and what they can do. I do want to express that diversity is important for all of us, even white, male, Americans such as myself. If all people are treated with dignity and are allowed to participate in something (work, society, etc.), outcomes will be better, and life will be richer, for all of us. I have seen that firsthand at a small scale, and wish to see it at a much larger scale. is a good place to start.

SwiftoDo Developer Notes, February 2018

SwiftoDo is a passion project for me. I love working on it, but, due to work and family obligations, I have very little time to do so. Consequently, I am way behind schedule in adopting features introduced in iOS 11. I also learned, the hard way, that lots of minor UI-related bugs popped up when I changed the app’s target iOS framework from 9.0 to 11.0. I have been slowly discovering and cleaning up those bugs, and adding minor features here and there, for the past two and a half months.

Release cadence

I have decided to release working code as soon as possible, rather than trying to batch features and bug fixes into larger releases. Therefore, I have been issuing new releases about once per week, the past few weeks. I will not be keeping up that release cadence, but I do want to reflect to my customers that the app is actively developed. More importantly, I want bugs to be fixed for all my users. I would much rather have a rock-solid, very simple app than an unstable one with lots of bells and whistles.


That said, I do want to keep adding bells and whistles. I am working on adding drag-and-drop support at this point, and plan to look into adding clickable URLs and Siri support. I have a long list of other ideas and concepts drafted, too.

I would like to add additional data providers, other than Dropbox, but I have little exposure to coding networking code, and the third party libraries I’ve looked at look like more trouble than they are worth. For some perspective, Dropbox’s SwiftyDropbox library, which powers file sync now, is a great library, but is also the source of most of the mysterious crashes on startup that a small number of people have reported. What is frustrating to me, as a developer, is that I can’t really fix those crashes, because I don’t fully understand what causes them, and the code is in a library. I don’t want to open my app up to more instability just to add a data provider. Also, I have been loath to support iOS 11’s Files app integration, up to this point, because I don’t see how the todo.txt “Archive” function, which moves completed tasks to another file, would be able to work with it.

Current focus

I have way more ideas for features and improvements than time to complete them. My focus in the near term will be on stability and satisfying user requests that seem like they would be useful for a majority of my users. Hopefully that is good enough for now. It’s amazing how much work my simple, text-based task list app has been!

Eye Round Roast Recipe


At my local grocery store, eye round roasts are relatively cheap and plentiful in the cold weather months. They are all cut to just over 2 lbs, as well, so this recipe works pretty well for me. If your roast is larger, set the oven’s “on” time to 5 minutes per pound.

The exact measurements of the spice rub are not important, but it should consist of mostly salt. It is important to heavily salt the roast and to let it sit at room temperature for at least an hour prior to putting it in the oven. If the roast is too cold, it will not cook through properly.

I have found that these roasts leave enough fat in the pan to allow me to make a pan gravy with just a bit of flour (about 1 tbsp) and 1 cup of liquid (often just beef broth). (It there isn’t enough fat left over to make a roux, add butter to the flour.)


  • 1 eye round roast, 2 1/4 lbs
  • 4 tbsp kosher salt
  • 1 tsp freshly ground black pepper
  • 2 tsp onion powder, 2 tsp
  • 1 tsp garlic powder
  • 1 tbsp olive oil


Dry off roast with paper towels.

Create a spice rub by mixing the kosher salt, black pepper, onion powder, and garlic powder. Coat the roast on all sides with the spice rub. (You will likely not use all the spice rub.) Let it sit at room temperature for 1 hour.

Set an oven rack to the middle or upper middle position. Heat the oven to 500º F.

Coat the roast with a thin layer of olive oil and place it on a pan. A 12-inch cast iron or stainless steel skillet works fine. A rack is optional.

Put the pan in the oven and roast it for 10 minutes, or about 5 minutes per pound. Then, shut off the oven, and do not open it for 2 hours.

After 2 hours, the internal temperature of the roast should be about 145° F. Set the roast aside and, optionally, make a pan sauce from the drippings.

Chicken Sausage and Escarole Soup Recipe


This is a hearty, pasta-free soup, fit for a winter meal. Lots of vegetables, sausage (either chicken or pork sausage can be used), and cooking liquid from cannellini beans (canned or homemade) lead to a chunky, filling soup with a rich mouth feel.

Developing a fond while cooking the sausage will add an important foundation to the soup’s flavor. Deglazing this fond early, before cooking the vegetables in the same pot, will prevent it from burning.

Ideally, the vegetables should be soft but not browned; if they are not softening sufficiently during the sauté, simmer them longer in the broth, rather than extending the sauté.

You can substitute your preferred herbs for the Italian seasoning that I use. If using fresh herbs, add them at the very end, or just before serving.

If you wish to add pasta, ditalini works well. Cook the pasta separately, and add it just before serving, to avoid the pasta absorbing too much of the broth during cooking or storage.


  • 1 12 oz package chicken sausage
  • 1/2 cup water or chicken broth, for deglazing
  • 2 tbsp olive oil
  • 1 cup chopped carrots
  • 1 cup chopped celery
  • 1 cup chopped yellow onion
  • 1 7 oz bag fresh chopped escarole
  • 2 15 oz cans cannellini beans, not rinsed or drained
  • 8 cups low sodium chicken broth
  • 1 tsp Italian seasoning
  • Salt and pepper, to taste
  • (Optional) Fresh squeezed lemon juice, to taste
  • (Garnish) Freshly grated Parmigiano-Reggiano cheese


In a large pot or Dutch oven, brown the sausage in 1 tbsp of olive oil for 4 minutes per side over medium heat. This will likely not cook it through, which is fine; it will cook through later in the soup. Remove the sausage and set it aside.

Deglaze the pot with 1/2 cup water or chicken broth. Retain this liquid in a cup or bowl; it will be added back to the soup later. If the retained liquid contains any solids, strain it to remove them.

Once the par-cooked sausage is cool enough, cut it into coins and set it aside, to be added back to the pot later.

Dry out the pot and add 1 tbsp olive oil. Sauté the onion, carrots, and celery over medium heat until they are soft but not browned, about 10 minutes. If the vegetables are not completely soft after the sauté, that is OK; they can be softened after the liquid is added. Add the escarole and Italian seasoning and stir everything to combine.

Add the chicken broth, and add back the retained liquid from deglazing. Raise the temperature to high until the broth starts to boil; then lower the temperature to medium or medium low, to maintain a low simmer. Simmer until the vegetables are soft, which can take 5 to 10 minutes.

Add the cannellini beans, including their cooking liquid, and the sausage. (These ingredients are added later to avoid overcooking them, which would lead to split beans and tough sausage.) Continue to simmer until the sausage is cooked through, which will take only a few minutes.

Season the soup with salt and pepper to taste. If, at this point, the soup tastes dull, add some fresh squeezed lemon juice, little by little, until the broth tastes as bright as you want it to.

Serve topped with finely grated Parmigiano-Reggiano cheese.

Plaintext Productivity: Still productive after all these years

I am still using the Plaintext Productivity system that I wrote about in 2013. It is a productivity system, based primarily on plaintext files, for Microsoft Windows users. Since I published a few people have asked me to write an update to Plaintext Productivity. The fact is, the system has held up so well for me that I really don’t have any updates to report.

One reason my system remains pretty much the same as it was in 2013 is that the operating system it is based on, Windows, despite some cosmetic changes, remains pretty much the same as it was in 2013. Sure, it got a better UI when Windows 10 supplanted Windows 7 and 8, but Windows still works just as well and just as poorly. Another pillar of the system, Sublime Text, also had a design change recently, to display more crisply on high-DPI screens, but it, too, works pretty much the same as it did in 2013.

A little bit of history

I developed my Plaintext Productivity system slowly over the years, as a result of the limitations I faced on my relatively locked down work computers, and my frustration with third party productivity apps going out of business and disappearing over the years. Gradually, I stripped down my productivity system to a great text editor and a todo.txt-format task list (with a good client), with some clever ideas about using a journal for planning, and for managing files.

Because I was stuck on Windows, an operating system I did not particular like, I had to make do with built-in functionality, portable apps that I could sneak onto my system, and a universal file format: plaintext. Even this was challenging. Windows, for all it’s ubiquity, has a dearth of good third party (non-Microsoft) software for it. There is a lot of crapware in the Windows Store, several world class apps from Adobe that everyone knows about, and not that much in between. Macintosh, iOS, and to a far lesser extent, Android, have attracted the attention on small, boutique publishers and indie developers who have contributed great plaintext-based apps. Like me.

Notes and drafts

I still firmly believe in writing lots of notes and drafts to help document thoughts as well as meetings. I draft emails, write planning documents, write out procedures for work I have to repeat, and so on. I also keep a work journal every day (well, I’m not perfect about writing it every single day, but I try). At the start of each workday, I write a short journal post to plan my top activities for the day. At the end of each workday, I wrote an even shorter journal entry to help remind me where I left things, which sets me up for the next day. I set up calendar entries to remind me to do these journal entries. These activities help keep me, a person who works remotely and alone, organized, engaged with my work, and on task throughout the day.

My text editor

Sublime Text is still my favorite Windows text editor. It is even better than when I first bought it, over five years ago, and it was worth every penny. I love that it is lean, fast, flexible, and handles both my short notes and huge data files with aplomb. Its plugin system makes it a serviceable Markdown editor. I have syntax highlighting for Markdown, HTML, todo.txt, TaskPaper, and the various programming languages I use at work: ACL scripts (which I created myself), SQL, C#, VBScript, and Python (and there are far more available).

Best of all, in my opinion, are its numerous, well-defined keyboard shortcuts for shifting lines around, selecting words, selecting whole lines, deleting whole lines, and so on. Its support for multiple text selection and multiple cursors makes certain quick edits, like making a bunch of lines a bullet list in Markdown, a snap; it’s actually kind of mind blowing when you get used to it. Lastly, I=its find and replace functionality is incredibly powerful as well, considering it supports regular expressions.

I have found no compelling reason to switch it out for a newer, shiner app—which is the whole point of having a simple productivity system in the first place.

I should say, though, that I do use Editorial or Ulysses on my iPad as a sidekick text editor quite frequently. I started to do so for a non-software related reason: my work machine’s mechanical keyboard is so loud that it bothers people on conference calls, while my iPad’s keyboard—the Apple Magic Keyboard—is so quiet that my phone does not pick it up. Those iOS apps are fantastic, but they are not vital to my Plaintext Productivity system.

My task list

I still use todo.txt for my work task list. Since I wrote Plaintext Productivity, I contributed a ton of patches to my favorite Windows todo.txt app: I contributed multiple task selection and editing, and a lot of other things. I went on to write Mac and iOS todo.txt apps, SwiftoDo Desktop and SwiftoDo for iOS. I tend to use SwiftoDo for iOS most of the time, and revert to only when I don’t want to context-switch away from my PC to my iPad or iPhone. My todo.txt file is synced via Dropbox between all these apps, so it doesn’t really matter which app I use at any given moment.

Todo.txt is the best system for me because my work, and my GTD-inspired way of looking at my work, tends to present itself as a large number of tasks that get picked up, dropped, and re-prioritized frequently. I have started to dabble with TaskPaper for some of my planning needs, either in my daily work journaling, or when I have a self-directed project to plan, such as drafting a proposal or creating a software-based audit tool. TaskPaper is interesting, but I do too much sorting and filtering of tasks throughout the day for it to supplant todo.txt as my main task list system.

I don’t keep track of every task in my life in todo.txt, however. I prefer to keep my personal tasks separate from my work ones, mainly because I find having them commingled with work tasks distracts me from my work. Therefore, I keep my personal tasks in Reminders, which has had solid Siri support and cross-Apple-device syncing since 2011, and has only gotten better since then. I have changed a lot about how I managed non-work tasks since 2013, but those fall outside my Plaintext Productivity system.

Filing and searching

I still use the same filing system, too, and have been consistently happy with it. While I believe that you should rely on search rather than elaborate folder structures for finding what you need to, Windows Search still is not great. Despite its weaknesses, and the frustrations those weaknesses sometimes cause, I still get by with it.

Hardware and other things

I also wrote about hardware and other things in Plaintext Productivity. Since 2013, I have had the fortune to upgrade my keyboard to a 87-key mechanical keyboard with Cherry MX Blue switches. I really like the clicky-clacky keyboard switches and the keyboard’s smaller size, which I credit with helping eliminate repetitive stress injuries in my wrists. I also made things easier on my eyes by upgrading my display from two 1080p monitors to one, much bigger, 4K display. Crisper text has reduced eyestrain and has made me much happier, though Windows has had, and still has, awful and inconsistent high-DPI support. I don’t miss having two screens at all, actually. I can tile two to four windows on screen, and use the virtual desktop feature that premiered in Windows 10, to get most of the benefits that multiple monitors afforded me in the past.

The future of plaintext productivity

I have never used the same productivity system for so long. It has been solid and reliable for me for years now, and required no real tweaks worth mentioning when upgrading from Windows XP to Windows 7 to Windows 10. I see no obvious need to replace or upgrade my system in the near future, either. Maybe someday, when everything is in virtual reality or something—but maybe not even then.

If you are interested in streamlining your Windows workflows, and discovering a productivity system that really lasts, I encourage you to check out my Plaintext Productivity guide.

Instant Pot Salsa Chicken Recipe

I’m posting this for the benefit of Traci on

This is a simple, lazy recipe for the Instant Pot. It isn’t entirely original, but it is extremely useful, and produces a result that everyone in my family will eat, which is no small feat.

I don’t measure anything. If I don’t have salsa, I dump in tomato sauce or even just water; the result is more bland, but still edible, and it can be shredded and mixed with barbecue sauce if desired. I make this in the morning or at lunchtime and let it stay on Warm for hours and hours until dinnertime. I find the taste of chicken thighs improves after a couple hours on the Instant Pot’s Warm setting.


  • 6 chicken thighs
  • 1 cup mild or medium salsa (eyeballed)
  • 1/4 cup water (eyeballed)
  • 2 large pinches kosher salt
  • 2 tbsp olive oil


  1. Oil bottom of Instant Pot.
  2. Coat bottom of Instant Pot with 1 pinch of kosher salt.
  3. Add chicken thighs in one layer
  4. Season top of chicken thighs with 1 pinch of kosher salt.
  5. Cover with salsa. Add water if salsa is not very liquid.
  6. Lid the Instant Pot and cook under high pressure for 20 minutes.
  7. Allow pressure to release naturally. The Instant Pot will automatically switch to its Warm setting. Keep the chicken thighs on the Warm setting as long as you would like. The chicken tastes better after several hours on Warm.