Thoughts and Observations

People often think of coding as an extension of writing and even the discourse on the internet agrees with this notion and I don’t agree with this notion. Let me explain why. Creative writing, which is the one often talked about and respected, happens when you consciously flex your creative muscles and start exploring the thought space. The tool you employ to materialize your thoughts in words is the natural language, which has a diverse set of features(metaphors, irony…). There is no structure you’ve to adhere to and if you’re skilled enough you can even create space for ambiguity in writing. ...

CountDownLatch is effectively a centralized barrier where the gate is closed until the set timer is exhausted Using sychronized block is an effective solution for most of the problems. If multiple threads are trying to access the critical section of a particular resource, then is better to have a lock (mutex) on the resource itself. For ex: In case of ticket booking systems, every ticket must be represented as an object and it should have private Object which is used as lock for mutations. This way only the threads competing for the same resources are blocked, instead of linearising all of them. TBC.

I abandoned some of my projects because they weren’t original enough. I was trying too hard to create something original until I realised that it was a foolish ambition. There might be a few number of people who can create something original from their very first step. Even by then they have slogged enough to exhaust all the mundane ideas that surfaced in their head. But from the vast swaths of the human population greatness/novelty/originality is more of an iterative process where you exhaust all the bad ideas (obviously with optimisations) until you start hitting with the good ones. ...

From very early on, we’re Trained/Prepared on multiple fronts to survive in life so much that we abandon our intuition and start behaving on a formulaic basis. This type of lifestyle (where you’re always simulating situations to tackle) requires effort and every second feels like a juncture where decisions are to be made. This sort of lifestyle arises from the assumption that patterns constitute life and you’ll do fine given that you master the patterns. This breeds a society where a situation is filtered through the training dataset to find whether we can model the situation. Unbeknownst to the followers of this philosophy, their intuitive capabilities are being sidelined. I’m not against Training regiments, rather the purpose of the regiment should serve to hone the intuition. The problem with too much training is that it gets preachy quickly and serves a gospel to the follower. Instead of being in a zone where you let your mind take control and react to situations, you’re left with the mind being in control of somebody (of course metaphorically ) and driving the situation. Now this is a spot of bother because you’re not acting naturally and playing by the rules that are established by the person who designed your preparation material. This can be observed with most of the politicians when they’re on important debates, they act by the political consultants and strategists. But some great debaters react to situations instead of facing them. And Vivek Ramasamy is one among them. When he was pressed on to take sides on a contentious political issue in All In Pod, he issued a disclaimer saying that he is forming the arguments on the fly and are subject to change as and when new evidence is found, which is a lot honest than just sticking to the rhetoric imposed by the campaign managers. Training in itself isn’t necessarily bad, but not at the cost of intuition. Ultimately, one should forego training after developing intuition and letting it drive the situation.

An important realisation that I learned the hard way is that don’t ever expect anything from your manager, by default. This realisation has been paramount to me because it implies a lot of other things professionally. Most managers aren’t that good, law of averages, and they are walking a tightrope. Expecting too much of them is waiting to watch yourself fail. I used to hold my 1-1s with my manager as sacred. But they were as worthless as empty shells. Devoid of any substance and meaningful interaction. Turns out my fellow colleagues also had similar stories to tell. This eventually led me to believe that aspiring to work under a great manager to catapult your professional career is a ludicrous goal as it is akin to hoping for a generational politician to uplift the human conditions in a country(too much, I know). ...

I used to play safe even when there was nothing at stake. To play safe is to accept that there is an inherent risk in doing otherwise. Or else, you are not challenging yourself enough which will lead to an inanely boring life. It hit me hard when I realised that I could challenge myself in diluted terms and it would only mean personal growth. Tackling intellectually difficult problems is one such case where there is only an upside, even when you don’t succeed. I used to shy away from them because I knew the end result. But now, I don’t hesitate to look at them. Another surprising realisation is that people gravitate towards others who tackle difficult problems. And Theodore Roosevelt agrees with me, “Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty… I have never in my life envied a human being who led an easy life. I have envied a great many people who led difficult lives and led them well.”

There are numerous reasons to prefer a Monorepo to Microrepos and this post is about the de-duplication. More often than not, when a team size crosses 20, a Microrepo fanatic raises his hand and starts advocating a move for dissolving the Monorepo. “Build times are high”, “getting blocked by other teams”, “easier path to cloud”, “drawing boundaries”, and “everyone else is doing it, why not us” would be some of the reasons that get tossed around in upper echelons of management. Unsurprisingly, no one objects to this proposal. Proposals discussed, Jiras created, and smaller pods formed to work in silos. ...

I made the mistake of not learning Git beyond the basics and only giving a cursory glance at the list of operations it can perform. As it turns out, it is a powerful tool to collaborate and think isolatedly. Initially, I made myself acquainted with only the most used git operations. Commit, Push, Pull, Origin, Status, Merge and Fetch. Though I performed my daily tasks with these commands, I did a lot of work that Git was supposed to do such as stash, reset and revert. ...

When I joined the workforce right out of college I was expecting to do only one thing. And that was to code. Eventually, I realised that coding is one of the many things I am supposed to do. Matter of fact is that there are boring parts of my job and I don’t remember signing up for them. Writing emails, communicating with the stakeholders, and painfully making sure that your colleagues understand your style of working are some of the parts that constitute the boring parts. Even though I understood the significance of those activities, I still have a hard time accepting them. Diabolically it is because of those boring parts, I value the time that I spend to code. ...

It makes sense to master the tools that you spend the most time with. And Chrome sits on top of that list. Here are some of them Ctrl + Shift + A -> search for both open and recently closed tabs, useful when you’ve 50 tabs across 5 different windows Naming your windows -> so that every window has some purpose Grouping the tabs -> for reducing the visual load if a window has too many tabs to fit in a screen Integrating search engines -> no brainer if you search the websites directly, a very handy feature. (I’m baffled that Chrome has this feature as it’s the antithesis of their advertising manifesto)