Engineering stack

Engineering stack

Most startups think of the engineering stack as if it is a single cohesive thing. However, I believe that there are three different engineering stacks that are loosely coupled to each other.

Engineering Guardrails

Engineering Guardrails

Guardrails are meant to protect us from tripping over. The same can be said about engineering guardrails.

GitHub Actions Logo

Common pitfalls of GitHub Actions

If you create GitHub Actions via GitHub’s UI by going to the URL of the form `https://github.com///actions/new`, it provides templates for setting up the build. However, the template is broken. There are four problems with the default template

The different layers of a web applications

The different layers of a web applications

There are three mandatory layers of any non-trivial user-facing web application. Storage, compute and view. The view is the front-end website and the mobile app(s). The storage is the database layer like MySQL or Mongo DB. The compute layer is the actual backend service serving the web content and related APIs.

5 reasons package.json doesn't scale

5 reasons package.json doesn't scale

package.json is the standard package configuration management file used in the Javascript world. To call it terrible is an understatement. Here’s why.

Low code

Low code

I’m a big of serverless. In fact, in 2021, I believe that it should be the default choice and one should have a strong reason to deploy their own servers.

Go language

Go Language concurrency and an easy pitfall

What should this code print?

React Native logo

React Native

There are tons of hyped-up claims surrounding React Native that are worth addressing.

How many source-code repositories should a startup have

How many source-code repositories should a startup have

Recently, this question came up during the discussion. “How many source-code repositories should a startup have?” There are two extreme answers, a single monorepo for all the code or repository for each library/microservice. Uber, for example, had 8000 git repositories with only 200 engineers! I think both extremes are wrong. Too many repositories make it hard to find code and one single repository makes it harder to do simple things like testing, bisecting (to find buggy commit), deciding repository owners.

The two-step approach to big code modifications

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.