Hacker News Reader

Comment by shanebellone | Hacker News Reader

"don't reinvent the wheel"

The single worst piece of advice that I consistently see repeated.

If you're product is a bunch of APIs, you're a user not a maker.

Then, where does being a "maker" even start? One will always end up using something someone else created, or discovered, whether it is a library, a language, an OS, hardware... Even if you build your own computer from scratch using materials you gathered, you still did not "create" the raw components, did you?

All of this is only but a paraphrase of this famous quote from Carl Sagan: "If you wish to make an apple pie from scratch you must first invent the universe"

Ironically it takes some pragmatism to accept that this is an instinctual thing. If you saw that a baker was just reselling baked goods from a supermarket you would not call them a baker, but you would be happy with them purchasing flour.

Proposal: Being a "maker" starts when one's addition —the stone one brings to the soup— is both novel and useful.

(the systems integrator may be doing something useful —certainly something lucrative!— while hardly novel; the shade-tree github'er probably has a directory full of explorations that are novel but not —at least not yet?— useful...)

IDK, I definitely don't consider novelty a requirement. Someone who makes a chair or a machine like https://www.youtube.com/watch?v=EgTnfTqycV0 is clearly a maker even if they're just making what many others have already made before; arguably the embodiment of the maker spirit is making something yourself even if someone else's solution is both available and more useful.

Is Frankenstein human? Configuration is not creation.

Whether Frankenstein is human or not is the question directly asked by Mary Shelley's book. As in our "making or not" problem, ironically, the answer is neither black nor white, as the monster is alive, yet made of dead flesh, and can be cruel, yet display human-like sensibility.

My point is that the line is blurry. "Configuring" a system with a large amount of parameters can be considered "creating something". A good example is how the knobs on a synthesizer can be tweaked to achieve a peculiar sound.

This is an interesting point. I believe the example provided might offer additional insight if rephrased.

Does the producer create music or simply refine it? Does the answer change when the recording artist is also the producer? What if the artist is not the producer or composer?

Being a "maker" starts when you want to existentially vanish whatever is providing you the interface, whichever that is, from copper wires, to a hacky Chinese PLC software which works only in Windows XP SP 1 with the manual translated to English by a word randomizer, to a fancy GraphQL API. And if your current interface is not hurting you, making you to want to hurt it back, remove it from existence altogether and start from scratch, one layer deeper in the stack, well, you are not a maker. And that is fine, enjoy your interface.

I agree with this. The inevitable conclusion of my focus is a bare metal implementation.

Manufacturers value supply chain; so too should tech. If it's not your advantage, it's likely a disadvantage. Own your stack.

'Don't reinvent the wheel' is a big reason I've put off almost all side projects that I've wanted to do. Everything I've thought of, someone else has already written, and it's quite demoralising. I end up thinking, 'what's the point?'

Keep in mind economic leverage is never a frontend feature. Gold is always buried.

If you cannot yourself come up with a truly original idea, consider this; There is always the opportunity and option to do a thing better than it's been done before. Choose a thing that excites you, but you see possibilities for improvement, or a unique way of doing it that may be better than those who have gone before. "Stand on the shoulders of giants" if that benefits you, but do it in the way that only you can do.

If you can't reinvent the wheel on company time, I would urge you to try and do it on your own time. You don't necessarily have to use the solution you come up with, but it helps to get a deeper understanding of the code beneath the libraries you use. Using this technique definitely made me a better developer when I was younger. I still like to take small portions of libraries I use and try to code them myself, just to get a better feeling for how things work (even if the code is vastly different from the library I use).

> on company time

Heh, I wish I had 'company time'. I am a final-year undergraduate with a mediocre GPA and no job offers. Ergo all my time is 'own time', and most of what I do is interview preparation by grinding Leetcode problems.

And what's the problem with that? You're a technology integrator, solving problems and getting paid. That's what engineers do, and customers want robust and maintainable solutions more than creative ones.

Making things is great, but some problems already have solutions everyone mostly likes.

Reply on news.ycombinator.com