Live data from Hacker News

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

news.ycombinator.com

41–50 of 178 posts

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

#41
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…

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.

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

#42
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…

> 17. Always tell your customer/user "yes", even if you're not sure. I have found that you get higher marks for saying NO in the right occasions than being known as the one that always says YES.

There's clearly a middle position to be had here. By saying NO if you're not completely confident you can do something, you miss out on the best learning opportunities. That said, if you suspect something cannot work, or isn't the right way of doing something for another possibly non-technical reason, being prepared to say NO is critical for delivering.

So possibly: If you always say NO, you never learn anything. If you always say YES, you never deliver anything.

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

#43
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…

Thoughtful, elaborate comments like this are why I read HN. Thanks, ed.

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

#44
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…

> 17. Always tell your customer/user "yes", even if you're not sure. I have found that you get higher marks for saying NO in the right occasions than being known as the one that always says YES.

Learning to say no is the biggest challenge and virtue of the best developers out there. It's not a "no I can't do it" it's more of a "no I can't do it in that time" or "no I don't think it's the right way to go, here is how I think we should do it". Saying NO can make a difference between a successful project and a nightmare.

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

#45
post #32

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…

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…

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

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

#46
post #21

Earlier quoted context omitted.

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.

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.

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.

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

#47
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…

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.

I'm glad you asked, I have the same question exactly.

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

#49
post #15

Earlier quoted context omitted.

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.

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

Absolutely. This is true in many fields, but I think particularly for the software industry. There are so many people in management positions who are clueless about what engineers and software can and can't do.

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

#50
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…

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.

I believe he referred to the rule to use a single return statement at the end of any single function definition.
Post reply on HN