Ask HN: What did the really successful programmers do differently?

- Highly Driven - Highly focus

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

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

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

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")

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

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

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.

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

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.

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.

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.

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

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.

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.

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.

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'.

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.

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

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

  goto end;
  ...
  end:

    start:
    if(!p) goto end
    ...
    goto start;
    end:

  - CommandRec
  - Command
  - Comm
  - Com

    if (UnexpectedOrUnhandledCondition(x)) {
      ...
      return false;
    }

    if (OtherError(y)) {
      return false;
    }

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.

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?

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

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.

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.

"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