the 555 graham cracker (or how to communicate a tech idea clearly)

We all know that sharing technical information in a clear (and ideally visually appealing way) makes it more memorable and understandable.  I saw a perfect example of it today with the electronics example of making a 555 timer.

What most descriptions do

  1. Tell you what you need so you can start out with supplies.
  2. Provide an overview
  3. Provide a circuit diagram
What good descriptions do
  1. Give you tips
  2. Show clear pictures of the completed breadboard.  Ideally from different angles.

What blows me away

The graham cracker 555 timer.  It has everything that really belongs in the 555 timer:

  • 555 chip – chocolate looking thing in middle
  • 9 volt battery – chocolate looking thing on lower left
  • three resistors – marshmallows with color stripings.
  • 1 microfarad capacitor – candy in top right
  • LED – red jelly thing
  • Wires – blue and red frosting
This is accurate (or at least really close).  It grabs your attention and makes you want to understand the concepts in mapping it back to the real one.  And it’s memorable.  Just what you want in your tech documentation.

How do I use this?

Remember tech documentation doesn’t have to be boring.  The Head First series uses cartoons.   The Developer’s Notebook uses journaling.  Manning usually uses stories and jokes.  All of this serves to keep us engaged in the material as we read.  If our brains are paying attention, we learn more.

What I didn’t tell you was that the wiki page was written by a high school student.  Don’t lose that skill after you graduate.  We need more tech writers who remember being fun fits in!

types of info sharing sites

I recently deleted someone’s thread at coderanch where the post was just links to blog posts.  There’s a time and place for everything.  Which got me thinking about where it belongs.  Let’s look at some social media sites for Java.

Sharing links

Starting point is sharing links followed by comments/discussion.  I’m leaving out the framework specific forums like Spring’s.

Forums or Q&A

Starting point is a question or discussion topic.

Q&A only

I separate stack overflow because it is more Q&A focused than the forum sites.

What else?

What others do you use?  Which is your favorite?

the trust cycle vs the hype cycle

Most of have seen the Gartner hype cycle graph – shown here from wikipedia.  This got me thinking about what would happen if we tried to do the same thing – except with trusting our teammates to see how they compare.  I’m calling that the “trust cycle.”  While we do hear a lot about trust and team in agile, the only place I found using the term “trust cycle” wasDavid Weiss’ blog.

The beginning:

With the hype cycle, we start at basically zero.  We haven’t heard of something and we remain skeptical until we hear a little.  Then we get too excited.

With the trust cycle, I think you start more in the middle.  When you first meet someone, you don’t inherently trust or distrust them.  And at the beginning, people are pretty cautious and don’t do anything to change that.

The middle

With the hype cycle, the trigger for change is reality.  We go from inflated expectations to seeing what the technology can really do.  Since our expectations were too high, we fall harder.

With the the trust cycle, the trigger for change depends on whether it is positive or negative.  For positive trust (teambuilding), it just takes time.  Our trust level slowly goes up until we trust the person fully.  For negative, the jump happens much faster.  Either as a series of little things that make you suspicious (as shown in the graph) or as one big thing that causes a series drop.  Once we’ve dropped, trust either stays at rock bottom or gets re-earned very slowly.

The end

Both cycles stabilize at the end.  The hype cycle stabilizes at reality.  The trust cycle stabilizes at either trust or distrust.

Conclusion

This stickyminds article talks about how to build trust.  What do you think about the trust cycle?