I’m looking for financial partners and would like to connect…

A sample of LinkedIn requests I receive these days.

Hi Ashish, I’m the CEO of [redacted]. [redacted]. I’m looking for financial partners and would like to connect to see if we’re a fit.

Hi Ashish, I’m the CEO of [redacted]. [redacted]. I’m looking for financial partners and would love to connect! – M

Hey Ashish, I’m the CEO of [redacted] – [redacted]. I’m looking for introductions to financial partners and would like to connect to see if we’re a fit. – S

Hi Ashish, I’m the CEO of [redacted]. [redacted]. I’m looking for introductions to financial partners and would love to connect! – K

Read More

Three days in Cancun (Mexico)

Cancun, or, more precisely, Cancún, is a coastal tourist city on the Caribbean (eastern) side of Mexico. There are two significant areas, Punta Cancun (tip of Cancun), also known as the Hotel Zone and Playa Del Carmen. We chose to stay in Punta Cancun. The Hotel Zone is walkable and you don’t need to rent a car if you are staying there. Buses are always available to go to other parts of Cancun though you rarely will.

Read More

The two-step approach to big code modifications

We all have to make significant code changes from time to time. Most of these code changes are large. Consider the scenario that you merged one such significant change, and then other team members made a few more changes on top. Then a major bug is detected. You desperately make the fix. It makes it in. You declare a victory, and a few hours later, your colleague notices another bug/crash/performance regression. Your commit cannot be reverted. It isn’t just about you. Many others have built on top of the change you made—the code sloths along in this broken state for a few days before you eventually fix it. Everyone has faced this issue at some point or the other.

If the code change is small, this is a non-issue, you can revert it and fix it at your own pace. Therefore, when making significant code changes, always try to do it in two different commits (pull requests). In the commit, you add the new code, add a switch (command-line flag or a constant) to turn it on, and keep that switch off by default. In the second commit, turn the switch on. Now, if there is a problem, you immediately turn the switch off and start working on a fix. No one else will deal with the broken code. It would be even better if the switch is a command-line flag since you can turn on the flag for 10% of the machines (or users) and see the behavior for a few days before rolling it out to 100%. It big teams, it is usually good to add a comment to switch mentioning when it should expire or else you will end with Uber scale problem.

There are a few cases where this cannot be done, for example, during big code refactoring. I think big code refactoring touching code written by multiple teams is almost rarely justified in a single commit.

Examples of some cases where this is useful

  1. Switching over from consuming data via v1 of some API to v2
  2. Switching over from returning computed results to stored results (for faster response time but possibly inaccurate outcome)
  3. Switching over from JSON to Protocol Buffer/Thrift
  4. Switching over from VMs to Kubernetes (don’t delete the old code yet, you might regret it)

In a remote village in Thailand…

After renting a moped in Thailand, I stopped at a small shop to ask for a petrol pump/gas station. Instead, the shop owner handed me a bottle of gasoline for purchase.

“Must be a peaceful country where they can sell gasoline in bottles.”, I said to myself, “In most parts of the world, people would use this as a petrol bomb during violent protests and riots.”

Petrol/Gasoline sold in bottles in Thailand

Petrol/Gasoline sold in bottles in Thailand

Dealing with phone numbers in contact book

If you are building an app that uses the user’s contact book then their certain gotchas to avoid.

Telephone country codes are prefix-free

If a country has a country code “+91”, then no other country will get a country code like “+912” or “+913”. This scheme ensures that numbers are inherently unambiguous.

Telephone numbers can have multiple representations

Since most people don’t dial internationally, telecom systems implicitly assume a domestic call. So, someone dialing 612-555-1234 in the US is dialing “+1-612-555-1234”, while the same person in India is dialing “+91-612-555-1234”. Since international dialing would be more infrequent, telecoms require unique prefix numbers like “00” to distinguish whether someone is 612-555-1234 in their country or 0061-255-51234 in Austria. In some states, even the domestic area code is not explicitly required. So, a user might have stored “555-1234” as the phone number to which telecoms will implicitly prefix the user’s area code. And if the user wants to dial beyond their area, the telecom operator would require an additional “0” prefix to mark that it is an STD call. This localization has a massive implication regarding processing cleaning and normalizing phone numbers retrieved from the user’s contact book. Both country code and area code don’t contain “0”, and usually, that’s superfluous. So, while telecoms might be OK with calling or sending SMS to “0-612-555-1234”, they will treat a number like “91-0-612-555-1234” as incorrect.

Multiple countries can share telephone codes

USA, Canada, and many countries in the Caribbean share the “+1” telephony code. The carriers would treat calls or SMS as international, though. Italy and Vatican city share “+39”.

Continuous area codes or country codes are not always adjacent

As the population grows in certain areas more than others, the codes reserved for other regions can get allotted to them. An example of that is the San Francisco Bay area, where the first 408 and then 669 was allocated on top of the existing 650 area codes to deal with the growing population.

Confirming phone number ownership

You can never trust an incoming call or incoming SMS’s phone number. Therefore, the only way to verify that the user owns a phone number is by sending them a text message or making them a phone call.

Things to do in Cusco (Peru)

Cusco or Cuszo, an Andean city in South America, was the seat of the Inca empire and is home to world-famous Machu Picchu. I would recommend staying near the city center of Plaza De Armas (“Parade Square”). Most tourist activities are in and around the area.

Read More

Incremental testing: save time and money on CI for monorepo

To use monorepo or not is an eternal debate. Each has its pros and cons. Let’s say you decide to go with monorepo, one major issue you will face over time is slow testing. Imagine a monorepo, consisting of an Android app, an iOS app, some backend code, some web frontend code. In only very few occasions will someone modify more than one of those simultaneously.

Further, add to the fact that most of these projects confined to their directories would be using different build systems as well, for example, gradle for Android, yarn/npm for Javascript, go/rust/java/npm for the backend. The total build time, as well as test time, will only grow over time. It annoys developers making small modifications to their part of the codebase. And it slows down the development velocity drastically.

Read More

Subscribe For Latest Updates

Signup for our newsletter and get member-only articles