
Ask HN: What did the really successful programmers do differently? - BadassFractal
This is a follow-up to the lengthy "Do you want to be doing this at 50" discussion that we've been having here on HN for the past week. For those of you who might have missed it:<p>http://news.ycombinator.com/item?id=4611337
http://news.ycombinator.com/item?id=4620276
http://news.ycombinator.com/item?id=4616635<p>As someone who is definitely on the path to be developing software for the rest of his life, I'm somewhat concerned. There are many anecdotes of programmers in their 50s having a pretty bad time, and yet there are real examples out there of programmers who have done phenomenally well: they've made a difference, they're well known and respected AND they've been financially successful as well.<p>I'm thinking of (contemporary) programmers of the caliber of John Carmack, Rich Hickey, Peter Norvig, Jeff Dean.. I'm trying to understand what it is that they did differently from everybody else that set them apart. I understand that many have been successful through their ventures (see Bill Joy or Eric Schmidt), is that perhaps the only route?<p>I think this is an interesting and valuable discussion for every developer out there.
======
lutusp
> I'm trying to understand what exactly they did from everybody else that set
> them apart.

Because I'm one of the success stories, I'm in a position to answer. A
successful programmer is not just a programmer, he is also a personal
representative, a salesman and a contract negotiator.

I originally wrote what became Apple Writer
(<http://en.wikipedia.org/wiki/Apple_Writer>) because I was writing a
technical magazine article that was difficult to organize. I finally realized
I could use my newly acquired Apple II to organize my disorganized notes and
help in editing. So I divided my time between writing the article (about
Special Relativity) and programming my Apple II to help with the writing task.
This meant I was the first user of my program, and I was a demanding customer,
a factor that helped the project along.

Eventually Apple heard about my program (originally called LexiCalc, a name
meant to remind people of VisiCalc) and, having far too few programs for their
computer, asked to see my program. After a lengthy negotiation in which I
demanded and secured a 25% royalty rate, we had a deal.

The bottom line -- Apple Writer didn't become a success only because of my
programming skills. It became a success and a household name because I was
able to negotiate a royalty marketing deal with Apple that served both our
needs. The fact that a 25% royalty rate was excessive, was unknown to either
me or Apple at the time of the original negotiation, and by the time we both
realized it, I was unwilling to change the terms.

To reiterate, programmers that become successful do it by having skills beyond
programming -- they know how to present themselves, they know how to
negotiate, and they earn a reputation for reliability.

~~~
bornhuetter
I think this is a common theme - technical people who also have business
skills are more likely to succeed; business people who have technical skills
are similarly more likely to succeed.

~~~
jd
Or more generally: it's much easier to excel in the intersection of two (or
three) disciplines than to excel in a single discipline.

Programming + Biology. Programming + Economics. Business + Comic book writing.
Programming + Business. Cooking + fluency in Japanese & English. You get the
idea.

~~~
bornhuetter
This is a good point. I was thinking in terms of people in specialised roles
having broader knowledge, but you are right that there are good opportunities
in blended roles. Either way, it's great to have depth in multiple fields.

------
patio11
Break down what "success" means for you, then figure out how to achieve the
really important parts of that formula.

For example, my cursory read of your list of programming success stories plus
"they've made a difference, they're well known and respected" suggests that
you might care about your status among geeks in particular. There's nothing
wrong with that, but it would counsel _very_ different career moves than if
you cared about your status among "the typical person who reads the New York
Times." You might, for example, aim your moves towards a high-status industry
that skews geeky (like, say, videogames, which is across almost any other axis
a _terrible_ place to work), startups, advertising firms which employ
anomalously high number of PhDs and get disproportionate love from geeks, etc
etc, and away from where many extraordinarily talented programmers are likely
to work (in a dark hole writing important code that the world will never know
or care about even though it keeps their planes in the sky, moves their food
to their table, makes sure that when they call 911 a phone actually rings,
etc).

In terms of being financially successful? There are many, many approaches to
it. Most of them boil down to figuring out how programming solves a problem
for a business, quantifying that value, and then shaking the money tree.

I think HNers sometimes have an unnecessarily narrow view of the solution set:
for values of financially successful which include "I don't need to be a
billionaire but I'd sort of like to earn, I dunno, doctor money rather than
marketing manager money" it includes things like "Run a small boutique
consulting firm", "Become an individual specialist in a few very valuable
things and just charge market rates for them", "Use your programming expertise
to found a non-tech business and ROFLstomp on one core area of operations due
to your unfair advantage", etc etc etc.

~~~
dschiptsov
Pardon me for asking, what are your programming achievements, besides writing
a long-length comments and blog posts?) Where could we see your code?

~~~
tptacek
You just asked a non-sequitur question. Patrick said, "consider carefully what
you mean by success; one measure is geek status ranking, another is financial
success". You responded by saying "show me your code" --- in other words, by
implying that there is only geek status ranking, which makes no sense as a
response.

When you grok what Patrick is doing, the programming angle on it makes more
sense. On HN, he's best known for Bingo Card Creator (that's the work he has
the easiest time talking about). Here is the right way to think about Bingo
Card Creator: it is an experiment in how much engineering effort you can apply
to marketing as opposed to product features and what the payoff on that is.
The engineering in BCC is invisible to users; the product itself is "hello
world", hooked up to a random number generator. The result of the experiment:
he matched his salary with it, and then left his full-time development job,
because 5-10 hours a week of effort was paying him better than the 60 he spent
as a salaryman.

Also: get past the idea that you can gauge people's skills from their Github
profiles. Nerds are in love with that idea because it sure would be nice if it
were true. I've been a professional developer, mostly in C, since I was ~17
years old. Only a tiny fraction of the lines of code I've written --- and
virtually none of my favorite lines --- are publishable on a site like Github.

