Another Poem, Riff Off 1 Cor 13

Perfect?

Completeness:
What I sought
when I was small.

Clarity:
What I thought
that I could call.

Calm:
What was not
were I to fall.

But if it fails,
or vanishes away,
or if I'm blind,
or mostly so today.

There is a promised tomorrow,
when that completeness will come
when I will see face to face
and know as I am known.

Poem for Grandma

I wrote a poem for my Grandma for Mother's Day.

Years

For when along
the road you've come,
you pause,
to see the race,
how it was run.

The mornings when imaginations sang
The afternoons when, interrupting
work and sun, the lightning cracked.
Then came the rain.
The evenings when all work was done.

Some goals were met.
Some riches won.
Some people left.
And not just one.

And then you stood.
Alone.
Dismayed.

But through
this turn and
that meander,
we kept,
we stayed,
we held each other.

Command The Computer

After hearing hype around machine learning eating up tech jobs, I've wondered if I just have my head in the ground about what kind of work I'm doing.  So far, I haven't seen a straightforward way to apply machine learning to my work goals.

However, today I realized I can start a mind shift toward my work that will be both more healthy for me personally, and will allow me to see opportunities for machine learning that I've been missing.

There are 4 main levels of work I can see:

1. Initiative
2. Project
3. Task
4. Micro-task

As an individual contributor or team lead, the aspects of the work are scoped down to levels 2-4.  Most of the opportunities I've seen for applying machine learning have been at the Initiative level, where statistical methods can be applied to solve novel problems or automate whole classes of new/existing work.

Now, imagine you already work at levels 2-4.  Imagine you have a computer with infinite intelligence.  Imagine that if you describe a piece of work that needs to be done down to the 80% level of precision, that this intelligent computer could get it done and take care of the details.  This is what I've found impossible to imagine in advance.

The best way I've found to imagine this is as follows:

• do a Task the way I've always done it (level 3)
• break the task up into atomic pieces by creating self-standing git commits as I go (one commit per level 4 Micro-task)
• when I write each git commit, imagine that I had asked a computer to do what I just did
• write the git commit in imperative form, as if I had commanded the computer to accomplish the work at the 80% level of precision
• imagine that I had spent the last 30-60min doing something other than solving the problem, and ask myself, "What else would I have been able to do while the computer was spending 15-30min on this?"

This helps me wire up the neurons in my own brain to start thinking about the computer as an intelligent agent that can assist me.  And it helps me to imagine how I can use my attention and energy more effectively, rather than just solving micro-tasks all day.

It appears to me that applying machine learning effectively requires stepping back at least to the Project or Initiative level and delegating more work to an "intelligent" computer.  And if such an agent doesn't exist, perhaps it can be built.

In a weird sort of way, I'm starting to use the Tell, Don't Ask principle in my own thinking to enhance my ability to imagine solutions coming together more quickly.  I know that's taking the Law of Demeter way outside of its traditional scope.  But I'm trying to break out of the box here. ;)

If 2018 was a year I didn't write any blog posts, it was certainly a year of great personal growth.  I look forward to writing here more during 2019.

Intractable Problems

Getting into the state of mental flow leads to enjoyment for me.  Whether it's playing a lively game of Monopoly with my kids, or playing/coaching an engaging soccer match, or developing the next feature for FamilySearch -- all of the above activities are more enjoyable when I spend a lot of time in the state of mental flow.

There's a book about this, and I still would like to read it at some point.  But today's post is not primarily about flow.

There are times when I know that a state of mental flow is possible, and desirable, but I can't seem to enter that state.  Maybe I'm meaning to write in my journal but the thing I want to write about is an unresolved problem of some importance to me, and I go into immediate problem solving instead of writing about it.  Maybe I'm trying to get going on a project outside but I'm exhausted from not getting enough sleep the night before.  Maybe I'm attempting to learn something new at work and there is too much new all at once.

