If you're good enough at what you do that you have time to blog your inner debates about how good you are, you're good enough to need more important things to do.
They always come across as nothing but self-promotion thinly veiled under buzzwords related to software development, rarely with any real substance.
From what I can tell, he hasn't really done anything notable. He's a college student who has apparently been involved with some relatively unknown startups, and otherwise does some pretty typical and unremarkable software development.
It just seems like he's usually trying to make a big deal out of stuff that's pretty inconsequential, while continually dropping his name or that of some startup he's involved with.
1) Dan is beyond his years in terms of articulating his thoughts on startups and software development, and reminds some people of a young Jason Fried (co-founder of 37Signals, author of "Rework", etc.)
2) Dan is (much like Jason Fried) a bit of a contrarian. He has shipped almost two dozen apps/sites in the past couple years and is working night and day on growing his current startup, but he isn't dropping out of university. He also isn't out raising venture capital and trying to scale scale scale -- instead focusing on building a business that makes revenue and is profitable from (almost) day one. And lastly, because he is not chasing the "sexy", popular consumer app space -- instead focusing his efforts on the 'less glamorous' SaaS and B2B space.
*
The combination of these factors make a lot of us in HN interested in where Dan's career is headed, and thus interested in reading his posts and watching him progress as a founder while still in school.
That's why so many Dan Shipper articles get submitted here, and why they always end up near the top. He is the real deal.
Surely that's what YouTube is for, people with no talent to post some random rubbish about something that nobody actually cares about?
We can't all be brilliant programmers. Heck I'm not, but I've been in the industry a long time, and know the difference between when to write good code at the expense of time and when something is unlikely to see the light of day/prototype/one-off.
If you're commentative enough at what you comment that you have time to comment on your inner comments about how good you comment, you're commentative enough to need more commenty comments to comment.