I don’t do fully offline programming often, but a big fan of offline tools, because they are usually much faster to use even when you do have interne. For offline docs there is devdocs.io and zeal. Also often you can install the docs from the package manager, or along with the dev toolchain depending on the programming language, then you can set a keyword in the browser to use it as a search engine. E.g in my firefox I have

py:  file:///usr/share/doc/python3/html/search.html?q=%s

, so when I type, say, py re.sub, I get instant results.

It’s certainly hard to replace googling + stackoverflow, but I often find myself searching for the same things I’ve already figured out before in other projects. For that it might be useful to setup a local code search (e.g. via Ripgrep). I’m describing my own code search setup here.

I personally think it’s a shame that in many languages (e.g. Python, the one I’m working most with) it’s not a common practice to package tests and documentation alongside the code, this would really help with offline workflows.

I use Dash on macOS for offline programming language and other programming related documentation searching and browsing (see Zeal for Windows, BSD, Linux). There are lots of docsets available for download.

man 3

I know you are looking for tools and techniques you can just deploy, but ultimately many people with these issues are better in invest in therapy to understand and deal with the behaviour.

You may see it impacting your programming, but this is likely only one example of it. We all suffer from varying degrees of mental issues and programmers need their minds operating as optimally as possible. There are lots of blog posts espousing exercise for the sedentary programmer because it’s an important aspect of health. Few directly mention anxiety, depression, etc which we are not immune from as programmers. In fact, we are going to be hurt because our minds are so important to our work.

I wouldn’t have guessed some of my behaviour was driven by anxiety because I didn’t understand these disorders and thought it only manifested in very big ways (and that it couldn’t be me.) I was very apprehensive about talking to a therapist, but I eventually reframed it as a performance optimisation versus a recovery. I now have some tools and techniques for dealing with it, but the main part was recognising when it was kicking in.

I would caution against life, or exec coaches, because you need someone who can properly diagnose a health issue. Some therapists work with executives, sports people, and the like. They are good ones to seek out. Finding the right therapist take some time.

1. PC in the room nearby (I work over USB and HDMI cables) no fan or other noises.
2. a inhouse spring? room fountain? (not sure about the english term) takes care of about 90% of the noises in my ears and distracts zilch comma nada.
3. pi hole blocks some things more during daytime, I would have to go up to the attic to change this (old house, internet still coming over copper wire on posts to the roof, router and pi hole are in the attic).
4. whiteboard, whiteboard markers (the thinner ones), post-its to make a plan for the week, green border around the portion of the day.
5. stop working something completely different (garden, sports, house, hobby, etc) if the portion of the day is done. Dont worry brain keeps running on the task, but can not clog up this way.

for video chat and conferences, I have a different place with an older thinkpad and a logitech cam in front of a sofa with neutral backdrop. I also use it for private lockdown/can-not-travel chatting. my office is sometimes my creative chaos (and will be), and I will never have the problem of someone spotting sensitive data. Plus I do not have the distraction of I might try to call XYZ, maybe he has time..

Pen and paper!

I’m not joking. That said, this is an approach I tend to use only when there’s a tricky logic problem I need to think through, or when I’m extremely blocked on something. I’ve found it particularly useful for those situations where I’m convinced there’s some magic assumptions in the intended software design but haven’t isolated what they are yet.

Basically, just write code. In pen, ideally, so you can see where your edits were after the fact.

Then, if it’s code that’s useable, type it in and (compile|test|whatnot). There’s something particularly satisfying about typing code in from longhand and having it work correctly the first try. I mean, you don’t always succeed at that, but it’s very satisfying when you do.

Sounds like you’re doing it right. Removing an entire class of distractions altogether is gonna work way better than will power.

I mostly code in Go and use go doc -all <package name> to view documentation. It’s fast, convenient, and works offline!

last year I did Train Jam, which is a game jam on a train from Chicago to SF. It takes about two days, and there’s a stretch of about 20 hours where you have no internet.

I took a Raspberry Pi and one of those external batteries that’s used for charging cellphones. I configured that as a WiFi access point, and then put all of my documentation on the Pi. Unless you’ve overridden your DNS settings, you’ll pick up DNS through the access point, so I had the Pi setup as a DNS relay where I could override specific domain names and point them at the Pi itself. I also put an IRC server on it, installers for various tools and game engines, a small file server, and configured a git user for putting repos on the Pi. It was great. We had a team of four people, chatting on IRC, sending links to docs, pushing and pulling to the Pi for our code sharing; we basically had all of the parts of the internet that were consistently helpful in doing our work, and none of the parts that were just distracting.

But more regularly at home I simply leave my phone inside and read a book on the porch, away from all the stuff to remove all of the distraction.

Yes, I work the same way, it helps me manage my ADHD.

Things that help me solve problems without needing to go online:

• As you say, keep offline copies of as many online documentation and other references as possible.
• I have a wget alias mirror to download a website for local viewing.
• Sometimes offline copies of webpages stay blank for 10 seconds because (a) they try to get Javascript from Google Analytics or some webfont server or Facebook or whatever, which (b) won’t succeed because you’re offline, but (c) it takes 10 seconds before the request times out. Solution: add entries to your /etc/hosts like 0.0.0.0 google-analytics.com www.google-analytics.com, so the request will fail quickly with ‘no route to host’. Bonus: this speeds up online surfing, too.
• Keep local copies, or even clones, of the source code of the libraries I interact with most. This allows you to solve questions the docs don’t answer.
  • for interpreted languages like Python, the source is already present, so I bookmark the/a directory containing the source code.
• For command-line tools:
  • Debianlikes default to not installing package documentation, but you can. The docs package for xxx is usually called xxx-doc, so run apt-get install xxx xxx-doc instead of only installing xxx.
  • get comfortable with locate (find file anywhere in filesystem), find (find file under current folder), grep/rg (find files containing text, and less (displays files, including man manual pages).
  • to make it easy to search inside man pages (usually rendered with less): keep a copy of this less cheat sheet

Things that help me look things up as little as possible: emprace the exobrain.

• I keep a ~/snippets directory for reusable snippets, rather than looking each one up in its own source.
• I keep a ~/sietselog file for reusable answers, rather than troubleshooting each time. When I have to solve something, I write the question there; when I’ve found the solution, I add the answer there; when I remember solving this problem before, I search that file.
• Any command invocation I find hard to remember (or even just annoying to repeat) gets a wrapper script in my ~/bin. Often the mere fact that I named the wrapper myself makes it easier to use and remember. Also, projects have to worry about unique and searchable names; but me, I have no qualms about about naming my Silicon wrapper code2png.
• Python-specific:
  • import pdb; pdb.pm() starts a post-mortem debugger. When you get an error in an interactive session (such as a Jupyter notebook), this will jump to the scene of the error, let you inspect local variables, and let you walk up and down the stack. Ofter quicker than searching for others who got the same error message. pdb command reference. NB: ipdb and pudb are even better debuggers.

I have two computers setups for what I call “ascetic computing,” which are minimal interaction machines; they:

• don’t have slack
• aren’t logged into lobste.rs or twitter generally
• aren’t used for banking or other things I need to do
• generally aren’t logged into anything

I just use git, whatever compilers I need, and the man pages for the most part. Getting a good workflow with my editor & version control system was pretty big, and being disciplined enought to make sure I pull before starting to code and push after I come back is key, but otherwise it’s pretty natural for me.

It really reminds me of when I was young, and would code just by man pages and local version control…

FWIW, which is perhaps not much, I’ve had some success doing this with a screen on the border of my field of vision.

https://rant.gulbrandsen.priv.no/images/arnt-desk.jpg is around half of my office. The top monitor is connected to a minimac and is used only for internet things, including team chat and suchlike. I am typing this on the minimac. All development takes place on the lower screens, connected to a shuffle mini-pc running linux. The minimac and screen was bought because I was required to have slack running, but I wanted it far from my vield of vision.

This is a bit of a hack: The top screen is just distant enough, above, that things there aren’t immediately visible. I ear glasses, and the top edge of my glasses “is at” the bottom edge of that screen. Once I get into the zone, what happens on the top screen is just distant enough that I don’t pay attention, and using the KVM to move my keyboard there doesn’t happen much.

Getting into the zone isn’t always easy, though. Sigh.

Honestly, I don’t think I could do offline programming on any regular basis. The kind of blockers that I cannot get past on my own are not the kind that can be dealt with even if armed with 100% comprehensive local documentation for languages, libraries, packages, APIs, etc. For me to get unblocked, I usually need to get on Slack to ask colleagues about some nuance about our codebase; or I need to hit the Internet with a copy-paste of some error output or stack trace message.

The test suites I deal with on a day to day basis execute parallelized in double-digit numbers of remote containers, and still take tens of minutes to run. A local run is so resource-costly that essentially nobody on the team does that any more. (We each only run a tiny subset of the suite related to whatever we’re working on at the moment.) We also have so much third-party integration by now that even local development requires Internet connectivity for authentication to the app(s).

When on flights, I’m always looking to get on-board wifi, just so I can get things done.

For me, hitting CTRL+SHIFT+B in chrome to hide the bookmarks bar when i begin work has worked wonders.

I have several office machines, each with a different level of connectivity. My main development machine, for instance, can’t get social media. That’s because I don’t want to be distracted by that crap when I’m trying to solve problems. My presentation/streaming machine doesn’t get any kind of pop-ups. I have one place in the entire house/office with FB messenger installed, and it’s in an inconvenient place. When I want to tweak things, I use my pi-hole.

I’ve used Kiwix in the past to keep an offline copy of StackOverflow and Wikipedia.

I do agree that offline time is useful for tasks related to productivity, though I find it makes research tasks more difficult.

[Comment removed by author]

In my experience, at least for my tech stack of choice (Go primarily), the main tool I need for effective offline development is the habit of using TDD. When I follow TDD practices, I find that my code works pretty well in isolation, and can be tested and developed easily without access to any network.

A couple of years ago I let myself get lazy, and built an OAuth flow without proper TDD. Then I had a trans-atlantic flight (back when those were still possible, aaah the good ol’ days….).

I spent the first half of the flight writing an OAuth implementation that would work without a server, so that I could continue development.

Obviously this isn’t a complete answer. It’s just the one thing I found that I kicked myself over when it bit me.

The godoc binary from the go package is nice. By simply running the binary, you have all relevant docs presented on http://localhost:6060.

I use different computers for different activities on different projects in different ways. I do a lot of work on my OpenBSD laptop because it doesn’t run most of the tools I use professionally but I can jump to machines that do. The modern browsing experience on this thing is not good. I do what I need to do, then get off the computer.

I’m fortunate enough to have been working on a computer that runs CP/M for a customer. I’ve had quite a profound experience using it. Doing one thing at a time in one session at a time allows me to remain much more focused. The web is not a thing on CP/M. I’ve been writing the manual for this thing in restructured text on the device itself today because it’s that good for distractionless writing.

For me, I think adding friction and removing distractions are some of the best things I’ve done for my workflow. Removing distractions helps focus. Adding friction slows me down to think about the problem instead of tweaking bashing build till it works.

It depends a lot on your environment obviously. I’m mainly developing native code on Windows, so:

• The Windows 7.0 SDK is the last one with bundled offline documentation and a full build environment. Older tools have this too. All of my systems have winhlp32 so they can look at absurdly old documentation.
• The WDK is also great if only for documentation value. A lot of things are documented for kernel that exist in usermode too but are otherwise hidden, and it provides hints as to why usermode does things that it does.
• In C, header files also provide a lot of documentation.
• Git is a godsend.
• If all else fails, use the debugger to see how things work. Doing this offline implies doing it online first to ensure the system has all of the symbolic information it needs, but this is cached by default.
• Sometimes it’s good to save web pages for offline reference. It’s not quite “the best of both worlds” but when trying to achieve a particular goal, helpful resources without distractions can still add value.

For me, you never know what obscure mailing list will have a hint, let alone a solution to the issue you face. Trying to save everything you can think of locally won’t be enough,

The other fact is I have to work with machines that are not the same platform as the machine I work on. (I have one in the basement, but it’s ancient and I have it because I’m a freak.)