Live data from Hacker News

The Code It Yourself Manifesto (2016)

pestilenz.org

1–10 of 57 posts

Re: The Code It Yourself Manifesto (2016)

#4
It is generally good to depend on well-tested, large and reliable libraries. I have done the code-it-yourself thing to smaller libraries, though. The quality of the maintenance work done on smaller libraries is by no means guaranteed. They can acquire bugs at any point in time and when they do it may be best to just replace them by home written replacements.

Re: The Code It Yourself Manifesto (2016)

#5
post #3

Doesn’t this quickly become untenable? Sure, you might be able to code some of your own tools, but what about the OS those tools run on? Hardware? Drivers?

This is kind of covered in that manifesto itself in that you only go down the road of making something yourself when the tools you use no longer match your use case.

A lot of tools will be fine or meet your goals, such as your OS. If your OS doesn't match your goals then you're left with the three options detailed. In the case of an OS, the "big" OS's probably meet most people's general computing needs. It's not uncommon to write a custom "OS" for embedded devices. Some people do feel like making their own OS and there are plenty of examples out there of them and that's perfectly fine.

Anything like this is also not written as law. Your text editor annoys you under these certain conditions? You don't have to rewrite it, fix it, or switch to another editor. If you're compelled to write a replacement, it shouldn't be stigmatized which rewriting existing software frequently is.

Re: The Code It Yourself Manifesto (2016)

#6
While I certainly would encourage and do encourage people to code (it) themselves, the claim that using that not doing so

> mean[s] endless seeking, evaluating and further deviation from our goals.

is simply not true. Only if software were written to serve ultra-particular and individual goals would that be the case.

Software is written to serve needs - of fewer or of many. And while it may serve a more constrained set of needs more optimally, it typically serves wide enough needs well enough, that the vast majority of people have most of their software needs met by software written by others (albeit with room for improvement).

Also, almost no person, even a proficient coder, has enough time and attention span to code most of the software they use. On the contrary, we absolutely and necessary _won't and can't_ code "it" ourselves, where "it" is the main bulk of software we use over the course of our lives.

----

Instead of this manifesto, I would suggest a "Write good, robust, widely-usable libraries" manifesto - because that's how other people will be realistically able to code "it" themselves when and if they need to.

Re: The Code It Yourself Manifesto (2016)

#7
post #3

Doesn’t this quickly become untenable? Sure, you might be able to code some of your own tools, but what about the OS those tools run on? Hardware? Drivers?

It _immediately_ becomes untenable, actually. It'll like telling people to "manufacture it yourself". That might be possible for a perfectly fit person living a Robinson Crusoe life in some remote region; otherwise it's just divorced from reality.

We are a social animal - "zoon politicon" in Plato's original Greek - and our activities are social. For better and for worse, we can't declare that not to be the case or claim that we want to just be "left alone".

Re: The Code It Yourself Manifesto (2016)

#8
One thing I would add is that it's much easier to appreciate existing solutions when you try to build your own. Often these "I could code something better in a day" thoughts turns into thinking "it's a tougher problem than I though".

Other times, though, either I learn something, or end up making something that is much better for me to use. I would suggest at some time every programmer try build their own limited scope library if they find existing solutions do not meet their requirements.

Re: The Code It Yourself Manifesto (2016)

#10
While I appreciate the sentiment behind this, with experience comes a sixth sense of what should be rebuilt, and what is better reused/modified. Experience also brings with it an ability to scan through foreign code and get a "feel" for how usable it is.

For example, I've chosen to replace one of the foundational data communication building blocks [1] because, after extensive research, the existing systems can't be modified to handle all of the general use cases I want handled. And it won't stop there, because I also have a number of additional requirements that HTTP won't handle (so there's also a new protocol in the works that will be based off this technology). If I could have simply modified an existing system to do what I want, I certainly wouldn't have spent the last two years on this! I've got plenty of other things demanding my attention...

[1] https://concise-encoding.org

Post reply on HN