~~~
dschiptsov
It is not, of course, about github. It is much simpler. When some scientist
met, say, mathematicians, it is very normal to ask - show me what you have
done. Or the same thing with writers - Oh, you're writer? What did you wrote.

This thread was about programming, and the given comment was mere a self-
assertion. So, it is OK to assert oneself if one wants to. But, show us, then,
what you have done.

~~~
tptacek
No. It is desirable that people contribute their answers to questions. It is
undesirable for people to respond to those questions not by challenging the
substance of the answer, but by questioning the respondent's standing to
provide the answer. There is no "but, show us then". You have no status to
demand that of anyone here.

I you have lots to say, for instance about modeling natural language as
s-expressions, you too can write lots of long comments and blog posts, and we
will enjoy reading them. Unlike the short, nasty one you wrote above.

~~~
dschiptsov
Sure, I have no status, and I have no demands. What I like to do is to
distinguish between people who can program and people who just can talk, to
form my opinion on what I'm reading. Words are cheap.

~~~
lazydon
Words are cheap if you quote someone else. Probably as you are doing Linus
here. Not when they come from genuine experience of being in the wild. I
think, we with a fair bit of experience can make a good judgment when we hear
someone who doesn’t really knows what he’s saying.

Rest assured these guys here: <http://news.ycombinator.com/leaders> wouldn’t
be there if they could not code. Most of them have detailed profiles for you
to check out first, instead of asking them ‘show me the code’ on their every
comment on HN.

------
lerouxb
There are no _really_ successful programmers. In a general sense: There are no
_really_ successful wage-earners. The only _really_ successful people are
business-people. That applies to just about every industry. No one is going to
give you a billion dollars (or even a million) to sit at home or in an office
and write code. No matter how beautiful and optimised and whatever other
qualities you think code should have.

Unless you want to define " _really_ successful" as really good (which is
subjective) or popular and then the answer is obviously to be really good and
make something popular. Oh and try to make sure to get the timing right. ;)

~~~
Evbn
Jeff Dean?

------
kamaal
I am not talking about Linus Torvalds, Larry Walls etc of the world. But I am
going to talk about other developers who often make it big. I am talking of
people who solve difficult problems, add value and make money.

Great folks I've met are high on productivity, they are quick in discovering
things and generally maintain an aura of self confidence around them. Many of
them start off because they a 'lucky break' somewhere but they build on it,
they work hard and make their own space.

When we are talking of successful guys out there. We are ideally talking of
guys who are >40 now. I know a relative of mine highly successful 40+ guy.
Some of the things that I've noticed is, he is insanely hardworking, nearing
50 he can give any 20 year old run for his money. He is productive, doesn't
blog much, not very active on social media. Doesn't go gaga on small wins, he
has great focus on picking and solving tough problems. I mean problems that
can add real great value.

A few things that I've noticed is he is agnostic to tool religion. He goes by
what helps him, rather than our usual religious tool affiliations. He is also
very well organized.

So to add it up:

1\. Work really hard, I mean I literally. No excuses on this point.

2\. Focus on solving tough problems, adding value and things that matter.
Learn and master things that can help you solve problems. But there is no such
a thing called 'permanent' technology. You have to learn to move on, because
tools help you solve the problems. They are not your problems you would want
to solve. Unless selling tools is your business.

3\. Technology matters, but that is only a enabler.

4\. Be a little disciplined and organized.

5\. Celebrate big wins, write and talk about them. Network with people just
like you and surround yourself with smart people.

6\. Work hard on opportunities and always keep a tab on your next move. The
more opportunities you convert to finished work the more you get next.

~~~
lutusp
> When we are talking of successful guys out there. We are ideally talking of
> guys who are >40 now. I know a relative of mine highly successful 40+ guy.

I like your post and this isn't meant as criticism, but ... could we not say
"guy" so much? Women are often terrific programmers, and there should be more
of them. But that goal is thwarted by a certain common assumption about who
programmers are.

~~~
noibl
I don't post this with any sarcasm or to draw any inferences about your
intended meaning, but just to bring to your attention that the point you've
now raised struck me independently upon reading:

> A successful programmer is not just a programmer, he is also a personal
> representative, a salesman and a contract negotiator.

~~~
lutusp
Yes, fair enough -- in that case, I had to either choose a gender for one word
or go with one of those malaprops like "they".

~~~
stray
That wouldn't have been a malaprop. A malaprop is a misused word that _sounds_
like the correct word.

~~~
lutusp
So it seems. I should perhaps have said "compromise word" or "PC word",
alluding to the reason for the usage.

------
dschiptsov
They _think_ differently.

Take a look at Smalltalk at Xerox PARC, AI lab and Scheme language at MIT,
Plan9 at Bell Labs, Erlang at Ericsson, Go at Google, FreeBSD and OpenBSD
projects, etc.

For an individual achievements - Linux 0.9, viaweb, arc, clisp, nginx, redis,
sqlite, git, vi, emacs, etc.

Each particular story could be enough for learning almost everything about
software engineering.

Erlang is a story of applied principles, methodology and design decisions -
real-world functional programming success.

Plan9 is an example of what system programming really are, that less is really
more and good is really enough.) Take a lot at src/lib

Arc is a prove of concept that lies in foundation of the "On Lisp" book - that
you could evolve a language together with your software in a bottom-up
process. And he did.

The story of Scheme language you could read in MIT AI memos, where, actually
you could find all you need to know about programming.

Go is an example of how ideas form Plan9 and language design comes together in
a unique language with unique features.

The evolution of the Lisp is another example. Systems should evolve.

------
edw519
How to be an Excellent Programmer for Many Years

(Excellent==Successful. Money & fame are more difficult to control.)

1\. Choose a small subset of available technology, learn it intimately, and
embrace it. Then evolve that subset.

2\. Understand the pros and cons of various data structures, both in memory
and on disk.

