Void

Month: June, 2018

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.

anger-1428042_640

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.

 

Advertisements

Conventions

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

rule-1752415_640

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.

feedback-3239454_640

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.

Luck

I read an interesting article by Richard Wiseman on luck, which I would highly encourage everyone to read. The gist of the article is that people make their own luck and being lucky is something that can be learned.

An excerpt from the article:

Lucky people generate their own good fortune via four basic principles. They are skilled at creating and noticing chance opportunities, make lucky decisions by listening to their intuition, create self-fulfilling prophesies via positive expectations, and adopt a resilient attitude that transforms bad luck into good.

horseshoe-504821_640

Patrick O’Shaughnessy, in his podcast “Invest like the best“, talks to interesting people. He mainly concentrates on investors who have made it big, but once in a while he also chats with people from other walks of life. A common theme that keeps repeating in his interviews is how these people jumped at opportunities which others had shunned, their optimism and an attitude that stresses on continuous learning and development. These qualities eerily match with what Richard Wiseman says makes one lucky.

In the recent Farnam Street podcast, behavioral economist Dan Ariely says the following – “I gamble with my time. I take risks, I do things that do not seem like the right things to do”.

Two of the most successful and rich people of our times, Bill Gates and Warren Buffett are gung-ho about the future. Bill Gates actively champions positive thinking and wants all of us to cultivate this.

Probably luck is not luck after all. I am sure it is more nuanced than this, but something to ponder about.

Taking calls

Making decisions is part and parcel of being a leader. It might feel empowering to take calls but the hallmark of true leadership is in enabling others to do this. The smoother the decisions making process and lesser the blockers, the better it is for the organization.

question-mark-1872665_640

One route to get there is to create frameworks, rules, and principles for decision making. When your team wants to do something and are confused as to how to get there, they just clawback to the principles and use them. For example, take hiring. Having a clear-cut framework for hiring that covers all aspects starting from what questions to ask, how many rounds of interview, how to reject or accept candidates, what qualities to look for in candidates aids the hiring decision process. By having this, teams are allowed to make hiring decisions on their own.

Also, when taking calls, openly articulate your thought process. Make it clear as to what assumptions you did, what questions you asked, what data you looked at, what trade-offs you did. Laying out in the open the way you arrived at a decision helps others to traverse the same path on their own the next time.

To summarise, instead of just taking calls on behalf of others, go that extra mile to create a framework which enables them to do this independently the next time. Also, laying out the decision-making process in the open gives everybody an opportunity to peek at your thought process so that they can borrow it the next time.