Skip to content

The String #19: Go Manual, Before You Go Magical

When building a new product or feature using advanced technology, we need to start with the basics. With written language or pseudocode we can articulate and understand what we need to achieve.

Jonas Achouri Sihlén
Jonas Achouri Sihlén
2 min read
The String #19: Go Manual, Before You Go Magical


To start with. 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 through the human/computer interface.

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

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 at least. Those are:

  1. Code can be written in clear text for anyone to understand. Before we transform it with syntaxes 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

Going back to the headline of this issue. It is a timeless advice for all programmers and 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 we didn't see the end-product

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.

Thanks for reading. Until next time.