Today I realized that when I have problems entering the state of mental flow, it's because I'm stuck trying to solve intractable problems.  See https://en.wikipedia.org/wiki/Computational_complexity_theory

Here are a few "intractable" problems I've faced recently:

• Which task would be most helpful for me to work on first this morning?
• What is important to deal with after a trip, and what can be dropped?
• Who can I get to help set up flags on Memorial Day?
• How can I get uninterrupted time to spend with my wife?
• What can I do to increase the likelihood of my son wanting to work with me outside?

The truth is the above problems are only "intractable" when attempted in a certain mental state that treats these decision problems as personal tasks.

Hint: It takes social skill & action to answer all of the above questions effectively.  And while the social skill can be learned, if you approach the above problems by thinking that they are personal tasks to be completed, they will by definition be intractable.

A useful word is "stall".  Some definitions, glosses, examples:

- https://www.google.com/search?q=define%3Astall

- http://wordnetweb.princeton.edu/perl/webwn?s=stall

- https://en.wikipedia.org/wiki/Stall_(fluid_mechanics)

So when you feel yourself get into a stall, think what intractable problem you are trying to solve.  And if it's a problem that needs social skills to solve, reach out for help.  Figure out what skills you need to develop and improve your abilities.

HELP: Happy, Evolving, Learning, Productive - Journaling template

Sometimes I go to write in my journal after lots has happened, and I find myself at a loss.  Too much has happened, I don't know what's important to record, it's all a jumble.  So I end up staring out the window and attempting a half-baked job of mentally processing things.

Here is a set of headings in an attempt to provide a skeleton for my journaling:

• H: Happenings
• E: Evolutions / Progress
• L: Learnings
• P: Plans

Or described more fully:

• H: just neutral reporting on what random stuff has been going on
• E: progress reports on things that have moved forward in some significant way in the last while
• L: what you've recently learned that sticks out to you
• P: what's coming up that has your attention

In an attempt at finding a mnemonic for HELP, I came up with the following:

• H: Happy
• E: Evolving
• L: Learning
• P: Productive

And here are some more detailed descriptions of the emotional states in the mnemonic:

• H: just starting to write can keep you happier than not, see this post
• E: highlighting progress, however small, turns into a sense of gratitude for me
• L: seeing that I'm still learning is encouraging to me
• P: putting rough plans on paper has a reassuring effect, and helps me move forward

Those adjectives have enough affinity to the headings that it might help me to remember them, and enough positive energy to help them to stick in my mind.

HPLP: Happy, Progressive, Learning, Productive - Journaling Ideas

Post rewritten here:
- http://deliberate-thinking.blogspot.com/2017/05/help-happy-evolving-learning-productive.html

With a better acronym.

Worry is a Signal, Not an Activity

"You look down today, what's going on?" my wife says when I get home from work.  I answer, "I don't know, I was just worrying about this project at work." What's wrong with this picture?

The mental error is that I was treating worry like an activity instead of treating it like a signal.  It's all about the self talk.  When there is some outstanding issue that needs attention, it is easy to jump straight to thinking about the issue, even though you can't really do anything about it at the moment.  The reality is that if I'm going to resolve the outstanding issue, I need my computer open, I need to talk with a team member to figure things out.  I need to write some code or run a query to see where things stand.

But if I attempt to sort things out mentally while I don't have everything I need to make progress on an issue, it's easy to spin my wheels and fall helplessly into a non-productive mental loop.

On the other hand, if the "outstanding issue" thought comes into my mind, and I call it worry (which it is), and instead of holding onto that thought, if I treat it like a signal, like an alarm bell, like a red light, then that frees me up to act on the signal.  Instead of treating the "outstanding issue" thought as an activity waiting to be engaged in, if I treat it as an self-alert, then I can move to deal with it at a later, more appropriate time.

