Years ago, I worked in the electronics department of the Kmart in the city where I grew up. I was a young fresh teenager attending college for both Computer Science and Music Theory. Each day I interacted with dozens of customers, coworkers, management, products, and store processes. I did not particularly like working at Kmart, but something happened during my time there that provided an unexpected practical application of the programming skills I had been taught in school.
Objectify the world
As I sat at the electronics counter of Kmart day after day, my brain began to unconsciously assimilate patterns–patterns of customers, product layouts, when and what people were purchasing, etc. Eventually these patterns broke into my conscious mind and were a curiosity. As I endeavored to understand these patterns better, I fell back on my programming skill to build a model.
In the programming world, there is a paradigm called Object Orient Programming, or OOP. In OOP, you create an object to represent a “thing.” That “thing” has attributes (information about itself) and methods (actions it can take). An object represents the entirety of what a thing is and can do.
Based on observation, and some clever deduction, I began to break the “things” in the store down into their associated methods and attributes. I have always had a thirst for knowledge and breaking down the “things” helped me better understand their purpose, how to use them, and what they were for.
By performing this exercise many times over, I acquired an innate ability to quickly look at a “thing” and break it down programmatically in my head. I gained a valuable life skill that has enabled me to confidently step into new situations, hobbies, projects, and more and have a level of immediate comfort and knowledge in how things work and why they work that way.
Create better relationships
Objects are cool! They can have fun attributes, such as how far you can shoot that water gun and soak your little sister, and relaxing methods, such as “play latest smooth jazz compilation”, but objects by themselves are boring. Objects, much like us, need relationships to flourish. Objects interact with each other through their methods, with methods often being defined by the user and relationship. For example, animals drink water. An object may have a “fill with water” method and a “drink water” method.
If the object was designed for a dog, it may look something like:
object WaterHolder
attribute type = bowl
method fill_with_water:
find_human
show_big_puppy_eyes
human_pours_water_into_bowl
method drink_water:
stick_head_in_bowl
lick_water
rub_wet_face_on_human
Whereas an object designed for a human may be
object WaterHolder
attribute type = bottle
method fill_with_water:
spin_off_cap
pour_water_from_faucet
screw_on_cap
method drink_water:
spin_off_cap
use_hand_and_place_on_lips
tilt
swallow
screw_on_cap
As you can see the methods and attributes of an object can help determine the purpose of object and how it relates to other objects. As I observed customers moving about the store, relationships between their attributes (age, gender, appearance, etc) showed in which products (“things”) and how they interacted with (used methods) them. It also helped me relate to them better.
Understanding how objects are built and relate to each other in a programming scenario has helped me look at the world around myself and identify the types of objects and how they relate to each other. This has been invaluable when learning a new skill, such as sailing, as I have at least an implicit understanding of how I need to interact with the people and gear around me.
Level UP
Whenever objects get together, they form a system. In the programming world, good systems have a very precise logical flow to them. As we look at the world around us, we see objects interacting inside of systems everywhere. At Kmart, that system started as soon as the customer drove their car onto the parking lot.
All of us have had experiences using applications that left us with a positive or negative feeling. Applications with positive experiences contain a well ordered system, or in programming terms, a good architecture. A developer should constantly be striving to create a better experience for users of the application. This comes through observation of usage patterns, user feedback, and other ways.
The world around us is built up of systems inside systems alongside systems. Programming taught me that the success or failure of any system is whether or not users will use and enjoy using the system. I have been able to reflect this knowledge into every area of my life, be it something small as to when and what food my dog likes to organizing a 700 person conference.
Give back
The next step, which we as open source developers embrace, is giving back. Systems, objects, and relationships are constantly being iterated on. New objects are created and inefficient objects discarded. As I have matured in my programming experience, how I code has changed. It is more concise, well written, and efficient. It interacts with other objects and systems better too.
Built into each of us is an innate desire to build and grow–to make systems and relationships better. I am no longer working at Kmart; now I enjoy my job and have even contributed to improving the system that is WebDevStudios. The things in my life that I am passionate about have/are improving as well. A few years ago I could sail a sailboat in good conditions fine; now I compete in any conditions against other very serious sailors and often come out on top.
The programming skills we have acquired on our journeys do not just have a few practical applications to our lives; they are the practical application of our life. If you let it, programming will change the way you perceive the world around you. It can provide a greater depth of understanding in how things operate and give you greater insight into how relationships work. Heck, it may even help you improve the relationship with your in-laws!
While I experienced much of what is described here, I found other programming-related skills to be more deeply ingrained in my subconscious over time. The “if-else” concepts of the old-time Cobol have popped up many times. Another example is that it taught me to be more aware of task prioritization as a result of the “critical path” concepts in basic project management – i.e. the module that has several dependencies must be programmed before one of those dependencies. Sounds logical when you think of it, but time and again I found those basic principles overlooked by people much, much smarter than I.
Hehe, the “lookahead” conditionals has me attempting to anticipate situations before they happen. It drives my wife crazy because she feels I am always 5 steps ahead of her!
Good read, Ben!
I cannot help but relate to it, as when I was studying Electrical eng. I used to solve circuit problems with programmatic logic. Not to mention the things which I still comment out as unimportant.
Great example. A lot of fields benefit from the use of programmatic logic. Including heated debates with your siblings 😉