Programming insights to Storytelling, it's all here.
"I'm sorry... did you want to go to the bathroom too?" "Oh no, I was just following you." "Oh, well I'd rather you not follow me." "Wait, it's not like you have something to hide, right? Make sure you don't leave the door closed."
One day I suddenly started feeling sick. My throat tightened, my nose ran, and my body burned. I thought it must be the flu. I took some time off from work. After a couple of days, I developed a cough, a cough that wouldn't stop. My kids were turning one, and my in-laws were here to visit. Not wanting to miss out on the opportunity, I started wearing a mask.
Most projects start with a burst of energy. Writing initial code, whether through vibe coding or meticulously setting up a new repository. This is the fast building phase: boilerplates are generated, frameworks are initialized, and thousands of lines of code appear almost magically. It's the era of rapid creation, where progress feels tangible, even exhilarating.
When I'm helping new developers, I often hear a familiar question: "Which is the best programming language?" They want a definitive answer, a shortcut to expertise. But I've learned that the question itself reveals a fundamental misunderstanding about how real opinions are formed.
I recently had to cancel my Internet service at home, and it was the worst experience I've ever had with customer service. A year ago, a new company that offers fiber internet was added to my neighborhood, so I decided to switch to the new service. I signed up online, entering all my information, including my credit card, only to find it wasn't available yet despite what their website claimed.
At an old job, our customers were early adopters of smartphones, and we had to ensure our web app worked flawlessly on their devices. As the newbie on the team, I was tasked with optimizing code to leave the smallest footprint possible without compromising features. This was before minifiers were commonplace, so I took it upon myself to write what I thought was beautifully compact code.
At the end of every month, I used to religiously check the total internet bandwidth we'd consumed at home. A decade ago, my ISP would throttle our connection if we crossed some loosely defined threshold, so monitoring usage felt essential. Those days are long gone. With gigabit internet widely available and everyone streaming Netflix in different rooms simultaneously, I've spared myself the monthly ritual of bandwidth anxiety.
I remember my first corporate job. The recruiter, hired just two months prior, hadn’t gotten a single candidate into the pipeline. In my interview, he kept asking: “Why didn’t you write about the things you clearly know?” I had trimmed my resume (advice from some blog) and lacked experience with big companies. He helped me rewrite it.
I was reading The Alchemist recently, one of the most satisfying and transformative books I have ever read. The author, Paulo Coelho summarized the whole story like this. "The reward for our work is not what we get, but who we become."
In the past, junior developers often began their debugging journey by Googling error messages. This approach, while frustrating due to the sheer volume of irrelevant results, forced developers to dive deep into their own code. To find the right answer, they had to iterate, experiment, and ultimately develop a profound understanding of the problem itself. This iterative process was a powerful learning tool, leading to both working code and a solid grasp of underlying concepts.
