Live data from Hacker News

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

news.ycombinator.com

91–100 of 178 posts

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

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

Great list Ed.

About #17, one of my clients once told me he hired and kept me because I never outright, or in the beginning said no, and instead said 'let me think about it', or 'anything is possible relative to time and money'.

As guides to implementing technology, I think this is a fundamental skill.

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

#92
post #36
post #24

Earlier quoted context omitted.

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

I don't post this with any sarcasm or to draw any inferences about your intended meaning, but just to bring to your attention that the point you've now raised struck me independently upon reading: > A successful programmer is not just a programmer, he is also a personal representative, a salesman and a contract negotiator.

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

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

#93
post #42

Earlier quoted context omitted.

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

That's a good way of putting it.

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

#94
post #86
post #5

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

Curiously, what do you do today?

I still write software (free) and articles -- my most recent:

http://arachnoid.com/MySQL

http://arachnoid.com/python/DBClient

And in the summertime I travel around by boat in Alaska:

http://arachnoid.com/alaska2012

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

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

> 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. Good advice. So why do you give the same amount of attention to variable naming and early exits as to much higher level issues? I don't think the difference between Carmack and a random developer has much to do with adherence to coding standards.

Variable naming and early exits are not details. They are fundamental issues, two of the most common causes of shitty code. Most programmers don't understand how important they are and relegate them to the pile of "coding standards" or just want to debate their theroetical pros and cons. Just look at what's happened to this thread.

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

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

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

This is not true.

It depends on how much data you can get and how representative it is.

A big mistake is to assume that an unrepresentative sample of data is representative, and to draw conclusions based on that assumption.

If you do not have a representative set of data (and you can't always get one) then data can be less-than "theory or opinions".

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

#97

Earlier quoted context omitted.

Also early exits are the exact same things as GOTOs. It equals to: goto end; ... end: It should help people figure out why it's bad - in 99.99% of the cases.

I believe early exit is strictly better than `goto end`. There's no language enforcement requiring the "end" label to be at the end of the function. If there was, I wouldn't mind the use of `goto end`. I don't think your argument is persuasive to anyone who doesn't already agree with you.

[deleted]

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

#98
post #55

Earlier quoted context omitted.

Excellent question that is difficult to answer. I'll give you a short response here and then write a blog post with example code when I have time. Put your email in your profile and I'll make sure to let you know when that's ready. A little background: I have gotten many calls when legacy code has a bug or needs a critical enhancement and no one in-house is willing or able to figure it out. I'm no smarter than anyone…

Also early exits are the exact same things as GOTOs. It equals to: goto end; ... end: It should help people figure out why it's bad - in 99.99% of the cases.

I think you misunderstand why goto's are frowned upon. Goto's are bad because they allows you to jump to anywhere in the code, regardless of structure, which undermines all assumptions you can make about control flow.

Function calls and return are like goto that obeys structure, and therefore don't have the same problems.

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

#99

Earlier quoted context omitted.

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

He lives from selling his own software... isn't that quite an achievement in itself? Unfortunately, his software isn't open source so I don't think we'll get a chance to take a peek.

Patio11 makes some of his software, A/Bingo, available as open source. A/Bingo is a Ruby on Rails A/B testing framework, available at his Bingo card site.

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

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

When you advise against naming a variable a subset of another variable, are you talking about confusing names, or practices like breaking off a chunk of array to process instead of finding a smarter way to step through it like mapping or in-place logic?
Post reply on HN