Show HN: Pinggy – A free RSS reader for the web (pinggy.com)
4 points by vasanthv 10h ago 0 comments
Show HN: MP3 File Editor for Bulk Processing (cjmapp.net)
27 points by cutandjoin 2d ago 17 comments
The curse of knowing how, or; fixing everything
342 Lunar5227 144 5/6/2025, 6:01:23 AM notashelf.dev ↗
I have many ideas that I want to build, but I'd have to learn new languages, yet I just can't sit and go through the documentation every day like I should. Still haven't finished the rust book.
The other way is start building already, and if you come across a block, then learn about that thing and move on, but I feel uncomfortable having gaps in my knowledge, AI exists but I don't want to use it to generate code for me because I wanna enjoy the process of writing code rather than just reviewing code.
Basically I'm just stuck within the constraints I put for myself :(, I'm not sure why I wrote this here, probably just wanted to let it out..
I've written a lot of Rust. I've read less than half of the Rust book. Your competence in Rust is a function of how many lines of Rust you've written; getting to the point you can start working with it is more important than completing the book. Jon Gjengset's videos were really critical for me there, seeing how he worked in Rust made it possible for me to develop a workflow. (I broke down what I learned in more detail at one point [1].)
Rust is an example I've honed in on because you mentioned it and I related to it, but this is broadly applicable. Dare I say, more broadly than just programming, even.
(Also, note that I'm a giant hypocrite who shaves yaks and struggles with perfectionism constantly. I learned Rust 5 years ago to start a project, and I've written 0 lines of code for it. If I sound critical, that's my self criticism leaking through.)
[1] https://news.ycombinator.com/item?id=38020654
> I've written a lot of Rust. I've read less than half of the Rust book.
Just knowing that there's someone out there who has worked like this or has been in the same situation gives me enough confidence to go through it!(the just write code part)
I've gone through so many resources (including the book) and I never managed to finish any of them. But I think now I need to get comfortable with having gaps and just start writing code and not be afraid of writing non-idiomatic rust code, atleast for now.
I speak it without an accent, but not at Ph.D level.
As to home projects, that's pretty much all I do, these days, ever since I "retired"*, in 2017.
I'm quite good at what I do, and generally achieve every goal that I set, but, since I'm forced to work alone, the scope needs to be kept humble. I used to work as part of a worldwide team, doing some pretty interesting stuff, on a much larger scale.
But what's important to me, is that I do a good job on whatever I do. Everything I write, I ship, support, and document, even if it isn't that impressive. The bringing a project to completion, is a big part of the joy that I get from the work.
* Was basically forced into it
I only tend to use AI for assistance, but for me at least it's easier to get started this way than to start with an empty source file.
I like this a lot. I told someone once I avoid documentation like the plague and it just didn't have the same poetic ring as this line.
Sometimes you need to dive in, other times you need to hobble together something to step over
There is two things I validated from reading Barbara Oakley and Kató Lomb is that a) it's okay to be a slow learner b) it's okay to learn differently.
Just do your thing.
Understanding why I feel this, when I have, has always proven enlightening. I find it never has to do with the gap or what would fill it.
I don't understand why so many people suddenly started to insist on taking this all away, and they totally seriously proposed to become a janitor of a hallucinated output of some overhyped tool. That's the most frustrating thing one can imagine about programming, yet people insist on it.
With AI there's nothing to be ashamed of as it is "what you can dream of, you can get today". There's not much left in programming in most of the projects (that are just repeated code, output, what not over and over) after AI , tools are just too powerful today.
you shouldn't write code until you know someone is willing to buy
i'd say somewhere between 20 < n < 100 for B2B makes sense, rather than 1000
Why? Why, specifically, do you "have to learn new languages"?
So, sure, I can see that, for some product, you might need to learn a new tech (say ... some specific AWS/GCP/Azure service), or perhaps a new configuration language (YAML, TOML, whatever).
And, sure, for some ideas (for example a mobile phone app) you're forced into that specific ecosystem.
Other than the mobile exception above, why do you need to learn a new language to build your idea? There is nothing stopping you from implementing your idea in (for example) Python. Or Javascript. Or Java, C#, C++, etc.
A programming-language-barrier absolutely does not stop you building your idea.
You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
Except there is, my brain :), that's one of the constraints I'm talking about, I'm a frontend web dev and I only know JS/TS, and like some frontend web devs, I'm enamored by Rust because it seems so different. I already use JS/TS at work so I want to use something else for my personal projects. So I definitely would have to learn something new.
> You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
If I was only interested in building my idea, I'd have just used what I know and used AI to accelerate the process. However for me the journey is also important, I want to enjoy thinking and writing code (and this project is something only I'd use, so there's no hurry to release a prototype). The problem is I want to start writing code right away, but that has the issue that I've mentioned above (gaps in knowledge).
Nobody is at fault, other than me for setting these constraints for myself. I know the solution is to just suck up and go through the rust book, read a chapter daily and eventually I'd have all the concepts in my head that I can then just focus on writing the code. But whenever I go about doing this, my mind always persuades me that there must be a better way, or it finds some flaws in my current approach and so on. So I need to learn how to not listen to my mind in such cases, and stick to the goal that I set.
Edit - After reading a reply to my comment, I've decided to just start writing the code and not worry about having gaps, anytime I start having doubts again, I'd go through this comment thread
No. The solution is to skip Rust and choose Java, C# or Go. Rust has a steep learning curve and if you project can tolerate a GC, there is next to no return for using Rust.
Instead of spending the next 6 months (for most people it's longer) to learn Rust, spend the next week getting to grips with C# (or Go, or Java) instead.
Even if you need to really shoehorn a component of the system in, just make a note about it and keep building. When you're done, you can go back and focus on replacing that one piece.
My view is that you learn a lot through the process of building this way.
I heard someone say "epistemic humility" the other day to mean fallibilism [0] and the conversation got interesting when we moved on to the subject of "what one can and should reasonably claim to know". For example: should cops know the law?
Not every programmer needs to be a computer science PhD with deep knowledge about obscure data-structures... but when you encounter them it's a decision whether to find out more.
Integrity is discomfort with "hand-waving and magical" explanations of things that we gloss over. Sure, it's sometimes expedient to just accept face-value and get the job done. Other times it's kinda psychologically impossible to move forward without satisfying that need to know more.
Frighteningly, the world/society puts ever more pressure on us to just nod along to get along, and to accept magic. This is where so much goes wrong with correctness and security imho.
[0] https://iep.utm.edu/fallibil/
I grew up in a datacenter. Leaky air conditioners and diesel generators. Open the big doors if it gets too hot.
Everything, everywhere, is greasy and lousy and half broken. Sysadmins, we accept that everything is shit from the very beginning.Then you see the real world and you think it must be because people are stupid, the bosses are pointy-haired, they don't understand, they don't value elegance, they are greedy, they etc. etc. But once you spend enough time on your own projects, and they evolve and change over the years, they turn more and more into a mess, you rewrite, you prioritize, you abandon, you revive, and you notice that it goes much deeper than simply laziness. Real solutions depend on context, one caching algo is good when one medium is x times faster than another, but not when it's only y times faster. It makes sense to show a progress bar when downloading a file if the usual internet speed is X but not when it's Y. Over years and decades the context can shift, and even those things can change that were only silent assumptions of yours when you made the "perfect" program as a young'un, looking down on all the existing "messy" solutions that do a bunch of unnecessary cruft. It's an endless cycle...
I don't really agree with this. Yes, it gets outdated quickly and breaks often if you build it in such a way that it relies on many external services.
Stuff like relying on "number-is-odd" NPM package instead of copy-pasting the code or implementing it yourself. The more dependencies you have, the more likely it will break.
If your software works locally, without requiring an internet connection, it will work almost forever.
Now, if you want to keep developing the software and build it over a long period, the secret is to always keep all dependencies up-to-date. Is there a ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
> ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
Is, to me, almost the same sentence as
> Every solution you write starts to rot the moment it exists
If you build it once, and the existing functionality is enough (no plans to add extra features ever again), then you can remove all external dependencies and make it self-contained, in which case it will be very unlikely to break in any way.
As for the security aspects of not updating, with the proper setup, firewall rules and data sanitization, it should be as secure 10 years later as any recently developed software.
This doesn't mean we shouldn't try to make it as good as we can, but rather that we must accept that the outcome will be flawed and that, despite our best intentions, it will show its sharp edges the next time we come to work on it.
Yes, prototypical school stuff like Pythagoras are "eternal" but a lot of math is designed, and can be ergonomic or not. Better notation can suggest solutions to unsolved problems. Clumsy axioms can hide elegant structure.
The only problem with this approach is I've gone from hating the thought of programming after work to coming up with side projects at work.
However, like every other solution built by Nature, this one also works through pain, suffering and death. Nature doesn't care if you're happy, nor does it care if you're suffering. And it especially doesn't care if your suffering is a low-burn, long-term pain in the depth of your heart.
So yeah, having kids will force you to make choices and abandon frivolities, in the same way setting your house on fire will free you from obsessing over choices for unnecessary expenses :).
But then I look at my son, and say "screw it, they couldnt pay me enough to care out of hours and give up play time"
I, for example, would perhaps not be a bad parent, but very likely at least one who does not obey the social expectations of how to raise a child.
My free time is to be spent on other things, I get paid to fix issues and that pays my bills, I don't want nor need to be thinking about these issues outside of paid hours, you know too much to the point where you know how much effort it will take to fix something that might look innocuous, innocent, but definitely has deep tendrils of other related issues to tackle. It's not worth it, not if I'm not being paid for it or it isn't part of a personal project I'm really passionate about.
So I learnt to not care much, I help my colleagues, deliver what I tell I will deliver, and free space in my mind to pursue other more interesting stuff to me.
This can actually make things (much) worse:
Since you have now another topic you are insanely passionate about, you see a lot of additional things in the world that are broken and need fixing (though of course typically not via programming).
Thus, while having a very different additionally hobby (not or barely involving programming) clearly broadens your horizon a lot, it also very likely doubles the curse/pain/problem that the original article discusses.
The script I made for deployment, because existing solutions didn't "feel" right, required a lot of work and maintenance when we later had to add features and bug fixes.
Another script I made for building and deploying Java applications, because I didn't like Maven and Puppet.
The micro service I rewrote because I wanted to use my own favourite programming language. I introduced a lot of bugs that were already fixed, missing features and another language for my co-workers to learn when they inherited the application when I left.
It is a rare and wise insight which only becomes crystal clear with age. Choose your battles very carefully.
This is a golden nugget up there with "time flies". I never understood that as a kid but really hits hard with your mid-life crisis.
Listen carefully little grasshoppers.
No comments yet
My honest, brutal answer is: "Your problem is very likely self-inflicted. Buy a decent Brother laser printer."
This attitude resolves you of nearly all such requests. :-)
https://en.wikipedia.org/wiki/Serenity_Prayer
Each time you set about to make a single change ask what is the probability (p) that this change results in another change, or track this probability empirically, then compute 1/(1-p) this will tell you how much change you should "expect" to make to realize your desired improvement. If you have n interacting modules compute 1/(1-np). This will quantify whether or not to embark on the refactor. (The values computed are the sum of the geometric series in the probability which represents the expectation value)
So this is about how we manage change in a complex system in order to align its functionality with a changing environment. I suggest that we can do so by considering the smallest, seemingly innocuous change that you could make and how that change propagates through to the end product.
In the end, a solution may be to make systems that are easy and painless to change, then you can change them often for the better without the long tail effects that drag you down.
E.g. you figure it'll take a minute to take the trash out and wash your hands. But on the way you discover you run out of trash bags, and while washing your hands you run out of soap, then as you pick the refill bottle from storage some light items fall out, and you need to put them back into a stable configuration, then you spilled a bit of soap during refilling so you need to clean up, but you just run out of paper towels, and...
Letting go is probably most people's answer - nothing bad will happen if I do all the dependent tasks (cleanup, restocking things that just run out) later in the day - but I have difficulty getting them out of my head, they keep distracting me until they're completed.
Structure, order, habits.
> I have written entire applications just to avoid thinking about why I was unhappy.
I think this is true too. The prefrontal cortex is inhibitory to the amygdala/limbic system; always having a project you can think about or work on as an unconscious learned adaptation to self-calm in persistent emotionally-stressful situations is very plausible.
I wonder how many of us became very good at programming ~through this - difficult emotional circumstances driving an intense focus on endless logical reasoning problems in every spare moment for a very long time. I wonder if you can measure a degree of HPA-axis deregulation compared to the general population.
And whether it's net good or net harmful. To the extent that it distracts you from actually solving or changing a situation that is making you emotionally unhappy, probably not great. But being born into a time in which the side effects make you rich was pretty cool.
This, but with proper balance. TBH, you can live a happy life if you just stop caring about every technical problem, but that would make you unimaginative and passive. Just make sure your pick a hole (or two) you're gonna die in.
It's not only that solutions decay, though that's true, but also that the search for improvement itself becomes recursive.
When you identify something can be improved, and fix it, your own fix and every individual step of it now become the new thing that can be improved. After the most fleeting of pauses to step back and appreciate your work, this becomes your new default.
Indeed I often look back at my own solutions and judge them more harshly than I would ever judge anyone else's. Why? Because as the article says, I know much more about how it works. Cracks increase surface area by a lot. I know about a lot of the cracks.
I wrote a blog post [0] about this mindset getting in the way of what you care about in product development which you might enjoy, if you enjoyed this article.
[0] https://davnicwil.com/just-build-the-product/
This deep desire to affect change in a controllable way...
This infinite desire for self value defined by external validation.
It's not sustainable. Perfection can only be obtained by observation of perfection of combined self through self and other.
It's okay to discard parts of yourself to balance yourself with your counterpart. A willing violation is no longer a violation.
Not observation of one or the other on a pedestal, but accepting that both are vital parts to the system and observing the perfection that comes from co-iteration.
Essentially turning a binary system quantum.
This really got to me because I've been doing this without realizing it for as long as I can remember.
This reasoning (which I can easily identify with) is a slippery slope towards OCD anxiety and depression when you refuse to acknowledge that you can't fix everything.
You need to be realistic, set your priorities within a limited, defined context, take decisions and actions based on those, and forget about the stuff that didn't make your priority list.
That's not not-caring. That's focusing on what really needs your care.
Wish I was better at it though.
OP's fear of (being seen to be) "coasting" would be entirely foreign to them.
So I explained it to Claude and made it write a Python script where I could manually set a few fixed times and it would adjust the SRT file, and it worked perfectly.
I literally paused the film and did that in under 5 minutes. It was amazing.
So fixing a lot of small things has become easier at least.
Like I have published a FOSS tool from some scripts I had for managing VPNs, and there I get constant issues around new providers / updates and it not working in people's specific environments (which I can't test).
The LLMs make it viable to write quick throw-away scripts with almost no time investment, and as such you feel no pressure to share or improve them.
Not joking with orders of magnitude. At this point, I regularly encounter a situation in which asking ChatGPT/Claude to hack me a little browser tool to do ${random stuff} feels easier and faster than searching for existing software, or even existing artifacts. Like, the other day I made myself a generator for pre-writing line tracing exercise sheets for my kids, because it was easier than finding enough of those sheets on-line, and the latter is basically just Google/Kagi Images search.
I make a matrix led clock that can sync time through network, using Arduino and esp32. Due to time constraint, the coding standard is horrible(magic number, dynamic allocation, no abstraction between module, etc), but hey, it works, at least for 7 years now. The code took me 3 days to finish, and i would never write such code in production FW.
There is a bug that may makes it unable to connect network, but it can be fixed by turning off then on again, i never bother to debug or patch it.
Perfect is the enemy of good.
We are playing software factorio and the winning move is not to play.
I find joy in receiving praise from my colleagues when they have good experiences with my tools.
(takes one to know one here)
Software is so spectacularly broken. Applications that don’t let me adjust the position of a little button for my work habits. Why is that impossible!?! A global software and commerce system, where you can buy candy or transfer $ billions, both with cute warnings like “Please, oh, please, sir! Please don’t hit the back button!”
I can sum up the results of my quest quite simply: “The rewrites continue…”
Is this chasing windmills? The case for that seems solid on the surface, but…
It is true that every rewrite of a specific set of features, or a platform for enabling better support for efficiently and correctly commingling an open class of features, inevitably runs into trouble. Some early design choice is now evidently crippling. Some aspect can now be seen to have two incompatible implementations colliding and setting off an unnecessary complexity explosion. Etc.
But on the other hand, virtually every major rewrite points to a genuinely much improved sequel. Whose dikes keeping out unnecessary complexity hold up longer with less finger holes to plug, for a better return. Before its collapse.
Since there must be a simplest way to do things, at least in any scoped area, we have Lyapunov conditions:
Continual improvement with a guaranteed destination. A casual proof there is a solution.
It’s a dangerous phantom to pursue!
——
It would be interesting to compile a list from the heady 90’s, when corporations created boondoggles like Pink and Cyberdog, and had higher aspirations for things like “Object Linking and Embedding”.
You just don’t see as many romantic technological catastrophes like those anymore. I miss them!
In terms of accessibility though, I'd recommend Forthkit (https://github.com/tehologist/forthkit), Miniforth (https://compilercrim.es/bootstrap/), Sectorforth (https://github.com/cesarblum/sectorforth), Sectorlisp (https://justine.lol/sectorlisp2/) Freeforth (https://github.com/dan4thewin/FreeForth2 contains an inlining cross-compiler for MSP430)
The problem with forths is that they don't seem as scalable as say lisp, from a social perspective. At a larger level, Project Oberon (https://projectoberon.net/) builds from the base CPU on FPGA, and A2 (https://en.wikipedia.org/wiki/A2_(operating_system)) show what can be done to scale up.
Steps (https://github.com/robertpfeiffer/cola/tree/master/function/...) also was supposed to do this, but the available code is rather disjointed and not really easy to follow.
Yes. Well, "tilting at," jousting specifically. The figure relates to the comical pointlessness of such an act; the windmill sail will in every case of course simply remove the lance from the rider and the rider from the saddle, and turn on heedlessly, as only a purblind or romantic fool could omit trivially to predict.
> You just don’t see as many romantic technological catastrophes like those anymore.
The 90s were a period of unparalleled economic surplus in the United States. There was more stupid money than at any other time and place in history, and stupid money always goes somewhere. Once that was tulips. This time it was this.
> I miss them!
I miss the innocence of the time, however amply undeserved. But I was young myself then.
It all boils down to the 3 key factors: speed, quality and cost. And you can't have it all
Know your trade-offs.
> Technical Work as Emotional Regulation
Men are taught to do that in most societies. You are unhappy - don't bother talking about it (men don't cry), do sth for the society - you'll receive praise in return and your pain will go away for a while. Even if nobody'll praise you - you'll think better of yourself. Same thing that makes our fathers obsessively fix any minor inconveniences around the house instead of going to the doctor with their big health problem.
Men often laugh at women talking for hours instead of fixing the damn problem (and it is frustrating to observe). But we often do not fix THE damn problem either - we fix other unrelated problems to feel better about the one we fear thinking about.
What's more tech-specific IMO is the degree to which our egos are propped by our code. Code is the one thing many programmers had going for them when they grew up. It's what made them special. It's what was supposed to pay for all the bullying in school. It's what paid their bills and made them respected. It's very hard not to make code your main source of value.
People praise "ego-less" programming, and most programmers adhere to the rules (don't get overly defensive, take criticism, allow others to change "your" code, etc.) But that's not actually ego-less programming, it's just hidding your ego in the closet and suffering in silence.
If you procrastinate when programming - it's because you feel your code reflects on your worth as a human being. It's all ego. Changing what you do won't change that. You need to change what you think.
Problem solving is easier than listening and empathy.
It is okay to do things and abandon them later, that is how we learn. We programmers are multipliers, which gives us special responsibility. If we create a shit tool with a shit workflow that wastes time, we waste time multiplied by the number of users of our software. If we save time or bring joy, the same is true. That can be beautiful and devastating.
But every software needs to be maintained somehow and maintainability is a technological choice as well. I have an embedded project running for well over a decade without a single maintenance step of either the hard- or the software. I could have built that project also with more dependencies to the outside world, or in more sophisticated ways with more moving parts, but I wanted to not deal with the consequences of that. This choice isn't always easy, but it is a choice. Ask your sysadmin which things worked for the past decades without having to touch them and investigate. Typically it is boring tech with boring choices.
Another aspect the article does not tackle is that if you know to repair or build many things, people will naturally also come to you asking you to do precisely that. But that again produces maintenance work and responsibility. This is why I like working in education, you can show people how to do it and then it is their project.
- Updates often don't break things
- Remind for notes
- Gopher as my main site
- Multimarkdown+git for a wiki
- A web/blog without RSS is not worth your time
- Nvi can be good enough against vim, entr+make do magic
- mbsync/msmtp/slrnpull and so work in batch mode, fire mutt and forget
I don't hack my tools any more. I don't distrohop. CWM, XTerm, MuPDF, GV and friends like Bitlbee do everything well since years. Now I'm focusing in Forth, because in a near future low power microcontrollers and laptop will say a thing or two.