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

Being a "Great Coder" and 10000 Hours

groups.google.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Being a "Great Coder" and 10000 Hours

#61

Post by matwood »

kamaal wrote: post #20

The problem: As it is mentioned in the email. People tend to believe, being great is about knowing a lot of facts and stuff from memory. Having information about stuff others don't know. While the fact is intelligence and knowledge only acts as catalyst in the path to success. They are not success or don't lead to success in themselves. Unless you don't understand this you will keep wondering why you are not getting…

Great post. Reminds of a recent interview I had. After we discussed my resume and a myriad of topics on tech, software, time management, and people the interviewer gave me a programming problem to solve in order to get a second interview. I asked about gotcha questions or if I was going to need to code with someone staring over my shoulder and he said that none of his employees would ever code that way while working there so what would that test?

It makes complete sense. So what if someone can answer how many ping pong balls are in a school bus, if they can't produce or get along with the team they will not be a good hire (unless of course the job is figuring out how many ping pong balls are in a school bus).

Re: Being a "Great Coder" and 10000 Hours

#62

Post by EmployedRussian »

agavin wrote: post #31
kenjackson wrote: post #29

Earlier quoted context omitted.

For the poor performers they may be nothing you can do. But for the merely "very good" are there practices that Balestra can teach them? For example, one thing I've seen that can increase productivity by a factor of ten is good debugging skills -- which are generally teachable. The other thing is to get people on things they're excited about. Mentally checking out is another area I've seen strong people lose time.

Good debugging is key, and as anyone who ever worked with me will note, I'm a fantastic debugger (in no small part because I'm cold, rational, and rarely get upset). I keep meaning to write up a post for my blog with "Andy's rulez of debugging." There are really very simple, but very effective. Like: "don't assume" and "divide and conquer" (they do require a bit of explanation)

I wonder if you have much to add to http://www.amazon.com/Debugging-Indispensable-Software-Hardw... (which I really like).

Rule 5: "Quit thinking and look" is (I think) equivalent to your "don't assume".

Rule 6: "Divide and Conquer".

Re: Being a "Great Coder" and 10000 Hours

#63

Post by scott_s »

ahuibers wrote: post #60
kenjackson wrote: post #39

Earlier quoted context omitted.

Definitely "being really smart" or "having a Ph.D" hasn't been a correlate in my experience; if anything, I've seen these to be negatively correlated with code production and quality. Unfortunately this is largely the case. It's in many ways similar to why many on HN don't want to do Java enterprise LOB apps. It seems like painful drudge work. For a lot of really smart people who did their PhD -- the work it takes to…

Um.. most PhDs in the experimental sciences involve lots of drudge work, and 14 hour days, and the people who make it are generally very hard workers. This may not be true in theory or engineering.

I have a PhD in CS. There's a lot of "drudge work" in the design and execution of experiments. I just spent four days designing, executing and analyzing experiments to see if our model was accurate and my implementation was correct. (Both are, which is nice.) But those experiments will never be published - experiments like them will, but not those. Those experiments are what I call "guiding experiments" - they're not rigorous enough to convince others that what we did works, but it's enough to convince me we're doing the right thing, and give me the confidence that things will work out as expected when we do the full, rigorous experiments.

So, yes, research has its own grunt work. And some of my code will make it into production.

Re: Being a "Great Coder" and 10000 Hours

#64

Post by codeonfire »

dmbaggett wrote: post #33
singular wrote: post #5

There really is a meme here I think, and it relates to ego. Having said that, I definitely do think there is truth in massive variations between programmers, though I personally think that is a combination of a small pre-requisite talent (the ability to code at all, which I think a surprisingly small amount of people have - simply a genetically determine brain configuration), and mostly attitude + hard work. For exam…

The best coders I know (including agavin, who comments below) are all insanely hard workers. There are a few other correlates, but these seem secondary to me: - willing and able to rapidly learn new tools (especially languages, debuggers, build/test infrastructures, and profilers) - understand software at many levels (so-called "full stack" programmers) - more interested in producing a working system than in technica…

"- understand software at many levels (so-called "full stack" programmers)"

People should start using "multi-stack" to describe those jobs when PHB's decide they know best which technologies to use, and not surprisingly, they're all incompatible and different than last month's technologies.

Re: Being a "Great Coder" and 10000 Hours

#65

Post by joe_the_user »

agavin wrote: post #31
kenjackson wrote: post #29

Earlier quoted context omitted.

For the poor performers they may be nothing you can do. But for the merely "very good" are there practices that Balestra can teach them? For example, one thing I've seen that can increase productivity by a factor of ten is good debugging skills -- which are generally teachable. The other thing is to get people on things they're excited about. Mentally checking out is another area I've seen strong people lose time.

Good debugging is key, and as anyone who ever worked with me will note, I'm a fantastic debugger (in no small part because I'm cold, rational, and rarely get upset). I keep meaning to write up a post for my blog with "Andy's rulez of debugging." There are really very simple, but very effective. Like: "don't assume" and "divide and conquer" (they do require a bit of explanation)

I often find that looking at the code hard and adding the appropriate tests and asserts can be better than immediately pulling out the debugger. Assert are continually testing your assumptions where you can only see them once in a debugging session.

Re: Being a "Great Coder" and 10000 Hours

#66

Post by superasn »

ken wrote: post #46
superasn wrote: post #6

A little off topic but somewhat relevant: When someone asked Larry Wall why there aren't any Perl certifications to classify the experts, he replied "I'm not going to tell people whether they're certified or not. My approach to language design has always been that people should learn just enough of the languages to get their jobs done. They shouldn't have to learn the whole language to begin with. But with certificat…

