Yeah I liken it to someone who picks up a blacksmiths hammer and then goes and drives some nails with it. It's like 'sure I guess it works, but man there are way better options that will work better'. Happens with all our industry tools, but perhaps there is no better example than database choice.

Engineers often see a database simply as a place to store things, it's just a box.. they work on a product for awhile that's using mongo, they are more likely to choose it later when they are developing a solution because they've used it before and know it 'works' and more importantly they know something about it. Databases as a topic of study are complicated, there are tons of tradeoffs happening all over the place and until you hit any given pothole you may not really understand those tradeoffs.

I guess what I'm saying is that in my life I'm lucky enough to have an old friend that is REALLY into databses. You should find this friend or become this friend.

Honestly at the end of the day this is all human nature. The hammer worked for you before why do the research to find out that there is a better hammer for you to use that would get your job done quicker and easier. You've gotta get these boards nailed down RIGHT FUCKING NOW or your bosses are going to be pissed.

> Engineers often see a database simply as a place to store things, it's just a box..

Oh man, I had an edit right after posting where I almost attached an addendum about this specifically, but then decided against it to avoid distracting from my core point. There's a totally bizarre allergy to actually using database features, for fear of "lock-in" or something, yet most programs are more likely to be re-written on top of the same database than to have the database swapped out from under it, unless someone made a really god-awful choice of DB, or load scales tremendously (which falls under "good problem to have, and you can afford the migration"). The result is that we as an industry waste an awful lot of time and money creating often-buggy application-layer solutions to things that could have been solved by leveraging features of, for example, PostgreSQL, with results that'd be cheaper, less-buggy, and better-performing. Drives me absolutely nuts.

Or, like, we have nginx in our stack and it could do something we need done, with a config change or a little Lua... but no, we'll spend 10-100x as long to make a worse-performing custom solution to this problem that a thing we're already using can trivially solve for us, but we'll do it in Javascript or Ruby or Python or whatever, as part of our "app". Ugh.

And don't get me started on system-level tools and daemons. Like, we're already using Linux or FreeBSD or whatever, which come with a stupid-large set of great, proven tools, so how about we actually use it rather than just using it as a fancy DOS and paying for SaaS to do things that our OS or distro can already do, probably more reliably? But no, we don't even bother to configure a recipient for root alert emails more often than not, and we just treat the whole thing as a dumb application runner that needs some complex external support system to keep it working right.

> Engineers often see a database simply as a place to store things, it's just a box.

As you said, it's just humans, really. How many self-help books about organisation are out there? Organising your files, organising your clothes, organising your tools -- it's not a solved problem, there are always tradeoffs, and it's very easy to just choose the same solution you've used before, because you already understand how to implement it.

TBH, I think oftentimes it's the right choice to just use any old tool as a hammer[0]. In many (perhaps not most?) cases, you're probably going to save more time implementing the organisational strategy you already know than you are implementing the technically-correct strategy. Though, you probably still need to do some quick maths on that tradeoff -- what's the cost of choosing the solution you know?

By way of example, when we were rebuilding our incident management stack at Dropbox, we spent a lot of time considering our database structure, because one of our key design goals was to reduce friction. Our existing tool had appalling load times, which was (in part) causing users to avoid declaring incidents. We knew we had to create a very low-friction experience to encourage users to declare incidents, and that this had long-term ramifications. So, myself and the other senior engineer on the team invested several days between us determining the correct design for our database. Conversely, when I was building a tool to do some trouble ticket automation, I just implemented things in a simple manner with questionable performance -- because the implementation only cost me 30 minutes, and the impact of a 5-second scan vs. a 0.5-second query was essentially nil (the absolute worst-case scenario was an automated process took a few extra seconds and cost a couple cents a day). No reason to overoptimise.

0. Adam Savage even titled his book "Every Tool's A Hammer"!

Symptom of a rapidly growing industry. With N(developers) doubling every 5 years or so, chasing newness at all times and not knowing about good old things is the norm.

I'd rather have that than an industry where any tech newer than 10 years is radical and scary.

Us old farts can remind the kids that old solutions exist when appropriate. It is much harder to try introducing something new into an org that doesn't want it, but needs it.