14 ms·

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

• patothon 14y ago
  - Highly Driven - Highly focus
  • JDW 14y ago
    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 14y ago
      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.
• notum 14y ago
  My guess is that they didn't waste energy by paying too much attention to blogging coder's rants.
• benologist 14y ago
  They got lucky - they picked the right career and made the right choice enough times to still enjoy what they do decades later.
  • bornhuetter 14y ago
    This is partly true, but mostly unhelpful.
    • benologist 14y ago
      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.
• lutusp 14y ago
  > 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 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 14y ago
    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.
    • lutusp 14y ago
      > business people who have technical skills are similarly more likely to succeed. Yes, and business people and managers who have technical skill and knowledge possess the advantage that they can detect when programmers are lying to them or exaggerating, and they can schedule realistic programming project times. Nothing is worse than a manager in charge of programming projects who doesn't understand programming.
• noobplusplus 14y ago
  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")
  • JDW 14y ago
    "Starting early", super important! "Getting lucky", yes - both in time and in income - striking gold is not much worth if you can not step up on the possibility - and sadly, for many, having kids or a ill parent, or loosing a steady income is to big a obstacle to tacle... Meaning, you might not have that many a year to live that, wild, frivolous, entreprenourish life...
  • dasil003 14y ago
    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.
• roh26it 14y ago
  I think great programmers are very much like other great people. To quote a cliche.. they stay hungry and foolish.
• lhnz 14y ago
  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 http://en.wikipedia.org/wiki/Structure_and_agency
• kamaal 14y ago
  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 14y ago
    > 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 14y ago
• ColinWright 14y ago
  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 http://news.ycombinator.com/item?id=4626349
• rsaarelm 14y ago
  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.
• manmal 14y ago
  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 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 14y ago
    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.
• michaelochurch 14y ago
  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/ 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.
• lerouxb 14y ago
  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 14y ago
    Jeff Dean?
• patio11 14y ago
  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 14y ago
    Pardon me for asking, what are your programming achievements, besides writing a long-length comments and blog posts?) Where could we see your code?
    • statictype 14y ago
      You're asking the wrong question. A better question would be "what have you achieved while being a programmer?". Possible answer: Learning a skill that most programmers shy away from, are afraid of, or down-right scorn, thus giving me (him) an almost unfair advantage over virtually every other programmer out there.
• dschiptsov 14y ago
  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.
• ak39 14y ago
  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.
• jmedwards 14y ago
  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'.
• edw519 14y ago
  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.
• threepipeproblm 14y ago
  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.
• silverlake 14y ago
  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 14y ago
    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.
• olalonde 14y ago
  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-competency-matrix.html http://www.starling-software.com/employment/programmer-compe...
• Loic 14y ago
  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.
• codex 14y ago
  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.
• deleted 14y ago
  [deleted]
• ChristianMarks 14y ago
  "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
• deleted 14y ago
  [deleted]
• Ensorceled 14y ago
  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.
• its_so_creative 14y ago
  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 14y ago
    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
• napillo 14y ago
  Only one of those guys is 50+. Carmack is only 42. You are talking about exceptional programmers, with a high impact on their fields. If you want to emulate them, you'll end up quitting at 50, realizing you aren't ever going to reach their level. Most people don't. You won't be a rockstar, you'll be lucky to be better than average. Set goals for yourself and meet them. If you don't have any goals, then come up with some good ones.
• zallarak 14y ago
  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.
• mengine 14y ago
  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 = $?
• lamdaman 14y ago
  Work on important problems.
• DenisM 14y ago
  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.
• snarfy 14y ago
  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.
• andrewartajos 14y ago
  They wrote books.
• sedachv 14y ago
  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 14y ago
  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.
• cx42net 14y ago
  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 http://www.youtube.com/watch?v=XKocnAS345U) and it's a mix of willingness, chance and dedication.
• fdr 14y ago
  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/article/view/769/678 http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/ar...
• reiz 14y ago
  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.
• mohit_agg 14y ago
  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. :)