3\. Understand the pros and cons of various algorithms.

4\. Understand your domain. Get away from your computer and do what your users
do.

5\. Be ready, willing, & able to deep dive multiple levels at any time. You
_must_ know what's going on under the hood. There is a strong correlation
between "number of levels of deepness understood" and "programming prowess".

6\. Use your imagination. Always be asking, "Is there a better way?" Think
outside the quadralateral. The best solution may be one that's never been
taken.

7\. Good programmer: I optimize code. Better programmer: I structure data.
Best programmer: What's the difference?

8\. Structure your data properly. Any shortcomings there will cause endless
techincal debt in your code.

9\. Name things properly. Use "Verb-Adjective-Noun" for routines and
functions. Variables should be long enough, short enough, and meaningful. If
another programmer cannot understand your code, you haven't made it clear
enough. In most cases, coding for the next programmer is more important than
coding for the environment.

10\. Decouple analysis from programming. They are not the same thing, require
different personal resources, and should be done at different times and
places. If you do both at the same time, you do neither well. (I like to
conduct analysis without technology at the end of the day and start the next
morning programming.)

11\. Never use early exits. Never deploy the same code twice. Never name a
variable a subset of another variable. You may not understand these rules and
you may even want to debate them. But once you start doing them, it will force
you to properly structure your code. These things are all crutches whose use
causes junior programmers to remain junior.

12\. Learn how to benchmark. Amazing what else you'll learn.

13\. Learn the difference between a detail (doesn't really make that much
difference) and an issue (can end the world). Focus only on issues.

14\. Engage your user/customer/managers. Help them identify their "what".
Their "how" is not nearly as important.

15\. Write a framework, whether you ever plan to use it or not. You'll learn
things you'll never learn any other way.

16\. Teach others what you know, either in person or in writing. You'll
accidently end up teaching yourself, too.

17\. Always tell your customer/user "yes", even if you're not sure. 90% of the
time, you'll find a way to do it. 10% of the time, you'll go back and
apologize. Small price to pay for major personal growth.

