The Data Engineer Bundle: Build the pipelines a whole company runs on, the kind of work that makes you central, hard to replace, and well paid.

Description

PYTHON: Become the reviewer AI can’t replace, the one who catches the bugs that run but are wrong and signs off on what ships

This book trains you to be the reviewer of vibe-coded Python, not to memorize the language. It starts from a different premise than every other Python book: the agent writes the code, and your edge is understanding what that code really does so you can review it with judgment the interpreter does not have. You’ll learn what a name actually binds to and why aliasing and mutability cause the bugs they do, what a type hint does and does not enforce, what the event loop is really doing behind async and await, why the global interpreter lock means your threads are not the parallelism you think, what an ORM and a connection pool actually do, and how the pieces integrate into a running service, and you’ll learn all of it the way a reviewer needs it: by reading real code the agent would generate and deciding what is good, what is plausible-but-dangerous, and what to push back on. The progression moves from reviewing a single object and a single name, to reviewing a component like the data layer or the request pipeline, to reviewing how the whole system fits together and where it will break under real load. There is almost no syntax drill here, and a great deal about the object model, concurrency, failure, and the specific ways an agent’s Python goes wrong. For engineers who are going to vibe-code in Python either way and want to be the one who catches what the model missed.

SQL: Become the reviewer AI can’t replace, the one who catches the SQL that runs clean but quietly returns the wrong answer

This book trains you to be the reviewer of vibe-coded SQL, not to memorize the syntax. It starts from a different premise than every other SQL book: the agent writes the queries, and your edge is understanding what the database really does so you can review it with judgment the engine does not have. You’ll learn why a relational table is a set and why thinking in sets is the whole game, the order the engine actually evaluates a query in, how joins and indexes really execute and when an index is useless, the three-valued logic that makes NULL the most common silent-wrong-result bug in SQL, how to read a query plan as the ground truth the SQL hides, and how transactions, isolation, and migrations behave under real concurrency and scale, and you’ll learn all of it the way a reviewer needs it: by reading real queries the agent would generate and deciding what is good, what is plausible-but-dangerous, and what to push back on. The progression moves from reviewing a single query and a single index, to reviewing a schema and its constraints, to reviewing how the whole workload behaves under load and where it will fall over. There is almost no syntax drill here, and a great deal about the relational model, query execution, data integrity, and the specific ways an agent’s SQL goes wrong. For engineers who are going to vibe-code SQL either way and want to be the one who catches what the model missed.

AWS: Become the engineer trusted to sign off on any cloud, catching the security and cost flaws an AI agent confidently ships past you

This book trains you to be the reviewer of vibe-coded AWS, not to memorize the console. It starts from a different premise than every other AWS book: the agent writes the infrastructure, and your edge is understanding the services well enough to judge the architecture, the cost, and the blast radius with the three questions the agent never asks. You’ll learn what the core services really are and when each is the right tool, EC2 and Lambda and the container options for compute, S3 and RDS and DynamoDB and ElastiCache and Redshift for storage and data, Athena and OpenSearch for analytics and search, SQS and SNS and SES for decoupling and email, and Bedrock for AI, and you’ll learn the foundations that decide whether any of it is safe and affordable, IAM least privilege, the VPC and where each tier belongs, how a real HTTPS endpoint is assembled from Route 53 and a certificate and a load balancer, and how to read a bill before it arrives. Every chapter designs a real piece of a working system, gives an illustrative cost estimate, and shows the good-versus-bad architecture an agent would produce, building from a single service to a full design expressed as reviewable infrastructure-as-code with the CDK. There is almost no console clicking here, and a great deal about cost, security, data, and the specific ways an agent’s cloud goes wrong. For engineers who are going to vibe-code on AWS either way and want to be the one who catches the design that would have leaked, broken, or bankrupted them.

GCP: Become the one who reads the cloud an AI agent built and knows what is safe, what will burn money, and what to send back.

