Introducing Open.Whiskay: Practical Developer Guides, Explained Simply

Introduction

Welcome to Open.Whiskay.

“If the same code shows up a third time, it has to be a function. Full stop.”

That was Amrith’s rule. He was my team lead at my first job — a startup in the digital marketing space — and he must have said it to me a hundred times over two years. I didn’t fully get it back then. Now it’s basically the reason this blog exists.

Let me back up.

I landed at that startup with zero idea what “being a software developer” actually meant. I could write code that ran; I had no clue how to write code that survived contact with a real team, a real deadline, or a real codebase six months later. Lucky for me, the team was patient with a level of dumb questions that, in hindsight, were genuinely dumb.

So I put my head down and grinded for two years straight. Work-life balance was basically DOA.

Somewhere in there I got promoted, and along with it came a job I didn’t ask for but ended up loving: mentoring the new hires. It’s less “shaping young minds” and more logistics — get their laptop set up, walk them through the codebase, help them scope their first feature without either underscoping it or accidentally rewriting the auth system. Most importantly, I answer their dumb questions — the same way someone once answered mine.

The hardest part for almost every new dev is the same: understanding code that already exists. I push them to comment clearly, but let’s be honest — deadlines don’t care about your commenting standards. What I won’t budge on, though, is duplication. Copy-pasting the same block for the third time isn’t a shortcut, it’s a future bug waiting for a reason to happen.

Here’s the tension nobody tells you about early: management wants bug-free code AND clean, readable code, on the same timeline, as if that’s a reasonable ask. Any senior dev will tell you that combo is basically a unicorn — it doesn’t exist, not on a deadline. Uncle Bob had it right: first you make it work. Then, if you’re given the time, you go back and make it good — readable, maintainable, something the next person won’t curse you for. Skipping straight to “good” is how you ship nothing. Skipping straight to “done” is how you ship a mess that duplicates itself six more times before anyone notices.

Amrith’s rule was his way of drawing one non-negotiable line in that mess — pick your battles, but pick at least one. This blog is me doing the same. I’ll be sharing the stuff I find myself repeating most — to my mentees, to myself, to anyone who’ll listen — so you can skip a few of the roadblocks I didn’t.

Work

Outside the day job, I’m an aspiring game developer — “aspiring” doing a lot of heavy lifting there, since I have exactly zero published titles to point to. I’ve also always wanted to properly contribute to open source, partly for the right reasons and partly because it looks good on a resume, let’s be honest. This adventure — which I ended up naming Whiskay, for reasons I still can’t fully explain — is where I get to chase both.

Amrith’s rule was about code. But the same logic applies to everything else I make, including this blog: if I catch myself explaining the same thing for the third time, it’s not a coincidence — it’s a sign the explanation should exist somewhere permanent instead of living in my head (or someone’s DMs). Simple code, clear naming, and something easier for the next person to pick up than what I started with — that’s the standard for the code, and it’s the standard for the writing here too.

Contact

I welcome your feedback and suggestions. Feel free to reach out at singh@whiskay.dev or through any of the social links in the sidebar.