Ask HN: How to hole up in a cabin in the woods to write my great software idea?
It's discouraging that it seems that in order to write software I'm expected to have constant and fast internet access to Stack Overflow or whatever search site to find answers or download crazy large toolchains.
How did people program working solutions before instant online answers and is it even possible to hole up in a completely distraction free, out of the way locale for that next great side project?
I'm jealous of the idea of the novelist holing up in a spartan cabin with just an idea and a typewriter. Maybe a dictionary, maybe some prepared research notes; but completely cut off and only running off meager brought materials.
So how would a programmer prepare enough to code up their idea without internet access?
What documentation, books, or materials would one bring?
Are these materials general, like journal articles about algorithms and CS? Or very specific to the OS, framework, standard library, etc?
Are there first principles at each abstraction layer from bare metal, OS, user space, and application level that allows cobbling software solutions without external resources? I used to rely on manpages, documentation (bundled in), and lots of trial an error. Honestly, the big difference today is having access to how others have solved a problem. This makes things quicker. Do I still learn? I learn more now because of the access. Now, are you expected? By who? This is your own project. Just do whatever works for you. If you read The Art of Computer Programming or Djikstra's writings they will tell you how this was done. They took a piece of paper, and they wrote down in a high level what their program should do. Then they took another piece of paper and they started to split up the first piece of paper into smaller subroutines. Then they took some more paper and split the small subroutines up into smaller and smaller subroutines. Then they sat in front of a computer and they wrote the program from the simplest subroutine up the tree and at some point totally trashed everything realizing they didn't fully understand the problem because architecting a program is difficult until you actually implement it. So back to the paper they did the exact same design algorithm using the new experience they had from actually trying to implement whatever they were doing but this time with the added experience of knowing more about the problem they were trying to solve. Then when the chance came to implement their program on a likely shared computer with limited time, they wrote this program the exact same way from the bottom up testing all the way until it was finished. Everytime I've asked a question on stackoverflow/exchange I realized half way through preparing and formatting my question that my program is too complicated, I should break up the logic and then I don't need to ask a question. I swear this is why they make posting there so tedious where you need carefully format and search for existing questions before posting a new one because odds are, you'll figure out what you trying to ask before even asking it. Sounds like the tried and true way. I'm always interested in learning about computing history and the people that set up the groundwork. The more I read, the more I find that tech doesn't learn much from its past and we're just stuck with many inferior iterations of the same things. I found a copy of, Notes On Structured Programming, by Dijkstra. I'm going to start giving it a read tomorrow (it's a whopping 88pg essay). It seems that Dijkstra did a lot of paper design work because he was programming for hardware that didn't exist in a programmable form yet. One potential avenue - download stack overflow data for your particular tech stack - https://meta.stackexchange.com/questions/221397/is-there-a-w... Download a pleasant language distribution with a capable base library and documentation, like Racket. You might not need to do everything in the fastest or most scalable way. Like how a writer in a cabin will produce something that later needs editing and typesetting for mass distribution. So, like, if you forgot how to use an SQL database or didn’t bring Postgres, just serialize a big hash table and do your queries in your programming language. So you can build the program out of parts that you might need to replace once you’re back online. You can also do a lot of work with a specification language like TLA+ where you don’t need to actually implement every algorithm. If you need a hash function you can just postulate a function from your domain type to the naturals. On macOS there is Dash -
https://kapeli.com/dash which can download and make easily searchable many documentations as well as StackOverflow answers. I have been using it sparingly, but for coding without an internet connection it seems ideal Now that you mention it, I tried a program called Zeal on another machine which could also use the Dash Docs format (I'm linux based). I was thinking one would need to download offline copies of the most immediate tools documents but I guess I was hoping for some tried and true articles or techniques (read: silver bullet) and not have to download the whole internet and cross my fingers that I got everything I needed :) The northern part of the US and lower part of Canada is going to have starlink in theory this year. Hugesnet is pretty terrible but might be workable. Or maybe try putting a cellular phone as a hotspot on hosted to the top of a flagpole might reach service.. * Download Stack Overflow data dump. * Download Wikipedia data dump. * Download documentation for the technologies you will be using. * Make sure you have power. * Take backups regularly. * If you get stuck, think and solve the problem. Consider it as an opportunity to employ your brain in a way you (probably) have not done before. I would strongly recommend not doing this. The worst thing you can do when creating a piece of software is isolate yourself for x number of months and build it out entirely in isolation. I've effectively done this in the past, only to find out the product I built was not something people wanted to use. If it's just for personal use, and/or you don't care about people using it, go for it. But if you care about adoption/traction, I would suggest surrounding yourself with people that may use your software, and constantly solicit their candid feedback (e.g. show them the software, but not tell them it's yours, etc...). Building software should be a collaborative process between you and your customer. Have you tried looking into devdocs.io? I believe it supports offline mode. Hmmm, no I've never heard of this although I've used a similar offline doc reader called Zeal. I just checked it out and it looks cool but I don't think it's for me. I use a Firefox extension called Saka Key that allows me to fully navigate web pages and tabbing with the keyboard but it doesn't work so well when a web page wants to be an app instead of a page. The site forces focus in a text search box and pressing escape doesn't leave the text box, it just replaces displaying the welcome message. It's a usability issue for me :( > How did people program working solutions before instant online answers Slowly Ha, probably too true! Part of this question is in response to the feeling I have that when I'm coding, I'm not hyper focused, I'm constantly sidetracked by dipping down documentation and forum rabbit holes because many things are non obvious at first glance, but then once one learns the abstraction or learns the narrative of thought, that it suddenly becomes obvious and second nature.
So following that, I was wondering if there were more resources to load up on these kind of insights to make looking up things only for the most arbitrary technical things. Then I can build a cabin and code up a storm amiright? :) John Carmack did something like that a while ago https://lobste.rs/s/o1xjaq/john_carmack_on_openbsd_c_machine Awesome! Thank you for the article reference, it was great and along the lines of what I was thinking about when I asked my question.
Even a novelist in the woods is only going to hack together a rough draft in the woods and then second draft with an editor once they get back to regular life which it sounds exactly what Carmack did.