| Eric.Weblog() |
| Put this feed on your website |
| Description: |
Thoughts about software from yet another person who invented the Internet |
| Format: |
RSS 2.0 |
| Url: |
http://software.ericsink.com/rss.xml |
| |
| Latest headlines |
Eric.Weblog()
|
Product Parenting
Wed, 22 Oct 2008 08:00:00 CST
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 3rd.
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.
|
More on the sad state of print publishing for developers
Wed, 01 Oct 2008 11:09:16 CST
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.
|
A Case Study in Bad Marketing
Tue, 12 Aug 2008 10:59:42 CST
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".
|
Randy Pausch
Fri, 25 Jul 2008 09:49:07 CST
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.
|
Summer Movies
Mon, 21 Jul 2008 11:18:24 CST
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.
|
C and Morse Code
Fri, 23 May 2008 06:40:16 CST
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:
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.
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.
|
My Favorite Books
Thu, 22 May 2008 08:00:00 CST
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.
|
Yesterday's entry: A comment and a correction
Wed, 21 May 2008 08:33:06 CST
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.
|
Choose Your Manager
Tue, 20 May 2008 08:00:00 CST
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 4th, 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 4th 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.
|
Upcoming Gigs
Mon, 12 May 2008 08:19:41 CST
In July I will be giving a keynote address at GUADEC, the
annual GNOME conference, being held this year in Istanbul.
In September I will be speaking again at the Business of Software conference,
being held this year in Boston.
And finally, for something completely different, don't miss
the Jam Session at Tech-Ed on June 3rd. 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.
And BTW, none of us will be dressed as The Evil Mastermind. This
should be obvious, as The Evil Mastermind would never do something actually
cool like a song by The Who. Rather, he would do something like a Kelly
Clarkson song and mistakenly believe it was cool. :-)
|
|