4 ms·

Here's the problem I see with unplugging to work; maybe it's an actual problem, maybe I'm just fooling myself. I work on software. I want the finished product,

by ralphc 6y ago

Here's the problem I see with unplugging to work; maybe it's an actual problem, maybe I'm just fooling myself. I work on software. I want the finished product, to build something useful for myself or others. I don't necessarily want the "journey". When I work, my concern, or fear, is that I'm going to work on some library or method, multiple days, then find that someone else did it better in a library I can just import. As I work I also look for these libraries, and look at questions on StackOverflow. I don't consider that time wasted. Between that, and docs that are all online nowadays, I don't see how I can work while disconnected.

cgag 6y ago
Scrape the doc sites with httrack or something. Don't turn the internet on unless you actually hit that library problem, I think it's generally pretty clear when a significant problem has already been solved. Or move on and solve that problem tomorrow, and go do deliberate research on it and download everything at night, and then work on it again offline the next day.
- j4ah4n 6y ago
  FWIW I've used offline docs via Dash[0] when working away from network access before. It works great! MacOS only though. [0] https://kapeli.com/dash https://kapeli.com/dash
bogwog 6y ago
> then find that someone else did it better in a library I can just import If it involves working with some common standard or protocol, chances are it's been done before and you probably shouldn't attempt to do it yourself unless the existing implementations don't work for you. But otherwise, why stress over it? The amount of "great" programmers in the world is tiny, so while the chances that someone did something already are high, the chances that it will be significantly better than anything you can make yourself are low. Unless it's impractical because of the sheer size of it, the time investment involved, or some other reason, building something yourself gives many long-term benefits for the upfront investment. Owning the code, not having to deal with the community/politics, developing at your own pace, not having to worry about maintaining a fork, minimizing external dependencies and the associated risks, avoiding licensing concerns, etc. Saying that you should use an existing library because "someone probably did it better" is F.U.D. If you're not confident in your abilities to do something better than an imaginary programmer you've never met, then you probably need to write more code and gain more confidence; and a great way to do that is to reinvent the wheel from time to time.
minerjoe 6y ago
> I don't see how I can work while disconnected. I'be been programming for many years almost completely offline. It has changed the way I develop in ways that are very powerful. Having local copies of all of your needs allows for things that you just cannot do with online resources, such as locally index. Having instantaneous (not internet fast, FAST!) fuzzy search through my entire collection of doucmentation AND all source code was a game-changer for me. Especially when learning a new language, its powerful being able to immediatly find example uses of functions from within your local collection of libraries without having to hit on google (and wait, and click, and read, and ...).
Balgair 6y ago
> I don't necessarily want the "journey". Aside: The 'journey' is typically structured wrong, dramatically speaking. With development, the product is released at the end of the 'journey'. Boom, it's done, the end, Fin. In a 3-act drama, the 'crisis' occurs at the midpoint of the story. It's the turning point. The iceberg hits the Titanic halfway through, Obi-Wan dies halfway through Star Wars, MacBeth kills Banquo halfway through, etc. The product should be released at the halfway point of the 'journey'. It's the turning point for the humans in this story. We finally have the elixir and we've used it for the first time (ie. we get real feedback from the market and customers for the first time). We're missing the rest of act 2 and the whole of act 3: the 'flight' part of act 2, the 'crisis point' at the end of act 2, and the 'synthesis' part that is act 3. Those missing elements exist for the actual product, it's just that they are not included in the 'story' of the product. The humans in the 'journey' only make it to the intermission. It's then handed off to another team, typically. Hence, there is a lot of frustration with these 'journeys'. We don't get any synthesis. To fix it, view the release as the halfway point in the 'journey', not the end of it. Keep the team a part of the product through the end of the dramatic 'journey'.

by ralphc 6y ago

cgag 6y ago

Scrape the doc sites with httrack or something. Don't turn the internet on unless you actually hit that library problem, I think it's generally pretty clear when a significant problem has already been solved. Or move on and solve that problem tomorrow, and go do deliberate research on it and download everything at night, and then work on it again offline the next day.

j4ah4n 6y ago
FWIW I've used offline docs via Dash[0] when working away from network access before. It works great! MacOS only though. [0] https://kapeli.com/dash https://kapeli.com/dash

bogwog 6y ago

> then find that someone else did it better in a library I can just import If it involves working with some common standard or protocol, chances are it's been done before and you probably shouldn't attempt to do it yourself unless the existing implementations don't work for you. But otherwise, why stress over it? The amount of "great" programmers in the world is tiny, so while the chances that someone did something already are high, the chances that it will be significantly better than anything you can make yourself are low. Unless it's impractical because of the sheer size of it, the time investment involved, or some other reason, building something yourself gives many long-term benefits for the upfront investment. Owning the code, not having to deal with the community/politics, developing at your own pace, not having to worry about maintaining a fork, minimizing external dependencies and the associated risks, avoiding licensing concerns, etc. Saying that you should use an existing library because "someone probably did it better" is F.U.D. If you're not confident in your abilities to do something better than an imaginary programmer you've never met, then you probably need to write more code and gain more confidence; and a great way to do that is to reinvent the wheel from time to time.

minerjoe 6y ago

> I don't see how I can work while disconnected. I'be been programming for many years almost completely offline. It has changed the way I develop in ways that are very powerful. Having local copies of all of your needs allows for things that you just cannot do with online resources, such as locally index. Having instantaneous (not internet fast, FAST!) fuzzy search through my entire collection of doucmentation AND all source code was a game-changer for me. Especially when learning a new language, its powerful being able to immediatly find example uses of functions from within your local collection of libraries without having to hit on google (and wait, and click, and read, and ...).

Balgair 6y ago

> I don't necessarily want the "journey". Aside: The 'journey' is typically structured wrong, dramatically speaking. With development, the product is released at the end of the 'journey'. Boom, it's done, the end, Fin. In a 3-act drama, the 'crisis' occurs at the midpoint of the story. It's the turning point. The iceberg hits the Titanic halfway through, Obi-Wan dies halfway through Star Wars, MacBeth kills Banquo halfway through, etc. The product should be released at the halfway point of the 'journey'. It's the turning point for the humans in this story. We finally have the elixir and we've used it for the first time (ie. we get real feedback from the market and customers for the first time). We're missing the rest of act 2 and the whole of act 3: the 'flight' part of act 2, the 'crisis point' at the end of act 2, and the 'synthesis' part that is act 3. Those missing elements exist for the actual product, it's just that they are not included in the 'story' of the product. The humans in the 'journey' only make it to the intermission. It's then handed off to another team, typically. Hence, there is a lot of frustration with these 'journeys'. We don't get any synthesis. To fix it, view the release as the halfway point in the 'journey', not the end of it. Keep the team a part of the product through the end of the dramatic 'journey'.