Being Fast Matters

Recently, I learned an interesting thing about my programming ability. That I have become faster at it over the years. In software literature, being ‘fast’ almost carries a negative connotation — of being reckless and clumsy vs. taking a more nuanced approach: using a pen and paper, and deliberating over the solution. Fred brooks famously said only 16% of the estimate should be devoted to actual coding, while 33% to planning and 50% to testing and debugging.

Clean Git History is Kinda Overrated

An important thing I learned early in my career was that best practices need not to be accepted at face value. There are so many nuances to Software development that a rule followed religiously can bite you in the back somewhere in the future. It’s not easy to realize this, though. Often, you read about an idea, you are sold to it (without considering its wider implications) and next thing you know you’re married to it.

How I Started Enjoying Programming Again

A question that has haunted me all my life is of identity. If I include my hobbying years, I have been programming for more than a decade. However, my interests have always been much wider—economics, psychology, mathematics—and the list of things that I have dabbled with is long and growing—design, writing, vector art, photo editing, chess. I am a textbook dilettante. The idea of having a single pursuit for your whole life doesn’t appeal to me, and perhaps, never will.

The Most Important Thing Paul Graham Taught Me

Few weeks back, Paul Graham published a post on having kids. When I was finished with the post, I knew I had read something very insightful. The topic of his essay was mundane, done probably a million times, but his perspective never is. I don’t know where the magic comes from, but he has a special ability to distill the wisdom lying in the far corners of the brain—what you might not know you know.

Accepting Technical Debt As Important As Fighting It

I was sixteen when I first read The Pragmatic Programmer. Back then, my programming career was in its very early stages—crude websites, silly games, and even sillier quizzes. The code I wrote was a shoddy, incomprehensible mess (for a long while, I preferred creating a single massive file, instead of modularizing the code in some way). I had only begun to learn that the job of a software developer goes beyond just making it work, that you’re writing code not for machines but humans, and a quote from The Pragmatic Programmer had a catalytic effect on me in that regard: