My college is surrounded by forest, and the internet behaves accordingly. What that taught me about working offline, reading docs, and needing the network less.
Select any sentence in this post to leave a margin note on it.
Did this land?
My college is surrounded by forest.
I've mentioned this before, when I wrote about Flux, the package manager I started because installs kept failing. But the bad internet did more than inspire one project. It changed how I learned to code.
Most programming advice quietly assumes you're always online. Search it. Watch the video. Ask the AI, which we didn't even have back then. Install the package. Pull the image. Every step is a network request, and when the network is unreliable, every step is a gamble.
So I learned to need it less.
The first habit was the simplest. When the connection was good, I grabbed everything I'd need later.
Docs, mostly. A lot of languages and frameworks let you download their documentation, and tools like DevDocs and Zeal keep docs for dozens of them on your machine, searchable instantly. No loading spinner.
Videos too. If a course or a talk was going to be useful, I downloaded it when the Wi-Fi worked instead of trying to stream it when it didn't. Same with Docker images. Pull the database image the night before, not when you're about to start.
Packages are the interesting one. A package you installed in one project is usually still on your machine somewhere, and package managers like pnpm and Bun keep a shared cache for exactly this reason. That idea is basically what Flux was built around.
None of this is about specific tools. It's a mindset. The network is something you schedule, not something you assume.
This one helped the most, and I only picked it up because searching was slow.
When every search takes forever to load, you start avoiding it. And when you avoid it, you end up reading the documentation properly instead of hunting for the one answer to the one question you have right now.
That's a much better way to learn. A search gives you an answer. The docs give you the shape of the whole thing. What else is possible, what the authors intended, where the edge cases are. Half the time, your next ten questions are answered on the same page.
Then the step after docs: the source. If a library is installed, its code is already on your disk. When something didn't behave the way I expected and I couldn't search for it, I opened the package folder and read the function. It feels intimidating the first few times. Then it becomes the fastest way to understand anything, because the code can't be out of date. It's exactly what's running.
This changed how I write software, not just how I learn.
On a slow connection, you notice very quickly which setups fall apart without internet. A dev server that calls some API on every page load. A build that downloads something every time. Tests that hit a real external service.
So I started building things that run locally by default. Local database, mocked external services in dev, committed lockfiles, seed data in the repo.
None of that is special. It's just good practice. I learned it early because the alternative was not being able to work at all.
When you can't quickly look something up again, you start keeping notes. Commands I always forget, how I fixed that one error, which flag does what.
I keep them as plain text files. Searchable, offline, and honestly faster than any search engine, because they're already written in the exact words I'd use to look for them.
I wouldn't wish slow internet on anyone. But I'm not sure I'd trade what it taught me. It made me less dependent on the network and a lot more comfortable reading things properly, and both of those mattered way beyond college.