This book trains you to be the reviewer of vibe-coded Google Cloud, not to memorize the console. It starts from a different premise than every other cloud book: the agent writes the infrastructure, and your edge is understanding what the platform really does so you can review it with judgment the cloud does not have. You’ll learn what IAM actually evaluates and why least privilege is the whole game, what Terraform’s plan and state really mean and why reviewing the plan is non-negotiable, how Cloud Run scales and cold-starts and bills, what Pub/Sub’s at-least-once delivery forces you to handle, how to choose between Cloud SQL, Firestore, and a Redis cache by access pattern, why BigQuery bills per byte scanned, and what embeddings, a vector index, and agent memory actually are, and you’ll learn all of it the way a reviewer needs it: by reading the real Terraform, IAM policy, and service config an agent would generate, with a running application designed across the chapters and a cost model for every service, deciding what is good, what is plausible-but-dangerous, and what to push back on. The progression moves from reviewing a single resource and its permissions, to reviewing a service and its data and AI layers, to reviewing the whole architecture for security, cost, and failure under load. There is almost no click-by-click here, and a great deal about identity, networking, cost, and the specific ways an agent’s cloud goes wrong. For engineers who are going to vibe-code on Google Cloud either way and want to be the one who catches what the model missed.

AI DATA ANALYST: From SQL and statistics to data-driven decisions in the age of AI

This book trains you to be the reviewer and decision-maker over data, not to memorize another tool. It starts from a different premise than every other analytics book: the agent writes the queries, the pandas, and the first draft of the chart, and your value is the judgment the tool does not have. You’ll learn to frame the question behind the question a stakeholder actually asked, to interrogate whether the data can be trusted before you quote it, to follow a number back through the pipeline and the warehouse to where it could have broken, to define a metric so it means what you think it means, and to use only the statistics an analyst really needs. You’ll learn to design an experiment that can be believed, to read a p-value for what it does and does not license, to catch the bias, the confounding, and the Simpson’s paradox that flip a result, and to downgrade a correlation to the claim its design actually supports. Then you’ll learn to choose the chart that tells the truth instead of the one that flatters it, to turn a finding into a decision a busy executive will act on, and to handle user data within privacy law and without letting a biased model launder old harm into a new decision. The progression moves from reviewing a single number, to reviewing an experiment and an inference, to reviewing how the whole story reaches a decision and whether that decision is fair. There is almost no tool syntax here and a great deal about questions, trust, inference, communication, and the specific ways an agent’s analysis goes wrong. For the analyst who is going to vibe-analyze either way and wants to be the one who catches what the model missed.

ETL: A practical guide to building data pipelines, from extracting and transforming to loading, orchestrating with Airflow, and trusting the result

This guide shows you how to build data pipelines that a business can rely on, the kind that run every night, survive a bad source, and leave the warehouse correct instead of half-updated. It starts from the shape of the problem (extract from somewhere, reshape it, load it somewhere queryable) and builds the practices that separate a pile of cron scripts from a real pipeline: how to extract incrementally instead of reloading everything, how to transform in a way you can test and that fails loudly on bad data, the ELT-versus-ETL choice and when to push the work into the warehouse, idempotency and backfills so a rerun is safe and a gap is fillable, orchestration with Airflow (DAGs, schedules, retries, dependencies, and the gotchas), data quality checks that catch the broken load before the dashboard does, and the monitoring that tells you a pipeline silently stopped. The book does not tour every tool. It teaches you to design a pipeline that is incremental, idempotent, tested, and observable, so the numbers downstream are trustworthy and a 2 a.m. failure is a retry, not an outage. For engineers and analysts who move data and want it to arrive correct, on time, every time.

VISUALIZATION: A practical guide to data visualization, from choosing the right chart to dashboards people actually read and act on

This guide shows you how to turn data into a picture that makes its point in seconds, so your analysis actually changes a decision instead of getting nodded at and ignored. It starts from the idea that every chart is an argument and builds the judgment to win it: how to choose the right chart for the question (comparison, trend, distribution, part-to-whole, correlation) instead of defaulting to a bar chart, how to use position, length, and color the way perception actually works, how to strip the chart down to its message by cutting the junk that hides it, how to use color with intent and stay readable for everyone, and how to avoid the distortions (truncated axes, dual axes, misleading area) that make a chart lie by accident. Then it builds up: designing a dashboard with a hierarchy people can scan, telling a story with a sequence of charts, and the honest line between a clear simplification and a misleading one. The book is tool-agnostic on purpose, with examples you can apply in any library or BI tool. It teaches you to make the right chart, remove what does not serve the message, and design for the reader under pressure, so your data gets believed and acted on. For analysts and engineers who want their charts to convince, not just exist.

