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

111–120 of 178 posts

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

#111

Post by FredBrach »

olavk wrote: post #98
FredBrach wrote: post #77

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

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.

Knowing where you are jumping doesn't help you to make assumptions about the control flow.

Goto's are bad because they allows you to jump. The jump in itself is the problem because it breaks the instruction flow arbitrarily - without explicitly expressing the boolean condition for it. Early exits are of the same kind: they don't express explicitly the boolean condition of the jump. We know where we are jumping. Not why. With time, the boolean equation of the code which determines the instruction flow is unmaintainable. And then you end up not understand where your flow is going through, not because you don't know where a jump is going, but because you have lost why.

Most gotos, early returns, breaks and continues (C speaking) are considered to be bad habits for this reason.

return only goal is to return values to the function caller. Not to jump.

Function calls jump back to whatever call them so it's like there has been no jump at all in terms of instruction flow - you basically can continue to read the code assuming some code has been executed behind the function name.

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

#112

Post by edw519 »

1123581321 wrote: post #100
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…

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?

No, just variable naming.

As we speak, I'm maintaining some old code with the following variables names:

  - CommandRec
  - Command
  - Comm
  - Com
along with the fact that some of these are reused for different purposes and all are global.

I'm having a hell of a time finding all instances to rename them properly.

I understand that some programmer interfaces are better than others hanlding this, but that belies my main point:

"Just name shit what it really is."

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

#113

Post by hythloday »

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…

"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 Clojure runtime, and LevelDB show that Carmack, Torvalds, Hickey, and Dean all use them where appropriate.

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

#114

Post by jules »

FredBrach wrote: post #77
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…

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.

While loops are the exact same thing as GOTOs. It equals to:

    start:
    if(!p) goto end
    ...
    goto start;
    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?

#115

Post by mamcx »

jerf wrote: post #108
jamesrcole wrote: post #96

Earlier quoted context omitted.

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

If we are in a situation where we are unable to collect the data in the first place and you propose that theories or opinions are better, from what place did these putatively superior data or opinions come from? Because they clearly aren't coming from data.

Leveraging the experience of many? I wan't my website to be fast. I don't have deep understanding on web optimization and don't have yet enough data or time to build my own solution. I search around in the web, and go to http://developer.yahoo.com/performance/rules.html. I trust them (yahoo) because them are probably more competent and have MORE DATA than me. I implement some of the ideas, get some results (and if I'm smart, get a clue on why are good ideas and how it affect the performance).

Acting in data IMHO is only if have LOT of data. If not, acting in expertise of others look best to me..

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

#116

Post by SimHacker »

ghc wrote: post #57
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…

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

I understand why not to use early exits. But what's wrong with early returns?

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

#118

Post by jamesrcole »

jerf wrote: post #108
jamesrcole wrote: post #96

Earlier quoted context omitted.

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

If we are in a situation where we are unable to collect the data in the first place and you propose that theories or opinions are better, from what place did these putatively superior data or opinions come from? Because they clearly aren't coming from data.

If we are in a situation where we are unable to collect the data in the first place

that's mischaracterising my point. I didn't say anything about having no data. I talked about when the data you're able to get is unrepresentative.

from what place did these putatively superior data or opinions come from? Because they clearly aren't coming from data.

i think that's just playing word games with "data". We're talking about data concerning the problem at hand. Theories may come from data, but they don't come from data you obtain about the problem at hand. And knowledge can come from experience, which again is a form of data, but clearly not the sort the person was talking about. You can reason based on knowledge and principles.

Sure, it'd be better if you had good data, but when you can't have that sometimes the best you can do is to reason based on knowledge/experience/theoretical ideas.

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

#119

Post by agentultra »

manmal wrote: post #20

I like to think that successful people of all professions owe it to their methods (and then there is pure "luck" too). E.g., Seinfeld has been known to improve his skills on a daily basis, and is still able to deliver highly successful products (e.g., he wrote "Bee Movie", a surprise hit movie). Might be that his daily improvement has nothing to do with it, but you can never make much of anecdotes anyway. There is an…

Practice is a good habit. I like to warm up in the mornings with a code-kata problem before I start my day. Just take a trivial problem and write a program to solve it. Take the same problem on another day and solve it a different way. Contrast the results of the two approaches. Think about which approach felt more natural, which one was most efficient, in what real-world cases would you choose one approach over the other... in other words, reflect. Practice without reflection is meaningless repetition.

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

#120

Post by tptacek »

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?

You just asked a non-sequitur question. Patrick said, "consider carefully what you mean by success; one measure is geek status ranking, another is financial success". You responded by saying "show me your code" --- in other words, by implying that there is only geek status ranking, which makes no sense as a response.

When you grok what Patrick is doing, the programming angle on it makes more sense. On HN, he's best known for Bingo Card Creator (that's the work he has the easiest time talking about). Here is the right way to think about Bingo Card Creator: it is an experiment in how much engineering effort you can apply to marketing as opposed to product features and what the payoff on that is. The engineering in BCC is invisible to users; the product itself is "hello world", hooked up to a random number generator. The result of the experiment: he matched his salary with it, and then left his full-time development job, because 5-10 hours a week of effort was paying him better than the 60 he spent as a salaryman.

Also: get past the idea that you can gauge people's skills from their Github profiles. Nerds are in love with that idea because it sure would be nice if it were true. I've been a professional developer, mostly in C, since I was ~17 years old. Only a tiny fraction of the lines of code I've written --- and virtually none of my favorite lines --- are publishable on a site like Github.

Post reply on HN