I'm assuming the sales clerk burst out laughing as soon as we left the pet shop.

Wait, let me give a little background here.

My daughter's quest to get a hamster has become rather a public spectacle, having been mentioned here in a blog entry as well as in one of SourceGear's comic books.  Anyway, her birthday was this weekend, so it seemed like time.

The Champaign Petsmart is designated as "male hamsters only".  In retrospect, perhaps we should have gone there.  But so many people encouraged us to "buy local" that we decided to visit Sailfin Pet Shop, just down the street from SourceGear's offices.

In Sailfin's defense, I would like to say that they provided us with a good price and excellent service.  In this case, "excellent service" means that they kept a straight face when we asked if the hamster could be pregnant.

You see, Lydia wanted a white hamster.  No other color would do.  And there was only one white hamster in the store.  And it was a female.  So we bought it anyway, but not without asking the otherwise very helpful sales clerk if there was any possibility that "Spunky" could be pregnant.  With no facial expression at all, he looked at the hamster and said, "Yes, that is possible."

Eighteen hours later when our family's talk of the hamster abruptly switched to the plural, it became extremely clear that this sales clerk not only knew darn well that Spunky was knocked up, but he could probably tell at a glance that she was in early labor.  I mean seriously.  We brought the rodent home one afternoon and she was pushing out offspring the next morning.  The Sailfin guy does this for a living -- he had to know.

In contrast, I don't know anything about hamsters.  All I know is that if the current birth rate of one new generation every day continues, I will have hundreds of billions of these little tribbles by Christmas, so there will be plenty to share.

So, if any of you would like to bless the geek in your life with the gift of a hamster at the holidays, please let me know.  No charge, as long as you come to Champaign and pick up the rodent in person.

On the other hand, if you would prefer not to travel to Illinois just to pick up a five dollar furball, consider gifting one of Andy Brice's geek T-shirts instead.  They're nice shirts, the proceeds are going to charity, and they've gotta be less hassle than a hamster.

The genesis of this article happened back in May when I posted a blog entry containing the following snippet:

And finally, for something completely different, don't miss the Jam Session at Tech-Ed on June 3^rd.  Several of us minions from SourceGear are planning to take the stage and give our rendition of Pinball Wizard.  It'll be me on acoustic guitar, our development manager Jeremy Sheeley on bass, and our product manager Paul Roub playing the Evil Mastermind Schecter PT that will be given away later that week.

BTW, I'm not a very good guitar player, but the jam turned out OK.

Anyway, the first comment on that blog post was from a reader who said:

3 managers. Wow. Your company must be growing and/or is fairly large.

The person who made that comment was probably using the word "manager" to refer to "someone who manages people".  If so, then yes, our company has more than 3 managers, but not all of the 3 people playing Pinball Wizard qualify:

• Jeremy Sheeley is actually a manager.  He runs the development team that builds Vault and Fortress.
• Strictly speaking, I suppose I am a manager.  But people who know me would say that referring to me as a manager is an undeserved compliment.
• But Paul Roub is a "product manager".  Here at SourceGear (and in most other companies I know), a product manager is not [necessarily] someone who manages people.

So when I saw that comment, I told myself I should write an article about the role of a product manager.  This is that article.

(BTW, the content of this article was my presentation (video) at the Business of Software conference in September.  For more information about this event, keep an eye on the Business of Software conference blog.)

What is a product manager?

In short, a product manager is a marketing person who focuses on strategic stuff and stuff that is specific to the product.

When people think of marketing, their thoughts often run to things like logos, graphic design, and advertising.  This is the communications side of marketing.  We call it "marcomm".

The other side of marketing is the stuff that is more focused on the product itself:

• Positioning
• Differentiation
• Features
• Competition
• Market research

These activities are the domain of the product manager.

I still remember the moment when I first started to learn this distinction.  Back when I worked at Spyglass, one of my peers asked, "Why don't we have any product marketing people?"

I said, "What do you mean?  We've got marketing people.  Marc and his team just spent six months deciding which Pantone shade of red we're going to use for our logo.  That's marketing, right?"

The discussion that followed my clueless remark was very enlightening.

Managing Products vs. Managing People

There is a confusion caused by the word "manager".  As noted before, a product manager doesn't necessarily manage people.

To highlight the differences between product management and people management, I'm going to start by offering a brief but reasonably complete lecture on managing people in a software company.

A Brief but Reasonably Complete Lecture on Managing People in a Software Company

Stop treating them like children.

That's it?

Yep, that's it.  Stop treating them like children.

If you follow this rule and all of its corollaries, you will be a competent manager, thus placing you in the top one percent of all managers in the software industry.

Software professionals are grownups.  They do not deserve to be treated like children.

On the other hand...

Unlike your coworkers, software products deserve to be treated very much like children.  They're rebellious and wayward.  They need to be given strict boundaries and lots of guidance.

