Programming insights to Storytelling, it's all here.
The barrier of entry for owning a website is lower than ever. For the price of a Starbucks coffee, you can rent a server and host whatever you want online. Yet it’s surprising how many developers shy away from building their own sites. They often fixate on replicating the enterprise-grade tech stacks they use at work, Kubernetes clusters, CI/CD pipelines, cloud orchestration, and dismiss personal projects as unrealistic. But sometimes, the most successful websites aren’t built by rule-followers. They’re built by people like Ron.
The moment I laughed, I knew I blew it. I was not going to pass this job interview. Not because I couldn’t answer the question, but because the interviewer sneered while asking about my experience with Silverlight, Microsoft’s long-dead answer to Flash. He warned me to “expect lower pay” due to my lack of expertise.
For developers, there's the tendency to imagine a showdown. A senior developer on one end, and a Sophisticated AI on the other, racing to complete a Jira ticket. Whoever completes the work first is the clear winner. It has to be high quality code, both reusable and scalable. This is where real human programmers like to believe they will make a difference. This is pure fiction. AI doesn’t compete with you. It dissolves your job into the system.
We live in a time of abundance. There are so many free, open-source, and battle-tested tools that can be used to build large-scale projects. But with great choice comes great responsibility.
A few months after I started this blog, I experienced an influx of traffic like never before. I wrote an article that went "viral" on both Hacker News and Reddit.
When I built shotsrv, my solo project for taking screenshots of URLs, I didn’t think much about system design. I spun up a single server, installed PhantomJS, and called it a day. If the server crashed, I’d restart it. If traffic spiked, I’d cross my fingers and hope for the best.
A coworker of mine once mysteriously vanished from work for two days. When he returned he tried to explain how he had this stomach bug. But then we saw the device he was holding in his hand. He sheepishly admitted he was camping outside an AT&T store to snag the new iPhone 4. He even turned down thousands of dollars offered for his spot. We marveled at his shiny gadget… until it started dropping calls. To hold a conversation, he had to grip the phone with both hands, pressing it awkwardly against his ear. We laughed. “You paid for this?”
When I built shotsrv, my solo project for taking screenshots of URLs, I didn’t start with a requirements document. I didn’t even start with a plan. I just opened my editor, installed PhantomJS, and started coding. If I hit a snag—like realizing PhantomJS didn’t support modern JavaScript—I’d Google a workaround or switch to Puppeteer. There were no deadlines, no budgets, and no one to answer to.
Once, I inherited an application so offensive, it felt like a personal insult. It wasn’t just bad code, it was a decade of bad decisions stacked like a Jenga tower. My task was to address a complaint by the internal users on a report that was generated. I looked in the company's git repository for the tool, but it was nowhere to be found. Only after digging through the server it ran on, I found that it was using Concurrent Versioning System or CSV, a version control system older than some interns.
Every developer knows the rush. You are driving and suddenly you’re struck by a “life-altering” idea (your 14th this week). At the next red light, you record an audio while driving, avoiding eye contact with what clearly looks like a cop’s car. At 2 AM, you wake abruptly remembering the recording. Now you’re setting up repositories, debating frameworks, and buying AWS servers in the middle of the night. The blind spot? You’re convinced this time, you’ll finish.
