All human behavior is shaped by the circumstances in which we evolve.

When you are new to an organization, you will see some behavior which may not make sense. Instead of trying to change it immediately, observe for some time, understand the motivations, and then try to change.

Commenting code adds value when you are doing counter-intuitive things which may not be obvious later.

Liberal use of Gmail filters and labels is the first step towards Inbox Zero.

If someone is implementing an idea or a concept that you believe is untenable, instead of outrightly dismissing it, get curious about it.

It is an opportunity to update your beliefs without incurring the cost of failure.

Before using new technology, assess whether you have the expertise to maintain it in the future.

Using is just half the battle won. The real struggle is in maintaining it.

Two kinds of meetings: \1. Information proliferation and strategy - daily standups, all hands, etc \2. Tactical decisions.

Two should always end with - who does what by when.

It is usually small tweaks and boring stuff that make a big difference. But our complexity seeking minds like to think the opposite.

Some find it incredulous that new age internet companies do not have separate QA teams. This is based on: \1. What is the cost of a bug in production? \2. How quickly can you detect production bugs? \3. How fast can you fix production bugs?

2 and 3 require constant focus on tools.

If the stability of your system depends on your users behaving a certain way, it is bound to fail.

On the other hand, your system should enforce the right user behavior.

If you spent a long time diagnosing a problem: \1. Do a self-retrospection to figure out what you could have done differently to cut short the time. \2. Ask yourself what observability interventions would have helped and add it.

Conflating authentication with authorization is one of the most common causes of security bugs.

Authentication - Is this the person who she is claiming to be?

Authorization - Is this authenticated person allowed to carry out the said task?

If you say something is important, it does not imply some other thing is not important.

Have seen conversations and arguments getting derailed with this line of reasoning.

When interviewing for senior roles, keenly observe whether the person talks in terms of strategy along with tactics.

Implicitly knowing the difference between the two is essential for senior folks.

Building non-scalable systems is fine as long as you are aware of this and have a rough idea of when it is going to burst through the seams.

Anything good you do, there will always be someone who will be like - “But what about that?” or “This is not enough.” or “This is just superficial.”

Ignore them and keep doing what you set out to do.

An ideal team is one where there is not too much variance in the output of its members.

Whenever someone blames a framework, usually it is not the framework, but their inability to use the framework in the prescribed manner and follow the best practices.

If you think something is not going to work, also think - What tweaks are required to make it work?

It is a useful exercise in opening your mind to new possibilities.

Moral Licensing - One does something good and then believes that the good act empowers them to overindulge.

Example - Because you worked out, you overeat.

Keep an eye out for this; all of us do this.