Python task manager from scratch, part 28: Taking stock

We have an app. I'm actually using it. I don't do a lot of task management outside the house these days, so I'm leaving it running on localhost. I'll be migrating my real, honest-to-goodness task management over to Veery over the next week or so. I'll still use Reminders (the built-in Mac utility) for alert management, but Veery, as a task app, will have at least one user.

There's something odd about using such a primitive system when so much lovely productivity software already exists. But, however much I enjoy managing my to-dos, I do not enjoy using any such software. And Veery makes me happy.

And there's nothing that helps software like users--or, barring that--a user. Relying on it for my actual task-tracking ought to keep me honest as a programmer.

Speaking of software making one happy: I recommend getting good linting / formatting software. Depending which Python version you're using, you might have Black as part of your Python installation. (I do.) So, optionally, you can run black . from your root directory (from veery/), and Black will go through and format everything.

That's the code change for the day. Feel free to simply skip this step or pull the changes from the veery/ GitHub repository (links below). But having well-formatted code that I didn't have to spend brain cycles formatting makes me happy.

Herk's the current commit in the veery/ repository.

My own use of the software will guide its development, but the magnitude of what's possible is overwhelming. Big teams of software engineers can work full-time on this sort of thing and still not implement everything that one might want. Consider the difference between where we are now and where we are at the end of a school assignment. Assignments are, however instructive and extensible, all about completion and definition. Working, living software is not, yet it starts life feeling a lot like an assignment. (I made a tutorial out of this precisely because the first steps of a software project are good teaching material: repeatable, independently good to know, and useful for the sake of many other things.)

The metaphor I can't shake: getting to this stage of a software project is like scoring a touchdown in a professional football game, then seeing the stadium open up in front of you, learning that some rare rules contingency has been invoked that will cause the game to extend indefinitely into the streets, and needing to come to terms with the fact that the game is unbounded. The drive you thought was done can go forever--from Toronto to Greenland and perhaps beyond. The whole thing is teleologically confusing, but first downs are still first downs and the game demands you keep going. Perhaps it will inform your whole sense of self; perhaps you'll turn it over on the next play. Strange obstacles await.

The reference is to The Tim Tebow CFL Chronicles Jon Bois' ~~novel~~ ~~novella~~ ~~story~~ experimental Web fiction about an alternative-reality CFL. I don't get many of my fiction recommendations from Hacker News, but this one delivered. No, it is not the best novel of our generation, but it is legimately moving. Jon Bois is skilled at managing his audience's attention span and reserves of credulity. And nothing stirs the heart like a fresh and convincing take on what's special about sports.

Anyway, I'm not surprised that software people like it. I liked it too. Whether or not it's a book, it made my top 100. And whether or not you have any interest in experimental fiction about Tim Tebow, happy coding.

Next post: Python task manager from scratch, part 29: Cosmetic improvements

Home page