Like children, products go through stages.  Joel Spolsky said that "good software takes ten years".  Those ten years are not all the same.

The life of a growing software product has six different stages.  And the progression of those stages is a lot like the stages of parenting a child.

• Each stage requires a different approach.
• There is a gradual progression from "high control" to "letting go".

Stage 1:  Prepare

In parenting, the first stage is conception and pregnancy.  In software, this stage covers all the time before your first product release.  The key concept for this stage is "prepare".

This is the stage where you find a product idea and dream about what it might be when it grows up.

Product managers in stage 1 tend to make the same mistake that a new father makes:  He believes that since the mother (the development team) is carrying the baby (writing the code), he doesn't have anything to do.  All he has to do is wait until the kid is old enough to throw a baseball around, right?

Prepare

As a product manager, stage 1 is perhaps your most important stage.  You have a lot of preparation to do if you want your product to be successful.

• You need to figure out your positioning.
• You need to clearly define your differentiation. 
• And you need to figure out how those two things are going to express themselves in every other aspect of the product.

This is challenging stuff, and you have to do it now.  Later it will be too late.

Fail

Anybody else remember the Apple Pippin?

When I speak at conferences, they sometimes introduce me as "the person who led the team at Spyglass who built the browser that Microsoft licensed to become Internet Explorer".  That's true, but it is an incomplete rendition of the truth.

Spyglass licensed its browser to around 120 different companies who released products based entirely or partially on our code.  All but one of those products crashed and burned.  So it would be equally accurate (albeit far less flattering) to introduce me as "the person who has been affiliated with more failed web browser products than anyone else on the planet".  :-)

One of those products was the Apple Pippin (although I would hasten to say that my code was not the reason why the Pippin failed).  :-)

The Pippin was a disastrous example of product marketing.  And it failed because somebody did a terrible job in stage 1.  The positioning of this product was never clear.

• Is it a game machine?
• Is it a computer?
• Is it a set top box?

The answer to all of these questions was "yes".  By trying to fit in every category, the Pippin ended up fitting in none of them.

Predictably, the primary differentiation for the Pippin was that it was lame in every category.  Yes, it was a game machine, but it was insanely expensive and incompatible with 100% of the popular games in the world.  Yes, it was a computer, but it was slow and underpowered.

Stage 2:  Care

In parenting, the second stage is birth and infancy.  In software, this stage covers the 1.0 release and the time thereafter.  The key concept for this stage is "care".

This is the stage where you endure the final pain of getting the product out the door. 

The product manager has a very important role in the first release of a new product.  The labor pains are endured by the development team, but the product manager is responsible for the launch.  It is important to get the messaging just right.

Shipping release 1.0 is a lot like the birth of a new baby:  Lots and lots of pain, followed by a brief period of pure happiness, and then no sleep for quite a while.

In most B2B software products, shipping the 1.0 release is more like a beginning than an end.

Care

After a baby is born, the parents are overwhelmed with the responsibility of its care.  A newborn is completely dependent, unable to do anything for itself.  When it wants to be fed at 3 o'clock in the morning, that's what has to be done.

Many version 1.0 products have similar needs.  Users need tech support, sometimes urgently and at very inconvenient times.  That's what has to be done.

Like the husband of a breast-feeding mother, the product manager may not have primary responsibility for all this care that needs to be provided.  But he can be involved, and both he and the product will benefit from his choice to do so.

Product managers and new fathers typically share one other task in common during stage 2:  Soul searching. 

Every father I know has held his new baby and wondered if he was really prepared for the responsibility.

Product managers in stage 2 need to be asking themselves questions about the quality of their preparation:

• Is the positioning right?
• Is the differentiation sufficient?
• Is the messaging clear?

Stage 2 is not the time to start doing the stuff you should have done in stage 1.  But it is time to review.  It's not too late to make changes.

Fail

Around ten years ago, my company shipped version 1.0 of a product called SourceSurf.  It was a web-based application for browsing source code repositories.

If you were to travel back in time and ask SourceSurf what it wants to be when it grows up, it would look into the future and say, "I want to be sort of like Atlassian FishEye".  But SourceSurf never got the chance to grow up.  Version 1.0 was its first and last major release.  What we should have done was tweak the strategy and keep going.  Instead, we looked at the initial results and gave up.

SourceSurf 1.0 didn't do very well, but the product concept was generally good.  We failed to make the minor course corrections this product needed to be successful.

Stage 3:  Listen

In parenting, the third stage is the so-called "terrible twos", (which, as all parents know, actually lasts until the child is almost four).  In software, this stage typically covers the 2.0 release cycle.  The key concept for this stage is "listen".

This is the stage of defiance and rebellion, where the product begins to exhibit its own will.

