Programming insights to Storytelling, it's all here.
The main problem with hype is that it keeps us from appreciating what we already have. It’s always about the next big thing. Something revolutionary just over the horizon. But while we’re busy chasing the future, we overlook the real progress happening right under our noses.
As a software engineer, my favorite part of any project is when I finally get to write code. Creating a new project, setting up the folder structure, installing dependencies—it’s like opening a fresh notebook on the first day of school. Even encountering bugs and fixing them feels like solving a puzzle. If planning the project is talking the talk, building a prototype is walking the walk.
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.
