Doing Something That's Never Been Done Before

> So if you want to truly do something that no one has done before, do something obscure, do something time-consuming, do something difficult, and do something that has unknowns you’ll only resolve once you complete the first bits.

This is an excellent checklist for doing something novel, but it doesn't provide any guidance towards doing something valuable that's original.

I don't think anyone has tried to build an ocean-going floating platform for raising wolverines for the pet trade, and that certainly checks everything on the checklist. Likewise composing a seven-part symphonic cycle written for bagpipe, slide whistle, and djembe with aleatoric and audience-participation components. Or inventing a way to knit edible garments out of extremely gluten-rich pasta. Training ravens to play Roblox games.

But are those worthwhile projects? I suppose there's only one way to find out.

Throwing yourself at something that's never been done is fun.

But know what's really fun? Taking something that's been done before, has been forgotten about, and can be iterated on with your own spirit. There's so much exploration to be done.

I don't really get the need for originality here. Why does it matter if someone else has done the thing too?

I never found myself in fear that I’m doing something unoriginal. However, I do find myself worrying I'm doing something a better resourced competitor is also working on. Most things worth doing are actually quite obvious. The determining factor in success is execution, not originality.

I started building something pretty obscure about 14 years ago; https://socketcluster.io/ an open source, WebSocket-based RPC + pub/sub library with a focus on in-order async stream-processing with backpressure monitoring.

It didn't start out like that. Initially, it was just another WebSocket library with a focus on making it easier to scale to multiple processes.

It's kind of mind-bending to me though that it still feels like it's "too early." You'd think that the ability to efficiently process RPCs and pub/sub messages from clients whilst maintaining ordering would be critical... Yet if you look around the industry; callback-based event handlers are still the norm for most application logic and people are still not using queues where they should be. People think of queues as some expensive/bulky system with overhead which requires additional architecture (e.g. RabbitMQ, Kafka, STOMP, NSQ) and always requires exactly-once delivery, they have not tried to make the idea a core part of their application logic. Software today is FULL of race conditions because of this blind-spot. Yet I still cannot communicate my message. It's too difficult to explain the benefits.

Is not about doing something never been done before. Feels more like doing something that can be sold, because else there could be legal problems, competition, captive markets and so on. That is about the current state of the world, not yourself.

You can't know everything that has been done in the past, or is being done and finished before you ended. But as far as you are not just cloning something that you already seen working, you can explore what you are capable of doing, for the sake of it, for the experience of doing it and make it work, for the things that you think are useful or nice or whatever in what you did.

And if all that effort don't end in something that can be sold, you still grow through the process. You are not ensured commercial success even if you try something truly new. But maybe that is not always a bad thing.

[dead]

[dead]