One day when my oldest daughter was in this stage, we called her to dinner.  She sauntered up to the table, glanced at the food we had prepared, and gasped in horror, "There's nothing here I like except butter!"  :-)

Obviously children need correction during these years.  But they also need to be heard.  This is the stage when "kids say the darndest things", some of which are cute, and some of which are annoying or embarrassing.  Either way, this process is an important stage of growth.  Parents need to provide correction without crushing the child's spirit.  Often that means listening to the weird things the child says.

Listen

The product manager also needs to spend stage 3 listening.  Customers ask for a lot of stuff, and that feedback needs to be heard and incorporated into the next release of the product.  There is still time to tweak the strategy before the product goes mainstream.

Fail

Stage 3 is the most common place where products fail.  There are plenty of examples.  Almost any product that died at the bottom of the chasm was a failure in stage 3.  My favorite two examples are BeOS and Wingz.

• BeOS was a new operating system released in the late '90s.  Technologically, BeOS was very cool, but it fell into the chasm because it never found a niche on the other side.
• Wingz was a new spreadsheet released in the late '80s.  Wingz had features that Excel doesn't have today.  But to survive, it needed to get popular with a small group of users and spread from there.  I liked Wingz a lot, but I think most people thought it was just too weird.

I often wonder if these products might have succeeded if they had been more willing to listen to the very early user feedback and change course accordingly.  This might have meant allowing the product to become something its parents never dreamed it would be.

Digression:  Looking across the chasm

Since I am employed by a version control vendor, the chasm situation that is most interesting to me today is the Decentralized Version Control System (DVCS).  Notable examples in this category include open source tools such as Git, Mercurial, and Bazaar.

Today, these products are not yet mainstream.  They have a lot of buzz in certain communities, but the vast majority of all companies doing software development are still using centralized tools.

Will the DVCS tools make it across the chasm?

Stage 4:  Talk

In parenting, the fourth stage is the time from elementary school to adolescence.  In software, this stage typically covers version 3.0, which is often the first release where the product can be considered mainstream.  The key concept for this stage is "talk".

Parents at this stage often express amazement at what their child can do.  "Little Bobby is just amazing!  Seven years ago we made this baby and now I can carry on an actual conversation with it!"  Stage 4 arrives, and quite suddenly the parent realizes that their baby has become a little person.

Similarly, software products in stage 4 have reached the point where most people can actually use them.  They're mainstream now.  Previous releases were really only popular with early adopters and people who have lots of patience.  But release 3.0 is polished enough to be a productive solution for more than half of its target market.

Stage 4 is when products and children begin to develop an unhealthy level of focus on the competition.  When kids go to school, they begin to learn that they can make themselves feel better by making others feel worse.  It will take them many years to unlearn this lesson, to learn that mental health and personal peace come from the disciplined choice to not worry so much about others and take care of yourself.

Similarly, stage 4 products should probably not be terribly focused on the competition.  If you don't have good differentiation by now, you're not gonna get it.  Take care of your own customers.

Talk

The most important thing for parents and product managers in stage 4 is talking.

This is the stage where kids need information, and it is the last stage when they are actually willing to listen to anything you have to say:  Parents need to talk to their kids about the risks ahead.  Tell them about the heartache and consequences that can come from poor decisions about smoking and sex and drugs and being a fan of the Chicago Cubs.

Similarly, stage 4 is the time when a product manager's primary job is providing information.  Your product is mainstream now.  People want it.  But to help them realize they want it, you have to give prospective customers lots of information.  You need whitepapers.  You need demo videos.  You need product comparison documents.  And so on.

Fail

As an example of a product that didn't do so well in stage 4, I cite my own company's flagship product, SourceGear Vault.

Vault is very popular and has been a success for our company.  But when it comes to providing all the different kinds of information that a mainstream product needs, we dropped the ball. 

Right around the release of Vault 3.0, the product started to get lots buzz through "word of mouth".  People would come to our website to get product information, but the stuff we had there was just too anemic.

To our credit, we realized our mistake and took steps to fix it.  We hired a product manager to focus on this kind of thing.  But still, we got a late start, so even now Vault is still catching up to where it should be.

Stage 5:  Balance

In parenting, the fifth stage is the teenage years, from adolescence through high school.  In software, this stage typically covers the post-3.0 releases.  The key concept for this stage is "balance".

This is the stage where a child wants you to stop calling them a child.  It is a time of transition to adulthood, defined by rebellion.  No stage is more trying and difficult for a parent than stage 5.  Every parent wants their children to eventually become independent, but few realize just how painful the journey will be.  The teenage years are a lot like the terrible twos.  When the child doesn't get his way, his anger can be quite explosive.  However, instead of lying on the ground kicking and screaming, he shouts "I hate you!" and slams his bedroom door.

Balance

