I’m convinced our deepest desire is, by paying the cost of time, to be shown a glimmer of some fundamental truth about the universe. To hear it whisper its lessons and point towards its purpose.

And, if you look hard enough for these lessons, you will find them. Whether they are a manifestation of your mind or can be held in your hand, once you see them, they remain yours forever.

Programming offers significant parallels to life. We are tasked with creating something–something whose sum feels more significant than the parts. Like life, it is a test of bounded creativity. There are rules we must follow, some we should follow, and others we are free to ignore. Programming offers us a glimpse, however ephemeral it may be, into some fundamental truths about the world in which we reside.

## The Four Parallels Between Programming and Life

### Iteration is progress.

Did you know, if you started the month with a single penny and it doubled every day, you would have \$163 on the 15th of the month? Surely, you think, there must be a better way to make \$163 in 15 days. But, if you wait another 15 days, you would have more than 5 million dollars.

Go ahead, I’ll wait while you do the math.

In programming, we use the term iterate to indicate repeating something. In a more formal definition, it is repeatedly applying a procedure to the previous result of that procedure. For example, adding the numbers 1 and 1 to get 2, then adding 1 and 2 to get 3, and so forth.

When we iterate, we look for feedback. We wait for some condition to be met so we can either stop iterating or adjust how we are iterating. If we fail to listen for that feedback, we can get stuck in an infinite loop.

Life is no different. We often expect we can jump from point A to point B without ever defining what point A or point B is. And, even when we identify those points, we expect an immediate move from start to finish. Instead, what is often the truth, is we must incrementally make our way from beginning to end. We must listen for feedback that tells us where we are so we can make adjustments.

When we have goals, progress can often feel–for the first few days, weeks, or even months–non-existent. We’re often enticed to start over or start fresh. But in doing so, we fail to realize, while we might not have reached our destination, we are somewhere far past where we started. A complete restart isn’t necessary, we just need to make some minor adjustments.

Stop starting over. Let iteration be the force the creates progress.

### Most complex problems are collections of smaller problems that have already been solved.

Even the most fascinating apps are a series of mostly mundane solutions to mundane problems. In fact, most of the solutions implemented within a program are nothing unique. It is the combination of those ordinary solutions that creates an extraordinary product.

In programming, there are different ways to use these quite-ordinary solutions. One way is through a term called abstraction. To abstract something is to move something away from something else.

In computer programming, when we abstract something, we are often building higher-level technology on top of lower-level technology. This makes it easier to work with lower-level technologies.

For example, most programming languages are abstractions of the enigmatic binary language (0s and 1s). They put a layer between us and some more fundamental, but cumbersome, level of interaction with the computer. These higher-level languages allow us to focus on higher-level problems.

Another way we can more efficiently solve problems is by using someone else’s solutions. You may have also heard the term library. And, while I am not speaking of a poorly lit, dusty, and quiet location where books live, it isn’t far off.

A library, in programming terms, is code that someone else wrote that solves routine problems. It also abstracts away those things which aren’t absolutely fundamental to solving whatever problem you have.

For example, if you are writing a program that requires someone to log in to use your application, you could write the code to encrypt and decrypt passwords yourself, or, you could use code written by someone else to do that for you. With the latter option, we free up time to focus on more significant problems our application is trying to solve.

All of us use abstractions and libraries in some shape or form. For example, the grocery store is an abstraction of producing our own food. A car is an abstraction of traveling on foot. An oven is an abstraction of building a fire. These are layers we place in front of us that allows us to allocate time to higher-level problems.

Reinvent the wheel only to learn how to make a wheel, not to drive to the store.

### How you define a problem is how you will solve it.

Recall the story of a truck that drove under a bridge and got stuck. Engineers spent hours trying to figure out how to move the bridge. A small child came up, face to face with the tires of the truck, and said, “what if you let the air out of the tires?”

From the child’s vantage point, the problem wasn’t the bridge was too short, but rather the truck was too tall.

Most people can solve any problem. In fact, most problems state the solution. For example, if the bridge is causing the issue, the answer is to do something with the bridge. If, however, the problem is that the truck is too tall, then the solution–almost glaringly obvious–is to make the truck shorter.

### The arrangement of parts is much more important than the parts themselves.

What does the Google Maps codebase, the Declaration of Independence, Martin Luther King Jr.’s I have a dream speech, Steve Jobs’s 2005 commencement address, and my first app, Hello, World have in common?

The access to the same 26 letters of the English alphabet.

There is very little that is more fascinating to me than the written word. The written word is one of the most powerful technologies that emerged from humans.

Yes, I use the term technology because–even carved into the wall of a cave–it fundamentally changed how we persist information. No longer was data constrained within the boundaries of our minds.

While the purpose of the written word was initially linked to record-keeping, it quickly became a way to spread ideas. Some of these ideas would anger, and others inspire.

Every language (including computer language) has subtleties when transmitting information through writing or speech. The words and their constituent parts may be slightly different. Still, however, a language is a set of symbols that can be arranged into what seems to be an infinite number of ideas.

For example, in the English language, there are roughly 29 symbols that I can use to represent nearly my entire universe. I’ve mentioned the 26 letters, but it is also helpful to have access to periods, commas, and question marks.

Those 29 characters are available to you, me, and were available to Steve Jobs. Yet, each of us, throughout our lives, will follow different trajectories based on the combination of letters we chose to believe and speak into existence.

Interestingly, while we often add words to the dictionary, we don’t usually add letters. This means, at the most fundamental level, that all the ideas that can exist, already do, with their constituent parts quietly waiting for us to shuffle them into existence.

Les Brown sums it up well with this thought experiment:

Imagine if you will, being on your death bed. And standing around your bed–the ghosts of the ideas, the dreams, the abilities, the talents given to you by life.

And that you, for whatever reason, never acted on those ideas. You never pursued that dream. You never used those talents. We never saw your leadership. You never used your voice. You never wrote that book.

And there they are, standing around your bed, looking at you with large angry eyes saying: “We came to you. And only you could have given us life! Now we must die with you forever.”

The question is — if you die today–what ideas, what dreams, what abilities, what talents, what gifts, would die with you?

Thank you for reading!

woz