4 ms·

SQL et al. were built to solve the problem 'how do I handle (possibly big) datasets'..._when_I_was_a_kid_, you had to learn in your programming language how to

SQL et al. were built to solve the problem 'how do I handle (possibly big) datasets'..._when_I_was_a_kid_, you had to learn in your programming language how to handle data and how to work with it. There was a lot of conversations on sorting techniques, how you laid data down on storage medium, etc. All that went away with SQL as the management was pushed down to the database. It freed the developer up to concentrate on the problem, rather than the hygiene. Likewise, I guess, the kids these days don't need to worry about the OSI model, subnetting, routing, TTL... I can complain that a cloud native Hello World application can be made with the end user knowing NOTHING about the underlying code to get it there, but that's just me being an old guy, shouting at a cloud. I look at what I know, and what the kids know, and recognize that each of these technologies was spoon-fed to me over decades. I didn't learn Linux, SQL, networking, GPU acceleration, Network Intrusion and Detection and how to manage it...all at once, when I was 21.

mike22 4y ago
It’s great to write carefree SQL, with the DB platform totally abstracted, until there’s a massive spike in query latency. Then hash joins vs nested loops and full table scans is useful knowledge which is a) mostly vendor specific b) requires a good prod-sized dataset to test on.
avgDev 4y ago
I mean you can only learn so much in school. I have been developing for 5 years now and I'm always finding a new neat thing even in SQL. Recently, had an issue with deadlocks, I learned about them in school(even did a presentation on it) but had to research how SQL handles them and how I can rectify the issue we were having. I really enjoy this part of the job. There is always something 'new' to learn, even if it existed for a while like SQL.
- Damogran6 4y ago
  Most of IT is a lake a mile wide and an inch deep...Sure, there's parts that you'll drown in, but you can get by with the inch deep stuff. It's not even a Jack-of-all-Trades thing, and I hate it. You're a Git away from building your startup and you've got no idea what libraries or dependencies it has, you just logged into AWS with a credit card and ran with it. (Not you, exactly, the 'Royal You')

mike22 4y ago

It’s great to write carefree SQL, with the DB platform totally abstracted, until there’s a massive spike in query latency. Then hash joins vs nested loops and full table scans is useful knowledge which is a) mostly vendor specific b) requires a good prod-sized dataset to test on.

avgDev 4y ago

I mean you can only learn so much in school. I have been developing for 5 years now and I'm always finding a new neat thing even in SQL. Recently, had an issue with deadlocks, I learned about them in school(even did a presentation on it) but had to research how SQL handles them and how I can rectify the issue we were having. I really enjoy this part of the job. There is always something 'new' to learn, even if it existed for a while like SQL.

Damogran6 4y ago
Most of IT is a lake a mile wide and an inch deep...Sure, there's parts that you'll drown in, but you can get by with the inch deep stuff. It's not even a Jack-of-all-Trades thing, and I hate it. You're a Git away from building your startup and you've got no idea what libraries or dependencies it has, you just logged into AWS with a credit card and ran with it. (Not you, exactly, the 'Royal You')