121–130 of 178 posts
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.
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 ;)
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.
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 ;)
One thing that I would like to point out is, being financially successful and extremely competent programmer are two different things. An example Zed Shaw is an extremely good programmer, but if you read his legendary rant "rails is ghetto" you come to know besides being an extremely great programmer he had to struggle financially. So being a good programmer is not synonymous to having your bank accounts with decent…
I'm going far than this and say are two OPPOSITE things. Being good a 1 thing is hard. Good at 2 things? 3 things? Rare. That is way is easy to have Teslas, but not Bells...
I know a lot of developers in the latin america community, and mi city (www.clubdelphi.com). Here, is VERY rare to find the super-rich, mega-startup anomaly (yes, it is). We can do the hard work, have competent skills and still survive. I don't see highly tech people being good at the art of make money (the lack of social skills hurt a lot!), and the time necessary to code + doing business is a big drag.
I have a partner that help in the sales side. Without him, I can't see how I can code and get client in a steady way (the economic realities here are differente to USA: Have FACE TO FACE is DAMM IMPORTANT!, internet-only business? close to impossible), and I'm lucky for that. A lot of my peers are code monkeys, even the good ones...
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?
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…
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.
Typical Engineer: 2000 work hours/year * $50/hour = 100k/Year
John Carmack: 1.7 million copies of Quake * $1 profit = 1.7 Million/Year
Jeff Dean: # of Google shares * $756 = $?
Earlier quoted context omitted.
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 poin…
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.
I you have lots to say, for instance about modeling natural language as s-expressions, you too can write lots of long comments and blog posts, and we will enjoy reading them. Unlike the short, nasty one you wrote above.
Earlier quoted context omitted.
> 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.
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…
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…