But just like the terrible twos, this stage is a critical part of growing up.  The parent must strike a balance.  This stage is the time to start steering a bit less.  Let the teenager take a bit more control over her own life.

Stage 5 is when children and products spend a lot of their time asking for things they don't need:

• But Dad, every other teenager on the planet has unlimited text messaging!
• But Mom, I can't wear a dress that I already wore once!  I have to get a new one!
• But Dad, ALL of the other word processors have a grammar checker!

As product manager in stage 5, you need to give your product some slack.  It's time to let customers have some of the features you have been resisting for years.  Even if you don't think the feature is a good idea, as long as it won't destroy the product, you should seriously consider letting it happen.

But you still need some boundaries:

• A parent must begin to let the teenager be what he wants to be.  But don't let the kid ruin his life.  Leave enough boundaries in place to ensure that he can finish the journey to adulthood safely and without doing something he'll regret for decades.
• Similarly, a software product can ruin its life in stage 5 by shipping a bad release.  A product manager needs to be a champion for quality.  It doesn't matter how great version 3.0 was.  If version 4.0 is buggy and unreliable, the product's reputation will probably never fully recover.

Fail

The perfect example of a product that ruined its life with poor quality is Microsoft Visual SourceSafe.

Today, SourceSafe is the punch line to almost every joke about version control.  It is widely despised and generally regarded to be unreliable.

Before Microsoft acquired SourceSafe, it was an outstanding and highly respected product.  This product didn't become the mostly widely used proprietary version control tool for no reason at all.  SourceSafe redefined the industry by bringing more ease of use than any of its predecessors.

But under Microsoft's parenting, SourceSafe ruined its life.  Versions 5.0 and 6.0 were disastrous.  I would bet that SourceSafe has more disdain per user than any other profitable product in history. My company has made megabucks from the world's dissatisfaction with SourceSafe.

Ironically, the latest version of SourceSafe probably doesn't deserve quite the level of scorn that it receives.  I haven't used SourceSafe 2005, but I understand that it's not actually that bad.  They fixed a lot of problems. 

But the product has become something that people love to hate.  Now it's too late.  The world will never trust SourceSafe again.

Stage 6:  Let Go

In parenting, the sixth stage is adulthood.  In software, this stage covers the time when the product is considered mature.  The key concept for this stage is "let go".

This is the stage where your work as a parent is basically done.  From now on, any mistake your child makes is their own fault.  You have to let go.

Similarly, a product manager doesn't have much to do anymore when a product reaches maturity.

For both parent and product manager, this is a time to celebrate the successful end of a long and sometimes difficult journey.

Let Go

Both parents and product managers often find it difficult to let go.  But it is important that you do.

You're a product manager.  Your job is to help define and shape the identity of this product.

Once the child is "all grown up", you need to stop trying to help it figure out what it wants to be.  It already is.

Let the folks in marcomm, sales and support handle everything from now.

This product is done.  Go find the next one.

Epic Fail

The two most obvious examples where product managers refused to let go:

• Microsoft Windows
• Microsoft Office

These products are done.  They've been done for years.  Unfortunately, Microsoft has largely failed to find its next product.  So, because Microsoft has nothing better to do, they continue to sell us new releases we don't need and create contrived reasons to force us to buy them.

Naturally somebody is going to gripe at me for saying that the two highest-revenue software products in history are a failure.  I'm not saying that.  What I'm saying is that these two products were stunningly successful in stages one through five, and that doesn't change the fact that their execution of stage 6 has been awful.

Final Remarks

The product manager and the parent both suffer from an abundance of diverse opinions.  Your local bookstore has hundreds of titles on each topic, many of them offering conflicting advice.

This article contains lots of my opinions about parenting and product marketing.  Some of my readers will agree with me.  Others will think I am wrong.  (The ones in the latter group will send me email.)

The problem with both parenting and product marketing is that everybody knows how to do it, but nobody really knows how to do it.  You read everything you can, and then you do your best.

And in parenting, your best is probably good enough.

This is one very important way that product management is completely different from parenting:  Most parents are successful.

Very few parents completely fail.  We spend many sleepless hours worrying, but in the end, stuff tends to work out.  If you love your kids and give them your best effort, they're probably going to turn out OK.

In contrast, most products fail.  Marketing is field where effort and "doing your best" are not usually sufficient.

The Pippin didn't fail because there was no product manager -- it failed because its product manager was a nitwit.

Microsoft isn't flogging us with Windows Vista because they don't care about finding new products.  Microsoft tried to find their next product.  They tried very hard.  They assigned their smartest people to the challenge.  They spent many millions of dollars searching for it.  But they never found it.

Google did.

People usually think of SourceGear as "Eric Sink's company", but that's only half true.  My business partner Corey Steffen has the same ownership that I do -- he's just not as loud as I am.