VIBE CODING: Become the programmer AI multiplies instead of replaces, the one who brings the judgment the machine still doesn’t have

This book reveals the secret that separates the developer AI replaces from the one it makes indispensable: vibe coding is not a collection of prompts, it’s software engineering with the AI inside the loop. On that premise, the book gives a chapter to each of the eight disciplines you have to bring to the table (strong fundamentals, AI-assisted coding, system design awareness, debugging depth, testing discipline, code review judgement, product understanding, and ownership of outcomes) and shows, in each, exactly where AI fails on its own and what your judgment adds so it doesn’t. It isn’t theory: every discipline lands in concrete scenarios, and the book closes with an operational kit (the costliest mistakes with their corrected version, prompt templates, checklists for before you prompt and before you merge, real before-and-after cases, and a one-page field manual) to keep beside you while you work. For engineers early in their career who want AI to multiply their value instead of making them disposable.

SPARK: A practical guide to processing data too big for one machine with Apache Spark, from the cluster model and lazy DataFrames to shuffles, joins, skew, memory, and running a job that finishes on a real cluster

This book gives you the mental model that turns Spark from a black box that sometimes finishes into a machine you can reason about. It starts where the pain starts: a job that runs in seconds on a sample and never finishes on the real data, and why throwing hardware at it does not help. From there it builds, in the order a real job forces the questions on you, the picture of what Spark actually does when you press run: how it splits your data and your work across a cluster of machines so the pieces run in parallel, why your transformations do nothing until an action forces them and how to read that to your advantage, what a shuffle is and why the stage that should be fast is the one that crawls, why a single popular key can make one task run for an hour while the rest sit idle, when to keep data in memory and what happens when it does not fit, and how to write output that the next job and the next analyst can actually use, then run the whole thing on a cluster you do not babysit. Every idea lands on one running dataset, a music service turning a billion daily play events into the numbers that pay artists, so you see each concept fix a real, expensive failure. The book does not tour the API surface. It teaches you to look at a slow job and know where the time is going, which is the difference between an engineer who writes Spark and one whose jobs finish on time and cost half as much. For the engineer who wants big data to stop being a mystery and start being something they can size, tune, and trust.

SNOWFLAKE: Load the whole company’s data into one warehouse everyone can query, keep the bill from exploding on a single careless query, and become the person the whole team trusts the numbers from

This book takes you from someone who can query a warehouse to someone who can run one the whole company depends on. It starts where the anxiety starts, with the first bill and the first wrong number, and builds the mental model that makes both go away: compute and storage are separate, and once you see why, the way a warehouse scales, costs, and stays fresh all snap into focus. You will build one warehouse across the whole book, a real one for an online plant retailer called Aster, and take it from empty to trusted. You will load raw data into it in stages and keep it flowing with COPY and Snowpipe, model it so the queries people run every day are both fast and cheap by working with micro-partitions and clustering instead of against them, and take apart the bill line by line so you understand warehouses, credits, autosuspend, and exactly how a single careless query becomes a five-figure invoice, and how to stop it. Then you make it safe and shared: roles and grants so the right people see the right data and nobody sees the salary table by accident, and secure sharing so another team gets live data without a copy. Finally you make it trustworthy, with data-quality checks, time travel to undo the mistake you will eventually make, and streams and tasks so the warehouse keeps itself fresh without a human babysitting it. By the end the numbers reconcile, the bill is predictable, the access is locked down, and when someone asks why the report says what it says, you can answer. For the engineer or analyst who has to make a warehouse the whole company can trust, and wants to be the reason it can.

DBT: A practical guide to turning raw warehouse tables into numbers people trust, by writing your transformations as version-controlled SQL models, layering staging into marts, testing the data before it ships, and deploying it all in CI like real software

