Lent: Giving up being always on-line

I gave up always-on connectivity for Lent.

Well, truth be told, that wasn’t quite how I planned it. It just happened. On my most recent trip out-of-town I was worried about theft and damage more than I normally am. Given that a “normal” business trip for me often involves third world cities with 90% unemployment and an hourly murder rate, you can guess what horror I was dealing with: teenagers.

So this is what I took:

That’s a Nokia 110 and a very old IBM laptop running Linux. The laptop did have Wifi, but no bluetooth. The Nokia had a very basic bluetooth, but has no capability to tether a laptop for internet access.

I’m not a luddite so I set myself up with the best I could using the hardware available. That’s a modern Linux distribution — which in itself is interesting: no one would try doing serious work on a Windows 98 system, which is probably what that laptop once ran.

Between bouts of nostalgia, I paused for reflection: roughly 15–20 years ago I was running something very similar to this kind of environment, and I was often to be found programming in the lobby of some hotel after delivering a tech class in some distant city. What have we gained, and what have we lost?

What was difficult

Not being online was a moderate challenge.

• All my accounting and business systems are SaaS, so I couldn’t do anything about the backlog of bank reconciliations that I need to catch up on.
• Navigation was a problem. It’s been a long time since I’ve navigated without GPS and it took a while to get used to it.
• I couldn’t look up the solution to any programming problem, so I defaulted to being very conservative in what I worked with: just the stuff I knew well enough that I wouldn’t need to look anything up.
• No Slack messaging. I came back home to a Slack constellation of red numbers on just about every channel. I’m running a mid-sized data science / AI class at the moment and a large number of students had homework questions and submissions.

Perhaps a bit of better planning (both short-term and long-term) would have resolved these problems. Maybe if I’d chosen GnuCash or OpenERP instead of Saasu accounting wouldn’t have been a problem. I could have carried around a physical GPS device, or taken some cheap device that could run google maps offline. I could have cached lots of documentation (as I used to do), but a lot of websites and tutorials don’t lend themselves that very easily. I could have installed a Slack client, but with long round trip delays it would have been functionally equivalent to email.

What surprised me is what I struggled with the most. Photography was terrible. I’m not a serious photographer, but I take quite a few pictures on my usual phone, which backs them photos up automatically after which they get turned into panoramas and stories and so on. But the Nokia camera has awful resolution, and I don’t even have a way of getting the pictures off it. We have raised our expectations of acceptable photos and videos very quickly in the last decade. This doesn’t seem to be slowing down, so what sort of cameras will we be using in 2025?

Then the other big problem was ergonomic. The laptop was clunky and heavy, it didn’t fit in my backpack very well and the battery life was terrible. It was probably mediocre at the time, but between the decay of the lithium battery and our increased expectations of what is normal, I found it frustrating. I was chained to the wall. I couldn’t move around or choose to sit outside to work for a while.

The Nokia had the opposite problem. It was so small I kept thinking I’d lost my phone, not realising that it was still in my pocket.

Where the internet has made no difference

By running a modern Linux distribution, I took advantage of Linux’s heritage, steeped in a world where being off-line was normal, and internet connectivity was brief: a world where we aren’t bound to monthly subscription SaaS services.

• Instead of Google Docs, I wrote text in emacs. I could have used something more normal (e.g. LibreOffice; or even run Microsoft Office in Wine on Linux) but why bother? Real-time collaboration would have been a problem of course, but the vast majority of documents I work on have one author only.
• Email and backups were batch-mode: I was able to get to wif intermittently during the trip (e.g. at the airport). I suppose pre-wifi this would have been like the times that I dialed up to get online. The IBM laptop did actually have a built-in modem, so I could have done a full nostalgia trip and listened to it squawk if I’d known of any ISP left in the country who still offered dial-up services.
• I just ran git push less frequently than I normally would, but everything else in git works as well off-line as it does online.
• All my data science tools were there on my laptop. The night before I left I’d run pip install jupyter ; pip install scikit-learn and it had finished by the time I packed my laptop up. We think of big data, AI and machine learning as modern things that require giant server farms, but most of the prototyping and testing can be done on sample datasets that are small enough to fit in even quite an ancient laptop.
• My wife called using a phone number instead of a WhatsApp contact. Skype redirects to my mobile number anyway, so no-one would have noticed anything if they had tried to Skype me.

Hearken to a simpler time

I’m not being rose-eyed for the past: I’m aware that there were some serious limitations. But what I found fascinating is that there were some advantages.

• I slept better. There was no point in checking my phone for email before I went to bed. Maybe the Nokia 110 has a snake game or something, but all I did was just set an alarm. Many hours later, the alarm rang. Then I got up. That was the entirety of my interactions with the phone in bed.
• Focus was easy: I wrote more text in one afternoon than I have done in weeks, possibly more than I’ve done this year. There were no interruptions. No email, no Slack, no chance to waste time browsing reddit or Hacker News.
• There was so much spare time! At the end of the day I read, uninterrupted.
• Breaks were real breaks. I had to put my laptop down, because it couldn’t go anywhere away from AC power for very long. I would walk around and get some fresh air. I watched some children play hide-and-seek for a few minutes because I couldn’t bury my face in my phone. Well, I could, but it was pointless. There was nothing there.

What we need to resolve once and for all

This was all extremely illuminating given my most recent data science project which was for a famous company that runs a lot of software development projects.

I analysed around 200 projects and identified some factors that can predict when a project is going to miss deadlines. I’ve done this before for other customers — I’ve got it mostly automated for JIRA and it drives the smarts in http://www.queckt.com/ if you want to take a look at it.

In most organisations there is one extremely clear predictive factor associated with missed deadlines: the word “meet” or “meetings” appearing in a JIRA ticket. But this company runs development fully-remote. You don’t ever meet in person: it’s all communications via Slack, or teleconference or whatever else the team wants to use. So the usual “meeting” factor predicted nothing. It didn’t occur enough to be terribly useful anyway.

But what did predict a deadline in peril on a fully-remote project was the density of Slack communication. If there is intense back-and-forth communication with large numbers of messages being exchanged with short deadlines between the development team, then don’t set your hopes on the next release being on time.

At the time, my interpretation of this was simply that there must be a lot of confusion about what’s required and that a lot of communication is going on trying to resolve it.

But now I’m wondering: what if the Slack communication is not just a proxy for confusion? What if it is causative? When I couldn’t interrupt myself, nor be interrupted, I was far more productive. Programming is a cerebral activity — even more than writing — usually done alone: is it better to take long periods of uninterrupted thought — even if it means reducing communication with team mates?

This is not just an academic question. One of these two things must be true and the implication is obvious:

• Instant messaging and communication is a net benefit to software development, or at least not particularly harmful. If we have to mandate instant messaging, should we?
• Or, instant messaging and always-on communication in a development team is a bad idea. If we have to ban instant messaging from our dev teams in order to get the best out of them, should we?

So let me announce here a project: I would like to measure this. I would like to create a distraction index measure, derived from corporate emails, instant messaging, and so on. Then I’d like to see how well the different distractions correlate with late projects, delays, milestone slippages, etc.

If you are in a company that has a good number of software projects on the go, and it’s worth a bit of money to you to know how to optimise your developer’s time, I’d like to talk to you. I’ve got code to analyse a bunch of other useful predictors too — such as the language used in git commit messages; the topics used in your JIRA tickets; and numerous others — so whatever happens you’ll get something worthwhile out of this.

Obviously, if you are working for Slack, or Atlassian or another instant messaging company, and you’d like to know your impact for better or for worse on your customers, I’d really like to talk to you as well.

Get in touch with me here: gregb@ifost.org.au

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!