I doubt too many people forgo learning SQL exclusively because they are too busy learning other, higher priority things. Most people have free time and still choose not to learn SQL. I had a teacher in highschool who referred to not doing things because they weren't really that important as being "legitimately lazy" which I feel is an apt description.

It's just that there's so much more exciting stuff to learn, like machine learning, game programming, latest shiny web framework of the month.

If you're a person who likes being visually stimulated while learning, spending free time outside of work to learn how to query tables and design schemas is about as exciting as watching paint dry.

It's exactly the sort of basic, ubiquitous thing that should be on the curriculum - especially if it's unpleasant to learn.

Also there is the balance (i.e. "go home and watch football after 5 p.m.) that the interns want as well. There are people who go do additional research and learning after class, but many don't. In the high-stress environment of CS or engineering school it's not easy to keep working in your little spare time, and I've seen burnout and loss of social opportunities occur as the result of that.

For SQL I think it's fair. It's ubiquitous, generally standard and unchanging, and knowing it well takes less time than just about any other skill in you need in this field. It's been the primary data fetching language at the six companies I've worked at. Some things change fast and go out of fashion, but SQL is clearly not one of them. I studied ONE SQL book over ten years ago now, and it's 90% of what I've ever needed.

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.

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.

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')

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.

It's not the right word.

I have never used and will (in the foreseeable future) not use SQL.

I already have a ton of stuff on my plate that I need or want to learn, SQL is not one of them and I won't include it "just because". Right now it's absolutely useless to my skillset and not something that I have an interest with either. This might change, and then we'll see, but right now it's not even a thought.

I'm pretty unhappy with my current job, but at least I can say I'm not expected to use my very limited and rusty knowledge of SQL. Working with relational databases is one of the least fun aspects of programming I've ever encountered. If a job interview heavily stresses SQL knowledge, I'm probably not a good fit for the position. Even if the position itself demands less SQL ability than the interview suggests, I take the questions as an implicit requirement for success. Also, if I end up in an interview where they delve more deeply into SQL than "when would you use and inner vs outer join", I've probably failed somewhere in screening for jobs I should interview for.

Lazy is almost never the right word: https://sonnet.io/posts/hummingbirds/