This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will block this actor and hide all of their past and future posts. Are you certain you want to block this actor?
This action will block this object. Are you certain you want to block this object?
Are you sure you want to delete the OAuth client [Client Name]? This action cannot be undone and will revoke all access tokens for this client.
Are you sure you want to revoke the OAuth token [Token ID]? This action cannot be undone and will immediately revoke access for this token.
Epiktistes is my home in the Fediverse. It is an instance of Ktistec, a single-user ActivityPub server like Mastodon, but with fewer users and fewer commits. Here's my introduction (last updated early-2025).
I wrote a series of posts about optimizing the performance of the Ktistec server, its build time, and its executable size: part 1, part 2, part 3, part 4, and part 5.
Some things I regularly write about, organized by hashtag:
I also wrote some #pointfreeverse.
I recently finished reading An Elegant Puzzle: Systems of Engineering Management by Will Larson. Larson is a solid writer, but what makes this book relevant is his time in the trenches—in management—at companies like Yahoo, Digg, Uber and Stripe.
An Elegant Puzzle is written for managers and aspiring managers. It’s a cookbook—built from posts on his popular blog—and it covers everything from sizing teams to presenting to executives. The appendix alone is 50+ pages of references to books and papers for further/deeper reading.
As an engineer, the metaphor of a "a puzzle" (think Rubik's Cube) appeals to me—managing feels like solving a puzzle, at times. An Elegant Puzzle is a collection of recipes that you can apply to parts of the puzzle. Occasionally, I feel like my own recipes are better than Larson's, but on the whole it's a pretty good cookbook.
There are a few gems:
Make your peers your first team. One of the first mistakes a new manager makes is failing to realize that, with their promotion into management, their team changed. Their team is now other managers—their old peers are maybe now their direct reports! The book explains why new managers should lean in to this change.
Work the policy, not the exception. Another common mistake is spending too much time dealing with exceptions to a policy (vacation, on-call rotation, technology...). It's not that no exceptions should be granted—because no policy is perfect. Rather, exceptions under consideration should be used to test and refine the policy and then the policy should be applied uniformly. (Of course, allowing no exceptions ever causes problems, too.)
Systems survive one magnitude of growth. Regarding infrastructure, I feel like this is reasonably well understood—the challenge for a manager is figuring out when and how to plan for and address it. Less obviously, but equally truthfully, this applies to organizational systems of people and teams and departments.
cassette tapes are back!?! really?!?
in what universe does data still come off a punched tape? why does every drawing program still include these shapes?? (does anyone still make flowcharts...?)
looking at options for solar power. the only conclusion i've drawn so far is, if you finance the purchase, you won't save any money, at least in the pacific northwest, where electricity is relatively inexpensive. at best you might break even.
I’ve just read two cookbooks back-to-back. What do I mean by "cookbook"? Short answer: I mean a "how to" style book long on checklists and instruction rather than abstract guidance or case studies. The first of the two books, which I’m writing about now, is Sprint.
TL;DR If you plan to run a design sprint, you should read this book.
The goal of a design sprint is to get honest customer reaction to a product or feature you believe will be critical to your success—in just five days! Is this kind of customer feedback important? Yes! Too many companies and too many products bet the bank on something that really doesn't matter much to their customers—but they take quarters or years to figure that out. If you believe you know what customers will line up for, test that now! Sprint shows you how to do that.
Some themes stand out:
Write things down. Be literal about the questions you want to answer. Draw maps of the customer journey. Use whiteboards, sticky notes, and pens—put away your devices until you're ready to prototype!
Never brainstorm or engage in group free-for-all discussions of any kind. In a design sprint, feedback is time-boxed and often in writing. Rather than the author of an idea "pitching their idea" to the team, feedback is often summarized and narrated by the Facilitator to the team.
"The Decider decides". A lot of what's good about Sprint can be summarized by this phrase. A design sprint is not a democratic process. There's voting, for sure, but after a vote, the Decider decides what to do (and may go against the vote).
Sprint is full of detail: who's on the team, what their roles are, what the agenda is for every day of the week. It describes how to find customers, how to run interviews, and how to observe and unpack reactions. Sprint includes notes specifically for the Facilitators.
Of course, to do a design sprint well, you can't just read the book—you need to practice!
nearly just shot my foot off with git. i popped a stash full of work onto a branch and then accidentally reset hard against my main branch by picking the wrong command in my shell history. poof! thankfully, with enough effort you can do anything in git—including checking out the commit representing that deleted stash...
but, some things you should somehow never allow in your shell history:
* rm -rf <anything>
* git reset --hard <anything>
* probably others...
i had to roll back to emacs v28.2 on osx (ventura). magit on v29.1-1 was super-slow and, generally, frames would unpredictably lock up and stop accepting input. it's not even obvious where i'd report this issue...
I just finished reading Minding the Weather: How Expert Forecasters Think.
TL;DR it's really a book on expertise—you won't learn how to forecast the weather by reading it.
My interest in weather comes via my company's work on maritime voyage and route optimization. I finished the book with a much deeper understanding of what weather forecasters do and what it means for them to forecast the weather, generally—which was the goal (the objective being to understand what it would look like to stand up our own weather team).
Surprisingly (or maybe not surprisingly), the idea that someone could actually forecast the weather was once thought of alongside pseudoscience like astrology.
As expected, the book includes a few chapters on using machines to forecast the weather. Unfortunately, if this is what you're looking for, the coverage is way out of date—and I don't mean in the 2017 to today sense. I mean in the late 1980's to today sense—the authors talk about using expert systems to forecast the weather. What?!? I don't expect coverage of GraphCast but I do expect something other than expert systems! (Maybe no one has used a NNs on weather data in the last ten years—I'd be surprised but I guess I'll check it out next.)
That aside, it was well worth my time to read. It definitely corrected many naive assumptions, and that's what I was looking for!
@rahul you are one of the people running ktistec v2.0.0-9. the "dist" branch had a bug that affects the metrics—all data points are added up each run, instead of only the new data points. you may not care, in which case everything should be fine. but it you do care, i recommend building and deploying the latest "dist" (or maybe let me run it for a day or two more) and then if you want the historical metrics to be correct deleting some data from the database, which i can help you with. let me know! (if you are running off "main" then you are probably not affected.)
@jayvii you are one of the people running ktistec v2.0.0-9. the "dist" branch had a bug that affects the metrics—all data points are added up each run, instead of only the new data points. you may not care, in which case everything should be fine. but it you do, i recommend building and deploying the latest "dist" (or maybe let me run it for a day or two more) and then if you want the historical metrics to be correct deleting some data from the database, which i can help you with. let me know!