Live data from Hacker News

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

news.ycombinator.com

161–170 of 178 posts

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

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

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

#163

Earlier quoted context omitted.

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…

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.

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.

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

#164
post #85
post #37

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 c…

Always ignore advice that begins with the word "always". The use of "never" is never a good sign either.

Only Sith deal in absolutes!

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

#165
post #155
post #92

Earlier quoted context omitted.

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

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

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

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

#166
post #37

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 c…

"Never use early exits" is tantamount to saying "never study programming languages deeply enough to understand control-flow graphs". That's not simply a good rule of thumb, it's a terrifying omission. I would suggest that early exists are simply a matter of taste and never using them is the crutch that keeps junior developers junior. Data are on my side here: a quick perusal of the Quake 3, the Linux kernel, the Cloj…

Agreed. A lot of the time, early exits just make sense. Instead of holding a variable called "succeeded" and doing a bunch of if elses, why not just continue on every failure? You're only testing for half a dozen side-cases and just exit out early when you encounter any one. No need to wrap all of your actual work in 5 levels of if elses.

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

#167
post #85
post #37

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 c…

Always ignore advice that begins with the word "always". The use of "never" is never a good sign either.

I never say always

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

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

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

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

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

#170

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…

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

Post reply on HN