5 ms·

It might seem like a JS problem, but it's inherent to making software. When it works, you feel amazing. And when it doesn't, you feel terrible. Not sure about

by meagher 10y ago

It might seem like a JS problem, but it's inherent to making software. When it works, you feel amazing. And when it doesn't, you feel terrible. Not sure about a specific plan, but I would go for a walk, take a hot shower, or call it a night. http://meagher.co/blog/2017/03/07/set-up-is-hard/ http://meagher.co/blog/2017/03/07/set-up-is-hard/

veidr 10y ago
I'd say part of this problem is specific to JS (in its current state). I don't think there is, or ever has been, a major swath of the software development world with: - so many tools - such a high rate of change and therefore obsolescence and tool breakage - such a huge number of shitty half-baked solutions (a function of the first two) Maybe this is just because there's never been a programming language relevant to so many people. But anyway, if you compare JS development to traditional native app development, or the more popular paradigms for back and development over the past years and presently, there are usually fewer and more dominant tools that maintain mind share and therefore get people to work on them and stay relevant over longer periods. I work with JS part of the time, and my own solution to this is just cargo-cult it. That is to say copy what my advanced JS colleagues who tinker do. The drawback is that I never have the latest state-of-the-art tooling (e.g. my project still uses npm even though I think I want to be using yarn). The obvious advantage is that I don't spend time dealing with this kind of stuff very much. The JavaScript world is kind of a painful place to be an early adopter right now.
- lokedhs 10y ago
  I think you nailed it. This is something that is pretty unique to the JS world. I think the reason for this is that the entire infrastructure is built on foundations that are constantly changing. It's impossible to spend even a year refining your infra when the foundation has been replaced at least once in the meantime. Imagine what would happen if the POSIX API's were to change every year instead of every decade or so. We'd have the same mess in the Unix world. In fact, there is one place where this happens, although not as bad as the JS world: mobile development. Coming back to Android after being away for a year forces you to learn a whole new set of API's and most of the things you used to do have now become obsolete. The main difference between JS and mobile is that for JS everybody builds their own frameworks and no one knows what the correct way is.

by meagher 10y ago

veidr 10y ago

I'd say part of this problem is specific to JS (in its current state). I don't think there is, or ever has been, a major swath of the software development world with: - so many tools - such a high rate of change and therefore obsolescence and tool breakage - such a huge number of shitty half-baked solutions (a function of the first two) Maybe this is just because there's never been a programming language relevant to so many people. But anyway, if you compare JS development to traditional native app development, or the more popular paradigms for back and development over the past years and presently, there are usually fewer and more dominant tools that maintain mind share and therefore get people to work on them and stay relevant over longer periods. I work with JS part of the time, and my own solution to this is just cargo-cult it. That is to say copy what my advanced JS colleagues who tinker do. The drawback is that I never have the latest state-of-the-art tooling (e.g. my project still uses npm even though I think I want to be using yarn). The obvious advantage is that I don't spend time dealing with this kind of stuff very much. The JavaScript world is kind of a painful place to be an early adopter right now.

lokedhs 10y ago
I think you nailed it. This is something that is pretty unique to the JS world. I think the reason for this is that the entire infrastructure is built on foundations that are constantly changing. It's impossible to spend even a year refining your infra when the foundation has been replaced at least once in the meantime. Imagine what would happen if the POSIX API's were to change every year instead of every decade or so. We'd have the same mess in the Unix world. In fact, there is one place where this happens, although not as bad as the JS world: mobile development. Coming back to Android after being away for a year forces you to learn a whole new set of API's and most of the things you used to do have now become obsolete. The main difference between JS and mobile is that for JS everybody builds their own frameworks and no one knows what the correct way is.