Deep Work, Developer stuff, Programming

Themes for Work and Learning, Week of December 23, 2018

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.

Cybersecurity, Developer stuff, IT Futures

Hack of the Week: Adversarial Machine Learning

I heard about this one at a talk on Monday at our Washington DC CTO Roundtable on machine learning.

I had read about a kind of smackdown sport where machine learning gurus set to work trying to break the algorithms of their adversaries.

When I asked the speaker about it, he said, “Oh yeah, adversarial machine learning”.

Well, that was it, and here’s the Wikipedia article on it (flawed though Wikipedia seems to find the article).

Per this article, “AML” as we might call it has been with us for some time, mainly in the form of the fight between spammers and spam-filter developers.

You know:

  1. Spam filters add the phrase “penis enlargement” to their algorithm. Any email with “penis enlargement” in it gets flagged.
  2. Spammers start spelling it “penis enl@rgement”
  3. Rinse and repeat

Since the spammers just have change some generated text and the spam filters have to change and train a changed algorithm, guess who’s more supple?

The Roundtable speaker alleged that there was a sticker you could put on a stop sign that could fool a self-driving car algorithm into thinking it was a “Yield” sign. Think of the fun you could have with that if you were intent on getting self-driving cars to hurt people…

Deep Work, Developer stuff, Programming

Summing Up The Week’s Work

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:

  • Increment a “Project” count every time we go into a sub-project, with the wrinkle that a sub-project need not be a child of a super-project; it could be a grandchild or even a great-grandchild
  • Call panic() if the Project depth gets to be greater than 4
  • Unwind the Project count as we backtrack on the XML tree

I’m not doing justice to it, but that’s the gist of the problem.

Probably just hyper-rustiness. Can anyone help/

Lifehacking, Tradecraft

How I Gave Up Smoking

I gave up smoking thirty years ago, when my son was born.  It was easy.

I tried to give up smoking for the fifteen years before that.  It was impossible.

OK, you might say.  Birth of your son.  Who wouldn’t be ready to give it all for their child?

Except that my daughter had been  born three-and-a-half years before my son, and I wasn’t able to give up smoking then, even though I wanted to.

What changed?  How did it work?

Well, first of all, all of the things I tried when I succeeded were things I had tried when I failed.  As I recall, I used nicotine gum.  And I put a pack of cigarettes out on the mantle of the fireplace so it was crystal clear that I was giving it up, foregoing this vice.

But I think there were two key things, one of them slow and gradual and one of them sudden.

The gradual thing was that my opportunities to smoke were diminishing.  We lived in California then, which had a pretty staunch anti-smoking portfolio.  You couldn’t smoke in bars.  You couldn’t smoke in workplaces, unless you went outside.  So my smoking habit was experiencing habitat destruction.

The sudden thing was that all of a sudden I was ready to quit.  And I don’t know much more about it than that.  Maybe it was the accumulation of the various restrictions.  Maybe it was thinking of my son becoming a smoker. 

Some switch inside me had flipped, and I was ready.

I won’t say that quitting was easy, but it was a no-brainer in a sense because I was determined.  More than that: going back to smoking was unthinkable.

I’ve tried to use this two-part formula for other vice removal — habitat destruction and recognizing when I’m ready.  I’ve had some luck lately with weight loss.

But I’m still puzzling over what happened with smoking… and how I could bottle it.

Personal Information Management

Pimcraft: The Difference between a Project/Goal and a Multi-Step Task

Porting over from MLO to Todoist has forced me to think about the distinction between a multi-step task and a project.

The distinction is forced upon us in Todoist because Projects and Tasks are two different entities in Todoist although each may have up to three levels of sub-<X> (either sub-project or sub-task).

On the one hand, this is a slap in the face to orthodox GTD.  David Allen is pretty clear that any multi-step process should be considered a project.

But being forced to partition my PIM into projects and sub-projects on the one hand and tasks and sub-tasks on the other got me thinking.  And thinking is the mother of More Refactoring Work On The PIM.

There’s a lot of things I do now in MLO that hardly merit the title of Project.  A mundane (and degenerate in the mathematical sense) example is reading a book.  This is a multi-step process for the most part, in that you read some every day until you’re finished.  But it’s really stretching things to call it a project.

Slightly less degenerate is getting together with a friend.  This is a multi-step process, but it doesn’t really involve much ingenuity to do it; it just requires tracking the steps so I know where I am in the process.

You know:

  1. Propose some dates
  2. Hear back from your friend
  3. Close on one date
  4. Book a venue
  5. Go to the get-together

I include the last because it ends up as a calendar entry as opposed to a task, but it’s all part of the same PIM.

Again, this is a multi-step process, but it’s pretty stereotyped.  You could almost have a template for it.

Which is a good rubric for what’s a project and what’s a multi-step task.  If you can gen up a template for it, it’s a multi-step task.  If you can’t, then it’s a project.

So what are some projects?

Projects have several moving parts.  A project — for example, building traffic to my blog — may involve:

  1. Measuring traffic, which is a multi-step task
  2. Pinging influencers, where each influencer ping is a multi-step task
  3. Buying traffic (I’m not there yet, but Facebook, for one, is always urging me to buy traffic for my page, and they have my best interests at heart, no?  :-))
  4. Brainstorming how to get to “1000 True Fans”.
  5. etc.

This kind of multi-step process naturally decomposes into a set of subsidiary multi-step processes until you get to the point where you’re basically dealing with multi-step tasks.