18\. Find someone else's code that does amazing things but is unintelligible.
Refactor it. Then throw it away and promise yourself to never make the same
mistakes they made. (You'll find plenty.)

19\. Data _always_ > theory or opinions. Learn the data by building stuff.

20\. At some point, run your own business (service or product). You will learn
things about programming that you'll never learn as an employee.

21\. If you don't love your job, find another one.

~~~
godbolev
Could you please elaborate on No. 11?

"Never use early exits". Could you please elaborate what you mean by that?

PS. I'm not trying to unintentionally start a flame war. Just trying to
understand.

~~~
edw519
Excellent question that is difficult to answer. I'll give you a short response
here and then write a blog post with example code when I have time. Put your
email in your profile and I'll make sure to let you know when that's ready.

A little background: I have gotten many calls when legacy code has a bug or
needs a critical enhancement and no one in-house is willing or able to figure
it out. I'm no smarter than anyone else, but because I'm stupid and fearless,
I often do something that few others attempt: I rewrite or refactor the code
_first_ , then work on the bug/enhancement. And the first thing I always do is
look for early exits. This has always given me the most bang for my buck in
making unintelligible code understandable. The only entry to any function or
subroutine should be on the first line and the only exit should be on the last
line.

This is never about what runs fastest or produces less lines of code. It's
strictly about making life easier for the next programmer.

Early exits can make things really easy (I'll just get out now.) 20 lines of
clean code. No problem. Until years later, when that function is 300 lines
long, and the next programmer can't figure out what you're doing. Much of the
maintenance had been done in emergency mode, each programmer just trying to
get in and out as fast as they could.

Early exits make it much easier for bad things to evolve:

    
    
      - 200 line multiple nested if statements
      - 200 line multiple nested recursions
      - unidentified but critical "modes" (add/change) (found/notFound)...
    

Removing early exits forces you to understand what really should be happening
and enables you to structure code into smaller, more intelligible pieces.

Short, hand-wavy response, but I hope that helps clarify some. Stay tuned for
a better answer...

~~~
albertzeyer
I'm not sure if I would agree on this. Take for example the Linux kernel. You
have basically early exits just everywhere. Take any random file from here:
[http://git.kernel.org/?p=linux/kernel/git/stable/linux-
stabl...](http://git.kernel.org/?p=linux/kernel/git/stable/linux-
stable.git;a=tree;f=kernel;hb=HEAD)

It often goes like this:

    
    
      check if we have already done this or so -> exit
      check if this is possible to do. if not -> exit
      do some first thing. on error -> exit
      do some other thing. on error -> exit
      ...

~~~
daengh
He also said his statement "This is never about what runs fastest...". Kernel
code needs to run fast and take advantage of shortcuts.

IME, the jobs most programmers are doing don't _need_ to try to accomplish
maximum speed or _need_ to wring a few bytes out of RAM. Certainly we don't
want to be wasteful, but long-term maintainability is more important, again
IME, than absolute speed or minimising memory footprint by a few (k) bytes.

Back in the bad old days when I was writing programs to run on mainframes,
yeah, we did need to fight for every byte. A $5 million machine back then had
less RAM and less raw CPU power than a tablet does today. We don't live in
that world now.

~~~
masklinn
> He also said his statement "This is never about what runs fastest...".

This style has nothing to do with running fast, it has to do with lowering the
cognitive load of the rest of the function. A branch means you have two states
to keep in mind (the state where the branch is taken, and the state where the
branch is not taken). Without early exit, you have to keep both states in mind
until the end of the function just in case.

With guard clauses, you can discard on of the states (the one which matched
the clause) entirely.

~~~
daengh
Computers can do that repeatedly and reliably with even (hundreds of)
thousands of discarded states. People reading code and trying to understand
what's actually in play at line _umptyfratz_ of function
iGottaGetThisFixedNow(), not so much.

In the end, I'm not disagreeing with early exits _per se_ , just that over
time they can make it more difficult to understand function because
assumptions about state have to adjust as a maintainer goes through the code.
Those assumptions may have been crystal-clear to the writer originally but how
many times is the original writer the only maintainer?

------
notum
My guess is that they didn't waste energy by paying too much attention to
blogging coder's rants.

------
rsaarelm
Another question: How much luck was involved beyond making the necessary good
choices? You can look at John Carmack or Peter Norvig and say that they made
good choices X and Y and so on, but how much will this tell you about the
prospects of a programmer who hasn't hit it big yet and who is doing all of X
and Y? Worst case is, even though everyone who makes it to the top needs to
have some qualities, successfully cultivating the qualities might still just
get you from a 0 % chance to a 1 % chance at ending up successful.

I'm sure it's far from being that bad for programming, particularly if your
main goal is to not end up miserable. Still, for every one John Carmack, I'm
sure there are a 100 or a 1000 people as skilled and as hardworking, but who
don't have the same amount of recognition.

They might have rather cushy jobs at some obscure R&D lab though. Which
suggests a third question: What kind of people without widespread name
recognition should we also be asking the "what did they do right" question
about? It's easier to start thinking about John Carmack instead of Joe Q.
Senior Systems Development Fellow, but that primes you for the somewhat wrong
goal of trying to get massive name recognition in addition to the not ending
up a miserable programmer one.

------
Ensorceled
I'm a 48 year old developer. I'm currently doing a bit of contracting on the
side while starting my own company. I can still see myself doing this in
another 10 years despite my current rate of decline.

Most 50+ developers "having a pretty bad time" have made the following
mistake:

They became highly paid experts in technology that was important when they
were 30.

Focus might work out for you, my uncle made a boat load of money in the late
90's when he was 58. Mostly because he was an expert Cobol programmer. But
more than likely you will regret it in 10 years.

Stay current. Stay passionate. Stay active on Slashdot, HN, or whatever the
next one is. I'm currently building using Django/jQuery/Bootstrap. My last
project was GAE. I love what I do.

------
lhnz
Many of those people have very individual approaches to development and are in
a sense making massive contributions to the industry.

I'm not sure if you've heard about the concepts of Structure and Agency [0] in
sociology? Consider the importance of: (1) being able to go off the beaten
path to chase a new way of thinking/working or an idea which can improve many
other people's lives, and (2) being in a company or position which gives an
increase in high-value opportunities.

In any case, forget about just being a standard developer if you want to reach
this level of impact. You own neither the platform on which you can reach a
large group of people; nor the intellectual skill, anti-authoritarian outlook
or vision required to create at a standard that sets you apart from your
peers. There is something qualitatively different here from the careers of
normal developers.

By the way, the ease of defining these qualities actually means it's not so
hard to go about reaching them. If you can engineer software, you can engineer
your career.

[0] <http://en.wikipedia.org/wiki/Structure_and_agency>

------
Loic
Programming is a _tool_ to solve a _problem_.

Focus on hard problems and you will end up using and developing the right
tools to solve them. By focusing on hard problems, you will naturally stay up-
to-date with companies looking for your expertise.

------
ChristianMarks
"We are prone to overestimate how much we understand about the world and to
underestimate the role of chance in events." -- Daniel Kahneman. Thinking,
Fast and Slow.

I returned, and saw under the sun, that the race is not to the swift, nor the
battle to the strong, neither yet bread to the wise, nor yet riches to men of
understanding, nor yet favour to men of skill; but time and chance happeneth
to them all. -- Ecclesiastes 9:11﻿

------
ColinWright
Read Richard Hamming's "You and your research", quoted on full on PG's own
site, and I've submitted it here for a separate and new discussion:

<http://news.ycombinator.com/item?id=4626349>

------
ak39
There's a crucial difference between a good programmer and a successful one.

And the two aspects are certainly not mutually exclusive, and by that I mean:
being a good programmer does not necessarily translate into being a successful
programmer. The reverse is true too.

IMHO, to nurture a lasting career as a "programmer", you have to balance the
two aspects. Be good and successful.

------
DenisM
People will give you huge lists which will disorient more than they help. Let
me give you a very short list:

1\. Learn more about your customers by getting out and talking to them. Most
engineers are deathly afraid do that, and many are not even technically able
to do so, living in other countries or just not having the access. Thus you
will have a big avantage over them.

2\. Force yourself to learn to work in teams. This will push you to go against
the typical lone-wolf attitude, but cohesive teams always win. without
exception.

3\. Learn to appreciate people who have complimentary expertise. Most
engineers prefer to stick with their own kind, which creates very lopsided
teams.

Ignoring these three factors dooms 99% of engineers out there to a life of
being merely average, and if you make the best of all three you will be in the
1%, the exceptional engineer.

------
roh26it
I think great programmers are very much like other great people. To quote a
cliche.. they stay hungry and foolish.

------
silverlake
You've picked the rare few outrageously smart and successful as examples. This
is like asking, how can I have a career in music like The Beatles, Michael
Jackson and Elvis?

~~~
smikhanov
But it's still useful to understand what made them successfull. People do
biographical research, write huge biography books, and read them for this
exact reason. In the case of Beatles, for example, it is widely believed that
it's their time in Hamburg, when they were playing every single day for hours
non-stop, that was crucial to their formation as star musicians.

------
cx42net
I'm starting to believe that to be a successful programmer, one has to be
ignorant and clever. It can seems contradictory but the more I work for
company, the more I'm starting to believe it.

The reason? You have to be a total ignorant to be ready to jump in a work that
will require you a 2000% commitment and a lot of stress, problems, and so on.
But still some of us go for it.

The next step requires to be more ignorant than at the beginning : when you
start doubting about your work/competences, facing problems with your project,
most people realize that they are stuck and abandon. Not successful
programmer, they keep going on, ignoring all the signals, friends telling them
the idea is stupid, recurrent (logical) problems, etc.

But at the end, something new appear, and sometime it's revolutionary, and
sometime, the programmer become sucessful.

It's the Entrepreneur Roller Coaster
(<http://www.youtube.com/watch?v=XKocnAS345U>) and it's a mix of willingness,
chance and dedication.

------
manmal
I like to think that successful people of all professions owe it to their
methods (and then there is pure "luck" too). E.g., Seinfeld has been known to
improve his skills on a daily basis, and is still able to deliver highly
successful products (e.g., he wrote "Bee Movie", a surprise hit movie). Might
be that his daily improvement has nothing to do with it, but you can never
make much of anecdotes anyway. There is an app for that which I like to use:
<http://itunes.apple.com/us/app/commit/id473527073?mt=8>

Einstein said something like "I owe many of my achievements to my persistence,
not letting go of my goal until I achieve it" (Nash proved later that keeping
to a strategy [= persistence] increases chances of winning a game), and
Feynman has been known as a big advocate of the scientific method per se.
Again, hard to say whether they owe their Nobel prizes to these methods, but I
like to think that they helped.

Methods are actions gone habits. If you force yourself to think "Is this
really right?" before coming to a conclusion, you will soon do it
automatically. As a programmer, you could build up the habit of understanding
the system you are currently operating in, before fixing or enhancing a part
of it. Or you could write a pseudo-code script using your API (or testcases
;)) before implementing it, to get a grasp of what your users will actually
use it for. You can make it a habit to blank out program areas in your mind
which you don't currently need, to reduce cognitive load and turn a greater
focus on the problem at hand (which will also enforce modularization
automatically).

There are many such methods (also including getting more focus out of your
worktime etc.), and they can become habits if you execute them for long
enough. Habits are everywhere, and the (IMO) most crucial ones are hidden in
how we think, and our thoughts eventually ensue our actions.

~~~
agentultra
Practice is a good habit. I like to warm up in the mornings with a code-kata
problem before I start my day. Just take a trivial problem and write a program
to solve it. Take the same problem on another day and solve it a different
way. Contrast the results of the two approaches. Think about which approach
felt more natural, which one was most efficient, in what real-world cases
would you choose one approach over the other... in other words, reflect.
Practice without reflection is meaningless repetition.

------
codex
There are plenty of things a "great" engineer does differently, but to be "as
successful" as those you've cited, you need more than that. There are 1.5M
software engineers in the U.S. Your examples are probably in the top 1000--
that's the top 0.1 percent (i.e. 0.001 of the total). To get there you need
high cognitive capacity, hard work, and an extreme amount of luck. That said,
you can increase your luck my examining macrotrends in the industry.

But what do I know--I'm not as successful as those guys, nor is anyone posting
here, so we're all just pontificating because we like to hear ourselves talk.
Don't lean too much on advice from anyone less successful (or as successful)
than you.

------
snarfy
When studying a musical instrument, it is important to spend your practice
time trying to improve. Do not waste time playing parts you are already
capable of. Practice must be difficult and push your limits. This is true of
many aspects of life, including becoming a better programmer. You should be
trying to write programs that you don't know how to write, not yet another
client/server database application.

------
fdr
In the class of programmer given as an example, I think a lot of the answer is
some amount of self promotion. This is not meant in a derogatory way: it is
true some people self promote to the exclusion of doing something actually
interesting, but there are a number of programmers who are very, _very_ good
whose names are known by very few, and the biggest difference I can see is
self promotion. Self promotion can take the form of writing useful, thought
provoking articles, so it is not in and of itself counter-productive.

Here's one of the programmers I respect most who I will guess only a few here
have ever heard of who falls into this category:

    
    
      http://en.wikipedia.org/wiki/Tom_Lane_(computer_scientist)
    

I heard of him because of a PostgreSQL committer I had the privilege of
working with briefly, Neil Conway, who described him in glowing language that
left an impression on me. However, his achievements far outstrip his strong
part in the stewardship of PostgreSQL: if you have seen a TIFF, JPEG, or a
PNG, you may also have some thanks to give to him. Especially mind-boggling is
his contribution as measured by a study in 2000[0]. I can't comment as to the
details of its methodology, but anyone who manages to show up in the top ten,
nestled among entire organizations (FSF, Sun, University of California, and
above MIT) is, to me, already someone deserving of a legend, or two. So are
probably the other individuals mentioned there...who, unfortunately, I have
never heard of: Gordon Matzigkeit, and Paul Houle. I have, like many people,
heard of Ulrich Drepper, who appears on this list, and the tidings I hear are
not entirely positive. But we know what is said about publicity...

Since that conversation with Neil some years ago, I have interacted with Tom
and read his mailings on the postgresql mailing lists a number of times.
There, you see him dealing with all the usual bullshit everyone has to put up
with in real time: toolchain regressions, build farm issues, niggles in two
features that interact badly, and so on. Besides that, the quality and care in
even the first draft of his features are also remarkable.

Unlike some famous programmers who -- while very competent -- can be very
contrarian in their work (and invite controversy, which is some form of self-
promotion), Tom is not as such, and I think provides a great counter-point to
that style of distinguishment.

I think it'd be fascinating for someone who has the skill to interview him
about his long and productive service to writing useful software. If I have to
guess on his behalf, here's what I can assess about Tom:

* Work on important problems

* Work on them for a long time each

* ...but not necessarily forever

* Build the software to last

* Keep working

[0]:
[http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/ar...](http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/769/678)

------
jmedwards
I think they stop being programmers and become solution engineers. The
programming changes with the times but the ability to design and implement
elegant solutions to a given problem is a timeless (and rare in terms of
'really successful') skill.

Or, so I think.

That's also one of the reasons why I don't like the title 'programmer' as
opposed to something like 'software engineer'.

------
benologist
They got lucky - they picked the right career and made the right choice enough
times to still enjoy what they do decades later.

~~~
bornhuetter
This is partly true, but mostly unhelpful.

~~~
benologist
Sure, but it's a generally unhelpful question I think. Most people aren't
going to stay passionate about the same job, career, wife, husband, problems,
solutions, whatever, for 50 years.

There is nothing you can do that will _make_ you remain interested and excited
and passionate about something for decades.

------
mengine
If you are talking strictly about money, the majority have figured out how to
trade their value for something other than an hourly wage/salary. You can only
make so much money by trading your time for it.

Typical Engineer: 2000 work hours/year * $50/hour = 100k/Year

John Carmack: 1.7 million copies of Quake * $1 profit = 1.7 Million/Year

Jeff Dean: # of Google shares * $756 = $?

------
olalonde
Not precisely answering your question, but I find this "programmer competency
matrix" to be a very good guideline of which skills I should try to work on.

[http://www.starling-software.com/employment/programmer-
compe...](http://www.starling-software.com/employment/programmer-competency-
matrix.html)

------
mohit_agg
they simply 'pursue excellence' and success follows.

they don't just think about adding a new feature, they are the one's that will
say, 'let's re-architect the whole system', 'we need a better programming
language'. they will read research papers, follow the latest in technologies
and apply them in their field to create prototypes even if it's not part of
their job.

good business people will appreciate it and back them up. if they don't they
will probably find other people who will because they are passionate about it.

they can start their own ventures but who wants 10 companies like google
believing in the same values, competing against each other, instead working
for a company lets them focus more on their passion.

this is just what i think and i may be wrong. this is my first comment on HN.
:)