This book shows you how to turn a warehouse full of raw tables into a set of numbers a company decides on with confidence. It starts from the mess most analytics lives in: correct SQL scattered across scripts and notebooks, with no order, no tests, and no way to reproduce it. Then it builds the discipline that separates that pile from a real analytics codebase. You will learn to write each transformation as a model, a plain SQL SELECT that dbt turns into a table or view, and let the tool work out the dependency graph so your models always run in the right order. You will layer raw sources into thin staging models that clean and rename, then into marts that hold the business definitions the whole company shares, so “revenue” and “active user” mean one thing in one place. You will write tests that fail the build when a key is not unique or a value goes null, and declare contracts so a column that changes shape upstream breaks the pipeline instead of the dashboard. You will get lineage and documentation for free from the code itself, and make the heavy models incremental so a nightly run costs minutes instead of a full rebuild. It closes on shipping this like software: version control, a pull request, a CI run that builds and tests every model on a sample before it reaches production, and the analytics-engineering role that owns the seam between the raw data and the number people trust. The book does not tour every dbt feature. It teaches you to build a transformation layer that is ordered, tested, documented, and deployed, so the figure on the dashboard is reproducible and defensible instead of a query someone ran once and hoped was right. For the analyst or engineer who wants to stop being the person the number depends on and become the one who built the system it comes from.

KAFKA: Move data the instant it happens instead of waiting for the nightly batch, stop losing events and stop processing them twice, and become the person who owns the pipeline the whole company runs in real time

This book takes you from someone who can write a service against a database to someone who owns the pipeline the whole company runs in real time. It starts where the fear starts, with the lost message and the double charge, and builds the one mental model that makes both go away: Kafka is a log, an append-only sequence of events that many readers share by keeping their own place in it, and once you feel that, delivery, ordering, parallelism, and duplicates all reorganize in your head. You will build one real-time pipeline across the whole book, a real one for a ride-and-delivery platform called Loom, and take it from a single lost event to a stream the business bets on. You will lay out topics, partitions, and offsets so many services can read the same events without stepping on each other, make a producer that provably does not lose a message even when a broker dies, split a stream across a consumer group so the work parallelizes and survives a server dying mid-shift, understand exactly when order holds and when a rebalance quietly reshuffles it, and get exactly-once processing so a retry stops turning one ride into two charges. Then you move it where the analysts live, streaming events into a warehouse with Kafka Connect and reshaping them on the way with Kafka Streams, and you learn to operate the thing when it is 3am and you are asleep: reading consumer lag before it becomes an outage, setting retention so the log does not fill the disk or throw away data you still need, and knowing which number tells you the pipeline is healthy. By the end the events land once, in order where it matters, fast enough that the dashboard is actually live, and when something falls behind you see it before the business does. For the engineer who has to make data move the moment it happens, and wants to be the reason it can.

METABASE: Turn a database nobody but you can read into dashboards the whole company opens on their own, stop being the person everyone pings to re-run the same report, and become the one whose numbers the business actually acts on

This book takes you from someone who can build a chart to someone who builds the dashboards a whole company self-serves on and trusts. It starts where the frustration starts, with the dashboard nobody used and the report you kept getting pinged to re-run, and it names the thing no Metabase tutorial does: the hard part was never the charts, it was making non-technical people able to answer their own questions and believe the answer. You will build one real Metabase across the book, for a home-goods retailer called Fernwood, and take it from a raw database only you can read to a set of dashboards the sales team, the ops lead, and the CEO open on their own every morning. You will connect Fernwood’s database and model a semantic layer on top of it, so people click on friendly names and clean columns instead of guessing at raw tables, and learn where the query builder is the right tool and where you drop to SQL. You will build questions and turn them into dashboards with filters and drill-through that answer what someone actually walked up wanting to know, so ‘show me last month’ or ‘why is this number down’ is a click, not a Slack message to you. You will define metrics once, so revenue means one thing company-wide, and wire up subscriptions and alerts so the dashboard comes to people instead of waiting to be visited. And you will make it self-serve and trustworthy: permissions so the right people see the right data, embedding so a dashboard lives inside another tool, and the performance work that keeps a shared dashboard fast when fifty people load it at nine in the morning. By the end nobody pings you to re-run a report, the numbers reconcile, and the dashboards are the thing people act on. For the analyst or engineer who has to make a company self-serve, and wants to be the reason it can.

HADOOP: Process data at a scale one server physically cannot hold, understand the distributed storage and compute ideas every modern tool inherited from Hadoop, and become the engineer a large enterprise trusts with the estate everyone else is scared to touch

