There was lots of family and friends this past week, and comparatively little Deep Work, but the few(er) hours paid off: I was able to solve the “depth of project/depth of task” design problem that had been vexing me, and the MLO parser now emits properly formatted (well, formatted with printf(); a few more details outstanding, but the gist is there :-)) project and task records.
Next week: Generating actual stuff that could be input into Todoist.
It’s going to be a short week with the holidays and family coming in from out of town, but, still…
In the the time I do work this week, I want to try to break through on the depth of “project” and “task” nesting that I complained about last week. That’ll be the software part of the week’s work.
And I want to reflect and maybe generate something on the topic of using Todoist as a fresh start in terms of fitting the work I want to do into the life I have available. For this, I may review some of the stuff the Todoist folks have written on how to use their system, as well as just a bit of navel-gazing.
Not much to say here.
It continues to be fun to code (yes, I can hear the professionals saying, “Yeah, I’d have fun coding too if I didn’t have to worry about deadlines and layoffs and burnout…”).
I’m surprised how much trouble I’ve had with the following problem:
I’m not doing justice to it, but that’s the gist of the problem.
Probably just hyper-rustiness. Can anyone help/
I had originally thought to spend another week on the MLO Parser front end.
I wanted to really get an elegant abstraction of the division of labor between the parser guts — which presumably would be independent of output and dependent only on input — and the app itself, which might use the input data to generate XML for updating MLO views on multiple platforms, for example, or might use the data, as in the current use case, to port the data over from MLO to Todoist.
But, as Einstein said, “If you are out to describe the truth, leave elegance to the tailor.” I thought it over, and I thought better of it.
In the first place, I’ll learn the most about the various use cases for the MLO input data by actually working the cases rather than by mulling about them in the abstract.
Plus I know that, left to its own devices, my mind over-abstracts. There’s an old FORTH cartoon I love (which I couldn’t find online) showing a device labeled “Processor” with a keyboard, a “system unit”, and a bowl. On the front of the device is a three-way switch which says “DATA/WORD/FOOD”.
That’s where I was headed.
So, to ground myself, to gain experience with one definite use case, and to actually get closer to my goal instead of messing around, I’m going to focus this week on parser output for Todoist from the MLO data.
There are a bunch of sub-problems here:
Should be fun.
Well, I just spent a good chunk of this week writing code, which I haven’t done this consistently for some time. Two hours on Monday, four hours on Tuesday and Wednesday, and an hour today. Not a marathon, but not too shabby for a code re-nube.
First of all, it’s a big kick. I forgot how much I enjoyed coding and I’m glad to decided to spend some time on it in December. I especially enjoy debugging, for the same reason you love hitting yourself on the head with a hammer: it feels so good when you stop! Wanting to a solve a software bug is a deep itch that nags at you and nags at you, and, when you solve it, it feels terrific.
Actually working at writing code, moreover, is teaching me a lot about the Go language that I didn’t grok from just reading the book. It forces you to make your ideas execute.
Not much more to say about it than that.
Continuing this week with work on MLO Parser.
It turns out I had gotten a basic parser turning over which could echo some fields to the output and visit every node of the XML, but not much more.
Task this week is to turn that raw prototype into something a bit more robust.
First order of business?
Many years ago a software mentor told me, “Dan, the problem with software is that entropy seeps into it, and so you always have to be pumping the entropy out.”
She hit the nail on the head. Of course, entropy probably seeps into everything, but software is nothing but entropy-waiting-to-happen, so the seepage is much more obvious.
“Refactoring” is part of entropy control, but really only a part.
In this case, the main thing is going to be getting the parser to visit every node, and getting it to do something uniform at each node.
Well, that has been quite the extended Thanksgiving holiday! It’s been two weeks since I’ve posted.
(Which calls for a word or two of self-criticism. At the end of the post.)
This week I’m continuing to work on the Go Language and the MLO parser. I think I’m going to continue with this through the Hannukah and Christmas holidays. So I’ll probably pick up 7 Hard Problems in January.
The goal this week is to find the right architecture for the parser now that I’ve read most of the Go Language book (except for the sections on concurrency, which I’m not ready for and which is not an issue for my parser project.) I’m wrapping up the book this week (again, except for those concurrency chapters 8 and 9).
This week is going to be a combination of reading and work on the parser, which I haven’t done since September. So there’ll be some context switching and dusting-off to do.
After the dusting-off I want to find the right way to handle the key problem of the parser, which is how to treat the various actions the parser might perform in response to the same input for varying contexts.
For example: I want to be able to parse an MLO file and output just the “views” from the file in a way that they can automatically synchronize with MLO instances on other computers and platforms. Right now I have to do this manually.
Another example: I want to be able to translate an MLO file into a nearly-equivalent ToDoist file (which is complicated because the ToDoist paradigm isn’t really hierarchical.)
We’re traipsing through a giant XML file in the same basic fashion for both of these, but the actions to be taken for each node in the XML couldn’t be more different.
I’m looking to use Go’s interface capability to represent these similarities and differences in a uniform manner.
Enough said. Happy to say more offline if you’re interested in Go, interfaces, MLO, my parser, and anything else related.
Now for the self-criticism…
I don’t know whether or not I’ve blogged about self-criticism, but I have a couple of non-standard ideas about it:
What makes a self-criticism real?
So here, what’s the self-criticism:
I think that’s a decent self-criticism. What do you think?
Because of the holiday this coming week, I’m trying something different.
Instead of working on the next chapter of 7 Hard Problems I’m going to give myself kind of a treat and flip over the Deep Work to learning how to program in Go.
Actually, I’ve been at this for a while. I’ve done the basic tutorials. I’ve carved out a project — writing a parser to take input from MyLifeOrganized and use it for a variety of outputs — and I’ve got the bare bones of the parser turning over.
I ground to a halt by “death of a thousand cuts” because I basically wasn’t very fluent in the language. Each time I hit a snag — and they were often basic snags about syntax — the wind would go out of my sails and I’d lose time on the project.
So I decided it was time to read The Go Programming Language, as near as I can find to a definitive reference, from cover to cover.
I’m about halfway through. In Chapter 5 (“Functions”) to be exact. I’ve been fitting it in around the edges of the work on 7Hard.
Well, I’m going to shoot my Deep Work wad this week on Go, and hopefully bull through the rest of the book.
Where will I be at after that? An expert in Go? Maybe. What I’m hoping is that I’ll now be fluent enough that I can work away on the parser in smaller dribs and drabs — a Pomo or two at a time, say — and not lose my gumption every time I hit a snag.
Because I have a mission. My next weight-loss treat.
I’ve been using tech toys to spur my weight loss. An Android tablet. An Android watch. A Sonos sound system for our house. Etc.
Well the next tech toy is not going to be a product, it’s going to be having permission to finish the MLO Parser.
Why reward myself for writing software?
So off-purpose treats that aren’t harmful are great weight-loss rewards. And that’s what I’m going to do.
