[deleted]
Things I wished more developers knew about databases
11–20 of 464 posts
Re: Things I wished more developers knew about databases
#12(The 80/20 rule applies below, some developers do care) Developers... just don't care. They want to spin up an ORM, point it at a URI, and forget about it. I've fought this for over a decade now as a DBA, SRE, DevOps, and architect. Most of the developers don't want to deal with anything infrastructure-wise; they want to spend all the time they can just focusing on the problem they're writing software to solve. Obser…
Many interests are pulling developers' attention in several different areas all the time.
Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things
All of these like to say "if only the developer could do $MY_AREA better, they'd be better developers and we'd have better software". Each of them wants to pile on more requirements for what devs ought to know.
Let's say we agree that devs should know all of these things. After you tally up every area's demand, you're probably looking at a 10 year timeline before someone's decent in all of these areas by spending approx. 1 year on each of these areas doing meaningful work (as opposed to contrived tutorials).
Even then, things change constantly, so you'd have to continually practice all of these things. Who knows if we'll add a new category next year? Then it becomes an 11 year timeline.
At some point, developer responsibility has to stop.
Re: Things I wished more developers knew about databases
#13[deleted]
Re: Things I wished more developers knew about databases
#14(The 80/20 rule applies below, some developers do care) Developers... just don't care. They want to spin up an ORM, point it at a URI, and forget about it. I've fought this for over a decade now as a DBA, SRE, DevOps, and architect. Most of the developers don't want to deal with anything infrastructure-wise; they want to spend all the time they can just focusing on the problem they're writing software to solve. Obser…
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.
Re: Things I wished more developers knew about databases
#15(The 80/20 rule applies below, some developers do care) Developers... just don't care. They want to spin up an ORM, point it at a URI, and forget about it. I've fought this for over a decade now as a DBA, SRE, DevOps, and architect. Most of the developers don't want to deal with anything infrastructure-wise; they want to spend all the time they can just focusing on the problem they're writing software to solve. Obser…
Perhaps development work has reached complexity where it demands full-time attention? Perhaps there is a reason why DBA, SRE, Devops and Architects are separate roles?
What, you're not a full-stack rockstar ninja?
Re: Things I wished more developers knew about databases
#16I never realized this before but many excellent developers struggle with SQL beyond simple SELECT statements. I have a colleague who is by all accounts a deeply technical person but one day he confessed to me that he didn't really grok SQL and that he'd rather work with a "real" procedural programming language to just store and retrieve data.
Part of it may be due to the fact SQL isn't really a programming language but a declarative DSL for manipulating sets and tables. Things like GROUP BYs and PARTITION BYs (window functions) that come naturally to mathematical types/functional programmers are less intuitive to procedural programmers.
I suspect this was what attracted developers to noSQL databases like Mongo in the first place -- it's more attuned to a programmatic mindset.
(this is not universally true of course -- many programmers have no issues with SQL at all.)
Re: Things I wished more developers knew about databases
#17(The 80/20 rule applies below, some developers do care) Developers... just don't care. They want to spin up an ORM, point it at a URI, and forget about it. I've fought this for over a decade now as a DBA, SRE, DevOps, and architect. Most of the developers don't want to deal with anything infrastructure-wise; they want to spend all the time they can just focusing on the problem they're writing software to solve. Obser…
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.
Re: Things I wished more developers knew about databases
#18There seems to be a wealth of information here. I wonder, though, if the goal would be better served breaking this up into a series. Or perhaps applying the 80/20 rule to the list to come up with truly “a few” items that will have the highest leverage. Otherwise, I think it will provoke a lot of discussion and analysis from people who are experts in databases, but it might remain impenetrable for the core audience: the majority of developers who ignore this stuff (according to the author.)
Re: Things I wished more developers knew about databases
#19> AUTOINCREMENT’ing can be harmful I'll add that they should never be trusted to not jump around either! I imagine everyone makes this mistake at least once in their life. There is a very high chance that the database will skip a few numbers from time to time. You will then have someone from an accounting department asking where Record #XX is.
I'd posit that autoincrements are fine for primary keys, but primary keys aren't fine for auditing.
Re: Things I wished more developers knew about databases
#20Learn about modelling. Database is more than just storing data. Drink less koolaid of NoSQL, any NoSQL. It is trading initial result with future development time. SQL has been battlefield tested. No amount of "convenience" is more convenient than learning the fundamentals.