You know, besides the essential actions such as eating and breathing, I can’t think of many things I’ve done for the vast majority of my life. One of those activities is computer programming. I don’t write code nearly as often as I used to. Rather than 40 hours / week, I now just dabble at work and with small projects on the occasional weekend. Most recently, I wrote a simple tool that scrapes the internet for news about our customers merging with or being acquired by other companies, so we can stay in the know. The skill that I do use constantly that I learned from programming is thinking.
Thinking? Yes. Programming teaches you how to think.
I can imagine a standard, and probably quite reasonable, reaction to that statement from someone who has never had to break instructions down to something so simple that a machine can understand the message. “What, you’re telling me I don’t know how to think?” No.. I’m being purposefully extreme with my statements. I am, however, telling you that your ability to process information and come up with a proactive plan would be improved if you wrote some code from time to time.
Virtually everyone has given some instruction or ask at some point in time. Even an inquiry as simple as “Hey, grab me a water would ya?” is an instruction to another person which will be met with a response. Think about what happens what you ask someone to grab you a water. That person instantly knows what you want. They know to get a “water” which could be a bottle of water, a cup from the tap, etc. They know how to get it. They know where you are and what it means to properly bring it to you without making a mess of things. Hands down, there is much more ambiguity in our average dialog than most people consider. The difference is, when you’re communicating with other humans, there’s another human brain on the other end to interpret the message, fill the gaps, and make decisions.
This is not the case with a computer, I don’t care how far machine learning has come. For machine learning to solve this problem, you first have to teach the machine to learn and then put it through years of “learning.” Substantially harder than just teaching it to get water.
So how would this work with a computer? Well.. Think about how your brain processes how to go and get water from the kitchen. Not at the “I need to get water” level.. No.. let’s get closer to the “bend my knee, move my foot, plant it on the ground, repeat for the other leg” level. A machine needs step by step instructions. It needs to know how to move, how to recognize water, how to retrieve the water, how to deliver it to you. It’s actually quite intensive.
Seven words, the initial inquiry was seven words, because a human already has all of the ability. By the time you’ve accounted for controlling motors, balance stabilization, object recognition, task management, ability to grasp / hold objects, you’re into the tens of billions of lines of code. Alas, I’m using a very over-the-top example to make my point, but that is, in fact, what it is like to spell things out for a computer. That is also why you should generally triple any timeline that a software developer gives you. It’s so easy for a human to envision how the pieces fit at a high level, but when you get down to it the devils are in the details.
The point is, since a computer cannot make choices or recognize patterns the same way that a person can, you have to spell things out at a level that most people are not accustomed to thinking. When you force your body to do something it’s not accustomed to, as with any exercising, it becomes stronger in that area. We take ours and others ability to process information the way we do for granted. It really is an amazing thing, something that we’ve been trying to recreate artificially for a while and are still just scratching the surface of.
So, let’s take a more realistic example. Let’s take a simple chat app that allows two people to chat with each other. What’s funny is, writing the “happy path” for this app really wouldn’t be too bad. You need some sort of user system, some sort of database for storing chat history, and some sort of basic interface which is basically a large text field (current chat text) above a small text field (what you want to send). It would take a few hours to stand all of the infrastructure up (should probably triple that timeline..), but it wouldn’t be too complicated. Before you knew it the computer would know how to facilitate chat with others.
The complexity with even the most simple app comes in the exceptions that usually don’t happen in design or controlled testing. There’s actually a whole other topic here I’d love to get into regarding designing for exceptions rather than use cases, but we can leave that for another day.
The gist revolves around asking questions like:
- What happens if a user loses connection mid chat?
- What happens if a user sends a message that’s too long for the server to process?
- How do we handle non printable characters such as 0-NULL or 8-BACKSPACE?
- What if two people try to chat with the same person at the same time?
- How are times handled in the chat database for differing time zones?
- et al
Each case needs to be handled, or the user experience will be laden with bugs.
Point being, if you want to be better at solving things, learn to teach a computer how to solve. It doesn’t know how to do anything. It has less solving ability than even the smallest child, and therefore, teaching it how to solve teaches you how to think at the most basic of levels. Applying this extremely detailed level of step-by-step thinking to bigger picture problems is a whole different story, but at least it gives a solid foundation.
Thanks for reading! Still trying to figure out if this whole blog thing is going to stick with me, but this was very enjoyable to write. Constructive feedback is certainly welcome.