Skip to content

Go Manual, Before You Go Magical

With writing clear text and using pseudocode we bridge the gap of the human - computer interface.

Jonas Achouri Sihlén
Jonas Achouri Sihlén
2 min read
Go Manual, Before You Go Magical

In my own learn to code-journey, one of the courses I have enrolled to is CS50 - Introduction To Computer Science.

In the first lecture David J Malan brilliantly explains the mental model around programming.

More specifically, how we communicate and build programs via the human/computer interface.

David uses the classical phone book to showcase how algorithms work.

Let's have a quick walk-through.

Task: How To Look Up David In The Phone Book

1. With the help of pseudocode we highlight the actions or functions.

2. Continuing with the conditions/branches.

3. We should not forget the loops. Very important. Making sure we go back to an action that can complete the process.

Where are we getting from this little exercise?

There are two things I want to bring up:

  1. Code can be written in clear text for anyone to understand. Before we transform it with syntax and scripts.
  1. By stating a step by step process makes us think through the basic needs and actions in a clear way: "Writing is thinking".

The above statements may seem obvious for many. But yet it is so easy to jump into programming mode and write that superscript that will solve the problem you have been thinking about for so long.

I immediately draw parallels to this excellent article on Spotify Design .

Stopping up and think things through can be a good idea. Just like Mark Kizelshteyn and Mat Budelman points out.

It’s tempting to get caught in the trap of applying a promising new technology like Machine Learning to every problem, but try and resist this temptation

The main message I want to send is that a "going manual before we go magical" is a timeless advice for all creators in tech that don't want to rush things with the risk of a disconnection through the human - machine interface.

I have many times analyzed and created requirement specs and functional design docs back in the "waterfall-days". In those, there were step by step guides on how the system should behave based on the end-users expectations and needs. In written form. I used to hate those artifacts, since it took weeks or months just to see a first version of the product in weeks or months.

Waterfall or agile, it doesn't matter which ideology you adhere to. Starting with the basics applies to us all.

We are all upgraded humans that currently use technology.

We don't want to become downgraded humans used by technology.

This is what I listened to while writing this blog post.

Photo by Dose Media / Unsplash