Coding like it’s 1999

“Run into an obstacle in what you’re working on? Hmm, I wonder what’s new online. Better check.”

If you haven’t already, you should start reading Paul Graham’s essays. In one on philosophy, Graham believes that many of the answers provided by philosophy are useless because “…of how little effect they have”. By that standard another of his essays is of high utility because it has affected the way I program. John Stuart Mill would be pleased.

In Disconnecting Distraction Graham tells how he finally dealt with the incessant distraction of the Internet — he simply disconnected his main computer from the network. The simplicity and possible effectiveness of this really intrigued me.

So, for the past two nights of programming, my own computer has been completely disconnected from the network. I pulled the cable from the router — and this is important — on the far side of the room. And that amount of friction was just the right amount that I stayed disconnected while coding.

What happened next

The number of times the mind wanders to check the Internet is stunning. It’s only when you can’t access it, that you realise it. It is from Disconnecting I take the opening quote, and it will ring true for many developers.

Without constant access, when you hit an error you’re forced to actually study what is in front of you, to fully understand what the computer is telling you. No more punching an unfamiliar and cryptic error into Google to see how to deal with it. No more fruitless detours down messy mailing list archives, hoping to find an answer.

Without distraction, a virtuous cycle begins. Less distraction means more productivity. And more productivity means an easier transition to the zone.

And there is a critical second-order effect: we all know that the more effort you expend in acquiring a piece of information, the more likely you are to remember it. This means that the knowledge gained during a disconnected programming session is actually learned, not just swapped into your working set from Stack Overflow, only to be quickly evicted when the next error occurs.

RTFM

Programming in Go means that disconnecting from the network is actually a pleasure. Go comes with a great tool — godoc — which allows you to spin up a local web server, serving up all the standard library’s documentation, and presenting it in an identical fashion to the online versiongodoc is another testament to the quality and coherence of the Go tool chain.

To me this was key — really useful, accessible, offline, documentation, in electronic form, to help me during coding. It’s been a couple of years since I did any serious Python programming, but one of the first things I would do before starting again would be to try mirroring the documentation. That way I would have a local copy, and could then disconnect. And I’d do the same for C++.

So, really 1999?

Perhaps not. I sent my first e-mail in 1993 so I’ve used the network for a long time, but coding-via-StackOverflow is a 21st century phenomenon. So try travelling back to an earlier time, disconnect, and reap the benefits.

Postscript

To run godoc in the manner described, set your GOPATH environment variable and execute: godoc -http :6060. The documentation will then be available at http://localhost:6060.

12 thoughts on “Coding like it’s 1999”

  1. This is also possible with languages like Python (pydoc) and Ruby (ri and rdoc). Perl was the poster child for this style of development as well with perldoc.

    I wish there was something for JavaScript like this and a culture of writing docs for JS libraries.

    1. In the spirit of this post, I can’t help mentioning BOOKS.
      I prefer to have Javascript “The Definitive Guide” open on my desk. It may seem odd but having a two page view of the text and knowing that I can flip a page or two back and forth to get to the next doc is really nice. I tend to remember where in the book I found the good stuff and it is easy to go back and find it.
      Old school, but remember: Everyday is a School Day!

  2. I recommend having an offline doc browser too. I’ve been using Dash [0] (OSX only, but there is also Zeal [1]for Windows and Linux) and I’m pretty happy with it — I know tend to read the documentation first before heading to StackOverflow or any other site to (let’s be honest) almost copy-paste some code-snippet

    [0]: https://kapeli.com/dash
    [1]: https://zealdocs.org

  3. Quoting Hans Gruber: “Benefits of a classical education.”

    I’m an old guy. I’ve learned that all too often the documentation lies. I go online for help in two cases.

    One, the offline documentation is crap (dark looks at Canonical) or unavailable (darker looks at Microsoft). Google gives you the possibility some poor schmuck has been down this road before you and blazed a trail. When you are the one blazing, it helps to have a background in figuring things out on your own. I think too many youngsters have gotten used to treating open source tools as building blocks. When a block doesn’t fit, they chuck it out and try another. They don’t seem to consider that they might be asking the wrong question, and it’s their application that’s the problem.

    Two, when I’m learning something new, and need to look at a sample. Most API help (on- and off-line) is abysmal. The typical complex API requires several calls to set things up for the main event, but the usual sample is nothing more than the method prototype with arbitrary values stuck in place of the arguments. Unfortunately, a lot of online samples are either poorly done or simply wrong. You still need the ability to dissect a poor sample, glean what is correct, and go forward on your own. Too many applications are built on top of poor samples that were copied with an uncritical eye.

  4. “Without constant access, when you hit an error you’re forced to actually study what is in front of you, to fully understand what the computer is telling you.” – makes me think I need to disconnect sometimes.

  5. Hey Philip,
    how are you? Hope things are well.

    You said “we all know that the more effort you expend in acquiring a piece of information, the more likely you are to remember it. ”

    I used to strongly believe in this as well, and it’s often true enough. E.g. even after learning something the hard way you may forget some details but at least some critical points can be recalled later on. In my early 20ies I remembered pretty much anything I encountered.
    But more and more I find this to be less true for me.
    I’m only 30 years old and I like to think my memory is still sharp, but I’ve been experiencing that my reality has been much more nuanced than this simple formula.
    I used to swear by “learn the hard way, I’ll remember forever”, now my stance has pretty much reversed: I know that I forget many things even if I learned them the hard way (very frustrating especially on repeat occurences) so now I sometimes deliberately try to find quick things to try out and keep the learning step for when i find something that seems to work, as that seems to be the better strategy now for me in certain scenarios.
    Recollection is probably affected by many other factors (time pressure, stress, other things on your mind, real life, age, etc) and I’like to understand it better, I wonder what other people in the industry think of this, especially across the age spectrum.

    1. Hi Dieter! Yes, this is an age-old question, as we age.

      I feel your pain. That said, I do hope it’s countered by growing experience. While recollection may be more difficult, I do believe that the subconscious pattern matching system one builds through experience generally compensates.

Leave a Reply

Your email address will not be published. Required fields are marked *