I’ve tried to explain what I do at my job as a programmer to my family and friends. Still, they often seem to get lost in my explanation when I say it’s like I build robots that live on the computer to do repetitive and mundane tasks for me. That might not be the best explanation, but the main takeaway I want to emphasize is that a programmer’s job is not so different from other jobs. To give you an idea, I often compare my experience as a cashier in a grocery store with my experience developing my software. That may sound weird but stay with me. If a customer brings an apple to my cash register, I will need to see if it meets the right conditions. What kind of apple is it? Do I need to weigh the apple to calculate its price? Each state will then lead me to decide what to do next. This process is just simple logic, but we need to think about these cases as a programmer. Like what if someone brings in a dog? Yes, a dog! We don’t try to find the barcode on the dog to scan; we know that the customer owns the dog and is just bringing them past the cash register. As a programmer, our job is to figure out what to do by thinking critically and practically. However, we can say the same about other jobs too.

The Recipe Inventor

The post Hard Coding Concepts Explained with Simple Real-life Analogies by Samer Buna gives a great analogy of the coding experience. He describes coding as writing a recipe. The language and order the writer uses for the formula are critical, and if not done correctly, the final result could end up in chaos. The video Exact Instructions Challenge perfectly illustrates this; I’ll give you a summary. The father tells his kids to write him instructions on making peanut butter and jelly sandwiches step by step. Most would believe this would be a simple task. How hard could it be? The father gets the instructions from his kids. He then follows the steps. “Put the peanut butter on top of the bread.” and “rub the jelly all over the bread.” At a glance, these steps seem self-explanatory, but when he begins making the sandwich, he starts putting the butter on the literal top of the loaf and rubs the jelly on literally all sides of the bread. The problem isn’t the father conducting the instructions; the steps are not specific enough. What is the top of a piece of bread? Where on the bread should the jelly be spread? As programmers, we constantly have to ask ourselves these kinds of questions. Are our instructions giving enough information for the computer to execute what we need it to do, and are they in the correct order of operations?

The Therapist

I’ll continue with the peanut butter and jelly sandwich analogy; even before making the sandwich, we have to consider what kind of sandwich they want? Blackberry or strawberry jam? It’s our job not just to write the code but to ask questions to our clients to confirm their requirements. Sometimes we also need to give them hard truths. What if we can’t deliver what they want? We ran out of jam. When this happens, we need to reassure them. We could postpone making the sandwich until we get more or make our jelly with the grapes we have in our kitchen. It’s not enough to say, “we don’t know how to solve the problem.” We need to brainstorm ways to help our clients understand the situation and develop potential solutions to lead them to the next steps. Like therapists, we need to ask these questions to help guide the client. With proper communication on the expectations and what is possible, we can help them get the PB&J sandwich they requested. Requirement gathering and setting boundaries with the client are essential.

The Gardener

Most people understand the analogy that a project is like constructing a building. First, the architect creates the blueprints. Then the contractor digs the foundation, builds the structure, and finalizes the appearance. Once all tenants move in, minor maintenance is needed occasionally, but the main components like the foundation and structure are set in place and aren’t easily changed. This system may work for some programming projects as it is comparable to planning, prototyping, executing, and sustaining the software created. However, in a recently read book called “The Pragmatic Programmer,” Andy Hunt and Dave Thomas explain that programming is more organic than concrete in structure. Programming isn’t rigid. A programmer’s code needs restructuring, refactoring, and monitoring to keep it alive, much like how gardens need new pots when their roots become too big or trim when they get too many leaves. Gardens are sensitive to change, and minor modifications to their soil or sunlight can affect their entire ecosystem. This sensitivity is a big concern for programmers as a seemingly minor update can break their whole system. A building is repeatable, but gardens grow in unexpected ways that need these constant revisions and adjustments. A programmer, just like a gardener, understands the importance of the continuous monitoring of the health of their system.

The System

Hopefully, you can see how programming relates to so many jobs out there. Everything is part of a system, and I think it’s beneficial to pay attention to our environment and appreciate the systems that make them work. Everyone plays a role in the system, and I believe it is important for us to have a programmer’s mindset and drive to continuously iterate, modify, and update our systems and techniques. In a constantly changing world, we need to be logical and pragmatic. It’s not enough to view our systems from a narrow lens; learning from each other and sharing knowledge is valuable and essential. A programmer sees the value of everyone and everything working together.