Do you have a dream?

Do you have a dream, your ultimate goal? If you don’t, have you already achieved all you could?

If you want to succeed but don’t have a clear goal, you’re running the infinite race. Every time you finish a lap another one is added because you don’t know what you’re running towards. If you want to achieve more, can you define what “more” exactly mean to you?

  • Is it more money? How much and by when?
  • Is it fame? What would you like to be famous for and among what groups?
  • Is it happiness? What does happiness mean to you?

Jim Rohn talks about the two ways you can face the future.

  • With Apprehension
  • With Anticipation

If you don’t have a clear goal, you are anticipating. And you have to accept (gracefully) whatever the universe will let you have. There is nothing wrong with this if you consciously want this. Don’t let anyone tell you that your way of life is not good enough. If you are happy where you are that’s all that matters.

If you want more in life, anticipation won’t take you very far. Apprehension is the key.

Apprehension of the future entirely depends on your ability to design it. You have to own up and create the outcomes of your life. You choose what you want to achieve, and what you want to be and then do whatever it takes to be successful.

How do you design the future?

  • You set goals and achieve them.
  • You don’t sell out on your dream.
  • You don’t compromise your values.
  • You reflect on your progress everyday.

The beauty of Why

I was listening to Richard Feynman the other day and loved how he explained the nature of every question that starts with a “why”.

“Why” is the question that exposes purpose.

“Why” led us, humans, to be the greatest species that ever existed. It’s the fundamental form of curiosity.

At a young age, we continuously ask why. Why is the sky blue? Why is the sun yellow? Why do birds fly? This is how each of us came to a basic understanding of the world around us.

To answer any question that has to do with “why”, we need to have a common framework or a basic understanding of the setting (things, emotions, the world) in place.

“Why did you call me?” “Because I missed you.”

We understand that people miss people and talking helps. That’s the common framework. If we don’t have this framework (which kids develop with their whys after whys), every answer results in another why perpetually.

One takeaway from this is, to ask better questions and really understand the answers to tough whys. We must keep learning. By learning new things we broaden our framework, and a broader framework leads us to a better understanding of ourselves, our purpose, and the world.


Don't see only what you want to see

People have strong opinions. Some people are more passionate than others in their values and beliefs, but everyone has them. Making rational decisions where the emotion is strong is hard, overlooking the facts that don’t agree with our values is very often the default mode.

The scientific term for this behavior is Confirmation Bias. A tendency to favor or look for information that supports one’s personal beliefs, a very common cognitive bias.

Confirmation Bias

Take the example of Ed. He is a person with low self-esteem.

Any person who sends a text and doesn’t get a reply thinks the other party must be busy. In this situation, Ed thinks that the other person doesn’t like him and chose to not reply.

He is biased towards thinking bad about himself and will believe the occurrence or a piece of information that supports his existing belief. For Ed, neglect is the obvious conclusion where ignorance seems apparent.


The same behavior goes to show why eyewitnesses are considered unreliable. The Innocence Project researchers have reported that 73% of the 239 convictions overturned through DNA testing were based on eyewitness testimony, source.

A neighbor who doesn’t care for dogs and thinks dogs are dangerous sees a vicious dog attack an innocent child. A bystander who loves dogs sees the dog defending itself against a menacing child. Neither eyewitness account is reliable due to confirmation bias.

So, what to do?

  • The first thing is to address that you may have confirmation bias where you have strong opinions.

  • Be careful and educate yourself when making your mind about things in those areas.

  • Go out into the world, discuss your thoughts with others. Surround yourself with a diverse group of people, and don’t be afraid to listen to dissenting views. Challenge yourself with disagreements and fruitful dialogs.

The true sake of an argument is to educate everyone involved in it.


View this post on Instagram

People have strong opinions. Some people are more passionate than others in their values and beliefs, but everyone has some beliefs. Making rational decisions where the emotion is strong is hard, overlooking the facts that don’t agree with our values is very often the default mode. Join me on my mission to be my best self and help others achieve their business and personal goals. Subscribe for more @therishpandey #personaldevelopment #personalgrowth #personalgrowthjourney #personaldevelopmentcoach #decisionmaking #personalitydevelopment #makingdecisions #betterdecisions #personalgrowth❤️ #personaldevelopmentgoals #mindset #coaching #positivemindset #growthmindset #lifecoach #businesscoach #highperformancehabits #mindcoach #leaderscreateleaders #lifecoachesofinstagram #selfdiscovery #selfreflection #changeyourmindset #businesscoaching #createyourfuture #healthymindset #mindsetshift #positiveliving #jimrohn #mindpower

A post shared by Rish Pandey (@therishpandey) on

Stick to your stack

In the book, the pragmatic programmer, there is a section where the author compares a programmer to a craftsman.

The craftsman or artisan mindset is a great way of thinking about our work. An artisan stands by her choices and work just like we must. Every artisan needs her favorite tools to do their finest work, as we programmers need our favorite programming languages, our editors and our stack.


Artisan Working

We programmers are fickle creatures and our whole industry is always gawking at another next best thing which is supposed to solve every programmer itch. Every day, we have ten new frameworks (and not enough good libraries).

This trend makes us question our own choices so much that if we don’t take up anything new in a few months, it feels like we are getting left behind.

Don’t get me wrong, we need to stay on top of the current technology.

But it’s pointless to try and catch up to every new popular thing.

What’s more important is, using a stack that you know well, will not let you forgive yourself when you cut corners or make bad structure choices. By allowing us to try new things every time, we start to think that a project is more about learning and less about perfection. And, we let ourselves off the hook and not hold us accountable for the quality of the project.

I know your usual stack may feel boring and stale, the new thing surely looks very fun.

It’s good to have fun and learn. There’s always a small chance that a new technology is better for you and for the things you are making right now. But you should know the tradeoffs.

Always staring at documentation for the new thing you are trying out of FOMO is just not productive.

Why should you refactor?

You have been working on this feature for a long time. When the client pitched this great new addition, you felt this would take a week. And here you are working on a Saturday and nothing feels right. You start to question everything about your career choices, the impostor syndrome kicks in.

Maybe you are not as great as you think. Highly unlikely but possible.


Stressed out

It’s not you, it’s Technical Debt

Martin Fowler defines Technical Debt as,

“Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt.”

Most of our work as programmers is paved by the need of stakeholders. The client usually wants something at the last moment and the conversation ends with, “just get it done before Y (an unimaginable deadline) or we will start loosing money”.

You need to opt for the “quick way”.

This is the curse of our craft, we have to make compromises that we know will come back to bite us (or another one of us) in the ass. These compromises allow us to meet the client’s deadline and save them money for now. Congratulations, the code is a step closer to a maintenance nightmare now.

You will surely be entertained when the next feature request comes in.

A few years go by. You keep adding features, layer upon layers of new code. Everything built upon the same code base, inheriting every misused design pattern and reflecting all your bad design choices. You are at the mercy of technical debt, if the interest rate is low it slow you down by days or weeks. If the rate is high, maybe you can’t even implement the feature without a rewrite.

Pay the Debt with Refactoring

Martin Fowler again has a solid definition of Refactoring.

“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.”

Fear not Padavan, refactoring is the way we can repay this debt. Just like any other loan, we keep paying the debt via refactoring and get to keep our sanity.

To get started just remember the boy scout’s rule. Leave your code better than you found it. Make small, incremental changes that leave the code in a better state than it was found.

You should get started with this by,

  • Naming your variables and functions well.
  • Extracting each step of logic into a function.
  • Keeping it DRY and removing duplicate code.