Why a article with such a provocative headline (and so little content) makes the top here at HN is a riddle for me. Might have something to do with the fact tha

Why a article with such a provocative headline (and so little content) makes the top here at HN is a riddle for me. Might have something to do with the fact that the HN Rules have been floating around too, namely alot of new people around. (Sorry for digressing.) Coming back to the article I want to mention some points. (Maybe some things are biased..) Ref. 1.) While a bigger font size is good for your eyes (hope you guys don't stare to long in one session on the screen) it is bad to understand the bigger picture in my opinion. Sure you are "forced" to write good code, but that is a standard mantra which you should follow anyway. People who like TDD (BDD) aso. have embraced this deeply. Doesn't that huge font size rather reduce your productivity? Please consider this: http://www.codinghorror.com/blog/archives/000012.html http://www.codinghorror.com/blog/archives/000012.html "Its better to have more screen space, not less." Ref. 2.) Making a syntax element like hard coded strings so much stand out is contra productive in my opinion. It would be much smarter to focus on emphasizing the important aspects of your code rather than over-highlighting strings. No? I mean sure, everybody has a different taste and style, but where is the harm in hard coding certain strings? Firstly its fast, secondly this is a typical flame of how far can we eliminate certain things from our code? (instead of embedding SQL use ActiveRecord, etc.) If you want to go so far great, start by embracing e.g. gettext, and put everything is a DB. Oh wait, why is my code so slow? Ref. 3.) I fully agree, though why does this whole article sound like a sales story for .net ? "Here are lists for a few .net languages: C#, VB.net, F#." Ref. 4.) Basically I agree but "Ghoulish regular expressions"? If you define it by "ghoulish", how about rewriting it to make it more clear anyway? Increase tests by 1%? Uh, well I think with proper input verification you can eliminate alot of problems. I mean its great to work with unittests but a good advice would probably have been, hey please work with unittests its has shown to make code better but if you are too lazy at least use assertions? Ref. 5.) Interesting advice, good idea though but if you look at code from "an open source project" than it might make you scream and run away. I think this advice is maybe better: http://norvig.com/21-days.html http://norvig.com/21-days.html This is btw. the perfect article to outline why this whole "How to manage x in y <time unit>." is stupid. Ref. 6.) Good advice. ".. distraught at just how much room you've got for improvement." Hm, depends on what my goal is. Ref. 7.) Interesting advice, though wouldn't a "cruicial to your application method" be rather well programmed? Often it is probably better to refactor the whole function because if its so long that you have problems just writing it from scratch again, then there is too much code in it in the first place. Ref. 8.) "And don't just write. Write a compiler!" WTH. Please Mr. Justice Gray, could I remind you that the article title is "8 ways to be a better programmer in 6 minutes." ? I mean the whole idea of this article is rubbish, (see peter norvig link) but compiler, 6 minutes, what? While I generally agree than understanding "a" compiler and what it does. (Scanning, lexing, parsing etc.) Then also implementing one, is very good for your education but it should rather be in your next article of "how to be a better .net programmer in x years." General comment: I really like HN, the quality coming from reddit is great, but posts like this are a waste of time. (At least in my opinion.)