Self-reliant programmer manifesto(yobibyte.github.io) |
Self-reliant programmer manifesto(yobibyte.github.io) |
Have seen too many cases where 10-20 lines of code avoided the need to pull in an external library with multiple dependencies.
Ironically, I also find for anything not extremely mainstream, external libraries tend to appear more complete/functional than they actually are. Often find I end up having to fork and/or rewrite them for my use case.
Sure, some say everything should be fixed with PRs. But my technical goals and timeline constrains don’t necessarily align with the maintainer’s. So fork/rewrite it is!!
I do agree with the nature of self sufficiency. That is the start of durability. Most people find this revolting though. The goal, for most people, isn’t stuff that works properly. The goal is inclusion and comfort, a social baseline opposed to a utility baseline.
That said, sometimes we need to take on the risk and effort of making a second system. I have often thought about the relearning/doomed-to-repeat-history problem, and I wonder if software - especially some open source software - might be uniquely positioned to build a second system due to bug trackers.
The bug trackers in software like Firefox effectively capture a large percentage of a project's history and design decisions. It seems to me that the bug tracker for a projects' predecessor could lay the proper frame for its successor.
I'm willing to accept a little bloat and pass on inventing wheels myself if I can grab something reliable off the shelf. I don't think that makes me less self reliant.
We should begin collecting and centralizing the insights learned from the development of software outside the source code of specific projects
At some point we might be able to be confident that the current version of all our dependecies has been carefully reviewed by enough reliable people, but right now we're not even moving in that direction; so, minimizing the dependencies is the proper thing to do.
Utterly bizarre rant.
The point seemed to be that even a rock-solid tool like curl started out tiny — just a few hundred lines — before growing to cover all the edge cases you’re describing. It’s more about showing that you can start with something simple for your own needs and customize it without depending on someone else.
I try to choose wise, even if someone will later throw shade on me for not being "self reliant" or some other insult of the day. If my goal is to write a better libcurl, then that's what I'll work on. But that's basically a solved problem and working on that doesn't seem like the best use of my time.