Earlier quoted context omitted.
Always ignore advice that begins with the word "always". The use of "never" is never a good sign either.
Wahh, I'm caught in a recursion. halp.
Case-distinction-man to the rescue
Ask HN: What did the really successful programmers do differently?
101–110 of 178 posts
Re: Ask HN: What did the really successful programmers do differently?
#102I am not talking about Linus Torvalds, Larry Walls etc of the world. But I am going to talk about other developers who often make it big. I am talking of people who solve difficult problems, add value and make money. Great folks I've met are high on productivity, they are quick in discovering things and generally maintain an aura of self confidence around them. Many of them start off because they a 'lucky break' some…
I'd like to place myself in this category, even though I'm only 34. My claim to being successful is that I make much more money than I can spend (though we're not talking millions here) doing things I enjoy doing. I largely agree with you, but have some comments:
1. I think my best quality is that I'm lazy. Extremely lazy. Yet still very productive. I achieve this by thinking more about problems before I do anything, which usually greatly reduces the amount of work I actually have to do, because I come up with a better way of doing it. I'm extremely serious here; on a normal working day I'll likely spend more than 50% slacking. My clients don't care, they get charged only for the effective hours. And I love it, because the effective hours become so much more productive that I can charge a lot for them.
4. This matters a lot, especially in communicating to other stakeholders. Nothing is more annoying than someone who promises to do something by date X, only to not hear anything by then.
6. Extremely true. I talk to a lot of people to find work, and generally have a ratio of 10:1 for possible opportunities to things that actually lead to real work. I don't think I can improve this ratio much, because really interesting work is not that readily available.
I'm also not very active in the blogosphere and social media, mostly because that's simply not where my work comes from. My work comes mostly from business people and they care much more about recommendations, being able to talk to them in language they understand, etc.
Re: Ask HN: What did the really successful programmers do differently?
#103Earlier 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.
[deleted]
Re: Ask HN: What did the really successful programmers do differently?
#104Re: Ask HN: What did the really successful programmers do differently?
#105How 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…
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…
And to add to that: one can easily misinterpret (or even just mismeasure) data, especially if it is data about a complex system.
Re: Ask HN: What did the really successful programmers do differently?
#106Earlier quoted context omitted.
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 n…
Yes, I think really "avoid early returns" is an overextended special case of "avoid the nonobvious".
Re: Ask HN: What did the really successful programmers do differently?
#107Earlier 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 ...
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 few (k) bytes.
Back in the bad old days when I was writing programs to run on mainframes, yeah, we did need to fight for every byte. A $5 million machine back then had less RAM and less raw CPU power than a tablet does today. We don't live in that world now.
Re: Ask HN: What did the really successful programmers do differently?
#108How 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…
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.
Re: Ask HN: What did the really successful programmers do differently?
#109Only one of those guys is 50+. Carmack is only 42. You are talking about exceptional programmers, with a high impact on their fields. If you want to emulate them, you'll end up quitting at 50, realizing you aren't ever going to reach their level. Most people don't. You won't be a rockstar, you'll be lucky to be better than average. Set goals for yourself and meet them. If you don't have any goals, then come up with some good ones.
Re: Ask HN: What did the really successful programmers do differently?
#110Earlier 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.
[deleted]