Blogs Versus Books

Long time back, in one of the social gatherings, someone asked me what do you do in your pastime? I said I read a lot. That person asked – What was the last book you read? I stumbled a bit and took a name. I realized that it had been quite a while since I read a book. Unbeknownst, I had gotten into the habit of reading blogs and articles online with social media and messaging boards acting as the source. There is always more than you can chew with articles touching a wide variety of subjects. Also, it feels a bit like going down a rabbit hole, one blog/tweet leads to another which leads to another and so on until you lose track of time.

I have been a voracious reader of books since my childhood. I got hooked onto online articles and blogs only during the later part of my life. This got me thinking about the difference between reading blogs versus books.


Even though most books revolve around a core central idea, the author takes the pain to reinforce this with varying thoughts and anecdotes. The author builds a structured case around the idea and presents a lot of scenarios leading to the core idea. Reading blogs and articles in most cases feels like reading a summary of a concept or just one facet of it.

When you read a book you are enjoying the journey whereas reading a blog feels more like focussing on the destination. Both have their own place but one should strike a balance between the two.


Naming Things

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

Even though the above might have been in jest, naming variables while writing code is a head-scratching experience. Should I make it short? Should I make it descriptive? If descriptive, how descriptive? These thoughts keep running in one’s head.


A simple strategy is to keep the descriptiveness of a variable’s name in line with the reach of that variable. If the variable is short-lived i.e within a small block, stick to a short name as the cognitive load of the variable is negligible. If the variable’s reach is much larger, as in if it spans a large number of lines, make it as descriptive as possible.

Goes without saying that names should adhere to the conventions that your team has adopted.


I recently watched the movie Hichki. The Plot of the movie revolves around a group of kids from less privileged strata of society who get a chance to attend an elite school. During the course of time, these kids feel that the school and the more privileged students there do not give them the respect they deserve. They rebel against this by not studying, causing nuisance and failing grades.


Kids can be excused when they exhibit self-inflicting behavior but sadly, a lot of adults too manifest this. One common adult refrain is – The organization is not treating me well, so I am not putting my best into the job. Keeping aside morality and call of duty, who loses due to this behavior? It is you. When you do not put your best into anything, you do not improve. If you do not improve, you do not progress.

It is in your best interest to put 100% into your job irrespective of how your organization treats you. If you feel you are not treated well, talk to your higher up and see if you can change this. If not, move on. Slacking is not an answer. You are harming yourself by exhibiting this sort of behavior.


When I was at FreeCharge, I did a lot of data engineering. One of the recurring patterns that I saw was:
1. A new product or feature gets launched.
2. The PM wants to schedule a report for her feature.
3. The report should run at a particular frequency.
4. The PM along with others from the C-team should get this report in their e-mail inbox.

We had hundreds of reports like this running at FreeCharge. We explored tools like Redash, Metabase etc; but all these tools were geared towards creating beautiful dashboards and visualizations, report generation and delivery through email was given a step motherly treatment. We hacked together a solution to solve this problem with bash/Python scripts, GIT, Jenkins etc. The query to generate the report was written by the business analyst team but they had to depend on the engineering team to schedule the report, convert the report into HTML and deliver it over email. One of the goals of the solution was to make the business team self-reliant in report generation. Since the solution was stitched together using disparate tools that were not really meant to solve this problem, it sort of worked but had its own chinks. This seeded the thoughts for Kwery in my mind.


Kwery is a tool that solves the above niche problem really well. It was also an attempt at building a single person lifestyle business that could supplement my regular income. I followed a lot of lean startup principles while building Kwery. Built an MVP, deployed it at an organization that had the above pressing problem and then iterated from there.

With Kwery, initially, I had to take a call as to whether to make it a SAS product or an in-house deployment. I decided against the SAS route as I was not sure how many organizations would be comfortable giving complete access to their data sources to an external fledgling SAS tool. I wanted to make the onboarding process of Kwery as simple as possible. Hence, I shunned all external dependencies for Kwery, opted for an embedded database so that I could package Kwery as a single binary. The only dependency needed to run Kwery is Java 8 runtime.

I did deploy Kwery in a couple of places which use it even today. Kwery has received a lot of love from these places but I never hit the numbers that I had in mind when I started. The opportunity cost was bearing on me. I had to take a call between continuing working on Kwery or cut my losses and move on, I chose the latter.

Like the old saying – Every cloud has a silver lining, I have open sourced Kwery under MIT license. It is very easy to get started with Kwery. Give it a spin, open Github issues if you face any trouble. Pull requests are very much welcome.

Solving Problems

When faced with a problem, the way we should think is:
1. What is the quick and dirty solution?
2. What is the long-term solution?


Most of the time, one tends to do only one conveniently ignoring the other. Our mind goes into overdrive and quickly implements a hacky solution and then we forget the problem only to find it re-occurring. Or, we languish to implement a long-term solution while the problem drags on.

One of the reasons why we might find it difficult to implement both is that they require a fundamentally different kind of thinking. The quick and dirty solution involves hustling and running around to get things done. Somehow by hook or crook, one wants to plug the hole. A long-term solution requires one to analyze the problem from all angles, think deeply about it and figure out a well-rounded solution. A vague comparison would be system 1 thinking versus system 2.

Both are equally important – neglecting either is a recipe for disaster.