This book takes you from someone who has only ever run programs on one machine to someone who understands, in their bones, how data gets stored and processed at a scale no single server can hold. It is honest about where Hadoop sits in 2026: it is a mature stack, past its peak, and for a brand new project you would almost always reach for Spark or a cloud warehouse instead. But the distributed-storage and distributed-compute ideas Hadoop pioneered did not go away; Spark, BigQuery, Snowflake, and every lakehouse inherited them, and you cannot really understand those tools until you have seen the originals plainly. And there is a second reason to learn it: enormous legacy estates still run on Hadoop, in banks and telcos and governments, holding the data those businesses depend on, and the engineer who can actually operate one is rare and well paid precisely because everyone else is scared of it. You will work one real problem across the whole book, a mobile carrier called Meridian that has to turn a firehose of call and clickstream records into the numbers the business runs on, at a volume that broke the single database they started with. You will see why one machine stops being enough and where the wall actually is, how HDFS stores one file across a cluster and survives disks dying every week by keeping copies, how MapReduce expresses a computation as work that runs next to the data and where that model hits its limits, how YARN decides who gets which machine when everyone wants the cluster at once, how Hive lets you write SQL over files that are not a database and why that query is slow, and how file formats, partitioning, and columnar storage quietly turn a Hadoop cluster into the modern lakehouse that Spark and the cloud query today. By the end you will not just be able to keep Meridian’s estate alive; you will understand the fundamentals of distributed data that outlast Hadoop itself, so the next tool you learn is a variation on ideas you already own. For the engineer who has to work at a scale one server cannot hold, and wants to be the person the business trusts to do it.

CLAUDE: Stop treating Claude Code like a chatbot that happens to write code and learn to drive it like the agentic engineer it is, across the terminal, your editor, the desktop, and CI, so it ships a day’s work in an hour without leaving you a mess to clean up

This book teaches the durable skill under Claude Code: not a list of features that will have moved by next quarter, but how to drive an agentic coding tool so it does real work you can trust. It starts where the pain is (the day it saved you and the day it burned you) and then walks the seven moves that separate the operator from the person the tool runs circles around. You will set it up across every surface and know when to reach for the terminal, when for your editor, when for the desktop app, and when for the browser. You will give it the context once (a project memory file, the repo, a plan agreed before it touches code) so it stops re-asking and stops guessing. You will drive a single task the right way, reading the diff and steering, so a good change never turns into a bad sprawl. You will set permissions so it flies on the safe work and stops at the dangerous work, decide what to auto-approve and what to gate. You will run work in parallel (subagents, several sessions, isolated worktrees) without the pieces colliding. You will extend it with the connectors, hooks, and commands that make it fit your stack. And you will put it in CI so it reviews, fixes, and answers issues on its own while you are not watching. It closes on what you become once this is second nature: the engineer who ships more, trusts the output, and is worth more because the machine multiplies your judgment instead of your mess. For the engineer who wants Claude Code to feel like a real edge, not a slot machine.

OWNERSHIP: Become the engineer everyone trusts with the thing that cannot fail, by owning the outcome instead of your ticket, driving problems to root cause and to done, and closing the loop so nothing falls through the cracks on your watch

This book is about the one trait that decides whether you get handed the work that matters: ownership, the habit of taking a problem as yours and driving it all the way to a real outcome, not just doing your assigned part and hoping the rest works out. It starts from an uncomfortable truth. Being blameless is not the same as being useful, and closing your ticket is not the same as solving the problem, and the whole industry quietly promotes for the second thing while grading juniors on the first. Then it hands you the habits, one at a time, that separate the engineer people trust with the important thing from the one who is always technically not at fault. You will learn to say I’ve got it and mean the whole outcome, to chase a failure down to its real cause instead of patching the symptom, to fix the problem instead of hunting for who to blame, to run an issue to done instead of tossing it over the wall, to close the loop so people know it actually landed, and to own the boring follow-through and the gap nobody’s job covers, including the failure that is yours to fix and learn from. Each habit comes with a drill you can run this week and a clear picture of what good looks like, told through one engineer’s arc from the guy who pointed fingers to the one they hand the thing that cannot fail. It closes on what changes when problems stop falling through the cracks because they are yours: you become the person they promote, pay more, and trust with the work that decides everything. For the engineer who is tired of doing their part and watching someone else get the credit for owning the result.