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.

Link to Paper

Dear Lazyweb,

I've wanted to link to pages of books, or at least down to the chapter, or subhead.

Take, for example, the following blog post:

http://deliberate-thinking.blogspot.com/2010/04/reality-quotient.html

In that post, I refer to printed, copyrighted content by URL, but with lame google books URLs that have nothing to do with the structure of the book, and that border on the potentially problematic situation traditionally called "deep linking".

Look for the following text in the blog post:

• text: Total Useful Mental Discriminations
• and link: http://books.google.com/books?id=563gvssRPvkC&lpg=PR1&dq=slack&pg=PA72#v=onepage
• text: capable people are credible
• and link: http://books.google.com/books?id=31Qe_e61Y10C&lpg=PP1&ots=bBbef5O2a3&dq=speed%20of%20trust&pg=PA92#v=onepage

Do you know of any way that I can manage a list of URLs per book that are just markers for the sections within that book?

Not page linking, but sections as defined by the work itself.  No content extraction except perhaps to put the subhead text in the URL itself (either in English, or in the work's native language, or both).  Now there would be a global permalink for a given chunk of a work.

So, as an example of what I'm shooting for, the following author has already done this with his book:

http://book.personalmba.com/bootstrapping/  (full of promotional material)

Even though this page is full of promotional material, the link itself has value, because now I can refer to that small section of the book and talk about my own ideas, relative to that section.

And I can do so in a web-friendly way, with a meaningful URL.

The closest think I found was OpenLibrary itself with canonical URLs to Works and Editions.  But has anyone done "link to paper" in a general sense?

Sincerely,
John...

Word Mixed With Faith

The Savior said:

Ye shall know them by their fruits.

Paul wrote to the Hebrews:

For unto us was the gospel preached, as well as unto them: but the word preached did not profit them, not being mixed with faith in them that heard it.

It feels a lot like the recipe for inspiration and blessings from God includes the following ingredients:

1. Word of God, shared or published
2. Faith in those who receive it

Mix the word with faith, season well with humility, patience & repentance.  Harvest the inspiration and blessings that God wants to give you.

Using dot from graphviz

The whole graphviz package is an amazingly useful piece of software.  Especially the dot program.

I've watched other people hand-craft Visio documents that go out of date really fast.

I've also watched developers try to use design tools for high-level sketch kind of diagrams and get bogged down with superfluous code-sync features.

When I want to illustrate a point, just plain old boxes and arrows work wonders.  Especially when I can commit the source and be able to tweak it afterwards.

I've found that dot meets and exceeds the my common use goals.  I would guess that 80% of the time, the diagram communicates what I want to say without any tweaking at all.  About 15% of the time, it takes some layout/shape/font/color tweaking to get the message across in a clear & direct manner.  About 5% of the time, I have to output the graph as SVG and load it into Inkscape for further slight tweaking.

Here are some especially helpful links:

• official site
• gallery of examples, also 
• up-to-date language reference, and other documentation
• outdated, but very well-organized Users Guide
• dot-functions.sh

The last piece of software is intended as a helper for invoking dot quickly from the command line as part of a REPL authoring flow.

To use dot-functions.sh, first download it.  The script defines a bash function that can be used from a bash CLI.  Source it into the current shell by doing: source dot-functions.sh, followed by dot somefile.dot.


Here is the source of dot-functions.sh:

Another very helpful article was written on this topic by Diomidis Spinellis.  Now that I think about it, there is another very helpful article about how to get a hand-written sketch into digital form.

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.

Any reason not to post this?

I remember reading Tim Bray's first post at Google, specifically the part that talked about continuing to post without editorial comments from his employer.

It was then that the whole Cluetrain Manifesto finally clicked for me.

And I realized that the real question wasn't:

Would this topic be something I could post on my blog?

but was really a quick:

 Any reason not to post this? (right before hitting the Publish button)

 Seems like I've been kind of dense about this sort of thing.