5 ms·

> that is usually the bottleneck... I want you to know WTF you are doing when you touch it. Why don't you hire a DBA and have all major queries go through them

> that is usually the bottleneck... I want you to know WTF you are doing when you touch it. Why don't you hire a DBA and have all major queries go through them if it's that important instead of asking developers to master yet another thing because you got burned in the past? I'm all for learning database stuff, but you and everyone else are pulling developers in all different directions by simultaneously claiming "YOU NEED TO KNOW THIS SHIT" about <THING THAT HURT YOU PREVIOUSLY>.

gfody 10y ago
"you need to know this shit" is something I say often to developers displaying complete ignorance of SQL. I think if you're an embedded systems programmer or an games developer focusing on the rendering pipeline or something then sure be blissfully ignorant of SQL. If you are a web application developer, where 99.999% of web applications use a backing RDBMS and a huge part of the heavy lifting and most likely bottlenecks and nearly all performance tuning is in the RDBMS - then you need to know this shit.
- FLUX-YOU 10y ago
  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.
- Retric 10y ago
  If you do sane things with your DB then you really don't need to mess with all the edge case crap that breaks ORM's. Great DBA's are rare, but vastly more important than most people think.
  - jackmott 10y ago
    I constantly pick up the metaphorical phone to call the DBA then remember that I am the DBA...
CydeWeys 10y ago
I've found that specialization is an emergent property of teams and organizations. Each developer naturally has propensity for and interest in some areas over others. Imagine a completely flat company with twenty developers, where everyone is supposed to be a full-stack, you-need-to-know-everything-about-everything developer. Well, in even a short amount of time, you're naturally going to end up in a situation where some developers specialize in certain sets of frameworks and tools, and become the go-to experts in that. So something like a DBA, i.e. an expert in your software's database, will emerge naturally over time on a product. In my current project, there are definitely some areas that I am the "go to" guy on, and likewise there are other people on my team that are the "go to" people for other areas. And yes, we even have two people who are especially knowledgeable about our backing datastore, and the library we use to interact with it.
pmontra 10y ago
That a DBA can make almost every query faster and every db schema better is often an unknown unknown for developers. Combine that with the need of having the DBA at hand all the time, because developers create new queries and possibly new tables or suboptimal solutions all the time. Small companies might get a DBA only when it's too late and they would need a major rewrite of some code and of the db schema. I've even seen companies with plenty of DBAs in Operations and none in development and no chances for them to affect the development process, both because the unknown unknown and because rigid compartmentalization between company departments.

gfody 10y ago

"you need to know this shit" is something I say often to developers displaying complete ignorance of SQL. I think if you're an embedded systems programmer or an games developer focusing on the rendering pipeline or something then sure be blissfully ignorant of SQL. If you are a web application developer, where 99.999% of web applications use a backing RDBMS and a huge part of the heavy lifting and most likely bottlenecks and nearly all performance tuning is in the RDBMS - then you need to know this shit.

FLUX-YOU 10y ago
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.
Retric 10y ago
If you do sane things with your DB then you really don't need to mess with all the edge case crap that breaks ORM's. Great DBA's are rare, but vastly more important than most people think.
- jackmott 10y ago
  I constantly pick up the metaphorical phone to call the DBA then remember that I am the DBA...

CydeWeys 10y ago

I've found that specialization is an emergent property of teams and organizations. Each developer naturally has propensity for and interest in some areas over others. Imagine a completely flat company with twenty developers, where everyone is supposed to be a full-stack, you-need-to-know-everything-about-everything developer. Well, in even a short amount of time, you're naturally going to end up in a situation where some developers specialize in certain sets of frameworks and tools, and become the go-to experts in that. So something like a DBA, i.e. an expert in your software's database, will emerge naturally over time on a product. In my current project, there are definitely some areas that I am the "go to" guy on, and likewise there are other people on my team that are the "go to" people for other areas. And yes, we even have two people who are especially knowledgeable about our backing datastore, and the library we use to interact with it.

pmontra 10y ago

That a DBA can make almost every query faster and every db schema better is often an unknown unknown for developers. Combine that with the need of having the DBA at hand all the time, because developers create new queries and possibly new tables or suboptimal solutions all the time. Small companies might get a DBA only when it's too late and they would need a major rewrite of some code and of the db schema. I've even seen companies with plenty of DBAs in Operations and none in development and no chances for them to affect the development process, both because the unknown unknown and because rigid compartmentalization between company departments.