Void

Month: July, 2018

Kwery

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.

logo

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.

Advertisements

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?

hand-2208491_640

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

think-2177813_640

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

money-767778_640

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.