3 ms·

Knowing how to data model is a skill I learned and got good at long before I was ever forced to write my first SQL statement. For all it’s power an usefulness S

Knowing how to data model is a skill I learned and got good at long before I was ever forced to write my first SQL statement. For all it’s power an usefulness SQL is to databases what JavaScript is to web development… some people are WAY too obsessed with using it for everything they can. And this is a bad thing. I find “DBA”s tend to reach for SQL first and can cause their own kind of chaos. From writing difficult to test code because they hand wrote SQL that only works on the production database (PostgreSQL vs in memory SQLite) to my pet peeve of constantly suggesting that a problem would be trivial to solve with stores procedures which would massively complicate (requirements completely replacing) the database migration system currently in use (because most frameworks, like Rails, Laravel and Django don’t have good built in tools for managing, versioning and updating stored procedures). Adding a DBA to a team is like adding an opinionated senior developer, sometimes you need that experience and sometimes it’s just going to be a total fucking pain in your ass. If you feel you need better data modelling skills in your developers, don’t hire a DBA, hire developers that know how to do data modelling.

NikolaNovak 4y ago
Agreed; depends hugely on system and project/team. I'm in the ERP space (Fun!:), which means a lot of code is effectively legacy and a lot of standards/methods are also effectively... old :-). We are lucky on my current project to have developers who ARE senior and experienced and pretty good at data modelling; but there is still a lot of need for somebody to own the back end system and design maintenance and notice problems and optimize things holistically as opposed to program by program. So I guess I should've clarified - a good developer certainly helps but does not obviate the need for DBA in many scenarios.
acoard 4y ago
This is a good caveat, and I agree with the thrust of your point. Especially about stored procedures. Sometimes DBAs, especially corporate oldschool ones, can really propose DBA-only solutions, and it's painful. I think another way of thinking about this is hire "former DBAs." Most of the developers I know who had really solid SQL, the greybeards I learned from, were either former DBAs or former sysadmins who had become full-stack developers. edit: Another was a junior developer who interned two years as a DBA role. He was desperate to lose the DBA title, and I always respected that, but damn if his SQL wasn't better than mine.

NikolaNovak 4y ago

Agreed; depends hugely on system and project/team. I'm in the ERP space (Fun!:), which means a lot of code is effectively legacy and a lot of standards/methods are also effectively... old :-). We are lucky on my current project to have developers who ARE senior and experienced and pretty good at data modelling; but there is still a lot of need for somebody to own the back end system and design maintenance and notice problems and optimize things holistically as opposed to program by program. So I guess I should've clarified - a good developer certainly helps but does not obviate the need for DBA in many scenarios.

acoard 4y ago

This is a good caveat, and I agree with the thrust of your point. Especially about stored procedures. Sometimes DBAs, especially corporate oldschool ones, can really propose DBA-only solutions, and it's painful. I think another way of thinking about this is hire "former DBAs." Most of the developers I know who had really solid SQL, the greybeards I learned from, were either former DBAs or former sysadmins who had become full-stack developers. edit: Another was a junior developer who interned two years as a DBA role. He was desperate to lose the DBA title, and I always respected that, but damn if his SQL wasn't better than mine.