What Is a Developer Analyst? The Analyst Who Ships Code

A developer analyst reads and writes enough code to verify, automate, and prototype, without becoming a full-time software engineer. Code is the tool, not the job. It is the hat that makes every other kind of analysis faster.

A developer analyst is an analyst who treats code as a tool for the job rather than the job itself. They read the codebase to understand how a requirement was actually implemented, write a script to automate a check they would otherwise run by hand fifty times, query a database directly instead of asking someone to run a report, and sit in a code review able to follow what changed. They are not a software engineer, and that is the point. Their deliverable is analysis, requirements, and verified behavior. Code is simply how they get to the truth faster than an analyst who cannot read it.

I am not a developer by title, but I write code most weeks: SQL to check state, a few lines of Node or Python to chain API calls and consume Kafka events, small scripts to compare two files of payment messages. That ability has done more for my credibility on delivery teams than any certification, because it means I never have to wait for someone to tell me how the system behaves. I can go and find out. This is the single highest-leverage habit a technical analyst can build, and it is the spine of The Technical Skills Guide for BAs.

What does a developer analyst actually do?

A developer analyst uses code to verify, automate, prototype, and understand, while keeping analysis as the actual deliverable.

In practice that means four recurring activities. Verify: write a script to confirm an API returns what the spec claims, or query the database to check the state model is what the diagram says. Automate: turn a repetitive manual check into a script you run on demand, so testing a release takes minutes instead of an afternoon. Prototype: when a requirement is ambiguous, build a throwaway script that demonstrates the behavior, so the team is arguing about something concrete instead of words. Understand: read the production code that implements a feature, because the code is the only fully honest document of how the system behaves.

None of this requires you to ship a feature. It requires you to be fluent enough in code to use it as a lens. The analyst who can read the function that validates a payment knows exactly which fields are checked and in what order, while the analyst who cannot read it is stuck with whatever the spec claims, which is often wrong. That fluency is what I package into The Technical BA Prompt Toolkit, because modern coding for analysts is increasingly about directing tools well, not memorizing syntax.

Does a business analyst really need to code?

A business analyst does not need to ship production features. A technical business analyst benefits enormously from reading code and writing small scripts, because it removes the dependency on a developer to answer basic questions about how the system works.

Here is the asymmetry that makes this worth it. The cost of learning to read code and write simple scripts is a few focused weeks. The payoff is permanent: for the rest of your career, you can answer your own questions about system behavior instead of queuing them for a developer who is busy. You can verify a spec instead of trusting it. You can automate the boring parts of testing. You can walk into a code review and contribute. Every one of those compounds your credibility, and credibility is the whole career for a technical analyst.

The barrier is mostly psychological. People assume reading code requires a computer science degree. It does not. It requires sitting down with a real function, reading it line by line, and looking up what you do not know. I have watched analysts go from “I can’t read this” to debugging an integration test in a matter of weeks, and the only thing that changed was that they started. The developer analyst hat is available to anyone willing to put in that focused time, and the structured path is exactly what The Technical Skills Guide for BAs lays out.

What programming skills should an analyst learn first?

Start with the skills that pay off immediately for analysis and testing, in this order: SQL, then APIs and HTTP, then a scripting language, then version control.

SQL first, because querying state is the single highest-leverage technical skill an analyst can have. After any operation, you want to read the data and confirm what actually happened. Being able to write a select with a join and a where clause covers most of what you will ever need during analysis.

APIs and HTTP second. You read REST contracts, understand status codes, and interpret JSON. You learn to send a request and read the response. In payments this is daily work, and reading an API spec well is a skill in itself, which is why I wrote API Documentation from Scratch.

A scripting language third, Python or JavaScript. This is where automation lives: chaining API calls so one transaction proves a whole pipeline, consuming a Kafka event to confirm it fired, comparing two sets of messages, generating test data. The daisy-chaining pattern, where each request feeds the next, is the backbone of how I test event-driven systems, and I walk through it in Automate Kafka Validation with Postman.

Version control last, enough Git to clone a repository, navigate it, and read a diff. You are not managing branches for a team; you are getting into the codebase to understand it.

That is the whole starter set. Four skills, none requiring an engineering background, each one immediately useful. You build them by using them on real systems, not by working through abstract tutorials.

How a developer analyst makes the other hats faster

The developer analyst hat is force multiplication. It does not replace business, functional, QA, or systems analysis; it makes every one of them sharper.

As a functional analyst, reading the code that implements a rule means you specify from what the system actually does, not from what you assume. As a QA analyst, scripting lets you automate the end-to-end checks and chain a transaction through every hop, so you test the whole system instead of one screen. As a systems analyst, reading the code and config tells you how the services really connect, including the integrations the architecture diagram forgot. As a business analyst, the credibility of being technical means stakeholders and engineers both take your analysis seriously.

This is why Analyst Engineering treats coding as one hat in a single discipline rather than a separate career. You are not becoming a developer. You are becoming an analyst who cannot be stonewalled by “you would not understand the code,” because you can read it. The full picture of how the five hats reinforce each other is the premise of the whole technical business analyst role.

What is the difference between a developer analyst and a software developer?

A software developer’s primary output is production code. A developer analyst’s primary output is analysis, with code as the tool that gets them there.

The developer builds the feature that runs for users. The developer analyst reads that feature to understand it, writes a script to test it, and specifies the next one. Both are technical; their center of gravity differs. When a developer analyst writes code, it is usually disposable: a test script, a data check, a prototype to settle an argument. When a developer writes code, it ships and has to be maintained. Confusing the two roles leads to a common trap, the analyst who gets pulled into building features and stops doing analysis, which helps no one.

The healthy version of the role keeps code in service of analysis. You read enough to understand, write enough to verify and automate, and stay on the analysis side of the team where your real value lives. That balance is what makes the developer analyst hat sustainable rather than a slow slide into an engineering job you were never hired for.

The takeaway

A developer analyst reads and writes enough code to verify, automate, prototype, and understand, while keeping analysis as the deliverable. Code is the tool that lets you answer your own questions about how a system behaves, which is the foundation of credibility on any delivery team.

You do not need a computer science degree to wear this hat. You need SQL, APIs, a scripting language, and a little Git, built by using them on real systems. Start with The Technical Skills Guide for BAs and The Technical BA Prompt Toolkit, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Software Development, SQL, API, Career Growth, Technical Skills