------
reiz
Somebody told me the only difference between a young programmer and a old
programmer is the experience. The old programmer did already a ton of
mistakes. And if he learned from that, he is dam good. The young programmer
will do a ton of mistakes and hopefully learn from that.

------
sedachv
There's a book called _Making it Big in Software_ by Sam Lightstone that came
out in 2010, about this exact topic. It has interviews with several prominent
programmers. I found it a boring read, though.

------
markab
Great Question, I'll add in my $.02 :)

I'm a 37yo that dropped out of college to go work during the late 90's in the
.com boom.

I don't know what other people judge as 'successful', but a few things of note
that has helped me make a great living and manage to get myself into positions
of control and equity.

1\. I'm always making sure that every hour I spend working is solving a
BUSINESS problem, not a personal bauble that looks shinny and interesting.

2\. Back to point one. I'm usually in a position where myself or the
programmers on our team have a unique perspective into any project or business
we are involved in. That said, I've become a quasi analyst with the business.
I'm able to find 'leaks' in process and revenue that would be harder to find,
and I'm always worth more around than to not be.

3\. Try to keep your miracles to 2x a year. Bill Joy wrote that once, their
aspen R&D team at Sun Microsystems are expected to perform them twice a year,
and though not every miracle made it off the launch pad, a lot did.