The question becomes: "What action can I take right now to make sure that the outstanding issue is dealt with at the appropriate time and place?"  Maybe make a reminder on an index card and put it in my work pants pocket.  Maybe make a reminder on my phone.  Maybe send myself a memory jogger in email.  Maybe write a card and stick it in the Trello / Getting Things Done inbox.  It just needs to be something that I am confident will get my attention and lead me down the right mental path at the time when I know I will have resources to deal with the issue.

Any time spent on worry as an activity (beyond dealing with the reminder for the future time/place) I now believe to be worse than a total waste.  Not just worthless time spent, but also a drag on the rest of my life.  Any unnecessary, anxiety-provoking activity drags me down, makes me less capable of living my life in a worthwhile, enjoyable way.

Why did I not see this earlier in my life?  What could I have done to have learned this earlier in my adolescent / adult experience?

Where I've been

It took a long while, but I believe I'm back after a knee surgery in 2015, after releasing / launching a new tree database for FamilySearch in the last half of 2016, and after coming through a difficult transition into a more positive life.

Thanks to my family who supported me (especially my wife), my friends and co-workers who were patient with me, and those who have waited for me to be a bit more positive and responsive in life.

Rubber Ducking with Git

You've heard of the phenomenon where when you try to explain a hard problem to someone else, you suddenly know the answer, and the other person did nothing but listen to you ramble.

On the C2 wiki, it's called:

• http://c2.com/cgi/wiki?RubberDucking
• http://c2.com/cgi/wiki?CardboardAnalyst

The theory I have about the phenomenon is that in a problem solving situation, the human mind develops a lot of parallel ideas & possible solutions, even ones that you are not aware of.  But when you try to describe the problem and your ideas to someone else, just the act of trying to explain the situation helps you see it more clearly and links the ideas together better in a way that you become aware of more possibilities than you were able to see before.

But I've always had a problem talking to inanimate objects.  Call me less imaginative, I guess.  Or timid, maybe.

Well, I've had the feeling for a while now that using Git with small commits made me more productive.  And I just realized, I'm using my future self as a rubber ducky, and that the act of writing explanatory commit messages to explain things to my future self is a source of ideas for me.

Kent Beck about steering code via tests

I was about to send this to my team, but then I realized this is a blog post.

Here is Kent's article:

    https://www.facebook.com/notes/kent-beck/driving-development-tests-as-a-steering-wheel/719644314735102

And here is a related tweet from him on that topic:

    "selecting the next test is an act of design"

    https://twitter.com/KentBeck/status/438709708887560192

I've always thought about "design" as choosing which classes exist and how they relate to each other, and what methods look like, etc.  Or at a system level, deciding which services exist and what their core of responsibility should be.

However, I never thought about gaming my own mind (like applying genetic algorithms to my own thoughts), and choosing to introduce tests in different orders -- in order to produce a different neurophysical response from myself.

Perhaps "design" is not just about a static system and what to include.  Perhaps "design" is about acknowledging the dynamism of the human/computer programming environment, and leveraging that dynamic nature in order to get a more optimum response.

Seen, Persuaded, Embraced, Confessed

One verse in Paul's description of the fathers of faith stood out to me:

Heb. 11:13 These all died in faith, not having received the promises, but having seen them afar off, and were persuaded of them, and embraced them, and confessed that they were strangers and pilgrims on the earth.

I've watched true followers of Jesus Christ demonstrate their devotion to Him in ways that involve all four elements of conversion.  In fact, I'd be willing to take this verse as a starting point for describing what true conversion is like.

It seems to me that this pattern of increasing commitment and devotion is tightly involved in the process of understanding what one's personal mission in this life is.  When it finally gels, there isn't anything else but just to go do your life's work, and give your whole self for your Lord Jesus Christ and what He's called you to do here.

Semantic Versioning

After having skimmed the semantic versioning proposal/spec, I really like it, and I'm going back for a deep read.

The most notable violator of this that has bit me in the past has been the jersey framework, and maybe earlier versions of commons-collections.

