I got my offline wiki installation to the point of giving me an internal server error. This is the same state the online website was in. My week was taken up with naps and reorganizing my cooking, so this wasn’t much progress, but it was an important milestone. Next I’ll increase the server logging and see what that tells me.
I’m spreading out my life maintenance tasks. My weekends were consistently overburdened with chores, so I’m finding ways to spread them out. So instead of planning and shopping for groceries on Saturday, which probably takes me longer than a normal person, I’ll plan on Monday and shop on Tuesday.
I’m making interval timers for my regular recipes. This feels like another level of nerdery, but timers really do help me: (1) They tell me how long to expect the whole task to take so I can fit it into my plans and hopefully limit procrastinating on it. (2) They keep me on task. (3) By breaking down the task and objectively keeping the time, they make it easier to learn how to speed up the activity. The only problem is it takes a lot of time to set up a recipe timer. So that could turn into the main project for this week.
In Modern Software Engineering, Dave Farley places software development practices into a cohesive framework built on the core ideas of engineering. I was interested in his take on an engineering approach to software development because of his YouTube channel, especially his criticism of the state of Agile. The core ideas he starts with are the efficiency and economy of software solutions and using an empirical, scientific approach to find them. To follow those principles developers need to become experts at learning and at managing complexity, and these are the two categories Farley places his recommended practices into, plus a category for tools that support the process.
I appreciated his framework and especially the nuances it added to common practices. But I’m still looking for more from the idea of engineering in software development. I’m looking for an in-depth treatment of parallels to other engineering disciplines, which seem to draw a lot more on existing, low-level scientific knowledge, whereas software consultants tend to focus on the high-level design process. Maybe I want something more like the books Cracking the Coding Interview or Elements of Programming Interviews, which are crash courses in computer science in the form of worked word problems that might come up in job interviews. I also wonder what the programming equivalent of a CAD tool would look like. I’m sure it would involve a lot more static and dynamic code analysis than I ever see, and also diagrams, though not necessarily UML.
Signature SELECT Colombia Ground Coffee: 3/5. I liked it better than the Folgers, but it was still sour a little too often.
Season 4 of Star Trek: Discovery just finished, and while I love the show and this season in particular, my feelings are mixed. The show continues to be sci fi comfort food for me, and I found this season’s themes of cognitive science, linguistics, and the profoundly alien especially relevant to my interests. And there were some moments I really felt.
But it has some quirks, which I just accept: The writers pack too much in, so problems are solved way too quickly, and some of the story elements get shoved in awkwardly, although I do love that each season covers so much ground. And it sometimes promises more than it delivers (e.g., I kept hoping Culber would get better therapy than a mere vacation; and for the season’s threat I was hoping for Nagilum-level weird). These traits aren’t that unusual for Star Trek, but Discovery seems to turn up the dial on them.