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

131–140 of 178 posts

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

#131

Post by danielweber »

dschiptsov wrote: post #124
tptacek wrote: post #120

Earlier quoted context omitted.

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

It is not, of course, about github. It is much simpler. When some scientist met, say, mathematicians, it is very normal to ask - show me what you have done. Or the same thing with writers - Oh, you're writer? What did you wrote. This thread was about programming, and the given comment was mere a self-assertion. So, it is OK to assert oneself if one wants to. But, show us, then, what you have done.

Writers of novelists have their works publicly available. What about someone who writes documentation for the launch code for nuclear submarines? While I will probably never ever see that documentation, it's really important that it is done well.

A corporate lawyer may produce a whole bunch of excellent work that the outside world never sees. Yet he keeps the company complaint with regulations.

If we were to do "show me the github" for stonemasons, we would want to see the pretty works of art that someone has made and select for that. But what about the guy who worked for 20 years laying the stone to keep the buildings up? He can't show off his work. But if I work in his building every day, I'm going to care a lot more that he was selected based on his ability to choose the stone that keeps buildings up than on his art.

The majority of code never sees the light of day. We are much more like miners than mathematicians in that the public cannot see our immediate work product, only the results after it has worked as a team. If you've never been hired you obviously can have all of your stuff public, but that's just selecting against people who have worked.

Analogies are hard.

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

#132

Post by 3pt14159 »

hythloday wrote: post #113
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 Cloj…

That one caught me up too. Maybe if you have full control of the input data and performance is not a concern, then they should be avoided, but "never" is a pretty small set.

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

#133

Post by nwmcsween »

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.

Huh? You _want_ early exits in c code how else will the compiler optimize?

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

#134

Post by nstokoe »

gns24 wrote: post #42
coliveira wrote: post #39

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…

It's important to also put either answer in the context of how it will affect the Time, Cost and Quality Triangle of program management. The customer loves to hear 'yes' but sometimes don't realize that that 'yes' is going to typically mean more time and/or money.

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

#136

Post by DenisM »

People will give you huge lists which will disorient more than they help. Let me give you a very short list:

1. Learn more about your customers by getting out and talking to them. Most engineers are deathly afraid do that, and many are not even technically able to do so, living in other countries or just not having the access. Thus you will have a big avantage over them.

2. Force yourself to learn to work in teams. This will push you to go against the typical lone-wolf attitude, but cohesive teams always win. without exception.

3. Learn to appreciate people who have complimentary expertise. Most engineers prefer to stick with their own kind, which creates very lopsided teams.

Ignoring these three factors dooms 99% of engineers out there to a life of being merely average, and if you make the best of all three you will be in the 1%, the exceptional engineer.

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

#137

Post by dschiptsov »

tptacek wrote: post #127
dschiptsov wrote: post #124

Earlier quoted context omitted.

It is not, of course, about github. It is much simpler. When some scientist met, say, mathematicians, it is very normal to ask - show me what you have done. Or the same thing with writers - Oh, you're writer? What did you wrote. This thread was about programming, and the given comment was mere a self-assertion. So, it is OK to assert oneself if one wants to. But, show us, then, what you have done.

No. It is desirable that people contribute their answers to questions. It is undesirable for people to respond to those questions not by challenging the substance of the answer, but by questioning the respondent's standing to provide the answer. There is no "but, show us then". You have no status to demand that of anyone here. I you have lots to say, for instance about modeling natural language as s-expressions, you…

Sure, I have no status, and I have no demands. What I like to do is to distinguish between people who can program and people who just can talk, to form my opinion on what I'm reading. Words are cheap.

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

#138

Post by masklinn »

daengh wrote: post #107
albertzeyer wrote: post #63

Earlier quoted context omitted.

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

He also said his statement "This is never about what runs fastest...". Kernel code needs to run fast and take advantage of shortcuts. IME, the jobs most programmers are doing don't need to try to accomplish maximum speed or need to wring a few bytes out of RAM. Certainly we don't want to be wasteful, but long-term maintainability is more important, again IME, than absolute speed or minimising memory footprint by a fe…

> He also said his statement "This is never about what runs fastest...".

This style has nothing to do with running fast, it has to do with lowering the cognitive load of the rest of the function. A branch means you have two states to keep in mind (the state where the branch is taken, and the state where the branch is not taken). Without early exit, you have to keep both states in mind until the end of the function just in case.

With guard clauses, you can discard on of the states (the one which matched the clause) entirely.

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

#139

Post by daengh »

masklinn wrote: post #138
daengh wrote: post #107

Earlier quoted context omitted.

He also said his statement "This is never about what runs fastest...". Kernel code needs to run fast and take advantage of shortcuts. IME, the jobs most programmers are doing don't need to try to accomplish maximum speed or need to wring a few bytes out of RAM. Certainly we don't want to be wasteful, but long-term maintainability is more important, again IME, than absolute speed or minimising memory footprint by a fe…

> He also said his statement "This is never about what runs fastest...". This style has nothing to do with running fast, it has to do with lowering the cognitive load of the rest of the function. A branch means you have two states to keep in mind (the state where the branch is taken, and the state where the branch is not taken). Without early exit, you have to keep both states in mind until the end of the function ju…

Computers can do that repeatedly and reliably with even (hundreds of) thousands of discarded states. People reading code and trying to understand what's actually in play at line umptyfratz of function iGottaGetThisFixedNow(), not so much.

In the end, I'm not disagreeing with early exits per se, just that over time they can make it more difficult to understand function because assumptions about state have to adjust as a maintainer goes through the code. Those assumptions may have been crystal-clear to the writer originally but how many times is the original writer the only maintainer?

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

#140

Post by wglb »

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?

A reading achievement would be to read his blog and understand the magnitude of what he has done.
Post reply on HN