4\. Wins are found through empathy and inititive. Make friends, make yourself
a hero by solving those friends problems and try to go out of your way to make
the lives of the pople using your software easier.

5\. Don't paint yourself into a box where you feel like you need to build
'fun' projects to be fulfilled. The most interesting projects I've done are
often problems that people would fall asleep hearing about.

6\. Get -very- good a picking horses. This is important! I've made a great
living make sure that the people I work with and partner with are better than
me. Always. I put myself in a situation knowing that if I don't go in with my
A game, I'll probably not last long. I'm expected to do and build great things
and often times I do.

That leads to...

7\. Share your losses and your wins with the non-developers. When something is
hard, and you solve it.. share it. When something is hard and you break it...
share it. Communication is so important to building the only currency we have
in our industry.. trust.

9\. Only work on projects you -know- have the potential to make money. Never
get stuck in the trap of being a 'cost center'. This is a dangerous place to
be. Every project I've done and lived beyond 9 months is when I bled to make
sure that the project is viable. Every project should be looked at as a
individual P&L. consider what you make, what your team makes.. and make sure
you're contributing to the bottom line revenue and health of the company.

10\. Never be too good for anything, but also never get caught into the trap
where you're doing anything that is below your pay-grade. This goes back to
point 9.

11\. Make your work your hobby, and your hobby your work. If you find real joy
and meaning in what you do you'll have a great career regardless of the
financial rewards.

12\. Never ever spend time away from the core of the problem. Be close to the
guys talking to the customers, or the vendors depending on your model.
Understand their pain points, their concerns. It will help you understand how
the software you're building is effecting the human-side of the equation.
-NEVER- isolate yourself away from what we call distractions. Be apart of the
chaos of a new business, you need to understand exactly what's going on so you
can head problems before they become a crisis and an emergency.

That said. I've been involved at a partner level at various companies over the
years. One we had a big hit that we sold to a international corp and though i
didn't leave and buy an island, it offered me the ability to pick my
subsequent projects very carefully. Any startup I'm in I'm sure that I'll at
least own a good-sized chunk of the company in equity. I spend a lot of time
working to understand what would be the best use of sparse technical resources
and development to gain the most buck.

Any time we as a team start looking on how to attack code, we all ask
ourselves... "Where is the business win?" We try to test all of our
assumptions on priorities and features against that. It keeps the true scope
of what we're trying to do in line, and can really add urgency when it might
of been less obvious.

I've worked with a couple of partners over the years that have proven to have
the right chemistry. I'm careful to not commit to things I don't believe we
can do with success. If I don't think our team can effectively guide the
project to success, we don't do it. If we do commit to it, we'll drive to a
POC as quickly as possible and start iterating through feedback as quickly as
we can.

We are engineers, we're not wage-earners. The experience we have solving
software problems often puts us in a position to solve business problems with
the same pragmatism.

