My weight dropped a couple of pounds last week, so apparently the diet is still working, and I wonder if the week before my body was just holding onto the extra water I’d started drinking to handle the extra fiber. My current task is looking up what I can eat at my usual restaurants, which is turning out to be not much. I also want to start cooking again so I’m not limited by my frozen dinner options, but I don’t want to spend much time on it, so I’m researching cookbooks of quick and easy recipes.
I managed to get to bed before 11 every day except Saturday when I had a few too many things to do. Two results I’ve noticed from my new schedule are that (1) I’m not taking naps after work and (2) on napless days I’m actually doing my night routine instead of flopping into bed out of sudden exhaustion. These somehow feel like small changes, but they’re actually a big deal, since those were nagging problems that dragged down my perception of my life. Not all my sleep problems are solved yet, but I’m counting this as great progress, and so far this bedtime doesn’t feel like a hard schedule to keep.
Continuing along my self-quantification theme, I returned to another app I used a few years ago, ATracker, which lets you track your time on categories of activity that you define. My initial purpose was to get an idea of where my time disappears to, but it’s getting me to use my time somewhat better while I track it, since (1) I have to think about my activities to track them, which gets me to make more purposeful decisions about them; (2) I’m motivated to organize my time so I don’t have to open the app so much and my activity history doesn’t look like total chaos; and (3) I feel like the app is judging me if I waste too much time, even though it provides no opinionated feedback whatsoever, unlike MyNetDiary and Fitbit.
Taking a tip from Living Documentation and Microservices Patterns, I listened to a trio of books on a practice that’s variously called Behavior-Driven Development (BDD), Acceptance Test-Driven Development (ATDD), and Specification by Example (SBE): Bridging the Communication Gap, Specification by Example—both by Gojko Adzic—and Writing Great Specifications by Kamil Nicieja. The idea is that business stakeholders, developers, and testers should work together throughout a project to define and refine its requirements in documents that are clear enough that they both communicate to all the people involved and can be used to automatically test the software as it’s being created. The Adzic books were good for the process of adopting the practice and collaborating on the specifications, and Nicieja was good for the mechanics of designing and using the specifications.
Thanks to a talk I watched by Gojko Adzic, after the BDD books I listened to a short book by him called Impact Mapping, which is about another task that accompanies defining requirements—choosing and monitoring the requirements your project needs, since it’s easy to spend time and resources on tasks that fail to help the customers or the business.
Despite the task tracking, life and poor time management crowded out my project activity last week, so I didn’t get much further in my RDF reading. This week starts Thinkulum project month February, when I’ve been planning to start learning first-order logic with Lepore’s Meaning and Argument, and to avoid uncontrolled delays I’m going to stick to that plan while interspersing some trailing work on RDF/OWL and some meta work. One of those meta tasks will probably be an impact map for my RDF learning, since I’ve realized I have too vague an idea of the kinds of notes I should be taking and what I want to gain from them.
Sunday Tim and I watched 1917, which my boss recommended. Even though I don’t normally go for historical movies, this one was very well done, I really enjoyed it, and I hope it wins things. Among its many appeals, a lot of it had an eerie, surreal tinge that connected with me.