Humans of the Data Sphere Issue #2 October 28th 2024
Your biweekly dose of insights, observations, commentary and opinions from interesting people from the world of databases, AI, streaming, distributed systems and the data engineering/analytics space.
“The hardest problem in computer science is neither naming things nor off by one errors. It’s talking to other people.“ — Julien Le Dem
If you came to HOTDS for some Hot Data Science, then I’m afraid you’ll be disappointed, but don’t worry, we’ve got a wide variety of interesting people from across the data sphere and beyond 😄
Ps: A huge number of us dist sys, infra, data infra, messaging/streaming, data eng/analytics, database peeps on Twitter have made the jump to Bluesky, it’s much better there, come and join us!
Here are a few Bluesky starter packs to get you going (they contain a list of people to follow):
The very quotable Julien Le Dem said it: “Data Twitter is dead, long live data Bluesky. 📊“
Quotable humans
Lorin Hochstein: My whole shtick is that I believe updating people's mental models will have a more significant positive impact on the system than discussing action items, but boy is that a tough sell.
Chris Riccomini: Pipeline ownership has shifted as well. WePay had a team of data engineers to manage our data pipelines. These days, we’re asking ML, AI, analytics, and product engineers to build data pipelines. […] There are challenges to this approach. If everyone is managing their own data pipelines, there will duplication. There is also likely to be inefficiency as engineers opt for simpler solutions rather than cheaper ones. Moreover, the pipelines could become a tangled mess with no clear ownership as employees come and go. […] But I think dlt has recognized something: data consumers want control of their data pipelines.
Forest Brazeal: I used the word "footgun" among engineers this week and found out that several people didn't know what it meant!
Richie Fink on Super Data Science 827, Polars, Past, Present and Future: There’s also quite some misconception about what (Apache) Arrow is. That’s because PyArrow, the library, does not only do Arrow memory but also Arrow compute. Sometimes people say “it’s fast because of Arrow” and that doesn’t make any sense. First, Arrow is a specification of how memory should be ordered for specific data types. That’s all Arrow is. That’s the same as JSON is a specification for how to store the bytes of a JSON serialized data structure. JSON is not a very optimal way to store data, so it’s not very good for performance; Arrow is much better, if you are doing columnar data processing.
Ben Dicken: Did you know that a random SSD read is multiple orders of magnitude slower than a random memory read? I made a little visual that really drives the point home. This is why memory buffers and caches are so important, especially for I/O heavy workloads like databases.
Craig Kerstiens: I mentioned recently that anytime I encounter a database without constraints I run into data integrity issues. Could not agree more with taking full advantage of them.
Alex Miller: I have a personal fondness for papers/posts which present two very distinct and opposing designs as just two extremes of some spectrum of design trade-offs. LSMs vs B-Trees is a space in which I've seen a few rather different pitches of what that design spectrum could look like.
John Kutay: TIL #duckdb uses Adaptive Radix Trees as one if its two key indexing methods… At their core, radix trees optimize for space by compressing paths where nodes only have a single child. Instead of wasting memory with unnecessary branches, it collapses them, leading to reduced storage overhead compared to a traditional trie.
Chris Riccomini: NVIDIA’s cuda-checkpoint is particularly important. CUDA offers GPU APIs meant for generic computation (not gaming). Such APIs are widely used in AI models and LLMs. As developers execute operations on a GPU, the GPU’s memory accumulates state. This GPU data is very difficult to read directly, which poses a problem if you wish to snapshot a machine’s state. Now cuda-checkpoint offers a simple, bare-bones, free tool to do GPU checkpoint and recovery.
For serverless functions, unikernels such as Unikraft now boast single digit boot times and fast snapshotting. This should enable faster cold starts and scale-to-zero, which will result in cost savings. Many unikernels tout increased security in multi-tenant environments, as well. As unikernels add Kubernetes support, I expect adoption to increase, so non-serverless workloads like microservices will benefit.
Kelly Sommers: How do you decide when something that is essentially a data pipeline job belongs in a data orchestration tool instead of a bunch of micro services reading, transforming & writing data using some scheduling lib?
Sometimes diff to decide when to disrupt a teams comfort choices.
John Kutay: I always recommend CDC for analytics on transactional data. OLTP systems rely heavily on efficient management of the buffer cache for high-speed data access. Analytical queries can increase cache pressure by loading large amounts of data that may not be reused frequently, pushing out more critical OLTP-related data from the cache.
Eric Sammer: The current discourse on disaggregated compute and storage in data infra says local disk is bad. I think this lacks nuance. Local persistent disk (e.g. EBS) is bad. Ephemeral local disk should be embraced as a block cache for reads and staging of writes to durable storage. The cost/op is a win.
Julien Le Dem: Modern data engineering is emancipating ourselves from an uncontrolled flow of upstream changes that hinders our ability to deliver quality data.
Julien Le Dem: The final step of standardization is to move the responsibility of producing lineage metadata to the producer of data itself. As it emerges as a common need for all data practitioners, lineage becomes a requirement for all data tools, open source or proprietary.
Craig Kerstiens: If you're not running PgBouncer check your idle connection count:
SELECT count(*), state
FROM pg_stat_activity
GROUP BY state;
Charity Majors: This is a hard truth about data-driven products. You can have a world-class team, great ideas, and tons of funding, but your ability to build a great user experience will always be bounded by how bits get laid out on disk -- decisions made long before any of you were even there.
Charity Majors: Catching up and closing tabs on a month or so if missed blog posts, and here's another dandy: "The Observability CAP Theorem", by @_cartermp. Everybody wants:
1, fast queries
2, long retention
3, rich context
4, low cost
You can pick two, *maybe* three.
Gunnar Morling: Thoroughly thinking about and describing the possible failure modes of a proposed design will put you ahead of 90% of software engineers.
SeattleDataGuy: Let's just fix it in SQL - It can seem really easy to fix business logic in the SQL layer rather than from the source. However, this means, in the long-run, anytime that business logic changes, your team needs to update the SQL as well. It's far more impactful to get the source team to ensure the data is right where they create it rather than in the data warehouse.
Aleksey Charapko: My student Owen (@owenhilyard) shares his thoughts on DPDK at the DPDK Summit: "DPDK in Databases: Why Isn't It More Common?" TLDR: DPDK is hard, and there is an impedance mismatch between DPDK and DB engineers in creating good network abstractions.
Vinoth Chandar: There is an unhealthy romanticism for war analogies in our industry. After all, we are here to build software, not take sides in wars 🙂. Thankfully, this does not matter since hashtag#opensource does not need vendor blessings to thrive. It just needs a strong community intent on building software.
Marc Brooker: "But what about time-to-market?" has been one of the objections to automated reasoning and formal methods forever, but in many domains they allow us to get to market faster. This is especially true in security, availability, and durability-critical domains.
Shaun Thomas: BRIN indexes are criminally underused in general. I need to sit down and do a writeup for good use cases for BRIN and KNN indexes.
François Chollet: If you take a problem that is known to be solvable by expert humans via pure pattern recognition (say, spotting the top move on a chess board) and that has been known to be solvable via convnets as far back as 2016, and you train a model on ~5B chess positions across ~10M games, and you find that the model can solve the problem at the level of a human expert, that isn't an example of out-of-distribution generalization. That is an example of local generalization -- precisely the thing you expect deep learning to be able to do.
Ethan Mollick: E-commerce companies are doing a good job in their A/B testing, avoiding p-hacking themselves. (This wasn't the case several years back when A/B testing was newer). Referring to:
https://alexmiller.phd/research/p-hacking/ab-testing-p-hacking.pdf
In recent years, randomized experiments (or “A/B tests’) have become commonplace in many industrial settings as managers increasingly seek the aid of scientific rigor in their decision-making. However, just as this practice has proliferated among firms, the problem of 𝑝-hacking—whereby experimenters adjust their sample size or try several statistical analyses until they find one that produces a statistically significant 𝑝-value—has emerged as a prevalent concern in the scientific community. Notably, many commentators have highlighted how A/B testing software enables and may even encourage 𝑝-hacking behavior.
Ethan Mollick: It is morally wrong to use AI detectors when they produce false positives that smear students in ways that hurt them and where they can never prove their innocence. Do not use them.
Nisan Haramati: Which is why it's really important to consider how cost behaves as a system scales. A system whose unit-cost increases with scale (particularly when it grows beyond its optimal operational size) does not actually satisfy "can always grow larger" [...] And it leads to the question that Graphium Labs is working on: can we design a system whose per-unit cost of operation does not overtake the value that the system produces, as the system grows well into the extreme scale range?
Andy Pavlo at P99 Conf: So we’ve been working on a new key/value storage system called BPF-DB. The goal is to provide a transaction storage engine, with a simplistic API with sets and gets, wrapped up in transactions. The idea is to allow developers to build more full featured systems using BPF-DB as the backing storage. Think of something like RocksDB (for eBPF).
Mim: maybe the most important discussion that will determine the future of delta table and iceberg, I hope cool heads will prevails :) https://lists.apache.org/thread/wyon0kvroxsmkxh153444xzscwbb68o1
CharlieDigital: Didn't look too deeply, but one of the keys with Cypher (at least in the context of graph databases) is that it has a nice way of representing `JOIN` operations as graph traversals.
MATCH (p:Person)-[r]-(c:Company) RETURN p.Name, c.Name
Where `r` can represent any relationship (AKA `JOIN`) between the two collections `Person` and `Company` such as `WORKS_AT`, `EMPLOYED_BY`, `CONTRACTOR_FOR`, etc.
So I'd say that linear queries are one of the things I like about Cypher, but the clean abstraction of complex `JOIN` operations is another huge one.
CharlieDigital: If you haven't been following it, I recently found out that it is now supported in a limited capacity by Google Spanner[0]. The openCypher initiative started a few years back and it looks like it's evolved into the (unfortunate moniker) GQL[1]. So it may be the case that we'll see more Cypher out in the wild.
Jeremy Morrell: Adopting Wide Event-style instrumentation has been one of the highest-leverage changes I’ve made in my engineering career.
Simple, Efficient, and Robust Hash Tables for Join Processing:
Joins are asymmetric. Most joins are asymmetric, with one side often much smaller than the other. Hash joins exploit this asymmetry by building a hash table on the smaller side and probing it using the larger side. As the sides are often orders of magnitude different in size, the probing phase must be kept extraordinarily efficient.
Joins are selective. The asymmetry of the sides also manifests in terms of join selectivity: Many probe-side tuples will not find matches. Therefore, it is crucial to efficiently eliminate tuples without a join partner from the large probe side. Bloom filters are ideal for this task.
An investigation of 𝑝-hacking in e-commerce A/B testing:
As empirical science and statistics evolved and became institutionalized throughout the 20th century, this simple rule-of-thumb gradually solidified into a widespread convention for evaluating statistical evidence, with the 𝑝=0.05 threshold often being treated as a definitive cutoff.2 In recent decades, however, the scientific community has increasingly scrutinized the utility, applicability, and consequences of widespread reliance on significance testing that dichotomizes results based on 𝑝-values in this way.
Given that academic researchers, often with doctoral degrees and graduate training in statistics, have been known to engage in 𝑝-hacking behavior (Brodeur et al., 2020, 2023b, Szucs, 2016), it is reasonable to ask whether analysts in corporate environments using similar statistical techniques make similar methodological errors.
Murat Demirbas: Finally, there are operational concerns! Reliably integrating ML into the critical path of any database management system is difficult. How do you ensure there are no surprises when faced with the long-tail of workloads? Whenever queries queue there is a risk of disproportional increase in the response time of short running queries compared to their execution time; a phenomenon often referred to as head of the line blocking (HLB). It seems like the query execution system can be a great breeding ground for metastable failures! How do you trust handing this over to a ML-based system?
Jack Vanlightly: The original state management design in Flink wasn't optimal for the ever growing size of the state being managed by stream processing jobs. But we've seen steady evolution, from aligned to unaligned checkpointing, generic incremental checkpoints, and new state reconstruction algorithms. The next step in this evolution is cloud-native, disaggregated state storage.
Gunnar Morling: In my opinion, CDC makes sense as part of a cohesive data platform which integrates all these things. These, and more: also data governance, schema management, observability, quality management, etc. Another angle for CDC productization could be to marry it closely with a database. Imagine Postgres provided out of the box a Kafka broker endpoint to which you can subscribe for getting Debezium-formatted data change events. How cool would that be? But again, that’s a feature, not a product.
James Governor: We’ve also had a long era of sprawl, where developers and organisations and engineering teams have had a lot of autonomy in the decisions they make, which has enabled productivity in some dimensions, but also major challenges in terms of complexity and lack of standardisation in databases, runtimes, monitoring tools, programming languages and so on.
Karthik Rao: I will argue that today’s query engines, such as Apache Spark, do not effectively interact with lake houses due to limitations in handling object storage semantics, lack of integration with catalog systems like Iceberg for governance and lineage, and inadequate support for lakehouse-specific features. I believe there is a need for a new class of lakehouse-native query engine APIs with explicit semantics for object storage and open table formats.
Craig Kerstiens: I’m often asked what do I think the future for Postgres holds, and my answer has been mostly the same for probably 8 years now, maybe even longer. You see for Postgres itself stability and reliability is core. So where does the new stuff come from if it’s not in the stable core… extensions.
Jamin Ball: As a result, we may see a fundamental change in how enterprise applications are built. The traditional model of a front-end application tied to a database like Oracle and a series of manual workflows might give way to AI-native applications built on AI native databases, where the database takes center stage. These AI applications will be designed to operate on top of centralized data repositories— like a data lakes or lakehouse —where AI agents gather and process information from a wide array of unstructured sources.
Bart de Water: Understanding a bit of queueing theory goes a long way in being able to reason about how a system will behave under load.
Weston Pace on Data Engineering Podcast E442 (23 min). So I used to work with PyArrow and Parquet data sets and there would be a lot of those sorts of configuration things. One of our goals with Lance was really to get rid of those as much as possible. We found that with these wide data types, it either becomes hard to figure out what the right setting is or its damn right impossible, there is no good setting. So with Lance, we got rid of row groups. I told my friend at the time, if the only good thing I do in my life is get rid of row groups then I will consider it a success. Hopefully that can eventually propagate back to Parquet and other file formats.
Weston Pace on Data Engineering Podcast E442 (40 min): Because what we’re seeing is that compression techniques, that again something that seemed relatively solved, well now people are talking about FastLanes and FSST and ALP, and all these interesting compression techniques.
Daniel Whitenack Practical AI E292: I resonate so much with this, coming from a background as a data scientist, living through the years of being told to use Spark for this. Basically my experience in this ecosystem is, I would try to write a query and it would get the right result, but to your point Till, I would just be waiting forever for a result. So I would send the query to some other guy, whose name was Eugene and Eugene was really smart, and he could figure out a way to make it go really fast, and I never became Eugene.
Humans with opinions
Seattle Data Guy (aka Ben Rogojan) on the Snowflake vs Databricks battle
[X post]
First off..."Spark-based SaaS"...they aren't Voldemort..you can say their name.
Second...the more you think about Snowflake vs. Databricks.
The happier Snowflake and Databricks must be.
Despite there being a dozen other options when it comes to building data analytics platform.
They’ve slowly turned the narrative into Coke vs Pepsi.
Nike vs. Adidas.
Burger King vs McDonald’s.
Don't think about any other solutions.
I posted this a while back, but this seemed pertinent.
Phillip Carter on The Observability CAP Theorem
[Blog snippet]
The theorem
Observability has a similar dynamic as the CAP Theorem. Generally speaking, sufficient observability for nontrivial, live applications/systems involves these properties:
Fast queries on your data right now
Enough data to access per query (days, months, years, back)
Access to all the data you care about for a given context
A bill at the end of the month that doesn’t make you cry
Of these, you can definitely get one, probably get two, maybe get three, and you absolutely, positively cannot get all four. The only way that’s possible is if you’re just not generating much data to begin with (e.g., a small business like Basecamp).
Every year, legions of engineers are tasked by their management to get all four properties themselves after experiencing an eye-watering Datadog bill. After having some fun trying to build baby’s first large-scale data analysis system, they ultimately fail.
Open Source Data Summit, Panel Discussion: The rise of open source data catalogs
[Video snippet]
What does your project and your community plan to do about structured data?
Denny Lee (Polaris): This isn’t just for the catalog community, we’re all facing the same dilemma. We want to apply the same logic, of governance, some form of lineage with structured data, and now we need to apply that to our semi-structured and unstructured data. GenAI is everywhere now, that’s great but what were the parameters you used? What was the training data you used? What’s the lineage of all this? Can you from a fiduciary or compliance perspective explain where the source of this data is from?
Russel Spitzer (Iceberg): I wonder, and we’ve had discussions about this in the Iceberg community, if we need some way of tracking blobs, and associated metadata, as entities within the table. Both in Delta, and in Iceberg and Hudi, we have this ability to do this tracking, this lineage, and all we really need to do is extend it past the relational table into attached blobs that are connected to these tables. If we do that in one of these base table formats, then these catalogs get it for free. […] We don’t need this to be a catalog-level concern if we can build this into the table formats themselves.
Helpful Humans
Bart de Water of Shopify wrote 10 Tips for Building Resilient Payment Systems (though I think it applies far more broadly)
Alex Merced wrote:
All About Parquet 01 (the first in a 10-part series on Apache Parquet).
A Deep Dive Into GitHub Actions From Software Development to Data Engineering
Jeremy Morrell wrote A Practitioner's Guide to Wide Events
Farzad Nobar wrote Time Series — From Analyzing the Past to Predicting the Future (an overview of statistical methods for making forecasts based on time-series data).
Brent Ozar wrote How Many Indexes Is Too Many? (Focused on SQL Server but broadly applicable).
R&D humans
A survey of different LLM fine-tuning techniques: https://arxiv.org/abs/2408.13296
The analysis differentiates between various fine-tuning methodologies, including supervised, unsupervised, and instruction-based approaches, underscoring their respective implications for specific tasks.
A structured seven-stage pipeline for LLM fine-tuning is introduced, covering the complete lifecycle from data preparation to model deployment. Key considerations include data collection strategies, handling of imbalanced datasets, model initialisation, and optimisation techniques, with a particular focus on hyperparameter tuning.
The report also highlights parameter-efficient fine-tuning methods such as Low-Rank Adaptation (LoRA) and Half Fine-Tuning, which balance resource constraints with optimal model performance.
The exploration extends to advanced fine-tuning techniques and configurations like memory finetuning, Mixture of Experts (MoE) and Mixture of Agents (MoA), demonstrating how these methods harness specialised networks and multi-agent collaboration for improved outcomes. Proximal Policy Optimisation (PPO) and Direct Preference Optimisation (DPO) are discussed as innovative approaches to aligning models with human preferences, while the benefits of pruning and routing optimisations are examined for enhancing efficiency.
In the latter sections, the report delves into validation frameworks, post-deployment monitoring, and optimisation techniques for inference. It also addresses the deployment of LLMs on distributed and cloud-based platforms. Additionally, cutting-edge topics such as multimodal LLMs and fine-tuning for audio and speech processing are covered, alongside emerging challenges related to scalability, privacy, and accountability.
This report aims to serve as a comprehensive guide for researchers and practitioners, offering actionable insights into fine-tuning LLMs while navigating the challenges and opportunities inherent in this rapidly evolving field.
Two papers discussing more efficient join implementation strategies:
Simple, Efficient, and Robust Hash Tables for Join Processing
Hash joins play a critical role in relational data processing and their
performance is crucial for the overall performance of a database
system. Due to the hard to predict nature of intermediate results,
an ideal hash join implementation has to be both fast for typical
queries and robust against unusual data distributions. In this paper,
we present our simple, yet effective unchained in-memory hash
table design.
POLAR: Adaptive and Non-invasive Join Order Selection via
Join ordering and query optimization are crucial for query performance but remain challenging due to unknown or changing characteristics of query intermediates, especially for complex queries with
many joins. Over the past two decades, a spectrum of techniques for
adaptive query processing (AQP)—including inter-/intra-operator
adaptivity and tuple routing—have been proposed to address these
challenges. However, commercial database systems in practice do
not implement holistic AQP techniques because they increase the
system complexity (e.g., intertwined planning and execution) and
thus, complicate debugging and testing. Additionally, existing approaches may incur large overheads, leading to problematic performance regressions. In this paper, we introduce POLAR, a simple yet
very effective technique for a self-regulating selection of alternative
join orderings with bounded overhead.
Notable trend - Streaming state management
Yuan Mei, Apache Flink PMC member and director of engineering at Alibaba Cloud spoke last week at Flink Forward about work to implement cloud-native disaggregated state storage in Flink 2.0.
Streaming state storage is an interesting subject and the state of the art is moving to disaggregated storage (separation of compute and storage) but also to more bespoke state stores. It turns out that there are challenges to utilizing state stores such as RocksDB in streaming workloads. No data store can serve all workloads, and we see much diversity in stream processor designs when looking across both mature and new stream processors today. Due to this diversity, many stream processors are working on building or have built native state stores to work well with their specific designs.
A number of blog posts have been written this year on this subject. It makes interesting reading to learn how stream processing often requires different state management from an OLTP database (where RocksDB is traditionally used). However, as you will see, each highlights different problems they overcome by choosing a more bespoke state store solution.
With that preamble here are a number of blog posts on this general topic:
Evolution of Flink 2.0 State Management Storage-computing Separation Architecture (Alibaba Cloud)
For this reason, we can consider doing this differently. We can use DFS as primary storage and local disk as an optional cache, and DFS data is the source of truth. In this method, state data is directly and continuously written to DFS, and memory and local disks are used as caches to serve operator state access at the upper layer. The benefits of this architecture are:
When a checkpoint is triggered, most of the state files have already been in DFS. Checkpoints can be quickly executed.
State files can be shared among operators. In some scenarios, storage resources can be greatly reduced by sharing state computing.
State query can be implemented based on remote checkpoint files and file-level APIs can be provided.
Compaction and state cleanup are no longer bound to the task manager. We can use methods such as remote compaction and load balancing to balance the overall resource usage of the cluster.
RocksDB: Not A Good Choice for a High-Performance Streaming (Feldera project)
One might argue that Rust has zero-copy deserialization libraries like rkyv that could be used together with RocksDB. Zero-copy deserialization allows directly casting the starting address of the bytes from RocksDB to an actual Rust type, eliminating CPU overhead. However, zero-copy deserialization requires proper alignment of the deserialized bytes for the target Rust type. RocksDB operates on generic byte slices (&[u8]), which have an alignment requirement of 1 in Rust. Additionally, RocksDB is written in C++, which does not adhere to Rust's alignment rules. Attempting zero-copy deserialization with rkyv and RocksDB might occasionally work, but it often results in a panic due to misaligned slices
RocksDB offers an overwhelming number of configuration options, making it nearly impossible for non-experts to ensure optimal settings. The complexity is so significant that a HotStorage’24 paper detailed training a large language model (LLM) to identify good configurations. It won the best paper award at the conference.
Why not RocksDB for streaming storage? (Materialize, 2020)
Each core in a Timely Dataflow cluster has a complete copy of the logical dataflow plan, and every operator is partitioned across every core. In this sharding scheme, operators on a worker are cooperatively scheduled, and have to be carefully designed to yield eagerly, or they will block other operators from executing, potentially stalling the entire dataflow graph.
And therein lies the problem with RocksDB: RocksDB is designed for liberally using background threads to perform the computation for physical compaction. In an OLTP setting, this is exactly what you want - lots of concurrent writers pushing to the higher levels of the LSM tree, lots of readers accessing immutable SSTables of the entire tree with snapshot isolation semantics, and compaction proceeding in the background with additional cores. In a streaming setting, however, those cores are better used as additional concurrency units for the dataflow execution, which means compaction happens in the foreground. And thus, scheduling when the compaction happens cannot be outsourced, and must be considered alongside all other operators.
Stop embedding RocksDB in your Stream Processor! (Responsive)
In many of these situations the RocksDB state has to be rebuilt from the underlying Kafka changelog topics. If that happens, the partitions in question will not be able to process any new events until the state is fully rebuilt, which could take a very long time for large state stores. This means that these partitions are offline for the duration of the state restoration, which could result in significant business impact.
Debugging incidents often requires you to look up state. For instance, if you can’t make sense of your join output, you’d typically want to look up your state in order to explain the output you see. Doing this with RocksDB is not straightforward: you need to know which partition the key is present on and then run an interactive query against the live application to get the state value for that key. By contrast, dedicated databases have full fledged query layers. This means that you can just issue a lookup against the key to get it’s value.
SlateDB is an interesting project that is relevant to this subject of embedded storage engines (such as RocksDB) and storage disaggregation. It’s the first mover in this area though I can’t imagine it will remain the only embedded state store built for object storage for long. Flink 2.0 has forked RocksDB to create ForSt, a RocksDB that speaks object storage (though it is being developed specifically for Flink, and not designed to be a general-purpose storage engine like SlateDB as far as I know).
My writing
The Curse of Conway and the Data Space. Last week I wrote about Conway’s Law and the data space. Could it be that many modern trends, and even many categories within the Modern Data Stack, have just been reactions to the negative consequences of segregating data teams from software eng teams? When you look the entire space more systemically, through the lens of Conway’s Law, it gives you a wholly different perspective.
The Teacher’s Nemesis: The curse of knowledge is our own blindness as experts regarding the difficulty of learning something and the complexity of concepts we have internalized fully.