Because Corey is sort of quiet, most people don't know much about him.  Here's a piece of information that I think is interesting:  Corey is an amateur farmer on the side.

Yep, Corey spends his days running a software company and his off hours running a small farm.  So he comes to work with stories about chickens and sheep and horses and pastures.  Oh my.

(It is interesting to note that Brian Harry, creator of SourceSafe and Team Foundation Server, also has a passion for farming.  So Corey and Brian are two data points that suggest some sort of a pattern involving version control and agriculture, but I dare not try to extrapolate.)

Anyway, since Corey's life is such an odd juxtaposition of two extremely different pastimes, folks here at the company tend to make the occasional joke about it.  In fact, Corey has been the recipient of merciless but harmless teasing here for over a decade now.  For some reason, the subject just never gets old.  When we get together for our company lunch on Wednesdays, a joke about Corey getting up at 4:30am to clean out the horse stalls before he comes to the office to clean out the bug database is probably a sure laugh.

Continuing in this fine tradition, one of our guys recently found the following promotional card and brought it in for a quick joke at Corey's expense:

"Hey Corey, I thought of you when I saw this magazine.  Maybe you should pick up a copy?"

That was funny.

And it got even funnier two seconds later when Corey admitted that he was already a subscriber. 

The next day, he brought in his copy of the most recent issue:

I would like to be able to say that I took this in stride.  After all, I've known for years that Corey keeps chickens.  I still remember back in 1997 when Corey joined the company he told me that his chickens provide them with 18 eggs every morning.

How does a family make use of 18 fresh eggs EVERY SINGLE MORNING?

Anyway, seeing this magazine left me speechless.  In part I was surprised by yet another Green Acres moment from Corey.

But mostly I was just shocked that this magazine exists.  I mean really.  An entire print publication for people who raise chickens as a hobby?  That's what I call a niche.  How does the publisher survive?

More to the point, how can this magazine be successful when Dr. Dobb's looks like it might be pushing up daisies sometime before the World Series is over?  Dr. Dobbs is arguably the most prestigious developer magazine in our industry, but it hasn't been looking any too healthy over the last year or so.

It's gotta be all about market penetration:

• In very rough and round figures, there are 3 million software developers in the United States and 1% of them are subscribers to Dr. Dobbs.
  
  
• I have no idea how many people raise poultry in their backyard, but I suspect my freshman chemistry class had more people.  However many it is, I bet well over 50% of them are subscribers to the magazine shown above.

Most software developers no longer use content in paper form.

Andy Brice recently commented on the poor sales of Charles Petzold's book on WPF 3D.  This is another sign of the major shift in our industry.  Petzold was maybe the last of his breed.  Most authors gave up years ago on the idea that they could make a living from writing alone.  Until quite recently, Petzold was one of the few who still did, and now even that appears to be changing.

Software development magazines and books are dying.  You already know this.  I already know this.  But I continue to be amazed at the pace of this change.  People resist change.  Billions of dollars of VC money has been lost by overestimating the willingness of people to embrace change.  In this case, I have underestimated it.  Looking ahead ten more years, I wonder how much smaller the "Computers" section at my local Borders bookstore will be.

They'll probably just fill the extra space with a bunch of titles about backyard livestock management.

OK.  Before I explain why Asus deserves to be mentioned in marketing textbooks for its horrible management of the Eee brand, let me first say that I love my Eee PC 901.  I've had this little device for a couple weeks now, and it's just a really great product.

