Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 178 posts

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

#71

Post by henrik_w »

albertzeyer wrote: post #63
edw519 wrote: 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…

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

This coding style is also referred to as "guard clause", embraced by e.g. Martin Fowler (http://martinfowler.com/refactoring/catalog/replaceNestedCon...) and Jeff Atwood (http://www.codinghorror.com/blog/2006/01/flattening-arrow-co...) (and by me ;-))

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

#72

Post by [deleted] »

albertzeyer wrote: post #63
edw519 wrote: 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…

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

[deleted]

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

#73

Post by adsr »

edw519 wrote: post #55
godbolev wrote: post #41

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…

What if you fail on line 20? Carrying on may cause cascading errors, what alternatives are there to return an error code directly apart from storing a return value in a variable, use a goto to the end and return once? (assuming this is C)

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

#74

Post by glassx »

albertzeyer wrote: post #66
ghc wrote: post #57

Earlier quoted context omitted.

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

Well, most early returns are avoided mostly because it makes it harder to understand the code. But when you use guard clauses, like on your Linux Kernel example, you actually improve the code, because you reduce cyclomatic complexity (everything is now a linear path: a -> b -> c), you can reduce nesting, you can avoid unnecessary mutable state... so it's a win. The problem with early returns is when you use them in non-obvious places.

I believe that the majority of programmers agrees that using early returns for guard clauses is an okay exception.

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

#76

Post by ChristianMarks »

"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

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

#77

Post by FredBrach »

edw519 wrote: post #55
godbolev wrote: post #41

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…

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.

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

#78

Post by olalonde »

dschiptsov wrote: post #28
patio11 wrote: 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?

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.

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

#80

Post by willismichael »

edw519 wrote: 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…

> 18. Find someone else's code that does amazing things but is unintelligible. Refactor it. Then throw it away

Throw away the unintelligible code, or throw away the refactor?

Post reply on HN