From Building Software to Analyzing Data: What Carried Over
I recently made a move I had been circling for a while: from building software to a data-analyst role. I expected a hard reset, a new stack, new tools, a humbling stretch of feeling like a beginner again. Some of that was real. But far more of my old work carried over than I had braced for, and the parts that did not were rarely the technical ones.
What transferred more than I expected
The habits of engineering turned out to be most of the job.
- Thinking in systems. Tracing why a number is wrong is not so different from tracing why a function returns the wrong value; the instinct to follow data through a pipeline and distrust every hop is the same.
- Version control and reproducibility. Treating analysis like code, committed, reviewable, re-runnable, is still rare enough on the data side that it felt like a small superpower.
- SQL. I had written plenty as a developer; as an analyst it became my native language rather than an occasional errand.
- Debugging as a temperament. Data cleaning is debugging in a different coat: the same patient, suspicious, one-hypothesis-at-a-time work.
More than any single skill, what transferred was a posture: assume the first answer is wrong, make the smallest change that would prove it, and keep a tight loop between question and evidence.
What was genuinely new
The gaps were not where I expected. I had braced for the tooling and found it familiar. What actually stretched me was thinking statistically and communicating uncertainty.
As a developer, code is mostly deterministic; it works or it does not, and you can usually prove which. Data offers no such comfort. A result can be real or it can be noise, and much of the craft is telling the difference honestly: sample sizes, confidence, the line between a pattern and a coincidence. Learning to sit with 'this is probably true' instead of demanding 'this is true' was the real adjustment.
The other new muscle was narrative. A passing test speaks for itself; an analysis does not. The same finding can change a decision or be ignored entirely depending on how it is framed, what it is compared against, and whether the person hearing it trusts where it came from. I had underrated how much of an analyst's value lives in that last mile.
How each side made the other better
The real surprise was how much the two halves reinforced each other. Building products first made me a more practical analyst: I think about how an insight will actually be used, shipped, and maintained, not just whether it is correct inside a notebook. And analyzing data has made me a more careful builder, more skeptical of my own metrics, more interested in whether a feature truly moved the thing it was meant to move.
It also closed a loop I had felt for years. So many of the products I built generated data that someone else interpreted. Sitting on the other side of that handoff, I finally see how much context gets lost in it, and how much better both roles get when one person can hold both ends.
If you are thinking about the same move
My honest advice is to stop drawing a hard line between the two. The fear is that you are starting over; the reality is that you are repurposing most of what you already know and adding a layer of statistical honesty and storytelling on top. Lean on your engineering instincts, reproducibility, systems thinking, debugging, because plenty of data work is crying out for exactly that discipline.
I thought I was switching careers. It felt more like discovering the other half of one I had already been doing.
I am still early on this path, and there is a great deal left to learn. But the thing I worried about most, that none of my old work would count, turned out to be the opposite of true.