Git as Menograph

Background

In Mar. 2010, Matz came and talked at MWRC.

The awesome talk focused around Ruby as a great invention that makes it possible for programmers to bring a new world into being that could only be imagined before.

He made reference to the inventor in Hugo Gernsback's book: Ralph 124c 41 +.  The name was a play on words "One to foresee for one", with "+" being reserved for the 10 or so greatest inventors currently living.

Although Matz's reference could be interpreted as prideful, anyone who has ever had anything to do with him would correct you -- he is a very humble programmer who does awesome stuff.

Because I wanted to understand Matz's reference very thoroughly, I went and read the book.  I was able to appreciate the scope of Matz's talk much more clearly after having read about Ralph, the great inventor.

Menograph, the invention

One thing that Ralph invented was a Menograph.  It was a mind-recording device, operated by pressing a button that started a mind wave recorder and operated a scroll of fabric on which the waves were traced in ink, similar to an old-style seismograph.

The Menograph was one of Ralph 124C 41 +'s earliest inventions, and entirely superseded the pen and pencil.  It was only necessary to press the button when an idea was to be recorded and to release the button when one merely reflected and did not wish the thought-words recorded.

Those thoughts could then be replayed again verbatim by any person by use of a device called a Hypnobioscope.

After reading an account of Ralph using this invention, which is more detailed than I am able to reproduce here, I had a vague sense that I had experienced a similar feeling before while programming.

Git as Menograph

After thinking about it for a while, I realized that how Ralph used his Menograph is how I use git.

While coding, I work on stuff, then I record commits into git.  Then I work on stuff some more, then record commits.

Then I take passes back over what I've recorded and get rid of the bad stuff and keep the good stuff.  Then I push it out to the team.  Sometimes, a pair or triple on the team do this as a group exercise, working history over a few time until it won't break the world.

The parallel to git was eye-opening.  In fact, after having noticed this behavior in myself, and seeing the behavior tendency grow over time, I'd say that git encourages multi-pass thinking styles.

P.S.  If you care at all about Ruby, listen to Matz's talk.  Some of the future stuff he was talking about is already in Ruby 1.9.2.  NOTE: I'm on linux, and I had to use the flash player to get the video to show.

Attention to Error vs Attention to Detail

After having read Talent Code, a friend pointed me to the following article:

Why Do Some People Learn Faster?

Although the author of that article had gotten some lackluster reviews on some of his book-length work on Amazon, this article brought a distinct idea to the forefront for me:

Attention to Error

I've always thought that attention to detail was an important tendency in myself that made me a good learner.  But I realized that there is a distinction between paying attention to detail and paying attention to error.

The constant reconciliation between what you believe to be correct and what turns out to be correct is the fuel for my personal learning.

Some people might say this is what the scientific method is all about.  I'm less methodical than a scientist would be -- I find it nevertheless useful to constantly put myself in situations where I can learn informally from comparing what I expect to what actually happens.

Keeping a Beginner's Mind

As an experienced software developer, I care deeply about retaining my ability to remain flexible in my habits and learning style.  That's the only way I got good, and if I ossify in my learning habits, I'll end up the equivalent of a COBOL programmer.  Certainly not the way to live up to the broad possibilities that exist to make the world a better place.

I appreciated the wider perspective that I got from glancing through these slides by Patrick Kua:

The Beginner's Mind

Although I had seen and skimmed Pragmatic Thinking & Learning, this presentation was a gentle and useful introduction to the whole idea of the Dreyfus model of skill aquisition.

Another very useful idea that this presentation expressed was the contrast between "skill-acquiring apprentice" vs. "closed-minded expert".  Patrick said that the "skill-acquiring" attribute can also apply to highly-skilled practitioners.

Among the tips Patrick gave, the following were useful to me:

• You can't be an expert on everything. [so don't even try]
• How can I try this safely?
• How does this fit in my world?
• Remain curious.
• Mix with diverse groups.
• Beware of built-in biases.
• Avoid judging early.

