The first thing I try to do upon encountering any technology/stack people recommend everywhere is try to figure out what’s wrong with it.
I then skim through anything I can find that’s relevant, and dig into the parts I didn’t fully understand (or skimming didn’t fully answer), until I can provide a comprehensive answer as to where it shouldn’t be used.
In general, implementation details from this skimming is only relevant as per the black-box abstraction — I only care about what workloads and impute the stack falls over on. The implementation itself I only keep around as:
1. I trust the looks of this implementation, so if I need it I know where to start
2. I can give a very superficial explanation of the implementation, just enough to defend my answer as to why it falls over in the workloads it falls over on.
So for databases, as an example, I care about the fact that
1. it stores by row (because this is the key differentiator from column-stores, and is the key as to why OLAP and OLTP have different preferred workloads — and why they can make different optimizations)
2. the indexes and roughly why they work/excel/fail (again, their existence changes preferred workloads)
3. That the SQL compiler produces a “plan”, and this plan is based on heuristics and estimates — So it shouldn’t be blindly trusted. You can view the plan and review it.
4. ACID, its guarantees, and implementation only as far as why can’t MongoDB and friends have it too (and why you might want to drop it — where does it only add overhead)
5. Probably other stuff not on the top of my head
Everything is a trade-off. The goal is to know what trade-offs you’ve actually made.
I then skim through anything I can find that’s relevant, and dig into the parts I didn’t fully understand (or skimming didn’t fully answer), until I can provide a comprehensive answer as to where it shouldn’t be used.
In general, implementation details from this skimming is only relevant as per the black-box abstraction — I only care about what workloads and impute the stack falls over on. The implementation itself I only keep around as:
1. I trust the looks of this implementation, so if I need it I know where to start
2. I can give a very superficial explanation of the implementation, just enough to defend my answer as to why it falls over in the workloads it falls over on.
So for databases, as an example, I care about the fact that
1. it stores by row (because this is the key differentiator from column-stores, and is the key as to why OLAP and OLTP have different preferred workloads — and why they can make different optimizations)
2. the indexes and roughly why they work/excel/fail (again, their existence changes preferred workloads)
3. That the SQL compiler produces a “plan”, and this plan is based on heuristics and estimates — So it shouldn’t be blindly trusted. You can view the plan and review it.
4. ACID, its guarantees, and implementation only as far as why can’t MongoDB and friends have it too (and why you might want to drop it — where does it only add overhead)
5. Probably other stuff not on the top of my head
Everything is a trade-off. The goal is to know what trade-offs you’ve actually made.