Running A Marathon (relay)

I ran in my second running race today – the Silicon Labs Austin Marathon Relay.  It’s sponsored by Silicon Labs, my employer.

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!

Technology vs. Psychology

Do you write software for a living?  Or design hardware?  Or maybe some of each?  While the particular projects any two software or hardware designers do may be worlds apart, we can characterize what we do in the same way: our work is 20% technology and 80% psychology.

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!

Geeky Grammar

Holy Parenthetical Emoticons, Batman!

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 😀 )
  • 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 😀 ).

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

Define the problem, define done

I. M. Wright’s latest post “Green fields are full of maggots” talks about defining the problem and defining done.

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?

M&M’s Musings

We have an M&M’s-filled candy machine at work and we wondered:

  • 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.

Google closing Austin office

It seems like just yesterday Google was celebrating the opening of their new office in downtown Austin, Texas – actually, it was mid-October, 2008, according to the Austin American Statesman (google has the story in their cache, but the Statesman’s link doesn’t work).

But today Google announced that they are closing the Austin office, along with offices in Trondheim, Norway and Lulea, Sweden, in order to “build larger and more effective teams, reduce communication overhead, and give engineers increased options for future projects” :

http://googleblog.blogspot.com/2009/01/changes-to-engineering.html

Google says they’ll try to keep people from those sites at Google, but of course the employees would have to move to larger Google sites.  That makes sense for Google in terms of managing tons of projects, sites and people, but that’s a real bummer for the Austin Googlers.

Again, from the Statesman:

“We really do like Austin, we like the engineers in Austin, we like the town, we like the geography, but there just wasn’t any way in the short term or medium term to really grow the office to the size that Austin deserves,” [said Alan Eustace, Google senior vice president of engineering].

Hopefully Austin tech companies can pick up some good talent from those who don’t want to leave Austin.

Book Review: Blog Blazers

I just finished the book “Blog Blazers” by Stephane Grenier. My three word review: “Not too shabby.”

I have to admit this book wasn’t exactly on top of my “to-read” pile. I’m not usually a big fan of blogs/books about blogging, podcasts about podcasting, etc. – it’s all too meta for me. But Ian Landsman was offering a free review copy on his blog, and I’m a sucker for free books, so I gave it a shot.

“Blog Blazers” consists of 40 interviews with popular and successful bloggers, including Andy Brice, Bob Walsh, Dharmesh Shah, Eric Sink and Jeff Atwood. Stephane asked each person the same questions, including:

  • What defines a successful blog?
  • Do you have any tips or advice on writing?
  • How do you market your blog?
  • What is your best monetization method?

Because each interview followed the same form it became a little monotonous to read in one sitting. I could only take about ten at a time. Many of the answers were repeated by several of the interviewees, which was a bit boring, but the repetition confirmed that their advice is probably good. Or they’re all suffering from groupthink, but I’ll go with the first reason.

As I read the interviews I asked myself, “So what? Will this change anything I do?” I came away with these thoughts:

  • Original content vs. commentary: try to write as much original content as possible, as opposed to just commenting on others’ content. For instance, don’t write book reviews. 🙂
  • Use your own domain, instead of myfreeblog.wordpress.com or myfreeblog.google.com. That’s next on my to-do list.
  • A lot of bloggers get found through StumbleUpon – I haven’t used that in a long time, maybe it’s time to check it out again.

Nothing earth shattering, but it’s a lot of good blogging advice. The book also included a number of blog(er)s that were new to me, some of which are now in my RSS reader.

My favorite quote was from Eric Sink. When asked “How long does it take to become a successful blogger?” Eric answered, “The time varies so much that any answer would be incorrect. I’ll just say this: Some things are not under your control. Persistence is.” (emphasis mine)

Becoming internet-famous overnight probably ain’t gonna happen – the best way to develop a good blog is to be persistent about writing good content.

So there you go – it was a decent read, well worth a trip to the library, and maybe even purchasing if you want advice on building your blog.