Ups and downs of a side project
jereze.com
Ups and downs of a side project
1–10 of 58 posts
Re: Ups and downs of a side project
#2I have several side projects. While I contribute to the ups and downs, the usual dagger that grinds things to a halt is hitting some bug in an open source library or language that I don't have the ability, expertise, what have you to fix. Inevitably, the library is maintained by one person who is minimally active, despite being used by tons of people, and so I just get stuck. Software is a very frustrating endeavor. Not complaining about people's time, just the fragility of the tower of stuff software stands upon.
Re: Ups and downs of a side project
#3I have several side projects. While I contribute to the ups and downs, the usual dagger that grinds things to a halt is hitting some bug in an open source library or language that I don't have the ability, expertise, what have you to fix. Inevitably, the library is maintained by one person who is minimally active, despite being used by tons of people, and so I just get stuck. Software is a very frustrating endeavor.…
You made the tower yourself, no? Not to sound snarky but by making sure that (1) you do not lock yourself into any dependency and (2) you keep the use of dependencies to a minimal you do prevent most of that pain? At least that is my opinion. As a temporary workaround (sometimes permanent) I opt for a fork, which when kept to the bare minimum is usually not more then a minor annoyance.
That’s at least my experience…
Re: Ups and downs of a side project
#4I have several side projects. While I contribute to the ups and downs, the usual dagger that grinds things to a halt is hitting some bug in an open source library or language that I don't have the ability, expertise, what have you to fix. Inevitably, the library is maintained by one person who is minimally active, despite being used by tons of people, and so I just get stuck. Software is a very frustrating endeavor.…
You made the tower yourself, no? Not to sound snarky but by making sure that (1) you do not lock yourself into any dependency and (2) you keep the use of dependencies to a minimal you do prevent most of that pain? At least that is my opinion. As a temporary workaround (sometimes permanent) I opt for a fork, which when kept to the bare minimum is usually not more then a minor annoyance. That’s at least my experience…
Well, the option is to rewrite the entire stack yourself. So sure, let me spend a lifetime doing that instead of things I'd like to be doing. I already opt for minimal dependencies. The problem is that every piece of software I have ever interacted with has had bugs that immediately surface, and nearly universally, there's only a handful of people that can fix them. I can't possibly be expected to reimplement or even fix projects that have taken decades to develop.
You say don't lock yourself into dependencies. Well, to create a window on an OS, you have no choice but to have a dependency, because that's how the real world works. The only option is to write your own OS, but even that has dependencies.
Re: Ups and downs of a side project
#5I have several side projects. While I contribute to the ups and downs, the usual dagger that grinds things to a halt is hitting some bug in an open source library or language that I don't have the ability, expertise, what have you to fix. Inevitably, the library is maintained by one person who is minimally active, despite being used by tons of people, and so I just get stuck. Software is a very frustrating endeavor.…
You made the tower yourself, no? Not to sound snarky but by making sure that (1) you do not lock yourself into any dependency and (2) you keep the use of dependencies to a minimal you do prevent most of that pain? At least that is my opinion. As a temporary workaround (sometimes permanent) I opt for a fork, which when kept to the bare minimum is usually not more then a minor annoyance. That’s at least my experience…
This x 1,000
Re: Ups and downs of a side project
#6Earlier quoted context omitted.
You made the tower yourself, no? Not to sound snarky but by making sure that (1) you do not lock yourself into any dependency and (2) you keep the use of dependencies to a minimal you do prevent most of that pain? At least that is my opinion. As a temporary workaround (sometimes permanent) I opt for a fork, which when kept to the bare minimum is usually not more then a minor annoyance. That’s at least my experience…
Well, the option is to rewrite the entire stack yourself. So sure, let me spend a lifetime doing that instead of things I'd like to be doing. I already opt for minimal dependencies. The problem is that every piece of software I have ever interacted with has had bugs that immediately surface, and nearly universally, there's only a handful of people that can fix them. I can't possibly be expected to reimplement or even…
That's what I typically do.
I'll make sure that the libraries I rely on are either ridiculously well proven, or easily replaceable. If they are neither of those things I implement a new one myself from stuff that is, while no doubt just as buggy, it's at least code I can easily fix myself if it breaks.
Usually it's not that much work. I'll just implement what I actually need. Many open source projects are hilariously over-designed and have significant feature creep. If you cut that out you can replace the critical components with not a lot of code and not a lot of hassle.
If it can't be trivially re-implemented, I've been known to fork an existing project and take a grinder to it until it does what I want, usually axing away most of what I don't need to only expose the code I need.
Re: Ups and downs of a side project
#7I have several side projects. While I contribute to the ups and downs, the usual dagger that grinds things to a halt is hitting some bug in an open source library or language that I don't have the ability, expertise, what have you to fix. Inevitably, the library is maintained by one person who is minimally active, despite being used by tons of people, and so I just get stuck. Software is a very frustrating endeavor.…
You made the tower yourself, no? Not to sound snarky but by making sure that (1) you do not lock yourself into any dependency and (2) you keep the use of dependencies to a minimal you do prevent most of that pain? At least that is my opinion. As a temporary workaround (sometimes permanent) I opt for a fork, which when kept to the bare minimum is usually not more then a minor annoyance. That’s at least my experience…
That's a really bad attitude. I ran into a bug in NPM that prevented our CI builds running entirely.
That NPM bug still isn't fixed (despite the bug having minor security implications), but there's no way I'm re-writing everything to not use NPM, it would be absurd, nor is it sensible to fork NPM and invest time into fixing the bug.
I ended up putting in effort to work around the bug entirely, but it was only coincidence that we could go without the feature that triggered the bug because we were going to deprecate that module anyway.
Are you really suggesting that developers don't "lock themselves in" to NPM? It's one of the most prolific projects that exists and it would be career limiting to avoid using a package manager or all dependencies entirely.
Re: Ups and downs of a side project
#8Earlier quoted context omitted.
You made the tower yourself, no? Not to sound snarky but by making sure that (1) you do not lock yourself into any dependency and (2) you keep the use of dependencies to a minimal you do prevent most of that pain? At least that is my opinion. As a temporary workaround (sometimes permanent) I opt for a fork, which when kept to the bare minimum is usually not more then a minor annoyance. That’s at least my experience…
That's a really bad attitude. I ran into a bug in NPM that prevented our CI builds running entirely. That NPM bug still isn't fixed (despite the bug having minor security implications), but there's no way I'm re-writing everything to not use NPM, it would be absurd, nor is it sensible to fork NPM and invest time into fixing the bug. I ended up putting in effort to work around the bug entirely, but it was only coincid…
You probably already know but I found patch-package [1] to be crucial when relying on minor npm packages. It’s so freeing to be able to just fix it on your end and move on (and also raise a PR against the package)
Re: Ups and downs of a side project
#9Earlier quoted context omitted.
That's a really bad attitude. I ran into a bug in NPM that prevented our CI builds running entirely. That NPM bug still isn't fixed (despite the bug having minor security implications), but there's no way I'm re-writing everything to not use NPM, it would be absurd, nor is it sensible to fork NPM and invest time into fixing the bug. I ended up putting in effort to work around the bug entirely, but it was only coincid…
You probably already know but I found patch-package [1] to be crucial when relying on minor npm packages. It’s so freeing to be able to just fix it on your end and move on (and also raise a PR against the package) [1] https://www.npmjs.com/package/patch-package
Thanks, but this was a bug in npm itself.
Re: Ups and downs of a side project
#10Earlier quoted context omitted.
You probably already know but I found patch-package [1] to be crucial when relying on minor npm packages. It’s so freeing to be able to just fix it on your end and move on (and also raise a PR against the package) [1] https://www.npmjs.com/package/patch-package
Thanks, but this was a bug in npm itself .
Ah my bad! Luckily I haven’t ran into one of those yet and I’m hoping I never will :p