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. Stacksmith 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! Most likely not! Is there room for improvement? Always! Feel free to raise a PR at any time. Always! Feel free to raise a PR Is it enough to start your learning journey? 100%! 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. yarn start In Chapter 2, I compare Linear Search and Binary Search on the same dataset. Linear Search Binary Search Linear Search checks items one by one → O(N)Binary Search repeatedly cuts a sorted list in half → O(log N) Linear Search checks items one by one → O(N) Linear Search O(N) Binary Search repeatedly cuts a sorted list in half → O(log N) Binary Search sorted O(log N) This table clearly shows how the checks change based on the data. The surprising part wasn’t the difference between Go and TypeScript. It was how insignificant that difference became once the algorithm changed. insignificant that difference became 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. O(N) O(log N) If you pick an O(N) solution where O(log N) is possible, no compiler, JIT, or runtime can save you. 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. 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 };
}); 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. useMemo 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. userDetails 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?) 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!) (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! Clone the repo: git clone https://github.com/joachimzeelmaekers/stacksmith. git clone https://github.com/joachimzeelmaekers/stacksmith Install the dependencies and run the CLI with yarn start. 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! 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. Stacksmith Clone it. Run yarn start. Race a few algorithms. Bring your own snippets. yarn start 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.

Stacks

Scale Is Not a Goal: Why Most Software Architectures Are Overbuilt

Checkout My Blog

Newsletter

The Practical Way for Developers to Learn Algorithms

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Five Years Later: Clean Code Is Still Right (But Not Always Useful)

The Recommendation Engine Behind Your Cart: Design, Build, Maintain

How to Make Engineering Knowledge Searchable (A Complete Guide)

Scale Is Not a Goal: Why Most Software Architectures Are Overbuilt

10 LeetCode Patterns to Solve 1000 LeetCode Problems

104 Stories To Learn About Go

Five Years Later: Clean Code Is Still Right (But Not Always Useful)

The Recommendation Engine Behind Your Cart: Design, Build, Maintain

How to Make Engineering Knowledge Searchable (A Complete Guide)

Scale Is Not a Goal: Why Most Software Architectures Are Overbuilt

10 LeetCode Patterns to Solve 1000 LeetCode Problems

104 Stories To Learn About Go

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps