HN, can you imagine building a meaningful project without constant access to internet / Google? Programmers in the 80s probably did that.<p>Inspired by: https://www.reddit.com/r/Python/comments/w46m73/how_far_could_you_get_without_google
In the good old *nix days the system provided pretty much everything you needed: C, perl, man pages, and well documented header files. Throw in a couple of good books on programming, and you could do a lot.<p>That's still the case, but it feels like today's software development reality is different. There are endless frameworks, apis, devops methods, scalability concerns, and n+1 standards with which to integrate and keep up to date on. Knowing your language is only about 25% of the battle, and few projects are developed in a vacuum.<p>It's not possible to keep track of all those things, so endless internet searches are the end result.
All the way through the 00’s!<p>Had a lot of dog eared O’Reilly books, now I haven’t bought a technical book in over a decade!<p>Btw, You could cut out google and go straight to stackoverflow, just saying.
I <i>was a programmer</i> in the 80s. We had MS-DOS, Turbo Pascal (with it's damned fine documentation, in an actual book, and help files).<p>The hardware sucked, but we didn't have to worry about anything other than putting characters on a screen, eventually VGA graphics if we got fancy. There was one platform, the IBM compatible PC, and that was the only one I worried about.<p>We didn't have GIT, we had PkZip, and a stack of floppy disks with labels like "Source Backup v42 2/3/89". If we made a mistake, we had to manually revert.<p>I wrote "OverSeer" - a program that managed the inspection of Fire Extinguishers, using hand-held computers and barcode scanners from the Norand corporation of Iowa. Eventually it was adapted to other uses. It was written in Turbo Pascal. All the libraries were my own, including one to do cooperative multi-tasking.<p>Our customers were in Northern Illinois, and I was the programmer/tech.<p>As me anything. ;-)<p>[Edit - Extended description of the stuff I wrote]
I used to write pseudo-code that didn't compile for one pass, working out logic, then work through turning it into code on a second pass. Generally, stuff I pseudo-coded seemed much less buggy than stuff I wrote straight in as compilable, presumably because I didn't have much besides program-logic to concern myself with. Translating it to something compilable was pretty mechanical, since I wrote something in the ballpark; I just didn't worry about syntax at all.
It wouldn't be a problem - as you state in the question - coders used to do that before the web.<p>This is a rare (?) occasion where old dogs would likely adapt more quickly due to having done it before. Not only will their old muscle memory kick in, they will be more comfortable with the situation.
More documentation was available at your fingertips because it wasn't assumed that you had an internet connection and search engine always at your disposal. Also heading into a datacenter to physically plug in a crash cart without a laptop was fairly normal.<p>I've been remote for years and tend to live in rural areas with spotty connections. I also travel frequently. I can usually stack up a week or two's worth of offline work just in case connections are terrible. Some of it's documentation and writing. But a lot of it is technical stuff or mock ups. Maybe I can't take a task all the way to completion without ci/cd or additional documentation, but I can keep making progress at least.<p><pre><code> * I download documentation sites for offline use with wget
* I set up virtual environments, containers, and dependencies prior to going offline.
* Abstract away any libraries that I might need to add or look up the semantics of. Handwaving over the details.
* If there's a dependency that I might have to patch, or upstream code I might have to read, I typically vendor things with submodules locally
* run local instances of infrastructure for testing integrations or tools that expect you to be online all the time such as; config management tools, helm charts, docker repos, secrets management.
* have testing plans that don't require online validation
* for code, unit tests
* for IaC stuff, templating it out and diffing or manually eye-balling
* keep the logic of ci/cd pipelines in code or scripts instead of platform specific configuration files (within reason)
</code></pre>
It doesn't have to be a technical solution. Explicitly planning out your work days to the minutia and accounting for all the tools you'll need will get you pretty far.<p>Now planning around times in-between access to power is an entirely different game.<p>edit: formatting
I don’t see the issue… I already seldom check google (maybe once a month). I have the official documentation of the language I work with (c++) and that covers most of the questions I might have on a day to day basis. Everything else I need comes from my education. I really don’t see why people should rely so much on google!
Depends what I'm currently doing.. The past week I've implementing some trivial feature in javascript and C and so haven't had to look up anything.<p>But weeks ago, I had to implement something in DQL, which I'd never used before, their documentation is terrible, and google didn't help that much either.
I’d get a copy of Dash and download the Docksets you probably needed.<p>[1]: <a href="https://kapeli.com/dash" rel="nofollow">https://kapeli.com/dash</a>
Yeah, a couple good books and possibly some source of my older projects and I'm set. I still regularly buy reference material, not as much nowadays but its nice to have it available in a pinch.
Same as before Google. Books, text files, and collected code snippets. During school, the SWAG collection for Pascal was eagerly downloaded from BBSs when new editions came out.<p><a href="http://www.retroarchive.org/swag/index.html" rel="nofollow">http://www.retroarchive.org/swag/index.html</a>
I'm not sure which is harder to imagine:<p>1. Programming without google<p>2. Programming (a web app) without webdev tools<p>When I first started learning development in the early 2000s, it was php, jquery, html, and css and very few search results when googling.<p>When Firebug came along for Firefox, my entire world changed and it was as if lights from the heavens had been turned on.
Depends on what I'm doing. If I'm working on my usual BE stuff, I'd probably go for years - I can't remember the last time I googled something about this. If you ask me to do frontend work I'd probably get stuck within a few days.
Pretty far actually...However without the package index, and documentation of other libraries and imported modules and without an IDE, much more slowly.<p>I find myself using the Google --> Stackoverflow work pattern less and less.
If I can cheat a little, OpenAI Codex has been more useful than Stack Overflow.<p>Also assuming you mean Google the search engine, not the company, because as an Android dev, it would be tough without any documentation.
Have an offline copy of devdocs.io which is all I need.<p>Although I would like instant access to Stack Overflow for various snippets. Things like ‘How to sort an array of numbers’
1. <a href="https://www.kiwix.org/en/" rel="nofollow">https://www.kiwix.org/en/</a> : see content at <a href="https://library.kiwix.org/" rel="nofollow">https://library.kiwix.org/</a><p>2. Info manuals, info browser<p>3. Self-documenting programs & environments (e.g., emacs but also Python with docstrings etc)<p>4. Look at the source code on your machine
Used to know somebody who contracted with national security and had to do this. They said it wasn't so bad with paper manuals! The worst part for them was not being able to use outside libraries without going through extremely extensive checking processes
I block outgoing ports 80 and 443 quite regularly when I need to get shit done, coding-wise. Takes some getting used to, but it's no major obstacle.