• The battery life is outstanding.
• It takes a few days of use to get accustomed to the keyboard, but after that, it's quite usable.
• I wish the Mac were available in this form factor.  (Yes, I know about the MacBook Air.  That's not even close to what the Eee is.)
• I'd prefer Linux, but I've got the XP version.  At some point, when Ubuntu Netbook Remix is ready to work smoothly on this thing, I'll probably repave.  But for now, everything Just Works, and I don't want to lose that.
• I got this device to replace my day timer, not my laptop.  I don't really do any serious work on my Eee.  It's a portable web browser and email client.  Visual Studio is not installed.
• OTOH, I'm thinking that for my next trip, the MacBook Pro will stay home and the Eee will go.
• I know the 10-inch netbooks are gaining in popularity, but for me the 8.9-inch form factor is much better.  The MSI Wind is a lot bigger.  The Eee is so small I can (and do) take it everywhere.  The 10-inch models remind me of a laptop.
• For me, the Eee is the second coming of my HP 200LX.
• I think of my Eee as a large and extremely capable BlackBerry, not as a small and a lame laptop.

So, like I said, it's a great product.  But Asus is doing everything they can to destroy this brand.

The brand name "Eee" is great.  It's short and memorable.  Its sound matches its sense.  It just fits.

But Asus is now introducing so many products under the Eee name that soon the brand will be meaningless.

I believe the first popular Eee was the 701.  People raved about it.  I never owned one, but apparently the two most popular attributes were the low price and the small size.  Either of these attributes could have become the positioning for the Eee brand.  Maybe both.

But now Asus has all kinds of Eee products.  Some are small.  Some are large.  Some are cheap.  Some are expensive.  They're even working on a desktop machine with the Eee brand.  After that I can only assume that we'll see Eee cola, Eee furniture and Eee shaving products.

Maybe Asus doesn't care.  After all, they're basically a manufacturing company, not a marketing company, right?  The fact that they created a great brand was probably an accident anyway.

But as a marketer, that's what makes this even more infuriating.  Creating a great brand usually requires hard work, lots of creativity, and tremendous discipline.  When someone pursues the goal in that manner and succeeds, I admire them.  But when someone accidentally succeeds, and then destroys their own work, I just want to bang my head against the desk.  Yes, I know that luck is a factor.  I just hate the situations where luck is the only factor.  We're making products here, not Top 40 pop radio songs.  Talent and hard work should count for something.

Oh well.  The Eee brand will die and Asus will return to its former life of making products that normal people have never heard about.

But I think this product category will survive.  These things might even become popular enough to go mainstream.  I can only assume that Dell will end up being the leader in this market segment.

But whatever brand they use for these products, it will never be as cool as "Eee".

I was saddened this morning to hear that Randy Pausch has lost his battle with pancreatic cancer.

Pausch was a CS professor at Carnegie Mellon who became famous for his Last Lecture, delivered in September 2007 and later published as a bestselling book.  He was also the creator of the Alice software project.

When a famous person dies, I often find myself appreciating their work, but I usually cannot say that I feel a personal sense of loss.  Richard Harris was fantastic in every role I have seen him play, but I doubt he and I would have found much to talk about.  For me, Randy Pausch is a special case.  All of us are lucky to have access to his work, but I think the people who really knew him are even more fortunate.  I wish I was one of them.

Every man dies.  Not every man truly lives.  Rest in peace, Dr. Pausch.  You truly lived.

This weekend I saw Wall-E and The Dark Knight, both of which are just amazingly good.  Lately I'm thinking this may be the best summer of movies ever.

Compared to cinematic masterpieces such as these, Paul Roub's recent videos are kind of lame.  His plot and characters are really anemic.  I need to talk to him about somehow working in a car chase scene and more explosions.

:-)

Seriously, Paul has been making some short videos to offer a different way of talking about our products.  His latest one is my favorite:  In order to show how quick and easy it is to setup SourceGear Fortress, this video shows every step of the install from start to finish.  The video is 3 minutes and 12 seconds long.

These movies aren't exactly Iron Man, but they're still pretty cool.

Darren Stokes sides with Joel over Jeff on whether programmers should know C.

This whole debate reminds me of amateur radio operators bickering over whether newbies should be allowed to get a license without learning Morse code.

Morse Code

So Eric, tell us about your experience as an amateur "ham" radio operator?

My call sign is KA9KEF.  To get my General class license, I had to pass a written exam as well as a Morse code test at 13 words per minute.

Really, you know Morse code?  Nowadays, it's possible to get a ham radio license with no code at all. 

Yes, and I think that's outrageous!  It's just wrong.

Why do you think that?

If I had to learn Morse code, then everybody else should too.

So does anybody really need Morse code these days?

Well, I suppose not.  But don't pester me with facts that distract from my point.  Learning Morse code should be a rite of passage for all hams.  Anybody who got a license without code is not a "real ham".

But you -- you are a "real ham".

Yep.  I passed the Morse code test.  13 wpm.

So you're still actively involved in amateur radio?

Well, no.

Oh.  When was the last time you used your ham rig?

I suppose it's been a few years.

How many years are in "a few"?  Maybe five?

More like twenty.

Twenty years? 

Twenty-three, actually.

And you still have your amateur radio equipment?

Well, no.  I sold my station a long time ago.

OK, let's review.  You're a "real ham", even though everything you know about ham radio is two decades out of date.  But the guys who got a "no code" license and are actively practicing the hobby today, they're somehow not "real"?

That's right.  I know Morse code.  They don't.

So you think all ham radio operators should be required to learn a basically useless skill simply because you did?

Exactly!  And don't ask me to get down from my high horse.  I like it up here.

C

The argument about whether programmers need to know C is just so similar.

All of the people arguing that C is important are the people who have already learned it.  I'm pretty sure that a lot of their argument is resting on the same foundation as those crotchety old hams:  "If I had to learn C, then everybody else should too."

I am one of those people.  Yep, not only am I a Morse code bigot, I'm a C bigot as well.

I learned C, and I learned it good.  I've worked on multiple significant C projects.  I even wrote a C compiler.  In C.  I think all "real programmers" know C.

Yep, we C programmers are elitist and proud of it.  The view from up here on our high horse is pretty good.  We see lots of so-called programmers down there:

• They don't really know what a pointer is.
• They're not even using a real compiler!  That thing they're using doesn't even generate native code you know.  It's "byte code", so it's not real.
• Those people have never had to manage their own memory.
• In fact, they've never really had to do anything at all.  I mean really.  They're building on a class library that's got more features in it than Photoshop.

We are different.  We learned C.  We are "real programmers".

One big difference

What's the main difference between hams who know Morse code and programmers know C?

The C programmers actually have a point.

Seriously, strip away all the elitism and see what's left.  Morse code is nearly useless, but C is still darn important whether you're using it or not.

And a lot of people are still using it, by the way.  Don't think of C as merely "important historical and foundational background".  In fact, my current project is being written in C.  Software development today is a big field.  There are still many problems for which C is the best solution.

But even if you're coding in something higher level, the experience of using low-level programming techniques is invaluable.

I'm not going to take a black-and-white stance on this.  I won't go so far as to say that every developer must learn C.  I've met lots of developers without C experience who are successful and making positive contributions to important software projects.

Furthermore, I'll admit that knowing C is not a magic solution to poor skills.  A lousy developer who happens to know C is simply better equipped to hurt himself or somebody nearby.

However, I can say these two things:

1. All of the truly extraordinary developer s I know are people who really understand the kind of low-level details that C forces you to know.
2. Every programmer without C experience has a clear path of personal development:  Learn C.  Get some real experience using C to write a serious piece of software.  Even if you never use it again, you'll be a better programmer when you're done.

People often ask me for a list of my favorite books.  So here it is. 

I reserve the right to update this list from time to time.

I tend to read a lot of stuff.  The fact that I recommend a book here does not mean that I agree with everything in it.

Coding

I think it's out of print, but I really liked Writing Solid Code.  It's very oriented toward C/C++, so if you're mostly in C#/Java/Ruby/Python/Perl/VB, it may not be worth your time.  Still, it's an outstanding book.

And of course Code Complete is a classic.

Software Management

Dynamics of Software Development is one of my favorites.

Business

I'm a big fan of Built to Last and its sequel, Good to Great.  The sequel is easier to read and a bit more relevant to smaller companies.

The Silicon Valley Way is a great book, and it's a very visual book with nice short chapters.  Easy to just pick up and browse..

If you get the opportunity, go hear Guy Kawasaki speak.  He's much better in person than he is on paper.  But if that doesn't work out, Rules for Revolutionaries is a good read.

Marketing

If you read only one book on marketing, it should be Crossing the Chasm.

But actually you should read at least a dozen books on marketing. 

Here's your second one:  Differentiate or Die

Now go find ten more.

Sales

I think Selling the Wheel is an outstanding book.  At first you'll be tempted to stop because it's kind of cheesy.  Don't.  Finish it all the way to the end.

Useless but Enjoyable Fluff

I really like the "Prey" series of novels by John Sandford.  Start at the beginning with Rules of Prey

WPF

I have all of the following WPF books:

• The one by Chris Sells and Ian Griffiths
• The one by Adam Nathan
• The one by Charles Petzold
• The other one by Charles Petzold, focused on WPF 3D

These are all good, each in a different way.  If you're going to do anything serious with WPF, it seems to me that you should own them all.

Other Stuff

The Seven Habits of Highly Effective People is still worth reading.  None of Covey's other books are nearly as good.

Any serious pool player has a copy of Byrne's New Standard Book of Pool and Billiards.

My favorite literary novel is The Count of Monte Cristo.  The unabridged version is worth the extra trouble.

For dog lovers, Marley & Me is terrific.

The Comment

I've received a lot of feedback on yesterday's blog entry.  The two most common questions are:

• Eric, why did you think that working on your Scrabble project was wrong?  It doesn't seem all that bad.
• And since you thought it was so awful, can we assume that you would go ballistic if someone in your company was working on a pet project at the office?

I sort of figured that if I wrote an article about a software manager that I really admire, I didn't need to address the question of how I would react in a similar situation.  It should be fairly simple to connect the dots.

But folks are having trouble with the fact that I held such a strict attitude about my own transgression.  They assume that I would be similarly draconian with others.  A fair assumption I suppose, but an incorrect one.

When it comes to ethics, most people treat themselves loosely and other strictly.  Instead, try being strict with yourself and gracious toward others.  You'll get along a lot better with the world.

Do I really believe that working on a fun personal project at work is such a heinous crime?  Certainly not.  But surely you can agree that goofing off and trying to cover it up isn't exactly the way to win the employee of the month award?

The truth is that I just don't believe in making excuses.  I'm not going to defend myself unless I have solid possession of the moral high ground.

