Developer Analyst
A developer analyst reads code, writes SQL, and debugs production instead of waiting on someone who can. This pillar covers that craft in practice: querying the database to find the truth, reading an API contract without a developer, tracing one transaction through production logs, and using Git, Python, and regex to automate the work you repeat. Written for analysts who want to contribute well beyond requirements, with skills you can apply on your next ticket.
What slowly changing dimensions are, how SCD Type 1 and Type 2 differ, how a Type 2 table works with valid_from and valid_to, and how to query it correctly.
Smoke testing proves the build is testable, sanity testing proves a fix landed, regression testing proves nothing else broke. How the three differ and when each runs.
What SQL window functions do and the three patterns analysts use daily: ROW_NUMBER for latest record per group, LAG for event timing, SUM OVER for running totals.
Airflow schedules tasks; Dagster declares the data assets those tasks produce. What the task vs asset split means for lineage, testing, and debugging pipelines.
A business analyst describes intended behavior; a technical BA verifies it against the running system. What separates the roles and how to cross the gap.
Data engineers build the pipelines and platforms that move data; analytics engineers model it in the warehouse so it means something. The split, explained.
A data mesh decentralizes data: domains own and publish their data as products, on a self-serve platform, under federated governance. Explained with a diagram.
A dbt DAG is the dependency graph of your transformations, built from ref() calls. How to read one, the staging to marts convention, and why tests live on nodes.
dbt and SQLMesh both turn SQL into tested, versioned transformation pipelines. Where they differ: SQL parsing, environments, incremental state, and lineage.
Both write code against the same systems. The backend developer owns the production system; the developer analyst uses code to verify and automate analysis.
Fivetran and Airbyte both move source data into your warehouse. They differ on openness, hosting, pricing, and who fixes the connector when the API changes.
Kimball builds dimensional marts first and integrates through conformed dimensions; Inmon builds a normalized enterprise warehouse first. The classic debate, mapped.
A warehouse is a managed analytical database; a lakehouse adds warehouse guarantees to open files on object storage. The real differences, with a diagram.
Looker is a code-defined semantic layer that governs metrics; Tableau is the strongest visual exploration tool. What each optimizes for and when each fits.
The medallion architecture organizes a lakehouse into bronze (raw), silver (cleaned), and gold (business-ready) layers. What each layer owns, with a diagram.
Medallion and Data Vault answer different questions: medallion says how many quality layers, Data Vault says how to model history inside them. With diagrams.
A QA analyst derives what must be tested from requirements and risk; a test engineer builds the automation that runs it at scale. The split and the overlap.
Snowflake and BigQuery are both elastic cloud warehouses. They differ on compute models, pricing units, cloud lock-in, and the knobs your team must operate.
Star and snowflake schemas differ in one thing: whether dimensions are denormalized. What each looks like, when each fits, and how to read one. With diagrams.
A systems analyst maps how systems connect and behave; a solutions architect decides how they should, and answers for it. The line, the overlap, and the jump.
A self-assessment matrix of 25 skills across the five technical analyst hats, with three levels per skill and where to build each one. Original to this site.
Both are technical; the deliverables differ. A technical BA ships verified understanding and specs; an engineer ships production code. Which seat fits you.
A practitioner guide to API testing: status codes, response schemas, request chaining, authentication, error contracts, and the checks that actually catch defects.
What contract testing is, how it differs from integration testing, and how consumer-driven contracts catch breaking API and event changes before they reach production.
What a data dictionary is, how to build one, and why a single authoritative definition of every field prevents the ambiguity that breaks integrations and reports.
Field notes on going from intimidated to fluent with OpenAPI: what confused me, what clicked, and how reading the contract myself changed how I work as an analyst.
The Git an analyst actually needs: clone, navigate, read a diff, browse history, and find when behavior changed. Read the codebase without breaking anything.
An analyst's guide to HTTP status codes: the 2xx, 4xx, and 5xx families, what each common code means, and why 202 vs 200 matters in payments. Practical, not exhaustive.
How to test idempotency in APIs and event consumers: idempotency keys, duplicate requests, redelivered events, and the race conditions that cause double processing.
The integration patterns that wire systems together: request-response, messaging, publish-subscribe, request-reply, batch file transfer, and webhooks. With payments examples.
How an analyst reads JSON: objects, arrays, nesting, and types. Understand API payloads, event messages, and config without asking a developer. Practical, not theory.
A practitioner guide to testing Kafka: consuming events in a test, asserting schema and key, verifying ordering, duplicates, and the consumer side effects that matter.
The production support skills that make a technical analyst invaluable: triage, tracing transactions, reading logs, calm under pressure, and turning incidents into requirements.
How an analyst reads an API contract: endpoints, methods, request and response schemas, status codes, and OpenAPI structure. Understand any API without asking a developer.
Field notes from a major payments incident: how reading logs under pressure works, what the trail revealed, and the lessons about observability that became requirements.
How an analyst reads production logs to understand and debug a system: correlation ids, log levels, searching by transaction, and following one request across services.
The regular expressions an analyst actually needs: matching patterns in logs, validating formats like IBAN and BIC, and searching data. Practical regex, not theory.
How to do regression testing in payment systems: what to retest, building a regression suite, risk-based selection, and automating the checks that protect live behavior.
How an analyst uses Python to automate repetitive checks: calling APIs, comparing files, querying data, and chaining requests. Small scripts, large leverage.
The SQL a technical analyst actually needs: SELECT, WHERE, JOIN, GROUP BY, and reading state during analysis and testing. Not for reports, for finding the truth.
Synchronous and asynchronous communication differ in whether the caller waits, and that choice shapes coupling, latency, resilience, and the customer experience.
A developer analyst reads and writes enough code to verify, automate, and prototype, without becoming a full-time engineer. Here is what the role does in payments.
A QA analyst proves a system behaves correctly by testing it end to end, not by reading the spec. Here is what the role does in banking and payments.
A systems analyst maps how services, messages, and data flow across a system so the pieces work as a whole. Here is what the role does in banking and payments.
Why testing a payment flow end to end teaches you the system and the UX better than any diagram: microservices, Kafka, the database, logs, and pain.002.
Newsletter
Practical, no-fluff playbooks for technical analysts who analyze, code, test, and support. New articles straight to your inbox.
No spam. Unsubscribe anytime.