A few days ago I switched to a new theme that I really liked, “LonelyTree.” One of my favorite parts of that theme was the header graphic: a great big, beautiful, wise looking tree.

Today I got an email from Oliver Flores, an artist from Guadalajara, Mexico, saying that the image was his, and could I please take it down. His email was very polite, and he gave me this link to his original image: http://oliverflores.blogspot.com/2007/10/grow.html

A quick look told me that the LonelyTree theme seems to have ripped off Oliver’s image, so I changed my theme and sent Oliver info on where I got it.

I browsed through some of Oliver’s other art, and it’s really good! You should definitely check it out. So even though I lost a great header image (for good reason!), I have a new artist to follow.

Nice, eh?

Though that little heart favicon has got to go.

Today’s race was a 5K, sort of.  There were five people per team, each ran one part of a marathon: 12K, 10K, 10K, 5K, and 5K.  I ran the penultimate 5K and blew away my time expectations – I guess I wasn’t training hard enough.

I’ve been training three days a week for the last month or so, doing 1-2 mile runs the first couple of weeks and then 3-4 mile runs the last couple of weeks.  I was running 10-11 minute miles pretty consistently, so I was hoping I could get near the 10 minute mark for today’s 5K.

I clocked myself at around 8:13 for the first mile.  Uh-oh.  Note to self: SLOW DOWN!  I realized during this first mile that drinking water from a cup while running is a skill that I do not possess.  The course had water stations, and I happily grabbed a Dixie cup of water only to choke and cough as I tried to take a regular sitting-down-at-dinner drink.  I recovered without spitting up too much water, poured the rest on my head, and ran on.

Mile two flew by.  I clocked myself at 7:10.  Uh-oh.  I wasn’t slowing down, I was speeding up!  Note to self: learn how to pace yourself.  I was worried that I would start dragging and have to walk.

The final 1.2 miles were definitely slower: my time was 13:08, which works out to about 11 minutes/mile.

My final 5K time was 28:31, which is 9:11/mile.  I felt pretty good at the end of the race, I ran the entire way, and I beat my time goal.  It helped that my wife was there cheering me on, as were a bunch of coworkers who were also competing.  (I think at least 30% of my department was running, including my entire management chain up to the VP.)

Our team (”Tortugo”) ran the entire marathon in 4:10:03, which I think is pretty dang good.

I look forward to running more 5K races this fall, and hope to work myself up to a 10K or two as well.  I think I may have even talked my wife into doing a 5K with me, which should be fun.

As I continue training I need to learn how to pace myself better, and push myself more – 9:11/mile felt pretty good, 8:30 here I come!

Most of the work we do is 100% solvable – it “merely” requires people and time to accomplish.  It may be difficult, it may be risky, but it’s doable.  Most projects don’t require quantum leaps in technology to accomplish – current hardware and software platforms will do just fine, thank you.  Most projects don’t fail because the IDE wasn’t up to the task, or the compiler, or the linker.  Most projects fail because of the carbon-based part of the tool chain, not the silicon-based one.

All projects have some inefficiencies and problems.  They always start small but aren’t life- (or project-) threatening:

• The build process is manual and annoying, and therefore error-prone; but most engineers run it before checking in new code, and the errors are always found quickly enough.
• Code drops from external groups happen less frequently than we’d like, but it’s been okay so far.
• The external contracting team has found a few bugs in the spec, but it’s nothing that can’t be fixed later, and we don’t have time to check the spec right now.

None of these problems will doom your project on their own.  And because you can live with the status quo, you won’t fix them now.  “I’ll get to that later when I have more time.”  But as the problems multiply, build in intensity and (gasp!) start to constructively interfere with each other, your forward progress will slow down.  It will take longer and longer to do what used to be quick tasks.  Many aspects of the job will become more frustrating, and morale will go down.

Inefficiencies and problems don’t persist because we lack the appropriate technology to fix them – they persist because we lack the appropriate psychology to fix them!

That’s an important thought, so I’m going to repeat it:

Inefficiencies and problems don’t persist because we lack the appropriate technology to fix them – they persist because we lack the appropriate psychology to fix them!

How do we address the psychological aspect?  We need to trick ourselves into doing the Right Things in the Right Ways to make continual progress.

Here are two guidelines for doing the Right Things in the Right Ways:

1. We MUST make activities that are good for the project as easy as possible and as enjoyable as possible. 
   • Can your pre-commit tests be run automatically?  Yes?  Great – do it!  Make sure they run reasonably quickly, with easy to read status updates.  When the tests are done and passing, can we help the user enter a helpful commit message by supplying a list of the diffs automatically?  Yes?  Great – do it!
