A More Practical Way for Developers to Learn Algorithms
“This post shares what I learned while building Stacksmith, a small lab to understand performance benefits from algorithms in Go and TypeScript.”
There is a myth I used to believe. You might believe it too.
It sounds something like this: "I am a developer, I write TypeScript, computers are incredibly fast now, and I mostly move JSON from an API to a UI. Big O notation is for low-level engineers who write databases or do game development."
It is a comforting idea. It lets us focus on frameworks, state management, crud operations and component libraries. It suggests that performance is somebody else's concern.
I built Stacksmith to test that belief. I wanted a practical way to re-learn Data Structures and Algorithms after years of neglect, so I spent the past few months revisiting them during my personal development time at DataCamp.
I decided to read and process the theory, and translate the exercises into code. This was also the perfect opportunity to try out a different programming language, Go. To make it easier for most people to understand, I also wrote everything in Typescript, so you get to choose your preference.
Is it perfect? Most likely not!
Is there room for improvement? Always! Feel free to raise a PR at any time.
Is it enough to start your learning journey? 100%!
The Universal Laws of Speed
Stacksmith ships with a small CLI. You can clone the repo, run yarn start, pick a chapter, and watch different algorithms race each other.
In Chapter 2, I compare Linear Search and Binary Search on the same dataset.
- Linear Search checks items one by one → O(N)
- Binary Search repeatedly cuts a sorted list in half → O(log N)
This table clearly shows how the checks change based on the data.
| Dataset Size | Linear Search (O(N)) | Binary Search (O(log N)) |
|---|---|---|
| 1,000 | ~1,000 checks | ~10 checks |
| 10,000 | ~10,000 checks | ~14 checks |
| 1,000,000 | ~1,000,000 checks | ~20 checks |
The surprising part wasn’t the difference between Go and TypeScript. It was how insignificant that difference became once the algorithm changed.
Yes, Go’s Linear Search was faster than TypeScript’s in raw milliseconds.
But the gap between O(N) and O(log N) completely dwarfed the gap between languages.
If you pick an O(N) solution where O(log N) is possible, no compiler, JIT, or runtime can save you.
That’s the universal law: algorithms scale, languages don’t.
Where Bad Performance Hides In Your Code
Most of us are not writing search functions from scratch. Our actual work looks more like "fetch data, filter it, merge two arrays, update the UI". That feels harmless.
Take this very common pattern:
const activeUsers = users.map(user => {
const details = userDetails.find(d => d.id === user.id);
return { ...user, ...details };
});It is short, readable, and easy to review. It is also secretly O(N²). If both lists contain around 1 000 items, this friendly looking code performs about 1 000 000 comparisons.
On small datasets you will not notice. But on a page where users can filter, sort, or search, it starts to add up. Suddenly a simple dropdown freeze feels "mysterious". We reach for useMemo, or we blame the backend, or we start worrying that React is just slow.
If we rewrite the same code to build a small hash map of userDetails first, the cost of each lookup becomes O(1) instead of O(N). The total cost drops from roughly 1 000 000 operations to something closer to a few thousand.
| Approach | Work Done |
|---|---|
map + find | ~1,000 × 1,000 = 1,000,000 checks |
Prebuilt map (Map / object) | ~1,000 inserts + 1,000 lookups |
Same feature. Same framework. Same browser. Completely different experience for the person using it, and completely different performance.
Once you start to see patterns like this, you cannot unsee them. They appear in every language: in Python scripts, in Java microservices, in SQL queries, even in infrastructure code.
Becoming a Stacksmith
That is why I picked the name Stacksmith.
A blacksmith learns the character of their materials. Iron is strong but brittle. Steel can bend. They choose the right one for the job.
As developers we work with different materials: arrays, maps, sets, trees, graphs, stacks, queues. Each one has a character. Some are great for random access. Some are great for inserting in the middle. Some are built for fast lookups.
Stacksmith is my workbench to explore that craft:
- Around twenty chapters of exercises, from arrays and linked lists to graphs and dynamic programming.
- Every solution written side by side in TypeScript and Go.
(sidenote: the code is not production-grade, and that's fine!) - A CLI to run the algorithms, print timings, and feel how they behave under different input sizes.
- A "KB Assistant" where you can paste your own code and get a quick, human readable "Big O audit". (If it doesn't have AI, is it even real nowadays?)
The goal is not to create perfect implementations. The goal is to give you a safe place to experiment and to build an intuition for how your choices in data structures and algorithms show up in real performance.
The Dual Language Advantage
Even if you mostly write TypeScript today, I would still invite you to look at the Go implementations in the repo.
TypeScript gives you many helpful abstractions. It hides pointers and most memory allocation details. It lets you resize arrays and objects without thinking too much about what happens behind the scenes.
Go is a bit more explicit. When you build a linked list, you wire together nodes that point to each other. When you create a slice and append to it, you see how capacity comes into play.
Writing the same algorithm in both languages forces you to reconcile the two views. You start to see that the "magic" behaviour in your high level language is still bound by the same low level rules.
You do not have to become a Go expert to benefit from this. Seeing how a few core structures are built in a different ecosystem is often enough. After that, you carry the mental model with you, no matter what language you are using at work.
Why This Matters For Your Day Job
So what is the practical outcome of caring about this?
First, there is the obvious one: speed. A list filter that runs in O(N) instead of O(N²) will feel smooth on devices that are older, slower, or busy doing other things. That is a quiet kind of inclusivity. You are respecting the time and patience of your users.
Second, there is cost. On the backend, more efficient algorithms and data structures usually mean less CPU time and more throughput, which slows down the need for scaling, which in turn reduces infrastructure cost (even if it's negligible at a small scale). That might not show up on your personal credit card, but it does matter for the teams and companies that pay for the infrastructure (no matter how negligible).
Finally, and maybe the most important, it is foundational knowledge. The exact frameworks and libraries you use will change over your career. The core ideas behind stacks, queues, maps and graphs are not going anywhere.
How To Try Stacksmith
If you are curious, here is a simple way to get started:
- Clone the repo:
git clone https://github.com/joachimzeelmaekers/stacksmith. - Install the dependencies and run the CLI with
yarn start. - Pick a chapter that sounds familiar, like arrays or maps.
- Run a benchmark a few times, then change the input size and see what happens.
- If you feel brave, paste a piece of your own code into the Knowledge Base Assistant (because what's a post in 2026 without some AI attached to it?) and see what it says about your current approach.
- Note: Make sure to read the README if you wish to use this!
You do not have to go through all twenty chapters. Even spending an evening with two or three of them can give you a strong sense of how much impact "small" algorithmic choices can have.
Conclusion
Performance is not a niche concern for low level specialists. It is part of building software that feels respectful, reliable, and enjoyable to use.
You can switch languages, frameworks, or hosting platforms, and those choices do matter. But underneath all of them, the same rules still apply.
If you want a practical way to explore those rules, take a look at Stacksmith.
Clone it. Run yarn start. Race a few algorithms. Bring your own snippets.
Most of all, use it as a reminder that you do not need to become a "low-level engineer" to write performant code. You just need to take a step back to the foundation, and treat data structures and algorithms as tools in your craft, no matter which language you use.
