I started my career in accounting, tracing transactions through ledgers, reconciling discrepancies, and asking questions until the numbers made sense. It was detailed work, but it taught me something important: most businesses rely on spreadsheets in ways that are fragile and hard to manage.
Every audit revealed the same problem. Somewhere in the organization, there was an Excel workbook doing the work of a full system. Millions of dollars in business logic lived in cell references and copy-pasted tabs. Very few people really understood how it worked.
That experience led me to focus on systems rather than applications. I wanted to make the spreadsheets stop breaking.
Learning to Build Reliable Systems
I learned SQL, VBA, and later Python. Each tool I picked up was to so…
I started my career in accounting, tracing transactions through ledgers, reconciling discrepancies, and asking questions until the numbers made sense. It was detailed work, but it taught me something important: most businesses rely on spreadsheets in ways that are fragile and hard to manage.
Every audit revealed the same problem. Somewhere in the organization, there was an Excel workbook doing the work of a full system. Millions of dollars in business logic lived in cell references and copy-pasted tabs. Very few people really understood how it worked.
That experience led me to focus on systems rather than applications. I wanted to make the spreadsheets stop breaking.
Learning to Build Reliable Systems
I learned SQL, VBA, and later Python. Each tool I picked up was to solve a practical problem: making manual reporting processes reproducible and reliable. Over the next decade I moved from financial analysis to business intelligence, data warehousing, and backend development.
In every role I saw the same pattern: messy human processes trying to act like systems.
The Pattern I Kept Seeing
- Critical business logic buried in Excel formulas
- Manual copy-paste operations that break under pressure
- Reports that give different answers depending on who runs them
- Key processes that only one person understands
Why I Focus on Data Systems
I enjoy full-stack development and have built products from the ground up, including my own project, ZerodaySignal.com. Programming and building data pipelines is something I know well, and I get deeply into the technical details.
The difference is that application development can feel somewhat siloed. You build features, deploy them, and while the work is satisfying, it often doesn’t require extensive interaction with the broader organization.
Working on data systems is different. To design reliable pipelines, dashboards, and reports, I need to talk to people across the company—finance, operations, marketing, and IT. Understanding their workflows, uncovering hidden assumptions, and translating their needs into technical requirements is a huge part of the work.
I enjoy this process the most: connecting the dots between different teams, identifying the real business questions, and then building systems that answer them accurately. It’s the combination of social insight and technical problem solving that drew me to data systems.
What Data Systems Work Involves
Technical Skills
- SQL query optimization
- ETL pipeline design
- Database architecture
- Data modeling
Business Skills
- Requirements gathering
- Process mapping
- Stakeholder management
- Business logic translation
The Hard Problems Are Often Invisible
Most organizations struggle because their metrics are inconsistent or unclear. Simple questions like “How many customers do we have?” or “What’s our churn rate?” can produce different answers depending on which system you check.
These problems are rarely obvious but they slow decision-making and reduce confidence across the business. Solving them is not glamorous, but it has a broad impact.
Common Hidden Data Problems
- Inconsistent definitions: “Customer” means different things in different systems
- Timing mismatches: Reports use different date ranges or cutoff times
- Manual interventions: Someone adjusts numbers “to make them right”
- Stale data: Reports based on outdated or incomplete information
- Broken lineage: No one knows where the numbers actually come from
When these issues get fixed, the impact ripples through the entire organization. Suddenly, teams can trust their dashboards. Executives can make faster decisions. Finance can close books more efficiently.
Why I Keep Doing This Work
Building data systems combines engineering, logic, and understanding how people actually use information. Each company is a unique set of processes and systems, and the challenge is to design pipelines and models that are reliable while still supporting the way people work.
I help organizations replace fragile spreadsheets with pipelines, models, and reports they can trust. I still write code every day, but the focus is on building clarity and consistency rather than just functionality.
I chose data systems because the work matters. Applications change over time, but reliable data is the foundation for every decision in a company.
The Impact of Reliable Data Systems
Faster decisions: Teams trust their numbers and act quickly
Reduced errors: Automated processes eliminate manual mistakes
Better collaboration: Everyone works from the same source of truth
Scalable growth: Systems grow with the business instead of breaking
The Choice That Keeps Paying Off
Every organization I’ve worked with has had the same fundamental challenge: they’ve outgrown their spreadsheets, but they don’t know how to replace them. The technical solution is often straightforward—build a database, write some queries, create automated reports.
The harder part is understanding the human side: how people actually use the data, what decisions they’re trying to make, and how to design systems that fit into their workflows rather than disrupting them.
That’s why I chose data systems over pure application development. It’s not just about the code—it’s about building bridges between technology and the people who need reliable information to do their jobs well.
💡 The Bottom Line
I could have focused on building user-facing applications or working on cutting-edge algorithms. Instead, I chose to focus on the unglamorous but critical work of making sure organizations can trust their data. It’s the foundation that makes everything else possible.