Isn't that the blub paradox? What if there was an unknown-to-you language feature that you were implementing by hand, or worse, if you were avoiding an end-user feature entirely because it would be too much work and so you're not even considering it? How would you know if it could affect user experience or revenue if you don't know about it? I've certainly used a language for a while, and then read the book on it, an…

In real world this isn't the case. First of all, when you're working on projects, you see that there are some things which you're doing over and over (like CRUD). Now at least in my opinion it is okay to create your first site by using mysql_real_escape_string like functions as long as by the end of the day it gets the job done. Because my priority as a small website owner is always getting new signups. And as far as I'm concerned, my lead does not care how I'm inserting his email into the database. But had I spend my time learning the proper MVC design, I maybe would have lost three precious months of leads which does indeed make a difference to my bank account.

Second of all nowadays you're never working alone (even when in fact you're working alone). What I mean is every programmer nowadays uses Google and StackOverflow to do a lot of his work. So when you're doing something wtf like using the mysql_real_escape_string, you maybe once in a while try to check how other programmers are doing it because maybe for you it takes too long or you're just stuck. And then you learn a thing or two about how to do is more easily. Still, it doesn't mean you have to become a great programmer of the language first, instead you just need to hone the things which you need the most for your business.

Re: Being a "Great Coder" and 10000 Hours

#67

Post by desireco42 »

kenjackson wrote: post #27
desireco42 wrote: post #26

I, of course agree with point author makes in this post, however 10,000 hours is also meme that Malcolm Gladwell uses to sell his books. I read articles that disprove his assertion and show that often he will fudge data to make a point. Still 10,000 hours is really good metaphor and it should be understood as such. It is a lot like that left and right brain, sounds really good and people pick this up because it sound…

The 10,000 hours predates Gladwell. He just wrote a book based on existing research. I haven't seen anything that actually disproves the assertion (again, it's not Gladwell's). Do you have references?

True, however it has been considered not true. There are example, Werner Heizenberg is one,

http://michaelnielsen.org/blog/malcolm-gladwell%E2%80%99s-ne...

that people made genuinely great discoveries without needing 10,000 hours, and there are other examples where people did 10,000 hours of deliberate practice without achieving results. I actually found a critique (can't really find it now) which convinced me that he fudges data to support his claims and sell his books, author examined his references that support MG claims and found many to not be quite supportive and that it is a pattern that is present in most of his books.

His books are entertaining read, well written and all, just not reliable scientific information.

There is discussion on Quora where some of the criticism is voiced as well: http://www.quora.com/Malcolm-Gladwell-author/What-are-some-c...

Re: Being a "Great Coder" and 10000 Hours

#68

Post by agavin »

EmployedRussian wrote: post #62
agavin wrote: post #31

Earlier quoted context omitted.

Good debugging is key, and as anyone who ever worked with me will note, I'm a fantastic debugger (in no small part because I'm cold, rational, and rarely get upset). I keep meaning to write up a post for my blog with "Andy's rulez of debugging." There are really very simple, but very effective. Like: "don't assume" and "divide and conquer" (they do require a bit of explanation)

I wonder if you have much to add to http://www.amazon.com/Debugging-Indispensable-Software-Hardw... (which I really like). Rule 5: "Quit thinking and look" is (I think) equivalent to your "don't assume". Rule 6: "Divide and Conquer".

I'll have to check that out. Although my advice will be free :-) But I'm sure that many many other good debuggers have developed the same basic techniques independently. Still, the vast majority of programmers could use some improvement in this area. "Quit thinking and look" is exactly what I mean by "don't assume." People tend to get wrapped up their own view of things and forget that empiricism really wins the day. There is often even fundamental denial, as in "what bug? I haven't seen it." Clearly if someone saw it, unless they were hitting the crack pipe, it's real.

Re: Being a "Great Coder" and 10000 Hours

#69

Post by mhartl »

lucisferre wrote: post #25
bdr wrote: post #22

Revisiting your old code is like reuniting with an old friend, and also your friend is now disfigured. Despite this evidence that I've improved so much in 10+ years of writing code, my self-assessment has stayed constant: very good, close to great. (This must be how Zeno's arrow feels.) Tim Daly's post provides some welcome clarity. I'm happy to still have a ways to go. "The lyf so short, the craft so long to lerne."

Well look on the bright side, in Chaucer's time the "lyf" was shorter. Chaucer himself died at 57.

That might just add to the pressure, though, if you think about it too much.

    It is a sobering thought that when Mozart was my age,
    he had been dead for five years.
        
    —Tom Lehrer

Re: Being a "Great Coder" and 10000 Hours

#70

Post by daly »

Curiously I think you missed the more important point of the post. The literate programming insight is clearly more valuable as a "take-away" idea.

Literate programming has the potential to allow a program to "live". Certainly it allows a program to outlive the authors. Most programs no longer have the original authors available. Look at the thousands of dead programs on sites like Sourceforge. Or consider the number of commercial programs that are no longer maintained by the authors.

Your program should be written to pass the "Hawaii test". That is, you give a new hire your literate source code, send them on a fully paid trip to Hawaii for two weeks. When they come back they should be able to maintain and modify the program as well as the original authors.

Literate programming is not documentation. It is a form of communication. You need to motivate code you introduce. You need a good story line. You need to get it past an editor-in-chief.

See "Lisp in Small Pieces" for a great literate program example.

Tim Daly daly@axiom-developer.org

Post reply on HN