Things I wished more developers knew about databases

Post by collyw » Thu, Apr 23, 2020, 9:01 AM UTC

listenallyall wrote: post #344

chaps wrote: post #149

Here's a fun bug I had a few years ago - Had a postgres database which was using pgbouncer for connection pooling. The most senior developer (24yo or so) we had on the project was using Go to connect to the database to write some simple reports, but each report took hours to run, and often had to sleep for 30+ minutes. So, after a while, pgbouncer would kill their connection, and their report would die. No other appl…

>> That ended up fixing the problem Interesting take, since you're still stuck with "simple reports" that take hours to run. What about writing more efficient queries, adding indexes, normalizing the DB... ?

Post by collyw » Thu, Apr 23, 2020, 9:23 AM UTC

codegladiator wrote: post #274

brabel wrote: post #261

Earlier quoted context omitted.

Just because you saw a few exception does not mean the rule does not hold in general. Or are you saying most people don't learn with time (a corollary of your theory that age is not a big factor)?

> most people don't learn with time I think this is correct. The curve flattens with age (in my opinion). > you saw a few exception I think the seniors you met (the knowledgeable ones) /were/ the exceptions. Most seniors I have seen have convinced themselves that they know all there is to know.

Post by collyw » Thu, Apr 23, 2020, 9:25 AM UTC

brabel wrote: post #343

codegladiator wrote: post #274

Earlier quoted context omitted.

> most people don't learn with time I think this is correct. The curve flattens with age (in my opinion). > you saw a few exception I think the seniors you met (the knowledgeable ones) /were/ the exceptions. Most seniors I have seen have convinced themselves that they know all there is to know.

> Most seniors I have seen have convinced themselves that they know all there is to know. Yeah, seems we've met different kinds of seniors... I don't know any senior who wouldn't understand that "the more you know, the more you understand just how much you still don't know".

Post by account42 » Thu, Apr 23, 2020, 9:51 AM UTC

inopinatus wrote: post #303

kerng wrote: post #276

Earlier quoted context omitted.

Go code often reinvents/reimplements a lot of things from scratch, reintroducing problems that have been addressed long ago in other systems. It's like this new trend, let's rewrite everything in Go to be cool. Financially makes little to no sense.

Let’s not just target Go with that sentiment, it applies almost universally, just in varying degree. Counterpoint: how is anyone supposed to learn, if not from their mistakes? We might worry about the blast radius, but there’s no compression algorithm for experience.

Post by ric2b » Thu, Apr 23, 2020, 10:28 AM UTC

hobs wrote: post #17

throwaway13337 wrote: post #14

Earlier quoted context omitted.

All of those things are unproductive until after your project is successful which is usually not a guarantee when building the software. You're not gonna need it.

Observeability, reliability, scalability - really easy to bolt on once you are successful. There's a middle ground, and a DBA turned SRE turned Architect is probably ok with compromises, those are all roles where "it depends" is a bylaw.