[fusiongyro]

I suppose answering snark with snark is fair play, but our industry has a real unhealthy preoccupation with the new. The early releases of MongoDB were great proof that the engineers had failed to learn many of the lessons of their predecessors, and I think this is why I and other database-y programmers distrust it to this day. Sexiness is not a prerequisite for reliability.

Your unspoken message reflects the widespread idea in the industry that a detailed knowledge of old things is incompatible with doing new and exciting things. I think this notion is naive and also contributes to ageism, and I hope our industry recovers from it in my lifetime.

[newishuser]

I feel like you're more concerned with making sure people understand where they sit on the totem pole than encouraging progress or exciting developers. While learning from history is certainly paramount in software development, raw experimentation, naive excitement, and continuing in the face of nay-sayers is what pushes all industries forward.

People are allowed to make mistakes, tons of them, and the software industry is one of the best industries to make mistakes in. You get quality feedback almost instantly and can fail faster than anywhere else. No one is claiming that "detailed knowledge of old things" is on it's way out. We are engulfed in systems and code that are decades old. I don't see the point in nay-saying.

[fusiongyro]

Actually I am claiming that detailed knowledge of old things has never been "in" to begin with. HN seems to harbor a great breadth and depth of knowledge and I don't think it represents normality in our industry.

Failing fast is nice, but a more measured approach might result in less of it. When it comes to storage and email, people are surprisingly unwelcoming of failure at any speed. If a little study can avert a few catastrophes it's worth it. I think ours is probably the only industry that would question the wisdom of study.

By positioning history as in conflict with raw experimentation, naive excitement and all the rest, I think you're engraving the line in the false dichotomy. Is a week or two of research sans coding really such a high price to pay? Personally, I find there are a lot of really inspiring ideas in old stuff, ideas that strike me as newer and more exciting than "embed Javascript in X."

Are young developers' egos really so fragile they can't weather having someone with experience say "fsync should be on by default"? Is cracking open the source code to BerkDB really such a deflationary moment that it threatens our industry's progress? I, personally, think they can handle it.

[lelandbatey]

As a young and very "green" developer, I have to agree. The biggest thing I've learned is:

Someone else has probably already solved this problem 30 years ago, and they solved it in O(n) time.

However, that's never a bad thing, or it shouldn't be.

I think an unwillingness to look backwards is a sign of an unhealthy level of pride, and I'll freely admit that it's something I struggle with. However, I believe many (most!) developers would also benefit from trying to get past one's ego.

[newishuser]

Totally fair. Next time, this should be your comment instead of just non constructively pooping on someone else's project.

This is discussion worthy, your original comment is just smug.

[fusiongyro]

I assume you're referring to Greg's comment about Pick and not my response to your response to it, because I think we've had a pretty good conversation.

[fennecfoxen]

You have a point.

But we can meaningfully compare and contrast newer database technologies as well. I think it's pretty clear that Mongo is the MySQL of NoSQL, and I do mean that in the most pejorative way imaginable. Architecture decisions like "let the kernel do all the swapping" decision, a casual approach to durability, the very mindset that leads to inclusion of SSL without certificate validation... ick.

They'll gradually polish their stuff up so that it's quasi-usable and maybe make lots of money, and good for their pocketbooks, but there are plenty of alternative data stores out there which have characteristics which render them more suitable for storing data for most if not all projects.

[gregjor]

In a production environment with real applications and important data people are not allowed to make tons of mistakes. Experiment and learn all you want, but I hope you eventually understand that what professional software developers and database admins do has very little relationship to weekend hackathons.

I know my clients won't tolerate "tons" of mistakes. Not even a few. In fact I am usually hired because the person they just let go made one too many mistakes with important data.

[pixelmonkey]

I used to work at a big professional shop. They made lots of mistakes, and the people who made the most fundamental ones were often promoted, not "let go".

The main difference in startups isn't that they don't build software the "professional way" and thus make avoidable mistakes. Instead, the difference is that startups recognize that the mistakes are inevitable, so may as well embrace them and build a process / culture around prototyping and continual refinement toward actual business value.

Pie-in-the-sky posturing about The One Right Way is nice, and especially nice when your BigCo is footing the bill, but when you operate under real constraints (e.g. economical) prototyping speed and simplicity can outweigh all the other factors.

All that said, I still think MongoDB full-text search was a bad idea -- only because their implementation is pretty naive and this corner is satisfied nicely in F/OSS by a number of other indexes like Solr, ElasticSearch, Sphinx, etc.

[coldtea]

>While learning from history is certainly paramount in software development, raw experimentation, naive excitement, and continuing in the face of nay-sayers is what pushes all industries forward.

Citation needed.

This "continuing in the face of nay-sayers" meme comes from old wives tales of "courageous inventors" that "went against the tide" etc.

In the general history of science and technology, those wasn't that many or important. They just make for a good media story.

The other side is more clear cut: incrementally building and learning from each field's history has been paramount.