Self-Reliant Programmer Manifesto

Posted4 months agoActive4 months ago

yobibyte

26 points

17 comments

yobibyte.github.ioTechstory

calmmixed

Debate

60/100

Software DevelopmentDependenciesSelf-Reliance

Key topics

Software Development

Dependencies

Self-Reliance

The 'Self-reliant programmer manifesto' advocates for minimizing dependencies and promoting self-sufficiency in programming, sparking a discussion on the trade-offs between simplicity and functionality.

Snapshot generated from the HN discussion

Discussion Activity

Moderate engagement

First comment

18m

Peak period

0-2h

Avg / period

2.4

Comment distribution17 data points

Loading chart...

Based on 17 loaded comments

Key moments

01Story posted
Sep 20, 2025 at 3:36 PM EDT
4 months ago
Step 01
02First comment
Sep 20, 2025 at 3:54 PM EDT
18m after posting
Step 02
03Peak activity
9 comments in 0-2h
Hottest window of the conversation
Step 03
04Latest activity
Sep 21, 2025 at 3:04 PM EDT
4 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (17 comments)

Showing 17 comments

panny

4 months ago

3 replies

Those "over complex" code bases like curl handle a lot of edge cases. Your 300 lines of C is starting over and relearning what they already learned.

yobibyteAuthor

4 months ago

1 reply

I agree! However in many cases, these edge cases (I'm not speaking of curl now) are not needed for my personal use. E.g. if I use linux/windows/os, I do not care about how my tool behaves on the other os, I do not want to support all kind of hardware etc. If I am the only users, I can prune these use-cases (and features I mentioned in the post) significantly. E.g. I reimplement a subset of vim at the moment, I do not use LSPs or syntax highlighting in my work, I do not need to implement support for them in my editor.

panny

4 months ago

1 reply

I'm thinking of something like curl specifically where the edge case isn't your machine, it's the machine you're talking to. Can I write my own curl-like downloader in a few hundred lines of code? Yes. Is it going to work first try with a 30 year old apache file server? Probably not. Do I want something that works "good enough" which breaks when I'm in the middle of a time crunch... or do I want something production tested that's probably not going to fail on me at the worst possible moment.

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.

balder1991

4 months ago

1 reply

Yeah, I don’t think the curl example was meant as a knock against curl or advice not to use it. I think any command-line user would agree that curl is not bad or bloated software, which is what they criticize.

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.

panny

4 months ago

There's the old saying, there are three types of people. Dumb people never learn from their mistakes, smart people learn from their mistakes, and wise people learn from the mistakes of others.

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.

dwoldrich

4 months ago

Also, software is hard to write, and second system syndrome causes loads of loathing and misery even when the goal is to "do it right, aka simple, this time."

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.

g-b-r

4 months ago

and a lot of legacy baggage.

We should begin collecting and centralizing the insights learned from the development of software outside the source code of specific projects

nchmy

4 months ago

1 reply

I'm all for reducing dependencies, but why is curl, of all things, catching strays here?

Utterly bizarre rant.

yobibyteAuthor

4 months ago

I use curl as an example of a powerful and omnipresent tool that started really small. I am not advocating getting rid of curl.

entaloneralie

4 months ago

Archaeologists have discovered Sumerian cuneiform tablets which complain that software quality isn't what it used to be.

abstractspoon

4 months ago

Just another rant

bediger4000

4 months ago

The author is on to something with this essay.

austin-cheney

4 months ago

This phenomenon of bad software isn’t new. Vernor Vinge mentioned this in passing in A Deepness In The Sky.

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.

mosura

4 months ago

Good intention, lacking in detailed follow through.

g-b-r

4 months ago

I hoped it would most of all meant not using LLMs, but this is good as well

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.

BobbyTables2

4 months ago

This writing mirrors my thoughts exactly.

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!!

general1465

4 months ago

Until customer Barry chimes in that he wants "this" feature, which they are never going to use, but they are also customer who is making 30% of your whole revenue. You can either say no and give opening to your competitor while keeping your ideals, or do what they want.

View full discussion on Hacker News

ID: 45316578Type: storyLast synced: 11/20/2025, 3:38:03 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN