Live data from Hacker News

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

news.ycombinator.com

61–70 of 178 posts

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

#61

Earlier quoted context omitted.

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 think the biggest problem is that early exits make you forget you have to clean things up before returning (a bigger problem in C and sometimes Java, than it is in modern dynamic languages). There are certainly other reasons, but I'll leave them to others that are more experienced!

As always, google is our friend. Some links:

http://www.osdata.com/programming/loops/earlyexit.html

http://programmers.stackexchange.com/questions/118703/where-...

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

#62
post #56

Earlier quoted context omitted.

Great comment. But aren't 7 and 8 kinda at odds with each other? I understand that #7 is a bit hyperbole, but still...

The best programmer in #8 already did #7. So he never had to write a lot of code to handle poorly structured data. That's why he says, "What's the difference?"

Oh, now I get it. When reading #7 I got the impression that you were dismissing the so called micro-optimization - something along the lines of "ship early, fix things later. Don't get stuck over-engineering and delaying writing code".

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

#63
post #55

Earlier quoted context omitted.

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.

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…

I'm not sure if I would agree on this. Take for example the Linux kernel. You have basically early exits just everywhere. Take any random file from here: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stabl...

It often goes like this:

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

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

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

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

#65
post #25

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…

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

You're showing your bias in that question. In the spectrum outlined in the post you're replying to, from valuing "really really good at writing code" to valuing "makes a ton of money as a result of applying a little bit of coding skill in the right direction", you appear to value the "good at coding" side of the equation.

If you read the comment you're replying to again, you might notice it to be written by somebody who lies towards the other end of the spectrum. As such, you might as well be asking him how much he bench presses, as it is equally relevant (as in, not at all so) to the utility of the advice he's giving.

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

#66
post #57
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…

> 11. Never use early exits. As a general piece of advice, this is flat out wrong. Or, to put it more correctly, this is only valid advice when using certain languages and only under certain conditions. Just because it is sound advice in languages with C/C++ derived syntax doesn't mean it should be presented as good advice in general.

Why do you think it is bad for C? Take for example the Linux kernel where you find early exits basically everywhere. (See also my other response here: http://news.ycombinator.com/item?id=4626763)

Even less bad in C++ where destructors can automatically handle any cleanup (exactly that is also common practice in C++; making the cleanup implicit). Similarly in many other more high level languages with GC and/or automatic refcounting or so.

In rare cases, it might be more complicated, though.

But you seem to have some languages in mind where it really doesn't matter? What languages?

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

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

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.

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.

Exactly. I was fortunate enough to realize this early on in college. Since that realization I've always made the effort to straddle the tech and business side. Programmers, even average ones, have the ability to multiply business effort by orders of magnitude. Look around in any business and even today it's easy to find places were software can help.

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

#68
post #55

Earlier quoted context omitted.

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.

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…

But, a computer scientist once argued, multiple returns are structured: they return to the same point. Knuth wrote an article on structured programming with GOTOs, and pointed out that this can save memory.

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

#69
post #57
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…

> 11. Never use early exits. As a general piece of advice, this is flat out wrong. Or, to put it more correctly, this is only valid advice when using certain languages and only under certain conditions. Just because it is sound advice in languages with C/C++ derived syntax doesn't mean it should be presented as good advice in general.

Exactly.

Also, for example, when you have lots of "if" clauses, those languages force us to use mutable state (and a variable initialized as null) just to avoid early exits. But we can avoid both by treating the "if" as an expression, as in Ruby, Lisp, etc, or with the ternary conditional operator...

Plus, IMO, there are some situations where early exits are a good idea even in languages derived from C, such as with guard clauses/preconditions.

There's a nice discussion about that here with some points I made: http://c2.com/cgi/wiki?SingleFunctionExitPoint

(EDIT: I edited a lot but still couldn't make it clear that I agree with you, but I still ended up making points about completely different things, sorry about that, my english skills are lacking sometimes)

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

#70
post #55

Earlier quoted context omitted.

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.

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…

> when that function is 300 lines long

This is what I would focus on avoiding instead.

Post reply on HN