2. We MUST make activities that are bad for the project as difficult and miserable as possible. 
   • Checking in without passing all tests?  Okay, but you have to run this ugly command line, fill out the TPS reports on this slow web page, and get a note from your mom.  Consider making “bad activities” impossible.  Checking in without passing all tests?  IMPOSSIBLE!  Can’t be done.

Two of my favorite geniuses agree with me, so I must be right:

• Albert Einstein said, “Everything should be made as simple as possible, but not simpler.” We need to worry about making our processes as simple as possible.  Don’t worry about making them too simple, I doubt we’ll get that far.   Can you make it simpler?  Yes?  Then do it!
• Kathy Sierra said, “Make the right things easy and the wrong things hard.“  She says it much better than me – go read her post!

Of course sometimes we don’t have time to improve a process right now, because we (hopefully) have paying customers banging on the door, deadlines to meet, product to ship.  You’ve got to pick your battles and manage your time wisely.

But we geeks need to spend more time thinking about our psychology – the “how” and “why” of what we do – instead of just focusing on the technology – the “what” we do.

The earlier you find and fix inefficiencies and bugs in a product, the more time and money you save.  In the same way, the earlier you find and fix inefficiencies and bugs in the way you create a product, the more time and money you save.  But you get an extra bonus from improving the way you create a product because it produces not just a one-time boost, it produces a many-time boost!  It’s like compounding interest.  Actually, it’s not just like compounding interest, it IS compounding interest!

I’ll be messing with the formatting, style and everything else over the coming days, so please excuse the mess.

I’m glad that Randall has the guts to tackle the tough issues facing the world today: emoticons in parenthesis. Check out the comic.

Since I’m starting my own copyediting and proofreading business, this issue is particularly timely and relevant for me.

Randall outlines the basic options:

• blah (or blah :)
• blah (or blah :) )

The first option looks like the author threw an extra colon in there.  The second option looks like the author mashed the keyboard with her elbow.

We also need to consider these options:

• blah (or blah :-)
• blah (or blah :-) )
• blah (or blah :-D)
• blah (or blah :-D )
• blah (or blah :-)-)
• and what about (this (or this (it gets ridiculous fast :) ) )

“American” English writing style is primarily dictated by two style guides: The Chicago Manual of Style (CMOS) and The AP Stylebook.

I could only find references to emoticons and parenthesis in CMOS, and it dodges the question (source):

Until academic standards decline enough to accommodate the use of emoticons, I’m afraid CMOS is unlikely to treat their styling, since the manual is aimed primarily at scholarly publications. And the problems you’ve posed in this note give us added incentive to keep our distance.

If the experts are no help, what are we to do?

Thankfully the web makes everyone a Certified Internet Expert (including me :) ), so follow along as I puzzle it out.

Round One

• As a programmer I want each open parenthesis “(” to match exactly one close parenthesis “)”.
• As a writer I realize that an emoticon must be considered as a whole, not merely as a collection of individual characters.  Therefore any parenthesis or other character within an emoticon should have no bearing on the punctuation of other words.

Round Two

• As a programmer I know that I will try to visually match each parenthesis pair I see.
• As a writer I find “) )” slightly less offensive than “))”.

Round Three

• As a programmer I will use sed or vim or a Firefox hack to rewrite any text I don’t like, so I don’t really care what you writers think.
• As a writer I want the rules that govern “:)” to match the rules that govern “:D”.

The Decision

As a Certified Internet Expert I decree that emoticons shall be considered as a single symbol.  An emoticon shall always be followed by a space.  If an emoticon ends a parenthetical phrase, the closing parenthesis that matches the opening parenthesis must be used, regardless of whether the emoticon itself contains a parenthesis.

Correct examples:

• He said he would be happy to do it (he lied :) ).
• He lied (she knew he would :D ).

Tune in next time for another exciting episode of geeky grammar.

My favorite quote (which is, itself, a quote):

“What’s so evil about general solutions? After all, your code could be both a floor wax and a dessert topping.”

He makes some great points about building software to solve a real, concrete problem, instead of building software as a semi-abstract-solution-that-could-solve-any-problem-possibly-the-one-people-are-paying-us-for.

My second favorite quote (second favorite only because it doesn’t quote Saturday Night Live) sums up the danger of the abstract:

“You put the problem at the center instead of the customer. When the customer isn’t at the center, your code loses its soul. It goes from being astounding to being adequate, from marvelous to mediocre.”

What is your goal?  Mediocre, or Marvelous?

• What do you call it when you get exactly 6 M&M’s in a single turn of the dispenser, one of each color?  M&M Yahtzee?  Full House?
• And how about when you get more than 6 M&M’s in a single turn of the dispenser, with at least one of each color?

Suggestions?  Please leave a comment!

PS: the 6 M&M’s colors are red, orange, yellow, green, blue and brown.  See for yourself.