[lug] Career advice

Rob Nagler nagler at bivio.biz
Fri Jan 1 21:01:07 MST 2010

On 1/1/10, Michael J. Hammel wrote:
> Healthy?  How does reaching to be something more than you are make it
>  unhealthy?

This one had me stumped.  It seems so obvious to me, and it relates to the

>  What does one do,
>  for example, once you get to be a really great coder?  Then what?  Pat
>  yourself on your back till you retire?

I have seen many people who think they are great coders who then
decide they need to make more money and "move up in management".
In the recent downturn, some of these people are now on the street.
I have said to them, "You should code."  They say, "I was never a really
good coder, and I can't learn now."  I tend to disagree with the former,
and the latter is fatalism.   You are never too old to learn anything.

I know quite a few coders.  In the recent downturn, none of them are
looking for work.  They are the last people to be fired, because deep
down, management knows that they are extremely valuable people.

I know of many people who aren't what I would call a "coder" or
"hacker". These people know how to work a programming language,
but they really haven't reached the stage of actually understanding
the deeper issues of software, and they don't really care about those
issues.  They are the first to be fired in a downturn.

One doesn't "get to be a really great coder".  It's sort of like saying
one is a "really great athlete or musician".  I am still learning how to
program.  I think I understand the couple of axioms which are the
rules of operation.  It took me about 25 years to get to the point
where I could distill the rule set to something manageable and what
I think is "true".   However, that's just the beginning for me.

I just finished up some code for an important project.  We were under
the gun to get it done by Jan 1.  I was going away on 12/30 so it
was important I get it done by 12/29, and there were two other
people involved.  I worked through xmas and the weekend after
creating this masterpiece.  My plan was to handoff bits to the other
people I was working with.  Yet, I didn't get done until 4p on 12/28.
That left precious little time for me to not only handoff the application
specific code, but to explain my wonderful creation to two people
who were not sitting inside my brain.  While all the code had tests,
the amount of time to do the brain dump was too large.  Fortunately,
I work with some spectacular people, and they were able to pick
up the application specific code and run with it.  They didn't
understand my masterpiece, and couldn't make the best use of it,
and of course, there was some very bizarre behavior which I had
to understand since no one else could figure out what was going
on.  So one of the rules I'm still trying to assimilate is being able
to communicate effectively with my coworkers.  I'm pretty good at
it, but I'm a long way from being highly effective.

The other rule I'm not good at is separating refactoring from
implementing new function.  It's very important to separate these,
because they are two independent tasks.  I work with somebody
who is very good at separating these two tasks.  I am trying to
learn from him, but I have some built in habits which block my

I'm trying to be open and honest about my development as
a programmer.  People who know me might think I am being
falsely humble.  I don't think I am.  I have a lot to learn, and
part of the reason I enjoy my work so much is that I have so
much to learn that I don't think I'll stop learning how to code
until I die.

I should also say that the stuff I'm working on is not available
in books or magazine articles.  Like I said in my other note,
I think many people confuse programming with other activities
like inventing and learning new programming languages and
frameworks.  This is not programming.  It's politics.  It's about
being popular (see Paul Graham's article on the subject to
learn more about what I mean by this).

Some people can make a lot of money by selling new
programming languages and frameworks.  The guys at
37 signals are a perfect example.  I don't think much of
Ruby on Rails, and I could give you a lot of reasons why
you shouldn't think much of it either.  Yet, I will say that
RoR is an extremely successful gig for them.  However,
it won't last, just like Java didn't last as well as many other
technologies.  So they won't be programming RoR the rest
of their lives, and that's sad, because they will have put
so much energy into their brainchild, and it will end up in
the dustbin in a couple of decades, if not sooner.

Now, if all you want to do is make a boatload of money
and retire, you might as well try to be the next @Last or
Skype or Crocs for that matter.  If your goal is to have a
career doing something you truly love, I think coding is
the way to go.  Even if you are lucky enough to have created
something as successful as Google, you had better learn
to love doing something quite different (managing lots of
people and projects) than what you started out doing

I do know a couple of people who still keep doing what
they love (hardware and software) even though they are
billionaires.  That's a rare combination, but I admire these
people for being able to do what they love doing despite
their success.  I also think they had to work exceptionally
hard to avoid the distractions of their success and to not
delegate the bits to people less competent than themselves.
This takes true guts and determination.

There are many other people I know who have become
"distinguished engineers" at various companies.  They are
victims of their success, and they no longer code or create
hardware (pretty much the same thing).   At one point or
another, they leave their companies, and maybe become a
VC or some other techologist-in-residence.  They get farther
and farther from the technology until they think sailing on
The Bay is fun, and can do that full-time, because they
won the lottery.

Not many people win that particular lottery, which is why
I think allowing yourself to get away from coding is a big
mistake ("unhealthy").  It's a lot safer to assume that you
will have a moderately successful career, and that you
will need to maintain your skills as a coder as sharp as
possible so that you are not easily replaced by the new
Architect who has impressed the management more than
you can do because he is younger, more charismatic, went
to better schools than you did, and is an all-around better
person than you.  That doesn't happen to the best coders
within a company.  They won't be outsourced either, btw,
because management doesn't fire their best coders.


More information about the LUG mailing list