Sharpening the Saw
codinghorror.com
codinghorror.com
If you want something passive to do, I recommend reading the blog aggregator for your favorite programming language (Planet Perl, Planet Haskell, etc.). There is obviously some junk in there too (the Perl people get to read all my Lisp articles), but the articles are generally "primary sources" describing new projects and techniques. (That is to say, the author of new module foo is the one talking about it. It's not some pundit that thinks it's cool.)
Anyway, read social news sites if you want, but remember that they are mostly entertainment, not work. If you want to be a better programmer, the most important thing to do is to program and be aware of other ways of doing things. Read the source code to your libraries. Read the academic papers that the documentation links to. Experiment with new ideas and techniques. Those things will actually make you a better programmer. Reading blogs, not so much.
Completely off topic (and I apologize to everyone else), but in viewing your profile to find all your Lisp articles, I noticed we are rocking the same top color... it is quite pretty.
The author of foo might not be able to explain foo very well. The HN crowd is used to reading the blogs and discussions of "hackers"--people who both program, and think/write/talk about programming. However, there's this huge set of programmers who aren't hackers, and have no idea how to communicate to you why you would want to use this thing they've built (or perhaps just don't care whether anyone beyond them uses it, now that they've scratched their itch.) That's what pundits are for.
Not because of the article alone, but it summed up with an almost creepy precision what had already unconsciously reduced my interest in his writing over the past months. Most of his blog-posts really match the template.
When I dropped the feed there were still 10 or 20 articles in the queue. Don't think I missed out on much.
I don't 'get' the backtracking.
There's the same amount of crap, it's just dressed up in more pretentious verbiage. IMHO.
90% of everything is crap, no matter how "non-lame" your audience is.
A brilliant yet terrifying insight.
I'm _confused_.
It's Jeff Atwood. He talks out of his ass and randomly bolds stuff. That's about it. (Remember, he wrote a book review on his blog about a book he clearly hadn't read. All he does is talk.)
It's not like the same people can't make something else, something new--for example, you could put all the writers, artists and actors of the Simpsons on a new project, if you like--but they don't need to do the Simpsons any more. It's done. Every possible angle, every single side-story, every inter-character meeting has been explored.
1000 posts is enough to say what you came to say. If not, maybe go back and delete a few, distill some points to free up room for new expression. Perhaps blogging software should have a million-character limit on the total aggregate length of post body columns; it seems to have encouraged tweets to be more well-thought-out (though some of that is also probably from the fact that the ones sent from phones cost money.)
"Let's assume that some or even most of it will not be new. Let's assume that we'll positively detest some of it. But let's also look at it in terms of our own profit: we win if we can find just one thing in there that makes us better programmers."
Yesterday he said HN is becoming overwhelmed with dreck. Today he is saying it's a win to read HN if you can find just one thing that makes you better.
The two statements are entirely consistent with each other, and I suggest they are the entire point of the post he quotes.
There are some concepts from practicing music that might be interesting to consider in the context of coding:
1. Play music that's beyond your current abilities; playing the things you already know won't help you improve. This is pretty easy to put in the context of writing software: don't write yet another little ruby app, write it in Haskell or Io or Clojure or Erlang...
2. Isolate weaknesses and focus on specific things to improve. I think this is tougher in software than in music, because a good musician is always listening to good music to benchmark against, but it's probably not as common for developers to constantly be reading good code. So, maybe go find some good code to read and find ways in which it's better than what you're churning out.
3. Don't practice music with mistakes; it's better to slow down and get it right than to learn it incorrectly. So maybe a test suite for that weekend hack isn't a bad idea...
I should do more of that... in both music and coding...
Does anyone else think Jeff finds a crafty little picture, and then writes a post about it.
http://blog.stackoverflow.com/2009/03/the-value-of-downvotin...
If at all his post is worst post ever, i don't agree all of us won't comment like this.
Hidden meaning is, we do agree with his post but not completely.
The article is still right on though.
It could be that there is a happy median and those of us over it ought to read less while those of us under it ought to read more.