The reason I decided to compare/contrast some of the ideas in this presentation was actually because of my forays into the Pragmatic Thinking & Learning book, which was one of three "Further Resources" offered at the end.

Patrick recommended the following books for further learning:

• Pragmatic Thinking & Learning
• Apprenticeship Patterns
• Changing Software Development

Because of the context in which the Apprenticeship Patterns book appears, I want to read that as a next step for learning how to make a real difference at FamilySearch.

Flesh pots & Resistance to change

I was reading the account of Moses leading the Isrealites out of Egypt. After all of the miracles that accompanied the exodus comes the account of the net sum response of the Isrealites (Exodus 16:2-3):

2 And the whole congregation of the children of Israel murmered against Moses and Aaron in the wilderness:

3 And the children of Israel said unto them, Would to God we had died by the hand of the Lord in the land of Egypt, when we sat by the flesh pots, and when we did eat bread to the full; for ye have brought us forth into this wilderness, to kill this whole assembly with hunger.

I'm sure that my response to inspired leadership has sometimes sounded like this. And I'm very much willing to both admit that and abandon that position.

In stark contrast, is the message contained in Pres. Henry B. Eyring's conference talk, Trust in God, Then Go and Do. In particular, another scripture comes to mind (1 Nephi 3:7):

7 And it came to pass that I, Nephi, said unto my father: I will go and do the things which the Lord hath commanded, for I know that the Lord giveth no commandments unto the children of men, save he shall prepare a way for them that they may accomplish the thing which he commandeth them.

Willingness to move forward and change and follow inspired leadership is a quality that I value, and that I seek to emulate & encourage.

Published with Blogger-droid v1.6.7

Heroes and Monoliths

I'm sure it's no surprise to anyone, but huge, monolithic software is extremely hard to ship.

It used to be that when I encountered a particularly complex software problem, I would work at mastering the complexity until (by hook or by crook) I figured it out. Then I would proclaim myself victor. It was often the case that people were waiting for me to figure out the hard problem, and would congratulate me on a successful resolution.

However, those congratulations feel empty to me now. I think I can finally appreciate what Dijkstra meant in The Humble Programmer (and here), argument #6:

... the only problems we can really solve in a satisfactory manner are those that finally admit a nicely factored solution. ... By the time that we are sufficiently modest to try factored solutions only, because the other efforts escape our intellectual grip, we shall do our utmost best to avoid all those interfaces impairing our ability to factor the system in a helpful way. And I cannot but expect that this will repeatedly lead to the discovery that an initially untractable problem can be factored after all.

Now I remain unsatisfied until I've solved that problem at hand "in a satisfactory manner", i.e. in a manner that is tractable to read, understand, and change in the future. Not just for me, but for any other competent software developer that comes behind me.

I think this links to the IEEE Code of Ethics, items #5 and #6, in which computing professionals agree:

5. to improve the understanding of technology, its appropriate application, and potential consequences;

6. to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;

While I was writing this, someone came over and asked me a question about complex software I wrote part of, and I helped him. And I laughed at myself for being unsatisfied about helping him. :)

5 Minute Send

There is something that happens in my mind when (and only when) I push "Send" on an email.

This mental process says "oh, I wonder how it will look when they get this email". So then I go back and look at the email from a completely different perspective -- from the perspective of the recipient. Everybody has a "missed attachment" feature or plugin. But nobody has a "missed idea" feature or a "missed stupidity" feature.

I wish all the email clients I use (gmail, outlook, other webmail) had the following two features:

• "Send" (on a draft message) which means: send in 5 minutes
• "Send All Pending" (on a global menu, not on a message)

Then I could get the benefit of focused authoring *and* self-review when I press "Send" and think "oh, what have I just done".

P.S. I really like blogger's "Post date and time" feature, and I use it all the time.