The issue is “framework developers”. I am not opposed to learning and using frameworks but you should always know at least one level below the framework you are using.

If you are a web developer who uses Angular/React and Bootstrap everyday you should know JavaScript, CSS, and HTML well.

If you use an ORM, you should know enough about how databases work to have a mental model of what the database is doing.

I've never heard that good advice put so succinctly before. Has this advice been around for ages and I just missed it, or is it a newly relevant concern?

BTW, what would two levels be to, say, a React developer, out of curiosity? Would it be the browser engines? Knowing how JIT compilers work, etc.? Or would it instead be a deeper understanding of the language spec, so that you know more internal functioning? Not that there has to be a clear-cut answer.

When I started learning AppleSoft Basic back in the 80s, I knew how to optimize my BASIC programs because I knew how the interpreter worked and so knew assembly.

When I started learning C#, I knew both C, Win APIs and how the CLR worked.

But for a web developer who communicates with backend servers, I think it’s important to understand HTTP.

Language-wise, I'd say babel "javascript" is the highest level of abstraction. One level below is understanding what things like JSX and class properties transpile to. One level below is understanding JIT strategies (e.g. when hidden classes deopt), memory usage of various patterns, etc. One level below is understanding specific semantics of high level APIs (e.g. exact accuracy of a high res timer implementation), or regexp memory footprint by looking at browser source code.

Why wouldn’t a developer’s job be to learn how to optimize a database query but would be to learn how to optimize a program?

No one has thought to run a query plan

(N + 1)*10000000000000000

Yet I've never once been asked about this in an interview despite using it maybe once a week for years.

O(n) on the other hand...

I run into this problem whenever I'm interviewing for devs on my team. As a java shop, we usually get people who come in and claim to be proficient in Spring, but when I start asking them questions about the underlying technologies they blank.

My favorite weed-out question when I'm worried someone is too tied to a framework (especially when its one that isn't actively in use on a project) is to ask them to give me some examples of the limitations of it. To me, being able to recognize the things your favorite framework is not able to solve effectively is the best indicator that you aren't using it as a crutch.

Now on the other end AWS CloudFormation for infrastructure as code, I could go on for days about its limitations.

1) It's a web framework. So, not suitable for command line tools, desktop GUIs or persistent message queue workers. But you can do all of that in other kinds of C# .NET app.

2) However, .NET is a Garbage Collected language and should not your first choice for e.g. a real-time device driver or OS kernel.

But people do try to do some of those things that I listed, using ASP.NET.

As someone who has had DBA in my job title before, it saddens me to think DBA was needed to explain the importance of foreign keys or indexes (this should be general developer knowledge at this point). As a general rule, any field used in a join or where clause is an index candidate. And foreign keys (along with other constraints) are like type checking in code. They help you not do anything stupid later.

My DB course taught us relational algebra and calculus and you were expected to learn SQL independently.

I am constantly bemused tho’ at the extraordinary lengths some devs will go to to avoid SQL. I’ve known people who will grudgingly do SELECT * FROM table; then extract the one row/column they want on the client. Then they complain that the DB is slow when it’s loadavg is 0.01...

Though, once you get into more advanced things like stored procedures and triggers, SQL becomes a little hostile.

My second point is that something about relational databases and SQL just doesn't sit well with (many) software developers. As a result, we have a lot of XML and JSON blobs stored in key/value databases, a lot of software that doesn't work very well, and we are still dealing with a lot of problems that Ted Codd solved 48 years ago.

In the end many of the various contracting companies started to work together to work around the DBAs ineptitude and work on ways to speed up performance, including projections. We kept him in the loop, but it just felt like the only thing the DBA cared about was permissions and user accounts. In fact that's the only thing we kept calling him for was one of our accounts would suddenly not work. He was also extremely insistent against tools like Liquibase to keep all environments in sync and standardized. Instead our Dev and QA through prod would all have different tables and columns all over the place because the DBA WAS IN CHARGE OF THAT.

This was a large organization, and 99% inefficient. There IS a reason large companies are trying to run projects like startups. DBAs are often like pizza flippers, whereas developers don't like doing things multiple times.

But it's not DBAs as in database admins that are needed. Every project should start with the correct data architecture and for that you need an architect. There are endless number of projects that eventually failed because the data architecture did not scale. That's due to a programmer who designs the database according to the way that their preferred tool works best, which is usually bad for data.

For any project that requires a database, always start with the method that data will be reported. If a report takes a long time to be generated because of your design, then you need to fix that first.

I think the reason DBAs are not hired is because we don't need them as often and for as long as we do devs.

And all the rest of the time, you've got a very smart person whose job is basically just to make sure the backups are running smoothly.

I'm not sure what the solution there is. Only the largest enterprises can really keep a good DBA busy with work that isn't just skull-splittingly boring. Maybe merge the DBA role with BI or data engineering?

Good DBA's are also really hard to find. We have been looking for one for the past 6 months with no luck

My school's DB course taught you to build databases. You're expected to learn SQL on your own. And we all did. Not knowing SQL is an ongoing lifestyle choice.

What? Relationships (and thus foreign keys) have been around since before 1.2.

I started using Rails almost at the very beginning. See https://stackoverflow.com/questions/2373262/are-foreign-keys... from 2010 for a bunch of links to DHH opinion on the matter (from 2006.)

Foreign keys made it into the DSL with Rails 4.2

http://guides.rubyonrails.org/4_2_release_notes.html#foreign...

https://apidock.com/rails/ActiveRecord/ConnectionAdapters/Sc...

Before that we were using gems or writing SQL into the up and down migrations.

https://robots.thoughtbot.com/referential-integrity-with-for... (from December 2014)