Your first comment didn't mention that he provided the wrong answers (most of it was about the word "career"). They seem (to me) to be common issues, and he mostly has the right idea. Rather than pick it apart point-by-point, could you pick just one point he's wrong on?
When a person makes disparaging generalizations, it sounds like they have prejudged the work, without reading it (why waste time reading it - they know it's bad). Maybe you're right, but it's hard to tell if you give only judgment and no evidence. Therefore I ask "can you elaborate please?" :-)
BTW: I followed your suggestion, and found this excellent comment of yours about pitching to VCs (http://news.ycombinator.com/item?id=866299), and I agree a lot of time and effort went into it. So I stand corrected on that issue, and my apologies for suggesting otherwise! :-) (though I'm sure much more blood sweat and tears went into the getting of your experience than in the writing - maybe that's true for the blogger too?)
aside: it's weird - I upvoted, but your comment is still at 1 point... I've seen this happen before when I upvote a reply to me. It may be a bug, perhaps related to downvotes being disabled on replies to one's own comments.
PS: this exchange made me think about my own mistakes. They are very specific to my area, and then to be against the received wisdom (e.g. Alan Kay above). But it's not immediately clear to me what my mistakes have been, and what I've learned... it seems like it would be a useful exercise to consider this.
It's not that they're wrong so much as that they're incomplete. The author has a very CRUDscreen/.NET/VisualStudio-oriented worldview, and his tips apply to that but probably won't be applicable generally. If you're working at Google, for example, an ORM is probably the last thing you'll reach for. And if you're working in an agile web-shop with RoR, generics are utterly useless.
I think HN drops votes selectively, most of the time it manages to hide the fact that it does to the voter. Personally I think this is rather childish but that's the way it works. (In my view if a function doesn't work you simply drop that part of the interface, not to give the user the impression that something has been done when in fact it hasn't. This is part of the 'secret sauce' of HN, so maybe the overall effect is positive, but I feel like I'm being treated like a child.).
About that 'one point':
1) not using a proper ORM:
ORMs have their place. In a project that does 'simple' stuff (ACID style) you can get away with using the ORMs
worldview to get through your day. The problems start when
you have to do stuff that the ORM does not provide for. As
soon as you hit that limitation you're in for a fun ride, mostly
because ORM data models were meant to be accessed through a
program writing the queries. To write queries that do complicated
stuff for database tables that have been created and maintained
through an ORM will get you bogged down pretty quickly. Assuming that you are even allowed to do so. So
to thoroughly research the use cases for your data before
committing to a specific ORM can save you a lot of time later.
In general I think this is a problem that relatively inexperienced
programmers face, they pick the first tool that seems to
cover all the bases and start working on the code, only to
run out of steam somewhere halfway in to the project, by
that time you've got a lot of effort invested in to that
particular solution and to abandon it gets harder with every
minute that you further invest.
The fact that the author has re-written this particular chunk of code 3 times now and still isn't satisfied is telling,
the lesson to learn here is not 'use a proper ORM', the
lesson as far as I can see it is 'research your work
before committing to your tools'.
Experience will teach you that requirements change, they
change all the time, there has never been a project of
any magnitude that did not have its requirements change
over the course of its deployment, and as a rule this
already surfaces during development.
So you plan ahead, you build for the future, not for the
simplistic view you have today. It will save you lots of
money and time later, your first rewrite then is a decade
off instead of a few months.
The rest of the 'mistakes' listed suffer from similar shortcomings in their 'lessons learned'.
That is why I have a problem with this posting, not because it is bad to learn from your mistakes.
I think this guy should work together with more experienced people that can guide him in the right direction, rather than to assume that because he's making some slow progress (5 years ??!) he is now in a position to present his wisdom.
I upvoted and checked immediately, and you're right: it presents an upvote in the JS interface, but a reload reveals the truth. Not counting reply upvotes does prevent long, mutual karma-generating exchanges,
but if it's trying to disguise that reality from users it isn't very effectively disguised.
I'm not 100% convinced it's deliberate, but it could be, like that idea of making trolls invisible, but not letting them know they are invisible (not sure how that's applicable here, maybe so people don't explore trickier ways of getting karma)
I agree that ORMs are good for the basic impedance mismatch, but are hard to optimize for more complex queries. I do wonder if working directly with the database is becoming a dark art, as most practitioners would prefer to avoid it if possible, and they often can.
"So you plan ahead, you build for the future, not for the simplistic view you have today." So you disagree with those agile ideas of "you ain't gonna need it" and "release early, release often". You're describing something like the waterfall model. I'm actually not against the waterfall model, it's just that you need to have done a few similar projects to have the requisite level of judgment, like a carpenter building his 10th kitchen. Most practitioners aren't at this level of expertise - they'll still learning what the problem is. If they try to do what you suggest without your level of experience, they'll really make a mess. It's a matter of a novice knowing that they don't know.
I agree that working with experienced folk would help, but such folk are in short supply (though possibly many people are reluctant to find them, and would rather be the "experts" themselves - maybe this is what you find objectionable).
I guess he could have gained much more experience in 5 years, if he had done several database projects over that period, instead of improving just the one.
Re. the voting, that's deliberate, PG is on the record about that. I thought it was a bug and reported it as such, he assured me that it was not, but that he was experimenting with deciding which votes to count.
re. software development:
Agile is great for web development, for projects that have a short life cycle and that are not going to be around 10 years from now in a way that you can relate back to your original design spec.
But not everything is web development (which is more closely related to evolution than to design), not every project has a short life-cycle.
If you are in lets say the banking business, where software routinely outlives its creators you have to have a completely different view of things.
Like everything else, agile is a tool that has its uses but it shouldn't be the only tool that you've got or know how to use.
Good perspective on different length of life-cycles; some areas repay careful investment; some don't.
I've found many of the common wisdoms don't quite apply to what I'm doing (in some ways it's analogous to DB's relational model; it's experimental, theoretical and practical)... and so my hard-won lessons aren't applicable to other areas.
Your first comment didn't mention that he provided the wrong answers (most of it was about the word "career"). They seem (to me) to be common issues, and he mostly has the right idea. Rather than pick it apart point-by-point, could you pick just one point he's wrong on?
When a person makes disparaging generalizations, it sounds like they have prejudged the work, without reading it (why waste time reading it - they know it's bad). Maybe you're right, but it's hard to tell if you give only judgment and no evidence. Therefore I ask "can you elaborate please?" :-)
BTW: I followed your suggestion, and found this excellent comment of yours about pitching to VCs (http://news.ycombinator.com/item?id=866299), and I agree a lot of time and effort went into it. So I stand corrected on that issue, and my apologies for suggesting otherwise! :-) (though I'm sure much more blood sweat and tears went into the getting of your experience than in the writing - maybe that's true for the blogger too?)
aside: it's weird - I upvoted, but your comment is still at 1 point... I've seen this happen before when I upvote a reply to me. It may be a bug, perhaps related to downvotes being disabled on replies to one's own comments.
PS: this exchange made me think about my own mistakes. They are very specific to my area, and then to be against the received wisdom (e.g. Alan Kay above). But it's not immediately clear to me what my mistakes have been, and what I've learned... it seems like it would be a useful exercise to consider this.