For a long time, I thought technology and finance belonged to two completely different worlds.
One was about code, APIs, databases, infrastructure and products. The other seemed to revolve around markets, capital, risk, incentives and economic behaviour.
The more I worked with technology and studied finance, however, the less meaningful that distinction became.
Both are ultimately about systems.
A software system receives inputs, applies rules and produces outputs. A financial market does something surprisingly similar, except that its components happen to be people, institutions, regulations, capital and expectations.
And people are considerably harder to debug than software.
Building things changes how you see problems
Engineering teaches you to decompose complexity.
When something large looks overwhelming, you don't solve the entire problem at once. You divide it into smaller components.
A backend application might become:
authentication,
business logic,
data persistence,
caching,
APIs,
background jobs,
observability.
A financial problem can be approached in much the same way.
Instead of simply asking:
"Is this company a good investment?"
you can break the question down.
What generates its revenue?
What determines its margins?
How efficiently is capital being allocated?
What risks could permanently damage the business?
How much of the expected growth is already reflected in the price?
Suddenly, an apparently subjective question becomes a collection of smaller questions that can actually be investigated.
Finance adds something engineering cannot: incentives
Software behaves according to instructions.
People don't.
Financial systems are fascinating precisely because participants continuously react to one another.
Investors respond to prices. Companies respond to investors. Regulators respond to companies. Banks respond to regulations. Consumers respond to economic conditions.
And then the entire cycle starts influencing itself.
That feedback loop is what makes finance both difficult and interesting.
A technically correct model can still produce a terrible prediction if the assumptions behind human behaviour are wrong.
This is one of the biggest differences I've noticed between thinking about software and thinking about markets.
In engineering, removing uncertainty is often the goal.
In finance, understanding uncertainty is the goal.
Markets are enormous distributed systems
There is another analogy I increasingly like.
A financial market resembles a gigantic distributed computing system.
Millions of participants possess incomplete information. Every participant processes that information differently and then communicates their conclusions through transactions.
The resulting price becomes something like a continuously updated consensus.
Not necessarily the correct consensus.
Just the consensus that exists at that moment.
New information arrives.
Participants update their expectations.
Prices move.
The system recalculates.
Thinking about markets this way makes concepts such as information efficiency, liquidity, volatility and price discovery much more intuitive.
Data helps. Judgment still matters.
Coming from a technical background makes quantitative approaches naturally attractive.
Give me data and I immediately want to:
structure it,
clean it,
measure it,
model it,
visualize it,
automate the repetitive parts.
That mindset is useful in finance.
But finance also forces an uncomfortable realization:
More data does not automatically create more understanding.
You can calculate hundreds of indicators and still misunderstand the business.
You can build an extremely sophisticated model around a fundamentally incorrect assumption.
You can create a beautiful backtest that collapses the moment market conditions change.
The difficult part is therefore not simply building models.
It is learning which questions deserve a model in the first place.
The intersection is where things become interesting
The areas that interest me most increasingly exist somewhere between finance and technology.
Quantitative finance.
FinTech.
Algorithmic decision systems.
Financial infrastructure.
Risk analytics.
Data-driven investing.
These aren't purely finance problems or purely engineering problems.
They require both perspectives.
The engineer asks:
Can we build it?
The finance professional asks:
Does it create economic value?
The risk manager asks:
What happens when our assumptions fail?
And perhaps the most useful question combines all three:
Can we build something valuable that continues to work when reality behaves differently from our expectations?
Learning to operate between disciplines
I don't think moving between fields means abandoning what came before.
Quite the opposite.
Every discipline adds another mental model.
Engineering contributes structure.
Programming contributes abstraction.
Product development contributes an understanding of users.
Finance contributes incentives, capital allocation and risk.
Economics adds behaviour and trade-offs.
Statistics adds uncertainty.
Together, they provide a much richer way of understanding problems.
And perhaps that is increasingly valuable in a world where the most interesting problems rarely fit neatly inside one academic department.
Still learning
This isn't a story about leaving technology for finance.
I see it more as expanding the toolkit.
There are still many things I want to understand better—markets, quantitative methods, economic systems, risk, artificial intelligence and the infrastructure connecting all of them.
For now, the objective is simple:
keep learning, keep building, and keep connecting ideas that initially appear unrelated.
Because somewhere between those connections, interesting things tend to happen.
Thanks for reading.
— SJG