> You cannot possibly know if your condensed version is accurate or sufficient if you can't point to the author of it and definitively state that they knew the original material well enough to summarize it.
I don't understand how this relates to the article. The author is not presenting himself as an expert on database indices, nor is the purpose of the article to educate people on database indices. If anything, he's illustrating techniques for dealing with technology when you're not an expert.
> I also continue to push back on the idea that [backend] devs shouldn't need to know SQL extremely well
The article isn't about any particular technology or type of software engineer, either -- this is just an example. We all have to use technologies that we're not world-class experts in, and part of being a professional engineer is learning ways to deal with that sad reality.
--
Edit to add: I do feel a certain sympathy/resonance for your claim that people should be really competent at the tools/tech they're using, and it's strictly "better" for everyone. But we also live in a world where the complexity and depth of software stacks is increasing rapidly, and developers often have to prioritize breadth over depth. (And yes I have seen a lot of people shoot their foot off with poorly-informed use of databases :/)
His entire article is about how to be a "good engineer", and "In my view, good engineering requires having reliable shallow intuitions about how things work."
I think he's wrong, but more importantly I think he needs to be more humble that it's not "good" engineering, it's probably bad. You can get by if you're a startup and just need to get stuff done, but don't start teaching people and writing blog posts on the topic when you have shallow knowledge.
I was replying to your statement, not the article. Did I miss that quote in it?
> We all have to use technologies that we're not world-class experts in
I’m not asking people to be experts, just to know how it works. If you write software that communicates over TCP, you should know how TCP works. If you write software that uses a deque, you should know how a deque works. Etc.
Re: the real world, perhaps that’s a good indication that we shouldn’t be unnecessarily increasing complexity, and use boring technology.
> I’m not asking people to be experts, just to know how it works
But if you "know how something works" in detail, such that you fully understand its workings and behavior, you're pretty much an expert. To really know how a database works is a project that takes hundreds of hours of dedicated study, and the deeper you look, the more nuance you find. Otherwise, you'll inevitably make the kinds of flawed generalizations that you dislike about the OP's mental model.
As I say, I have sympathy for your argument. I have spent a lot of time studying databases, I've contributed some patches to Postgres, I like understanding how things really work. But the reality is: full-stack development today is fractally complex. There are MANY components that each might require hundreds of hours to understand, and it's actually not economically valuable for you or your employer to rabbit-hole down each one before you start using it. You need to be able to pick up the key idea of a technology, using the appropriate resources, without fully studying it out.
--
I think that perhaps we understand the article differently. I think you understand it as a tradeoff between "understanding a system a little bit" vs. "understanding deeply," in which case, sure, it's easy to argue that we should all understand technologies deeply. But I think the real tradeoff is for beginners -- "understanding only the apparent outer workings of a system" vs. "having a first-order model of the components that lead to that behavior." Going one level down is the first step to going all the way, and there is a big difference in even going one level down.
> full-stack development today is fractally complex. There are MANY components that each might require hundreds of hours to understand
This is precisely why I maintain that the entire notion of full stack engineering is flawed. It’s absurd to think that one person should be able to meaningfully understand front end, backend, networking, and infra. Even if you abstract away networking and infra (spoiler, you’ve just kicked the can down the road), I’d argue that expecting someone to be good at frontend and backend is ridiculous. Maybe if the industry didn’t have such insane abstractions and frameworks, it would be doable, but that’s not how it is.