Reinventing the Wheel

When I just started programming, I got under the influence of a popular online IT community, where “reinventing the wheel” (also called “inventing the bicycle” where I’m from) was very frowned upon - because business wants you to build features, not play code. I took that advice to heart, which was pretty easy, considering that it’s a generally accepted idea.

Everyone was smirking at the “not invented here” syndrome of Microsoft and other companies who insisted on doing their own thing, and often that smirking was for a good reason - after all, why make something crappy homemade, when there’s already a popular alternative?

I still think that’s a good idea in general, but it got to an unreasonable extreme, in particular in web development. First it was jQuery and people doing in jQuery things that could be done in vanilla JS (and I was one of those people). No hate to jQuery - it made frontend development much less of a pain than it was.

But at some point, it exploded - everything had to be plug and play, otherwise you waste valuable time on what already works. With a major caveat - a lot of those things were not something that already works. A lot of the time it gave an illusion of something that fulfills all your needs, while in reality it created almost a black box that was harder to maintain and debug, not even talking about the dependencies galore.

Now, I don’t think that we should rush and reinvent things that actually work. But my bar for that is much higher nowadays - it should be something fundamental, with minimal friction and relation to the code that we write. Ideally it should be on a different level of abstraction, i.e. not something that we’d realistically would do ourselves in the first place. For example, if you are a game developer, you probably won’t want to work with OpenGL directly (unless you always wanted to draw a lot of triangles on the screen very quickly).

Because even if we might have to spend some time building our custom wheel solution upfront, there’s a good chance that it will save us time and effort in the future, when something inevitably breaks and we go on a wild goose chase through unfamiliar code filled with features that we don’t even need.

And sometimes, the upfront investment isn’t even meaningfully different from setting that thing up. If you are like me, a recovering liboholic, try making something yourself and see that it isn’t as wild as you thought.