Seek to make impact. As a matter of fact, try to be an impact-whore. In
business I've seldom seem much else matter.

As someone else in this thread said, you can be a wage-earner or figure out
how to participate in the business. By doing the later, I've been able to
exceed what I believe my peer-wage earnings by many times. Don't be scared of
that side.

No point in human history has so much new business and revenue been possible
with just the trade-off of energy of the building of something new. I've been
a part of a new start-up that started sadly enough in my basement. We operated
like that for about 3 months before we felt we could justify the office space.
We brought on people very slowly, and though now we're moving forward at a
little more exciting pace, we were profitable at month 2 with 5 employees
including myself and a few other not-so-expensive people.

The joy is, as the business continues to grow, I'll participate on the upside
of it.. and one good month can be worth more than a year of salaried work. You
taste that 1 time and it's like crack, it's hard to go back to being just a
wage earner.

------
zallarak
This is a bit more pragmatic and short-sighted, but learn a good text editor
(Vim, Emacs, there are others too) and type [relatively] fast.

------
patothon
\- Highly Driven \- Highly focus

~~~
JDW
Yes, to say the least... I do not know what paved the way for all
aforementioned programmers put after reading about Carmacks work in "Masters
of Doom" I'd say focus is extremely important... And at least myself is
extremely bad at it - there is always 10-ich projects going on... If you want
success today I think being extremely specialized is a must.

~~~
patothon
It's not only about specializing yourself.

It's about knowing where you want to go, what you want to achieve, and be able
to focus enough to go there. Vision + Execution.

For me focus is at the same time "fast and slow".