My kids read this blog.  I'm trying to teach them to take responsibility for all their choices, good and bad, big and small.  How can I do that if I'm not willing to set the example?

If I found somebody in my company working on a pet project at work, I imagine I would handle it pretty much like Tim did:  I would be more disappointed in the company than in the individual.  If people are working on hobby code, then they're bored.  In my opinion, the blame for a bored employee splits about 80/20 toward management.

The Correction

Tim's current car is a Lamborghini, not a Ferrari.

The Context:  Being a slacker

In the early months of 1994 I wrote a program to play Scrabble.

It was a magnificent piece of code, easily the fastest Scrabble program I had ever seen.  The implementation (in C) was based on the GADDAG data structure and algorithm explained in a paper by Steven Gordon.  The resulting program was so fast that computer moves were instantaneous.

Unfortunately I had to keep my software a secret.  The lawyers at Hasbro love to send nastygrams to anyone who implements a Scrabble program.  These guys are a lot like the lawyers at the RIAA who have become famous for their lawsuits against toddlers and family pets.  The Hasbro legal team is merely less prolific.

Actually there was one other reason why I kept my Scrabble program a secret:

I wrote the entire thing on company time using my employer's hardware.

At the time I was working for Spyglass.  We had recently finished shipping version 2.0 of our flagship product, Spyglass Transform.  Things were a bit slow, so I was discreetly hacking on my pet project.  I setup my office such that nobody could see my screen from the door.

Unfortunately, I gave myself away.  At times when I was working on my Scrabble code when my boss (Tim Krauskopf) walked in the door, I would flinch and quickly try to minimize the window.  About the third time it happened, Tim said, "All right, what game are you playing?"  Suddenly I wished I actually was playing something like Doom.  In that moment, working on non-company software seemed more shameful than wasting time in a first-person shooter.

I offered a full confession and an apology. 

I don't remember what he said. 

I do remember that he never mentioned it again.

The Inflection Point:  Day 1 of the browser wars

A few weeks later, on April 4^th, 1994, Tim once again stepped into my office.  He said he needed to talk with me somewhere offsite.  We left.

In that conversation, Tim told me that the Spyglass management team was making the decision to abandon our then current business (scientific data visualization tools) and get into the web browser business.  He asked me to immediately begin working and commit to giving a demo to an important potential customer a few weeks later.

I shifted into high gear.  I came in at 5:30 am every day for weeks.  I was writing code at a fantastic pace.  The demo was successful.  We showed them our browser.  It didn't have as many features as NCSA Mosaic, but it was a lot faster.  We didn't tell them that it was written from scratch in less than a month by a kid who had never written any networking code before.  We got the sale.

And that was just the beginning.  The project started out with me alone, but two years later it was a team of 50 with me in a leadership role.  We were the first Internet IPO.  We licensed our browser to Microsoft and it became Internet Explorer.

That conversation on April 4^th ended up being a defining moment for my career.  And it happened just a few weeks after Tim caught me skiving off on the job.

What the %#$@ was Tim thinking?

The Premise:  Tim made a wise choice

I'm going to surface a lesson from this story, but you should probably read no further if you disagree with Tim's decision.

And if you do, I can't really argue with you.  I'm not going to defend my actions.  I was being irresponsible, even dishonest.  There are no excuses for behavior like that.

Maybe Tim should have fired me.  At the very least, maybe Tim should not have entrusted the development of his company's next big product to someone who lacked the discipline to stay on task.

Still, the overall results deserve some kind of voice in this argument.  Tim and his company were very successful.  Tim drives a Ferrari now.  Tim's choice worked out very well for me, but it turned out pretty well for Spyglass too.

The Lesson Learned:  Choose your manager carefully

This story may seem like it's about me, but really it's about Tim Krauskopf.

I've never asked Tim why, so I guess I don't really know.  Maybe he just believes that being obsessive to a fault about code isn't the worst character defect for a developer to have.

I spent five years at Spyglass.  The incident described above is just one of many that left me in awe of Tim's leadership skills and discernment.  I don't think I ever really figured out what makes that guy tick, but I still think of him every time I measure myself as a manager and leader.

The part that seems most astonishing to me is that he kept his emotions in check.  Didn't he feel any sort of disappointment or even betrayal?  Why didn't he overreact?  That's what most people would have done.  I probably would have.

All I really know here is this:

Your manager plays an enormous role in determining the success of your career.  Choose your manager very, very carefully.

• Choose somebody smart. 
• Find somebody who is not merely smart, but "emotionally smart".
• Find somebody who is not merely smart, but wise.
• Choose a person from whom you can learn.

Just to be clear, I am not saying you are powerless.  Your success is mostly determined by your own abilities and choices.

But one of those choices is the decision of who you are going to work with.

Don't take that choice lightly.

Update:  See my follow-up.