Things I wished more developers knew about databases

> Learn about modelling.

So true. I worked at a database-centric place for a while, so I read up on database stuff to fit in.

Learning about first, second, and third normal forms was very enlightening. If you learn these thoroughly enough that they are second nature, it really helps you see modeling mistakes that you might be making. It just becomes a lot easier to think clearly about how to lay out data. Just like there are code smells, if you learn normalization, you will immediately detect data structure smells.

Third normal form is not always the one and only right answer for modeling data, but it's a pretty good starting point from which you can refine and adjust if needed. Just because you understand normalization doesn't mean you have to do it all the time, of course. But if your data isn't normalized, it should be for a specific reason (performance), not by accident or because you don't know how to keep it organized. It is one of those things where knowing the rules gives you the freedom to know when it's right to break them.

It's even useful when thinking about organizing data in RAM. The situation is a little bit different because in RAM you follow pointers instead of doing joins. But there are still cases where it helps. For example, you might have one big struct, and you realize it should be two different structs because you are filling the same (redundant) data into multiple instances. And you know how to fix it.

Another very useful concept from modeling is choosing keys. One of the lessons of databases is that if you don't use synthetic keys, you're going to have a bad time. When you choose real-world data (like first name and last name as a key for a table of people), you're going to have problems like non-uniqueness.

Relational databases aren't the last word on how to organize and store data, but there are just a lot of good ideas that pick up if you learn about them.

I don't agree. If you're designing data structures in a code base you shoulder some of the responsibility for the persistence characteristics of that data.

There's a lot of devs that think database design is the same as starting a new ORM class and generating a migration file.

> Database, security, accessibility, performance, infrastructure, tooling and productivity, business concerns, workflow processes (agile), language concerns, new things

Yes, these are all things that devs should strive to know as much about as possible. Software isn't easy. It takes a long time to become an expert. 10 years sounds about right.

> Who knows if we'll add a new category next year?

Skill domains do come and go, but I think the ones you've listed are solid staples of web development for the past decade and likely will still be for a decade more.

Unless you got yourself into a situation where you were expected to set up a whole office with the same speed and expertise as a full-time network engineer based on some gross misrepresentation of your skillset, I don't see how this story is particularly relevant. Maybe it's a good cautionary tale about presuming that SoHo is the limit of networking?

Technical topics are indeed both very deep and very broad. The level of sophistication and depth is how you choose your specialization, but that doesn't mean you're never allowed to learn anything else. You should learn enough about each field to know the shores when you're standing there, to be able to communicate with the "natives"/specialists, and to know when you're getting out of the shallow end. This expectation should exist for everyone: DBA, application developer, devops, network, whatever. They should all know the territory and be able to work together cohesively to identify the best place to take something down deep.

Depending on the constraints of the project, leaving the shallows means either a) developing more proficiency directly and getting deeper yourself; or b) acknowledging that you need someone with more expertise in that area to take it from there while you go back to handle things in areas you know better.

The thing we must avoid is "well I'm not a network engineer so I don't look at Cisco configs, sorry". That should be replaced with "well I'm not a network engineer, so I have no idea what's happening here, but it's still interesting, can I sit behind you and learn?"

This is a very interesting comment!

Two questions:

Do you have any example code that shows how this works? I get what you’re saying intuitively but example code will help me bring it to table.

What about cross cutting concerns? I’ve found stored procedures to be a performant solution here. By version controlling them, and limiting to pure functions, I found them quite maintainable. Would you instead just define a new view, or extend an existing one, or refactor into a separate view that’s then joined into the existing views?

I haven’t delved as far as views, admittedly. One app featured a bit of complicated logic and eschewing the ORM in favour of raw SQL helped (instead of getting tangled up in Demeter chains). Despite new developers, who have used purely ORM for years, shitting their pants at the raw SQL, both of us who worked on it felt it was the right call. We feel much better about leveraging more of the database in new projects.

In fact, when we took our experience to a Django project, my colleague wrote a Manager method in such a way that an ORM favouring developer questioned because it looked too much like SQL. But it was the obvious implementation to us after using raw SQL. And, after benchmarking, the most performant.

I think by "application level" they are saying "using transactions at the application level". If you require a strict sequence of numbers then you BEGIN, READ, INSERT, COMMIT, that is really what you want so just do it explicitly. If the COMMIT fails because of a duplicate key then you start over.