Home About Eric Topics SourceGear

2003-08-19 13:49:24

Career Calculus
A couple weeks ago there was a flurry of blogging over the price of Microsoft's upcoming
Professional Developers Conference (PDC).  In the midst of this controversy, Doug Reilly
chimed in with a post entitled "Who is responsible for your career?".  Doug's post got a lot of
reads and links, including well-said "amen posts" from Sam Gentile and Robert Hurlbut.

While I don't care to debate the issue of PDC pricing, I do want to affirm the concept of taking
responsibility for our own careers.  Often we choose to focus on the things which are outside
our control.  But the truth is that our career path is largely determined by our own choices.

I've known and worked with lots of developers, and I have noticed one thing which
separates those with great careers from everybody else.  Developers with outstanding
careers understand a secret that seems to elude the majority:

Focus on the first derivative.

And You thought Math would Never be Useful

Remember your introductory calculus?  Probably not.  You were either a horny high school
senior or a hung-over college freshman, so you weren't paying attention.  But there in the
first few chapters of your calc textbook is a hint about the secret of your career path. 

In basic calculus we learned that the first derivative of a function is the "rate of change" of the
value of that function with respect to another variable.  In the case of your career, the other
variable is time.  The basic equation for a developer career looks like this:

C = G + LT

C is Cluefulness.  It is defined as an overall measure of your capabilities,

expertise, wisdom and knowledge in the field of software development.  It is the
measure of how valuable you are to an employer.  It is the measure of how
successful your career is.  When you graph your career, C is on the vertical axis.

G is Gifting.  It is defined as the amount of natural cluefulness you were given "at
the factory".  For each individual, G is a constant, but it definitely varies from
person to person.

L is Learning.  It is defined as the rate at which you gain (or lose) cluefulness over

time.
 T is Time.  It is on the horizontal axis of your career graph.

As you can see above, your career success is determined by three variables, only one of
which you can control:

You obviously can't control T.  Time marches forward mercilessly at the same rate for
everyone.

You also can't control G.  The truth is that some people are just naturally smarter than
you are, and that's the way it is.  But G is not the sole determiner of your success.  I
have known some truly gifted programmers with lame careers, and I have also known
some less-gifted folks who have become extremely successful.

You can make choices which affect the value of L.  In fact, you do make choices which
affect the value of L, every day, whether you know it or not.

Focus on the First Derivative

Old habits die hard.  Focusing on the first derivative can be very difficult to do, as our natural
inclination is to focus on C itself.

We wonder why somebody else got the promotion. 

We wonder why the boss doesn't seem to value our ideas as much as some other
person. 

When we apply for a job, we submit a document which is filled with claims about how

high our C value is. 

We convince ourselves that the real problem is that people don't seem to know how clueful
we are.  Over time, we come to believe that the important thing is not our actual cluefulness
but rather the degree to which others perceive us as clueful.

I submit that worrying about how others perceive your C value is a waste of time.  The key to
a great career is to focus on L, the first derivative of the equation.  L is the rate at which your
cluefulness is changing over time.  The actual value of C at any given moment is usually a
distraction.  Only one question matters:  With each day that goes by, are you getting more
clueful, or less clueful?  Or are you just stuck?
Sound obvious?  It's not.  Most people don't get this, and you will leave your peers in the
dust if you do.  For most developers, L is zero.  Any positive value for L can elevate you
above the crowd.

When you make L into a positive number, you have a great career happening.  It no longer
matters what G was.  You are getting more clueful every day, and that means your
opportunities are going to get better in the future.

Constant Learning

I started with the example of paying your own way to PDC.  Yes, this is one example of a
positive L.  Go to PDC and you'll learn about C# generics and query optimization for Yukon
and managed APIs in Longhorn and all kinds of other stuff.  In the last week of October, your
Cluefulness will increase.

But PDC only happens every couple years or so.  How are you going to keep L positive the
rest of the time?  A great career is not likely to happen if L merely spikes above zero once in
a while.  We need "constant learning". 

We want learning to be a process, not an event.  Making your first derivative constantly
positive is not just about formal training.  It is a posture which you bring to your job each day. 
It is a posture of teachability, a constant willingness to learn.

What opportunities do you have for learning on a typical day as a developer?  You spend
approximately 250 days a year sitting in front of a keyboard and a screen.  For how many of
those days can you make L a positive number?

Unfortunately these are questions you have to answer for yourself.  When you start looking
at things from this perspective, you will find your own ways to be constantly learning.  The
implementation specifics depend almost entirely on you and your work environment.