Switching Languages


Many are apprehensive about switching programming languages. It is perfectly fine to have preferences – I am heavily biased towards statically typed languages with great tooling support, but being dogmatic is not something one should aim for.

What could be the downsides of switching programming languages? I am disregarding the psychological aversion to change and sticking to hard facts.

1. One will lose the fluency(syntax).
This is a non-issue, syntax is similar to muscle memory, one will get it back in a day or two. This is akin to swimming or driving after an extended break, one naturally gets it back.

2. One will forget the way of doing things.
Every language has a culture and a community accepted way of getting things done. Regaining this might not be as easy as syntax retrieval, but with some effort and thought, one should recoup.

3. One will not be up to date with the language.
Languages keep evolving, core ideas and philosophy remain the same. The standard library might become more expansive, VM might become faster, some earlier prescribed way of doing things might be an anathema now but the foundational principles remain intact.

4. There is no demand for this language.
As long as your fundamentals are good, this should not be a concern. There are roles which require deep language know how, but these are far and few. In fact, it is the opposite, more the languages in your kitty, more the opportunities.

The biggest upside to learning a new language is the exposure to new ideas and thought processes. Any new language immensely expands one’s horizon. For example, the way Java approaches concurrency is very different from GoLang’s take on concurrency. Having this sort of diverse exposure helps one build robust systems and mental models.

Programming languages should be viewed as a means to an end, not an end in itself. There are cases where programming languages make a difference, otherwise, there would not be so many around with new languages cropping up now and then, but you are doing a disservice to yourself by restricting to a few.

Pay The Price


Obstacle racer Amelia Boone says that she is not able to devote enough time to friends and family due to the demands of her tough training regime. That is the price she pays for being on top of her sports.

In the movie HEAT, Robert De Niro says – “Don’t let yourself get attached to anything you are not willing to walk out on in 30 seconds flat if you feel the heat around the corner.” That is the price he pays for being a master thief.

Michael Mauboussin says his quest for knowledge means he misses out on latest series like Game Of Thrones. That is the price he pays for being a crème de la crème investor.

I feel one of the reasons why people give up something too soon or midway is they have not figured out the price they have to pay for doing it.

Everything that one does has a price. Sometimes it is implicit, sometimes not. Better to figure it out beforehand.

Oops, I did it again

It is a packed elevator. Occupants are rubbing shoulders. Stops at a floor. Door opens. A lady wants to get in but there is no room. Annoyance plays on her face. Elevator moves on.


We all know that worrying over things that we cannot control is a pointless exercise. We are aware of the many cognitive biases that we have, we still fall prey to them. Why does this happen? There is a huge difference between knowing something and internalizing it.

Daniel Kahneman says that in spite of studying biases throughout his life, he is no better at avoiding them compared to others. Dan Ariely believes Kahneman was playing to the audience with that quote and we do get better at recognizing cognitive biases and sidestepping them.

Two simple practices that I find useful in becoming more aware of my emotions and biases:
1. Carrying out a daily audit. Every night, I go over circumstances that day where I believe I could have reacted better. Along with this, I also ruminate situations where my cognitive biases one-upped me.
2. Whenever I know that I am getting into an unpleasant situation, I keenly observe my emotions. This might be something as mundane as getting stuck in a traffic jam to dealing with an unpleasant situation.

I am not sure whether anyone will be able to completely eliminate these but I believe we can get incrementally better at it. Minuscule daily improvements compound to mammoth changes over a long time.



Most programming languages have conventions. These could be for naming or code patterns.


How does this help?

A simplistic view is that it helps to keep code consistent, especially when multiple people work on it.

A deeper way to look at this I believe is in reducing the cognitive load.

In cognitive psychology, cognitive load refers to the effort being used in the working memory.

If you have conventions, it is one less thing to think about. You do not have to spend mental capacity on thinking whether to name variables small case, capital case, camel case, with hyphen, underscore etc. You blindly rely on the convention. Same applies to code patterns. You look at the pattern and automatically grok the idea; without expending grey cells.

I strongly believe that all tech teams should have conventions wherever possible; outside code too. Freeing up any amount of working memory for things that matter will go a long way towards increasing productivity.


Anti features

When evaluating new technology, framework or library; a lot of importance is given to the salient features. While it is very important to know the positives, the negatives usually tend to be glossed over. Being aware of the shortcomings of a framework gives one the ability to anticipate problems down the road.


For example, let us take NoSQL databases. A lot of time is spent on singing paeans to the scalability, malleability etc of NoSQL databases while hardly thinking about the negatives that come with it.

Two simple techniques which give a good visibility on anti-features:
1. The very obvious one, Google for the shortcomings. Someone would have written a blog post on the interwebs highlighting how a framework or technology let them down. For example, take this post by Uber on how Postgres did not work as expected for them.
2. Comb through Github and/or JIRA peeking at the bugs raised and enhancements requested.

Both of the above will provide a good picture of the shortcomings. If you are evaluating a closed source proprietary technology, the above may not make the cut.

Once a mental note is made of the negatives, ponder on the scenarios where this might affect your usage. It helps to spend quality time on this as this will save one from a lot of future trouble.

If you think about this, this might sound very obvious but tends to be highly neglected. We get so caught up in the positives of something that the negatives tend to be ignored and this usually comes biting us back later.