(Sorry to belabor this. I can’t help myself :-))

What happens as we travel up the tree?

The projects become more and more:

  • General
  • Long-term
  • Goal-like

So the first four levels of the tree are essentially goals and projects.  The bottom four levels are essentially tasks and sub-tasks.

One might have a goal of Health whose subgoals are Control Weight, Strength training, Feel Better, etc.  Strength Training may go directly to a multi-step task of finding time to lift and lifting (since I already have a lifting routine in place).  But Feel Better is still pretty abstract, and its subs may be:

  1. Control Fear
  2. Master Pouting
  3. Feel what you actually feel
  4. etc.

These sub-projects are in turn complicated, and may consist of still further sub-projects or may go directly to a multi-step task.

Well, so the next step for figuring out the port from MLO to Todoist is mapping my multi-step things to either projects or tasks.

I thought at first I would do it automatically, but that began to seem like more elegance.  So I’m just going through my PIM and marking up multi-step things manually, some as projects, some as multi-part tasks.

It’s a good exercise in any case, since it forces me to look at a lot of projects I’ve become numb to in my daily and weekly grind.

And, in my book, no amount of effort spent on PIMCraft is too much.

Cabinet of Curiosities, CrummyCook

Cabinet of Curiosities: Farmer Cheese

I’ve blogged at this site — and, in the past, at crummycook.com — about my escapades in cooking, growing, and making food.

My latest attempt is farmer cheese.  This is a soft, bland cheese that is quite similar to cottage cheese but does not have a discrete curd structure.

I wanted to make it because my grandma had served it at breakfast years ago when I was a boy, and I, who didn’t like anything very strongly flavored, took a liking to it and asked her for it when we visited.

Her farmer cheese was a block of solid somewhat like halvah in texture, but easier to cut.

I ran across a recipe in Mother Earth News last year for making farmer cheese, and decided I would give it a shot.  Which I’ve finally done.

It didn’t come out 100% like Grandma’s.  In the first place, the lemon juice and buttermilk made the product slightly but noticeably sour, which would have dismayed young Danny but didn’t bug me.

More importantly, the cheese was too granular to slice.  You could scoop it up and spread it (like Boursin, perhaps), but I wanted to slice it as I had sliced my grandmother’s farmer cheese so many years ago.

My daughter and her vegetarian boyfriend put it on some vegetables my wife had whipped up and it crumbled nicely on top and was a great complement to the veggies.  Happiness all around.

Next?  I’ll make farmer cheese batch 2 or perhaps try a companion recipe for cottage cheese.

Deep Work, Developer stuff, Programming

Themes for Work and Learning: Week of December 16, 2018

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:

  • Generating the actual bytes that Todoist needs as input.  These are mostly in JSON, so 
  • Dig in to the JSON library in Go
  • Todoist makes a distinction between “projects” which are higher in the hierarchy and tasks which are lower.  Projects are allowed to have sub-projects up to four levels and Tasks are allowed to have sub-tasks up to four levels, so I have to somehow split my lovely MLO hierarchies into higher-level “projects” (with multiple levels) and each project ultimately owning a bunch of “tasks” with sub-tasks.
  • Set up a streaming connection to the todoist sync server to load the data
  • Regulate the flow of the data so that it doesn’t overload the server (or, what is the same thing, break any of the server’s load-throttling rules).

Should be fun.

Developer stuff, Programming

summing up the Week’s Work

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.

Personal Information Management, Tradecraft

The Elusive Search for Focus

Blogging yesterday about the Pomodoro Technique put me in mind of the search for focus, and how it has eluded me.

A good PIM should do (at least) three things for you:

  1. Show the relationship between goals (or higher-level constructs generally) and tasks.  Connect ends and means.
  2. Take all the “open loops” out of your brain (where they nag at you without peace) and put them in a trusted system.
  3. Help you decide what the best thing to do is in the present.

MLO is great for #1.  (Any hierarchical PIM would probably do.)

Any GTD-ish system is great for #2.  That’s the whole point of GTD.

But #3?  Bit of a mystery.

I used a PIM once — briefly — that sorted everything by importance and by what would fit into the open parts of your schedule and then told you what the next thing to do was. 

It was terrible.  All but unusable.  It was too tyrannical, too dependent on the weights you put on everything.

What I do today is gen up the tasks for the day on a list creatively called “@Today” and then pick something from the list each time I come up for air.

(Oh, and I try to get the “@Today” list to be something that could fit in the day.  I run through my list of things in the morning and see what I think I can accomplish.)

That’s where the religion of Pomodoro is supposed to keep you honest.  By comparing what you thought you could do in a day and what you actually did in a day you’re supposed to get “better.”

I’ve never given up on the notion that focusing on some small # of things (3? 1? One Thing?) will get more accomplished.

The problem is that I often pick things that are urgent rather than things that are important and end up not having much to show for a day or a week.

Am I just longing for someone or something besides me to tell me what to do?

(I have a trick I do sometimes where I get someone else to set me a deadline.)

(“Dan, please finish a draft of 7 Hard Problems by January!”)

(If I say this to myself it has no impact.  If someone else says it to me — even if I tell them myself to tell me — it has much more effect.  Go figure.)

It seems like a simple problem: figure out which tasks are most important and then do them.  But as I’ve struggled with trying to do just that over the past thirty-five years ( which was when I first started using software to help me manage my todo list) I have to admit that the goal remains elusive.

Benefit from my 35 years of tech industry experience