3 ms·

Performance doesn't necessarily kill a product or service. And since they were too busy figuring out all of the odds and end of X database, the UX went to shit

Performance doesn't necessarily kill a product or service. And since they were too busy figuring out all of the odds and end of X database, the UX went to shit because they didn't learn about some quirk of Chrome, Firefox, Safari or something on mobile and suddenly a deployment breaks stuff for one of the browsers/platforms. If you can't afford a DBA when DB performance is critical to your application, you probably don't have good QA for all of those platforms either. But suddenly your developer is supposed to stretch over all three areas? When people talk about hilariously long laundry lists of technical requirements, it's an aggregation of demands like these over time that has inflated those requirements.

gfody 10y ago
in my experience 99/100 major debilitating webapp performance issues are from SQL-oblivious developers making basic variations on the "n+1" problem, executing a thousand queries instead of one, failing to think in sets, treating the database like a dumb key-value store and paying extreme taxes on roundtrips and connection overheard. Bring a DBA into this situation, he might look at your queries, look at your indexes, and say "everything is fine". It's the developers who need to know how to use a database.
- FLUX-YOU 10y ago
  But how do you draw the line on required knowledge? At some point you need to say "This should be DBA territory", and that's the soft wall where responsibility gets thrown over to the other side. Do I spend time poking around at a problem I've got, or do I hand it off? The thing is that soft wall is wayyyy too vague for anyone to prepare themselves before actually joining a team. I may not want to join your team if you require everyone to be a database expert because I don't like databases. But because the communication around this is so damned vague, there's no way to know before joining. If you somehow have a SQL-oblivious developer, he should be identified early on because it's not compatible with the level of competence you've established for your business. Why is this guy suddenly writing performance-critical queries for your webapp and not working with his strengths? Does he have any strengths? No? Why was he hired? Shouldn't someone be reviewing this guy's code? The SQL-oblivious developer is a perfectly natural occurrence from a time past when front and back end job postings were not wrapped into a full stack developer position for less pay than those positions combined. It's just that it's so easy to pile on requirements that it just outpaces some people. Can we identify those people reliably? Yes? Congrats, you've probably got a way to actually test developer competence without invoking another 300-post threadnought on HN and you will likely be very, very rich. But see, you can't go off studying every single thing mentioned in the context of "Things important for developers to know" even if you wanted to try and keep up. There have been tons and tons of blog posts and articles and angry posts about terrible situations created due to a lack of knowledge and everyone just says "Hey, you should know this, get to it". Even if I wanted to filter through all of those posts, how do I know who to listen to?
  - gfody 10y ago
    If you want to specialize in javascript and html that's fine. The middle/backend/API then ought to be developed by someone knowledgeable in SQL - but it's still a developer, not a DBA. DBAs are sysadmins not programmers. If you want to specialize in middle/backend development and think you should be able to defer all your SQL problems to a DBA then no your dead wrong. You simply cannot be a good backend developer for web applications utilizing RDBMSs and not know this shit.

gfody 10y ago

in my experience 99/100 major debilitating webapp performance issues are from SQL-oblivious developers making basic variations on the "n+1" problem, executing a thousand queries instead of one, failing to think in sets, treating the database like a dumb key-value store and paying extreme taxes on roundtrips and connection overheard. Bring a DBA into this situation, he might look at your queries, look at your indexes, and say "everything is fine". It's the developers who need to know how to use a database.

FLUX-YOU 10y ago
But how do you draw the line on required knowledge? At some point you need to say "This should be DBA territory", and that's the soft wall where responsibility gets thrown over to the other side. Do I spend time poking around at a problem I've got, or do I hand it off? The thing is that soft wall is wayyyy too vague for anyone to prepare themselves before actually joining a team. I may not want to join your team if you require everyone to be a database expert because I don't like databases. But because the communication around this is so damned vague, there's no way to know before joining. If you somehow have a SQL-oblivious developer, he should be identified early on because it's not compatible with the level of competence you've established for your business. Why is this guy suddenly writing performance-critical queries for your webapp and not working with his strengths? Does he have any strengths? No? Why was he hired? Shouldn't someone be reviewing this guy's code? The SQL-oblivious developer is a perfectly natural occurrence from a time past when front and back end job postings were not wrapped into a full stack developer position for less pay than those positions combined. It's just that it's so easy to pile on requirements that it just outpaces some people. Can we identify those people reliably? Yes? Congrats, you've probably got a way to actually test developer competence without invoking another 300-post threadnought on HN and you will likely be very, very rich. But see, you can't go off studying every single thing mentioned in the context of "Things important for developers to know" even if you wanted to try and keep up. There have been tons and tons of blog posts and articles and angry posts about terrible situations created due to a lack of knowledge and everyone just says "Hey, you should know this, get to it". Even if I wanted to filter through all of those posts, how do I know who to listen to?
- gfody 10y ago
  If you want to specialize in javascript and html that's fine. The middle/backend/API then ought to be developed by someone knowledgeable in SQL - but it's still a developer, not a DBA. DBAs are sysadmins not programmers. If you want to specialize in middle/backend development and think you should be able to defer all your SQL problems to a DBA then no your dead wrong. You simply cannot be a good backend developer for web applications utilizing RDBMSs and not know this shit.