Coding, from 20 years ago

I was updating a few things in the Todo.txt Android app earlier today. I have a second hand Pixel device that I use for testing as I develop. Since I hadn’t used it for a few days, its battery was fully discharged, and it’d be a short while before I could use it to run and test the code. I had the option of using one of the many software emulators, but they are slow on my system1 when run alongside the Android Studio and multiple Chrome instances. Instead, I decided to just code the stuff, document it, and write a few tests till the Pixel was ready for use.

This was different from my usual development practice of writing a few lines of code and then executing to see if it’s working as expected before continuing. I had to think ahead, and structure the code a bit more. I had to mentally execute the method, and its tests. I wrote a bit more comment docs than usual to account for lack of instant execution confirmation. It felt odd and marginally discomforting at times. But it was fun.

Towards the end of the session, I realised that it was also more productive. I had almost completed two of the three planned updates by end of the hour-long session. Not taking frequent pauses to compile-execute-observe-confirm freed me up to continue planning and coding further and faster. It also stopped me from taking detours on updating unrelated or tangentially-related bits observed in the execution.

The session reminded me of how we used to write code when I was studying engineering. Compiling and executing even our C programs was slow on my PC back then2. So, executing was infrequent, and often followed long periods of writing code, and running through the flow manually multiple times. If the program required internet access, it meant even more coding and manual verification before testing it by execution3. Fond memories :)

Anyway, the Pixel is charged now. I can now test the morning’s code and, if it works, commit it, and move on to the third update.

  1. I use a 2015 MBP, though well specced. It has 16GB RAM, 3.1GHz dual core i7, and 1TB SSD. 
  2. I had a best-amongst-peers custom assembled PC. It had 256MB RAM and 8GB HDD. I can’t recall the processor details, but it was a Pentium II. 
  3. This was after I got a PC. Before that, I’d write the code on one of the PCs in the computer lab, print it on dot matrix printers, and take the printouts back to hostel/home. There I’d go over the code, update it with pen, and then go type it in at the lab the next day to execute and debug. It was more fun than it sounds. 

2 kinds of people…

There are two kinds of people…

One kind likes to have the trash can / recycle bin on their computers empty. They take every opportunity to right click and select clear / empty trash. Emptying that trash can provides them with a cathartic release.

The other kind treats the trash can as another storage folder. It frequently has thousands of files, residing in there for months. Clearing the trash can brings to them a dreadful feat of loss—of the unknown unknown. Clearing the recycle bin is only done when system space runs low, and even then, painstakingly, on a file by file basis.

Continue reading 2 kinds of people…

Is Ctrl+Z handicapping us in the real world?

Has an easy undo feature trained us to work at high-speed but low focus?

When it’s always easy to undo and correct, there’s no reason to focus on getting things right, or even thinking things through before doing them.

Handwriting (or typing on a typewriter) a document meant being focused on the task because any mistakes meant ugly cross marks or rewriting the page.

Similarly, working with physical objects – in a carpentry class in college, or cooking a simple dish – required strong focus. A wrong cut in a wood slab meant a wasted slab or a hacked joint. A dish could end up overcooked or unsalted.

But when working on a computer, any errors due to a lack of attention can easily be rectified with a simple undo, removing the need for full focus in the moment.

As we (I) spend more of our time—work and leisure—on computers, we may have trained ourselves to expect the undo feature everywhere.

This mental training (‘all errors are undoable’) creeps into our non-computer activities and interactions. We may be forgetting to stay fully focused in the moment, to think ahead (before we speak/do), and thus may be becoming more inefficient/incapable than before.

Continue reading Is Ctrl+Z handicapping us in the real world?