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)

Binary vs Linear Search

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.

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.

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.

In this post, I will go over some of the rules that you can apply to improve your code. All code samples are Javascript.

I find that Readable code is maintainable code.

The goal for me as a developer is to write quality code. Every developer on the team, regardless of their skill level, has to be able to understand the code by reading it. This helps young developers to be more confident in writing code.

Remove unnecessary code comments

Of course, some code can be very complex. I know that and I have seen that many times. Here where I would add proper documentation and code comments. Don’t get me wrong. I’m not a fan of code comments or in Javascript JSdoc. Or at least not as long as I don’t need them.

I don’t need any comments to read that this function takes X amount of arrays and merges them together into a new array.

function mergeArrays(...arrays) {
  let mergedArray = []
 
  arrays.forEach(array => {
      mergedArray = [...mergedArray, ...array]
  })
 
  return mergedArray
}

Adding JSdoc to this code does not improve the readability. I expect that my team members know what the spread operator is. And if they don’t, they should ask about it during the code reviews.

And let’s not forget the commented code blocks. Only one solution for that: DELETE THAT CODE. Git has the amazing feature to checkout old code, so why leave it in the comments?

Please stop making a junkyard of your codebase.

Focus on naming

If you look at the name mergeArrays, it should be very clear that this function combines X amount of arrays into a new one.

I know that naming things is hard. And the more complex the function, the harder the naming part will be… I use a rule to make naming easier for myself. Here’s how I do it.

Imagine a function that merges 2 arrays of numbers and generates a new unique list of numbers. How would you name it? Something like this?

function mergeNumberListIntoUniqueList(listOne, listTwo) {
  return [...new Set([...listOne, ...listTwo])]
}

The name is not that bad, because it does what it says. The problem is that the function is doing 2 things. The more a function does, the more difficult it is to name it. Extracting it into 2 separate functions will make it much easier and more reusable at the same time.

function mergeLists(listOne, listTwo) {
  return [...listOne, ...listTwo]
}

function createUniqueList(list) {
  return [...new Set(list)]
}

Of course, it’s easy to create a beautiful one-liner without calling a new function. But sometimes, one-liners are not that readable.

If statements

I could not find a name for this problem… See! Naming is hard…

But I see this a lot.

if(value === 'duck' || value === 'dog' || value === 'cat') {
  // ...
}

By doing this, you create a readable piece of code that looks like an English sentence.

const options = ['duck', 'dog', 'cat'];
if (options.includes(value)) {
  // ...
}

If options include value then …

Early exit

There are a dozen ways of naming this principle, but I picked the name “Early exit”. So let me show you a piece of code. I’m sure you saw something like this before.

function handleEvent(event) {
  if (event) {
    const target = event.target;
    if (target) {
      // Your awesome piece of code that uses target
    }
  }
}

Here we are trying to check if the object event is not falsy and the property target is available. Now the problem here is that we are already using 2 if statements.

Let’s see how you could do an “early exit” here.

function handleEvent(event) {
  if (!event || !event.target) {
    return;
  }
  // Your awesome piece of code that uses target
}

By applying the “early exit” here, you check if event and event.target is not falsy. It’s immediately clear that we are sure that event.target is not falsy. It’s also clear that no other code is executed if this statement is falsy.

Destructuring assignment

In Javascript, we can destructure objects and arrays.

According to the documentation, found on developer.mozilla.org, the destructuring assignment syntax is a JavaScript expression that makes it possible to unpack values from arrays, or properties from objects, into distinct variables.

Some code samples

// Destructuring an object
const numbers = {one: 1, two: 2};
const {one, two} = numbers;
console.log(one); // 1
console.log(two); // 2

// Destructuring an array
const numbers = [1, 2, 3, 4, 5];
const [one, two] = numbers;
console.log(one); // 1
console.log(two); // 2

The problem with destructuring is that it sometimes creates a bad name for a property. The perfect example is fetching data from an API and receiving a response object which has a data property.

const url = "http://localhost:8080/api/v1/organizers/1"
const response = await axios.get(url)
const {name} = response.data

This code sample indicates that you are fetching an organizer with id 1. The organizer object has a name, and you destructure it. Nothing wrong with that.

This code works and is fine. But why is the name still name? Will that be the only name property in the whole scope? And from which object is it the name again?

Avoid these questions by renaming the property.

const url = "http://localhost:8080/api/v1/organizers/1"
const response = await axios.get(url)
const {name: organizerName} = response.data

This code becomes more readable. Everyone will know that the variable is the name of the organizer.

The boy scout rule

Ever heard of the phrase: “Leave it better than you found it”?

Well, this is exactly what the boy scout rule is. Leave the code better than you found it. Did you find a code smell? Refactor it! Did you find an unused variable? Remove it!

I like to compare it with a room cleaning situation. Let’s imagine that everyone in your house leaves the dishes on the sink, puts all garbage in the hallway, and leaves all the laundry in the bathroom. But every Sunday, you have to clean up the whole house and it takes well over 4 hours. Would you like that?

I’m sure that the answer is no. So if everyone immediately cleans up little parts of the house, the work will be smaller on Sunday.

This is the same with codebases. If every small code smell is left in the codebase, no one deletes unused variables, the linter is going crazy and has about 77 warnings. There will be a lot of clean-up to do, but if everyone takes his responsibility and applies the boy scout rule, a lot of the problems will be solved.

Code style

Last but not least. Determine a code style in your team.

I don’t care if you like single quotes or double quotes, spaces or tabs, trailing comma or no trailing comma. Pick 1 style and stick to it. You can do this with a linter and/or a prettier.

There are so many tools to use to fix this kind of issue. My favorite is a pre-commit hook using Husky. Prettier also has a page in their documentation about pre-commit hooks.

This pre-commit hook always runs the configured command before every commit. If you configure it in the correct way, it runs the prettier and applies all the rules on all files. This makes sure that the team always has the same code style without any bad code.

Conclusion

I know that some rules are obvious and others are not. But as a full-time developer, I get to work on different codebases. The importance of these rules only become clear in larger codebases. But that doesn’t mean that you should not apply it in your smaller projects. Improving your code quality will help you to be more efficient in your smaller projects. It will also help your team with reading the code and approving your pull requests. As I said, readable code is more maintainable, but it also has many more advantages.

If you wish to learn more about clean code, you should read Clean Code by Robert Martin. If you like my content, make sure to follow me on Twitter where I post all the links to the blogs I release. I try to release 1 every week on various topics.