All rights reserved.
No part of this book may be reproduced in any form or by any electronic or mechanical means, including information storage and retrieval systems, without written permission from the author, except for the use of brief quotations in a book review.
I dedicate this book to everyone who decided to be a programmer when there were no computers in peoples homes and it was considered unwise to work with computers as a career choice.
THE MATRIX
I meet with a lot of founders, CEOs, CTOs, investors, and other people who want to talk about new software development projects. Regardless of how exciting that may sound, after many of these meetings, I am reminded of the following story:
William Gibson the sci-fi author wrote his books on a type writer. He used to go to bars where computer geeks went after work and he listened to them while they talked about computers. He attempted to create verbs from various words he overheard and then use them in his books. After writing several successful sci-fi books that inspired Matrix and other films, as well as coining the term "Cyberspace," his typewriter broke down and he decided to purchase a computer. Finally, he had the opportunity to learn how to use one! It wasn't the experience he had hoped for. He imagined computers to be silent, eternal machines powered by crystals, but instead he experienced the process of swapping floppy disks on an Apple IIc and he naturally assumed the computer was broken.
In these meetings sometimes I feel like Im talking to a sci-fi author and Im about to show a demonstration of an Apple II computer. It occurs near the end of the meeting after someone say how hard can it be?.
This is a valid question even if its not exactly meant in that way. Why is it hard to answer this question in the first place?
It is difficult because software is intangible. This means it cant be directly accessed with any of our senses. Sure we can look at the result on the screen, we could touch a USB stick or measure the electricity in the circuits but the logic that constitutes the software itself have to be experienced in the brain by reading and understanding the instructions. Or vice versa, by making up instructions for logic to process information we can create software. It not visible what software is and it is hard to know who possesses the competence to create it.
This phenomena is so greatly exploited by large consultant companies and recruiters that it has become normal and part of the industry to not know much about what you are working with. So many professionals dont know the answer to how hard can it be?.
We can also conclude that we have arrived at William Gibson's predicted technological future of about 40 years ago. It is possible to wear VR glasses and look into the Metaverse in the same way that Case jacks into cyberspace. Everything I could have imagined as a child is now a reality. I could write programs for the rest of my life and still not try even 1% of what's available. I'm able to keep this perspective because some fundamental things haven't changed a bit (no pun intended).
The C program in the below picture looks the same today as in 1978.
"Hello, World!" program in C by Brian Kernighan (1978)
Despite the fact that few core concepts, such as the program above, have changed in the last 40 years, learning about programming and computer science today is difficult.
For this reason I will discuss well-known concepts in this book. The ones I believe it is critical to understand. Things do not appear out of nowhere in technology. These concepts will help us form a bigger picture of where we are and where we are going.
EVERY DAY LIFE
S oftware is typically defined as a set of logic instructions that are translated into machine code and executed by the processor. The phrase was coined around 70 years ago, and software remains largely unchanged in this regard.
It's a very specific and yet generic description. It includes all software. It can, for example, be used to describe both a project to develop an an Ethereum wallet and another project to develop electronic timetables for public transportation. People must be more precise when communicating with one another, but without using terms like logic instructions or machine code.
Hardware and software platforms, version numbers, and software names are all used casually. In the previous example to describe the logic context, the platform on which the software runs, the term Ethereum is required. The term wallet is required to describe the type of functionality that the end user may expect. Because the Ethereum project runs in the cloud, we don't have to think about what hardware it runs on, but if we did, we'd most likely added something about it, for example:
- I played Battlefield 3 on my PS3.
The PS3 section provides vital information about the game's hardware, allowing us to deduce what graphics the game is expected to have and how we will provide user input, via a PS3 game controller. If it is important to us, we will also use version numbers. Many people care a lot about the most recent iPhone model number. If a person instead say:
- Do you want to Netflix and chill?
Now this can mean several things, and even even in the realm of computers, because if you live in a dorm room it might mean that it will be on your laptop but if you live in a house most likely a TV will be used, and there will be a device connected to the TV, most likely a Google Chromecast or an Apple TV. In the end, video will be streamed, but the streaming part becomes superfluous in comparison to the user experience, which is very similar to watching TV.
Yet another example is if someone say:
- Im testing a math application for 3rd graders.
Or:
- Im using a math application for University students.
This suggests that they will not have the same user interface, but that they will both most likely have tutorials with questions and answers.
- I need a USB-C cable.
Unfortunately, humanity has not discovered a better way to name the distinct appearance of the copper connection at the end of a cable. We use words describing hardware, hardware standards, software, and versions of software to refer to the capabilities, functionality, and user interface based on most people's experience with software and what can be seen or marketed.
Other than the things we usually refer to, there are other factors that influence how software works. It's not just the programming language; it's also what data is available, standards, and business requirements.