(Coding: the toxic relationship that broke me, bent me. and I hate to admit, it made me better)
Originally posted on Medium under the same title
I came back. My restlessness flared up again, and I needed something to divert my attention. Besides, using a pen name “quill of a coder” as an identity, and not writing anything on how coding has been a part of me seems to be a little ironic, don’t you think?
I believe programming has changed me in just the way I wanted. It forced me, broke me, bent me backwards. And even after all these, it looked me dead in the eyes, and told me “you think you’re good? Think again”. It made me accept my defeat. It made me realize I am no better than anyone else.
Yes, we have a toxic relationship. And yet, I chose to endure that toxicity. Because it was worth it. And now, I am paying homage to that toxicity. We have to show gratitude where it’s due. So here it is.
1. The worst-case scenario
We, humans, like to hope. Hope keeps us alive. But the problem is, hope doesn’t solve problems. Hope doesn’t make things work. Hope doesn’t make dreams come true. We face scenarios that couldn’t possibly get any worse.
In programming, a very simple phenomenon can be, the user input the payment data, but before the request was processed and saved on the database, the internet was disrupted. Or perhaps, someone uploaded a 5GB image file. For all these scenarios, we write exceptions, redirections, and graceful handling. Erasing anything that might be an obstacle for graceful sustaining.
Coding doesn’t erase “hope”. Rather it seals the deal for the dream that we hoped to come true. Or I would say, it teaches us to hope with precision.
2. Signal vs. Noise
The city of Königsberg was divided by a river containing two beautiful islands. People built seven bridges in different places for their convenience. And this birthed a local puzzle, “if they could take a Sunday stroll through the city crossing every single bridge exactly once without repetition?”
Clearly, for this we needed to know about the city’s geography, city planning, and walking paths.
However, Leonhard Euler looked at the city, threw away the maps, city plans and beautiful islands. Rather, he turned the landmasses into vertices (or nodes) and the bridges into edges. From that, he proved, a path only exists if the number of vertices with an odd degree is either 0 or 2 — a simple mathematical fact. His solution laid the foundation for “Graph Theory”.
Even seemingly important details like geography, city maps proved to be unnecessary noise blurring the actual signals.
While doing competitive programming, I have seen many times programmers, including myself, lose their way in the noise, solving something entirely different than the actual problem. There, I learned, coding constantly asks “what do you actually want to achieve? What is your preferred end result?”
It doesn’t make decisions for us, but forces us to focus on what we actually want. Forces us to constantly but consciously separate signals from noise.
3. Assumptions Are The Starting Point
In Architecture, we can see a crooked wall. In Civil Engineering, we can see damaged dams and polluted water. In software engineering, we see “The website returned HTTP 500”, and we “assume” the database crashed.
We are taught assumptions are dangerous. We know we can’t take any action based on mere assumptions. But in programming, the assumptions are the starting point.
Sharing a particular experience, I was working on an API module, and needed to test it. I created a new user account. But after registration, I couldn't login to the user’s profile. I knew the authentication module had been built months ago, and was tested thoroughly. The authentication module shouldn’t have contained any bugs. But the error message said otherwise. It said — there’s no user with this particular ID. My first assumption was —the user’s authentication info couldn’t be saved on the database. So there might be a disruption in the data flow. I started my debugging from there, putting flags at the starting and ending of every function on that workflow. And later found out, while creating the profile of the user, where profile for the user, a new ID was being created. Essentially 2 different IDs of the same user.
So the data flow was working perfectly. But the problem was a tiny logical mistake with large consequences.
Software is intangible. Here, we can’t point to a broken beam or a cracked wall. We can only begin with symptoms, form assumptions, and test them one by one.
Coding says — assumptions are not conclusions but the path for investigation.
4. "Works on my machine" Is Not A Conclusion
“Works on my machine” - a success story that makes us feel invincible. And a horror story that dismantles our ego in a blink.
At least once, every programmer has said “it works on my machine just fine” after running their code on another machine. Mine happened in the university's first semester, during the semester final’s project demonstration. My code was fine. But the IDE on the university computer had a different set of plugins. Luckily, my professor understood, and gave me decent marks anyway.
We assumed our reality was absolute, and made conclusions. But now, different environments, language versions, browsers, time zones, dependencies, even tiny configuration differences can completely change the outcome. And we start thinking, what works for us and our environment, may not work for others. Either we need to have a universal standard, or a dynamic approach that adjusts itself to another environment. Either way, we had to accept, even reality wrote its name on the list of things that change.
“Works on my machine” —a single reality that taught me our reality may differ from one another. And teaches us the value of adjustments.
Who knew coding would be giving relationship advice?
5. Imagination Is The Real Engineering
This one’s my personal favorite. This one took me the longest to take in.
And the one I am most grateful for.
Depth-first Search (DFS) and breadth-first search (BFS) —the problems that made me realize, not communication, but imagination is the key. Problems that even team collaboration couldn’t fix. Team collaboration can birth ideas. But to think deeply and broadly, one needs to do it alone, and one needs the power of imagination.
We know software is intangible. We can’t see data flow, we can’t see function calls, we can’t even see the database tables or relationships. Yet we imagine dataflow, database relations, login workflow, routing workflow.
From the eagle-vision, we imagine an app where people write their thoughts, and read another person's thoughts. Here, users have a profile, they have a list of published blogs, drafts, reading list of blogs or stories. They have statistics to analyze their audience. In depth, these all are standalone modules fulfilling a particular role with their own logical structure. Here, a user is related to their “published blogs” as the “writer”. In view count as the “reader”. Their “published blogs” can be on another user’s “reading list”, and vice versa.
All these modules are “nodes” or “vertices”, and relationships are “edges”. We think broadly about the whole picture from the above when planning the whole app. And think in-depth when building a module where we need to put a Boolean field “published = True/False” for an authenticated user to write jumbled-up thoughts as drafts, and publish only the polished pieces.
DFS as in-depth thinking. BFS can be compared to eagle-vision, thinking broadly about the whole picture. Two algorithms that can be applied to think about almost every problem.
Programming trains our imagination. Instead of jumbled up thoughts, we make one coherent system. We see a problem, we think in breadth about the solution and consequence for years which we call vision. Then we take a small, in-depth mission to make that vision a success story.
And we thought, imagination is furthest from engineering…
I believe real engineering begins with imagination.
“Works on my machine” Is Not A Conclusion But This One is:
So this was not all, but all for now. Though it feels like I just described that one toxic teacher who did everything to break you. Years later, you see, it actually made you.
Now, I don’t like the notion of “what doesn’t kill you makes you stronger.” I don’t like giving too much credit to struggles. But as i said, we have to show gratitude where it’s due.
And I must say, it feels good to sit with a cup of coffee, wear a smirk, and act all-knowing. A true guilty pleasure of mine.
Well then. Adios.
— From the coder who has a toxic relationship with coding, and writes about it with a quill.