But there is one big factor which is holding back L for almost everybody.  The most important
learning experiences in day-to-day work are the opportunities to learn from our mistakes.

Seize Your Mistakes

In between formal training events like PDC, our mistakes are the peaks in our opportunities
for learning.  Our value of L is heavily determined by the way we handle those mistakes.
My own mistakes have been the difference-makers in my career.  When SourceGear won
the Inc 500 award last fall, the editors asked me to name the most surprising thing I had
learned from being an entrepreneur.  I told them the most surprising thing was that I could
make so many dumb mistakes and still end up on the Inc 500 list.  :-) 

I've been running my own company for almost seven years now, and I have made some truly
excellent mistakes.  Some of these mistakes have been downright embarrassing, but I
have very few regrets.  I have learned an awful lot.

We all screw something up from time to time, but we don't always learn from the experience. 
Why not?  Quite often, the reason we don't learn from a mistake is because we're too busy
trying to hide it.

The best learning occurs when we choose to process a mistake with a mentor or peer. 
Unfortunately, this goes against our natural tendency.  When we foul something up, the last
thing we want to do is shine a light on it so everyone can see what a bonehead we are. 
What we really want to do is cover it up and hope nobody notices.  But in doing so we miss a
huge opportunity to increase our cluefulness.

Sometimes we become so practiced at hiding mistakes that we learn to hide them from
ourselves.  When the daily build fails, what is your first reaction?  Do you just assume that
somebody else broke it?  People with a positive L are more likely to immediately investigate
to see if one of their checkins caused the problem.  A posture of teachability means that you
are quick to recognize your own mistakes and can confidently process them.

Bottom line, you can choose only one of the following options:

A -- Manage your career.

B -- Manage others' perceptions of you.

Choose A and your career will be outstanding.  Choose B and your career will stagnate.

Bug 5909

We recently had an opportunity to practice this discipline here at SourceGear.  One of our
best developers (let's call him Jeremiah) made a really big mistake.  The coding error itself
was small, a simple case of an if statement that wasn't quite right.  But the potential effect of
the bug was rather severe.

Jeremiah took full responsibility for cleaning up the mess.  The actual bugfix was only the
beginning.  Jeremiah worked directly with each customer that might have been affected.  He
didn't stop to worry about whether anyone would think less of him for the mistake.  In fact, he
handled the situation so well that his perceived C is up, even though he never seemed to
make that a goal of the experience.

In the end, we lost some time, but the major lasting effect of bug 5909 was increased
cluefulness for Jeremiah.

Risks
I am quite tempted to argue that an everyday posture of teachability is a lot cheaper than
PDC.  :-)

But to be fair, I'll have to admit that constant learning is a choice which involves risk.  In two
very important ways, choosing to have a high L will make you more vulnerable to your
manager:

The first big risk is the possibility that getting your mistakes out in the open will mean
that your manager will punish you for them.  The consequences here could vary
broadly.  Your manager might simply start thinking you are an idiot.  One of those
mistakes might even get you fired.

The second risk is the possibility that your manager will become afraid of you.  Some
managers really prefer to have a zero-derivative team.  Whether consciously or not,
they stack their team with stagnant people who are not likely to threaten their position. 
If you are on just such a team and you suddenly become a "first derivative developer",
you are upsetting a very delicate balance.  Your manager may react unpredictably.  You
may be labeled a troublemaker.  He may even contrive some excuse to fire you.

Both of these risks are real, with consequences that can feel quite severe.  Depending on
your personal circumstances, the sudden loss of a job can be a very distressing event.  This
is a valid concern, and I am trying not to flippantly dismiss it.

But you really don't want to work for this kind of a bozo anyway.  In either of the situations
above, it is time to be shopping for a new manager.  This a basic axiom and a starting point
for taking responsibility for your career:

Don't work for a manager

who is actively hindering

your practice of 

constant learning. 

Just don't do it.

Corollary:  Next time you're interviewing for a job, pretend that the power structure is
reversed.  The hiring manager is trying to figure out if there is any chance you are worthy of
the job.  Ignore that.  Instead, spend your time trying to figure out if there is any chance that
guy is worthy of being your manager.

Postscript

By the way, as long as you're going to develop a voracious appetite for knowledge, may I
suggest that you not necessarily limit your scope to issues of coding and architecture?  If you
are in a small ISV, or if your career goals include management, you may want to watch for
opportunities to learn about other stuff.  Heck, you might even want to learn a thing or two
about marketing. :-)

Copyright 2001-2022 Eric Sink. All Rights Reserved

If you are in need of contract software development services, I would appreciate your consideration of
SourceGear.