Mathieu Eveillard

Why We Need to Reinvent the Wheel

Why We Need to Reinvent the Wheel

Here’s an exercise I’m particularly fond of and often suggest to the people I mentor: re-coding the development tools we use every day—Jest, Redux, React, and even TypeScript. Come to think of it, “re-coding” is a bit of a stretch. Let’s say instead that we’re exploring the core principle behind these tools—the gist.

A test framework in 20 lines

Jest, for example. A testing framework that actually performs three distinct functions:

The first component—and the most important one, in my view—is what’s known as a test runner. Implementing a test runner involves being able to store test scenarios in a list as functions and then execute them one after another. In other words: invoking these functions.

So, when you really look at it, it’s not very complicated. In 20 lines of code, you have a rudimentary test runner (https://github.com/mathieueveillard/jest-gist).

What’s the point?

The fun part: there’s nothing better for unwinding on a Friday evening over drinks, when the workweek is over. To each their own, I’m well aware. Maybe I should reconsider certain aspects of my life…

If you can do the more, you can do the less

This exercise is complicated because it starts from a blank slate and requires you to build a framework from scratch. In contrast, most of the development work we do on a daily basis takes place within a framework that has already been established—either by us or by others. Laying the groundwork for an application state management tool, a virtual DOM, and the accompanying reconciliation algorithm will inevitably give you a broader perspective and greater autonomy.

And since the framework doesn’t exist, how do we test our code? This exercise is exploratory—we won’t necessarily be doing Test-Driven Development (building a test runner with TDD can give you a headache 🤯). However, even without doing pure, hard-core TDD, we can draw on some of its methodological elements: identify areas of complexity, address them one by one, and above all, above all, take baby steps.

By the way, when it comes to the test runner specifically, the need to automate non-regression tests arises fairly quickly… and thus to use the test runner to test the test runner itself: “eat your own dog food!”

Reinventing to Better Understand

Beyond that, this helps demystify tools that sometimes seem a bit magical to us. But if you look closely, there’s nothing extraordinary about it: we’re doing business computing, not sending people to the Moon. The difficulty of our jobs stems mainly from the need to write code at scale—in other words, to work effectively as a team.

This exercise is similar to the small-scale simulations discussed by C. Martraire in Living Documentation: Continuous Knowledge Sharing by Design: a simplified version of a complex system, derived from a technical demonstrator or created retrospectively to facilitate understanding of that system.

Ultimately, reinventing a tool allows you to better appreciate its value. Sometimes, we hesitate to use a library for tasks that remain simple. For example, I don’t use any libraries for functional programming: not Ramda, not fp-ts, and not Lodash. Their added value seems too small to me compared to the constraints they impose. And I know this because I write monads by hand, my friend.

These exercises, similar to kata, are very educational. And who knows—perhaps they’ll give rise to new tools (at the “creation” level of Bloom’s Revised Taxonomy)?

← All posts