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. :-)