You have the focus on the long term vision of your career, products etc. That
means, yeah, probably choose between your 10 projects. But again, it depends
the goal you set yourself concerning those 10 projects. If you're a pragmatic
OSS commiter ("I commit the changes to this lib' I really need for my main
product"), then 10 projects is okay.

Then You have to focus, during your day to day work. Where do I head with this
feature? What do I want to achieve? What problem am I trying to solve here?
Did I think about all the edgy cases? Did I test everything? Is the code
better now than before? etc.

It's hard work.

Be Driven, Be focus.

------
threepipeproblm
I can't wait to read the responses, but before I do I'm going to throw out my
theory. Some people keep their physical health going, and some don't. I'm not
talking about going jogging, but rather metabolism, toxin accumulation, brain
function, etc.

------
lamdaman
Work on important problems.

------
andrewartajos
They wrote books.

------
noobplusplus
One thing that I would like to point out is, being financially successful and
extremely competent programmer are two different things. An example Zed Shaw
is an extremely good programmer, but if you read his legendary rant "rails is
ghetto" you come to know besides being an extremely great programmer he had to
struggle financially.

So being a good programmer is not synonymous to having your bank accounts with
decent zeroes following some non zero number.

Incidentally, yesterday I was talking to a programmer who had been coding for
17 years, he codes bots for games in C++ when not coding other stuff. He did
not take his degree seriously, and today is looking for an MNC to hire him, so
that he gets married, for the chic wants a secure life.

What did the good programmers do differently? Its a difficult question to
answer. Having said that, couple of things are:

1\. starting early

2\. getting lucky

3\. focus and hardwork

4\. marketed themselves properly

5\. surrounded themselves with better programmers, to get better at it.

6\. capitalized on the opportunity of solving a __tough __and __challenging
__problem.

ending on a pragmatic quote: _passion burns out, what sustains is greed_.
(taken from "Do you want to be doing this at 50")

~~~
dasil003
Great post. I think there's a huge selection bias when someone drops the kind
of names the OA did. All those guys had hugely visible successes, but it's
hard to know how replicable any of that is. Given equal skill to Carmack or
Hickey, I don't see a brilliant guy having a reasonable chance at writing the
next Quake or Clojure. Those successes are black swans.

There are a lot of guys making $250k or more working on some obscure B2B
product or enterprise team somewhere. Just because we don't hear about them
doesn't mean they aren't just as happy or find as much meaning in their work,
and it's certainly a lot easier to optimize for if that's what you want.

That said, I think programming is a bit like a professional athlete in that
you can't have a great lifelong career by sticking purely to the technical
aspects. You need to be learning how your skills apply to real businesses and
building your network. Fortunately I think these things happen naturally to
some extent, but it can't hurt to think about them.

------
michaelochurch
I think that a big part of it is the quality of work you get. If you work on
business apps that aren't very well appreciated and most of your time is spent
maintaining projects where the decisions were already made, you're never going
to get to that level. A couple scut projects early in your career can teach
you things about maintenance and just why code quality is so important, but
eventually, you need to graduate beyond that sort of thing and move to
projects where you can learn from _your own_ decisions.

Working with software is like poker. If you aren't playing with real money, it
gets boring quickly. Programming is fun if you have "skin in the game"-- a
decision where you want to see if it was the right one, a problem you want to
solve-- and it's mind-numbingly boring if not.

You need, somehow, to ensure a reliable stream of high-quality work. You need
to become that guy who moves from machine learning to self-driving cars to new
language development while the unlucky saps are trying to swing from an HR app
led by a Manager II to an HR app led by Manager III.

I don't want to trivialize this, because getting high-quality work is really
fucking hard. There just isn't much of a budget for it, and usually getting
the best work involves manipulating the politics, especially when you're young
and not "obviously" qualified for it yet. Good work tends to be R&D stuff
where up-or-out business people who will be promoted or gone in 4 years can't
see the payoff. You often have to take a mercenary attitude toward transfers
and job changes and, if your boss isn't personally interested in your career
growth, balance out the universe by stealing an education. Most people learned
how to program by doing something other than what they were supposed to do.
This doesn't change when you become a professional programmer. Good
programmers tend to put their own development over business goals--
"optimizing for learning"-- because otherwise, they wouldn't have become any
good.

People talk about "5:01 developers", but I've started to think of myself as a
"1/21 developer". I expect to grow the value of my programming skill set (and
indirectly, my earning potential) by 1% every 21 days. It doesn't have to be
coding only. Improving social skills or business knowledge can easily account
for such an improvement. I make that rate of growth (more as metaphor and
guideline than hard lower bound, because it's impossible to measure such a
quantity precisely) an almost inflexible primary constraint, as important as
(a) getting done what I'm told to do, (b) showing up on time, and (c) not
being offensive at work. None of these get slack except in extreme
circumstances, so why should my learning rate?

1 percent every 21 days might not seem like much-- it's incremental change as
opposed to get-rich-quick bullshit-- but that's a doubling every 4 years, or a
factor of 32 in two decades.

What I think is getting much harder is consistently putting yourself forward
as a person who deserves the best projects. As the number of frameworks and
languages increases, we're getting curse-of-dimensionality problems. Being
seen as a good programmer (which is increasingly different from being one) is
an artifact of terrain knowledge, these days, more than general competence.
This makes political battles around tooling a lot nastier, because the stakes
are so high.

I think the way out is, for now, to establish a credibility in something other
than engineering-- statistics, business, design. Hence the X-Who-Programs vs.
Just-A-Programmer phenomenon:
<http://michaelochurch.wordpress.com/2012/08/26/xwp-vs-jap/> . If you're a
software engineer and nothing else, your place in the pecking order is unsafe
because of tool-sensitivity, so you need to diversify into other areas of
knowledge.

~~~
manmal
How do you quantify the 1% per 21 days improvment? There are no easy-to-get-at
brain weight scales yet. I agree with your incremental change mindset, I just
find it hard to measure.

An addition to your proposition that you needs make your decisions in order to
improve: You also need to actively learn from your failures. Many people just
go like "That sucks, it did not work out" without ever asking the Why. That's
not enough to learn, and one could even learn the wrong lesson from a failure.

~~~
michaelochurch
_How do you quantify the 1% per 21 days improvment? There are no easy-to-get-
at brain weight scales yet. I agree with your incremental change mindset, I
just find it hard to measure._

Agreed. 21 days is a good audit point. If you can make the case to yourself
that you've improved the total value of your skill set by 1 percent, then
proceed normally.

This is equivalent to 19% per year. That's measurable if you pay attention to
market trends. Keep in mind that if you stick with one job, you're likely to
bank only half of that increment. You probably won't get 20% pay increases
unless you work for yourself (in which case your expectancy might go up by
20%, but you have a lot of volatility). You'll get 6 to 10 percent per year.
It might still be worth it to stay in the same job, if you feel like you're
learning a lot. Part of the reason why the pay improvement is slower is that
the best engineers tend to prefer more interesting work (and stability, as
they get older) over aggressive salary growth.

Here's a scale for software engineering:
[http://michaelochurch.wordpress.com/2012/01/26/the-
trajector...](http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-
of-a-software-engineer-and-where-it-all-goes-wrong/) . Each 0.1 increment
seems to be about a 26% increase in abstract business value (or a 10-fold
increase per 1.0) and about an 8-15% increase in salary. You should be aiming
for 0.1 every 18 months, which is hard but doable, although it usually
requires pushing back at work sometimes.

 _An addition to your proposition that you needs make your decisions in order
to improve: You also need to actively learn from your failures. Many people
just go like "That sucks, it did not work out" without ever asking the Why.
That's not enough to learn, and one could even learn the wrong lesson from a
failure._

Absolutely. No disagreement there.

------
its_so_creative
one thing the most successful - truly succesful - programmers i know or have
heard of do, is understand the importance of the big idea, of designing
something worth designing.

on the previous article (do you want to be doing this when you're 50), i tried
to submit the following comment.

" Well, a programmer can - in a matter of hours, or at most days/weeks -
assemble a factory performing the work of 10,000 full-time highly trained
workers (actually more, we're talking billions of operations per second), at a
total direct cost of a couple of coffees and use of a device costing few
hundred dollars new, and then fully own all rights to the factory, and operate
it full-time for about the cost of a normal person's phone bill per month
(server instances). So the question isn't why there are millions of high-
paying jobs to do so for someone else with the resulting rights and ownership
by someone else:

the question is why anyone takes any of these jobs. why not build your own
damn factory. It's usually only because you lack some of the skills (design,
business development, marketing, choosing what to produce, etc).

so, team up with a cofounder. hence: hacker news. well, there is one downside
here. the programmers who work here would never team up with a designer who
knows just what to build. instead they both get hired by someone who does. the
designer gets hired at a low rate, then the programmer gets hired at a high
rate, just because the person hiring the two knows what is needed to get the
factory producing something people will pay for: but the programmer (readers
on this very article right here at hacker news), doesn't.

so yeah there are millions of jobs for you to build value for others, but it's
just because you're not quite wise enough enough not to need these jobs.

(suppose i'm such a designer. split a company 60/40 with me? No, you would
not. But work for 1.5 my wage at the same company, so that neither of us gets
to reap the benefits. yes you would.) "

~~~
markab
You did a much better job of articulating a point I've ranted on many times to
my colleagues. I love the analogy of the factory worker.

The interesting thing is no point in human history has the walls of
aristocracy and institutional money been torn down so quickly in a single
industry.

To do what many of us can do in our basement for the same 'work yield', people
would borrow millions in the past. In the industrial era of our country, who
would of been able to start a factory in their basement with $200 worth of
equipment.

That's what drives me nuts when friends and people I respect want to spend
their time building gimmicky products and hope they get picked up by someone.
If people spent 1/2 the amount of energy looking around them and just finding
one business problem to solve that makes someone else money (not just
yourself) in either efficiency or growth, you'll be a very successful software
engineer.

Thanks for sharing :D

