Showing posts with label Random Whining. Show all posts
Showing posts with label Random Whining. Show all posts

Saturday, June 27, 2020

The story of Lord Shiva and Bhasmasura - what can we learn from it..

Storytelling is an innate human quality! We often do it to teach , influence and inspire...

Indian Mythology is one of the richest elements of Indian Culture. Through time, different stories in Indian mythology have been passed from generation to generation either by word of mouth or through carefully stored scriptures. It is a very fascinating world , it sparks human thinking , fuels creativity , and has high entertainment values.

One of the stories of Lord Shiva and Bhasmasura ( Asura / Daemon ) goes like this:



               PC: various vedic sites from internet. Not distorted , used just for depiction.



Bhasmasura :


Bhasmasura was a very strong daemon but he used to act before thinking. He wanted to become the most powerful Asura in their community. He knew Lord Shiva was very generous and could be easily pleased and was capable of giving any boon of his choice , so he decided to perform severe penance to win the heart of Lord Shiva.. Every day, during his prayers, he used to cut a part of his body and offer it to Lord Shiva to please him. He repeated this for many days. 


Lord Shiva :


Out of 10 qualities of Lord Shiva -  one of the qualities which made him very different from everyone else,  was that he was a 'benevolent deity'.  He was a kind hearted lord ,  "The Bholenath" , and has an ocean-like forgiveness quality. 


And hence ,  Lord Shiva was pleased with Bhasmasura's prayers and came forward to grant him whatever boon he wished for. 


The wish of Bhasmasura :


Bhasmasura wanted to be  immortal , so he said, "Lord, please grant me the wish that whichever person, place or thing I place my right hand on, is reduced to ashes".  Lord Shiva granted him the boon and Bhasmasura was very happy.


Wicked Bhasmasura :


Bhasmasura, being the wicked demon ..as he was .. wanted to try his boon on Lord Shiva himself and tried to touch his head. A panicked Lord Shiva had to run away from Bhasmasura and approached Lord Vishnu to help him.


Lord Shiva himself was immortal , hence, it was a now a severe contradiction which he landed into by granting this boon.


The saviour - Lord Vishnu takes the ‘Mohini Avatar’:


Lord Vishnu changed himself into a beautiful young girl Mohini. Bhasmasura stopped as he had not seen such a beautiful girl earlier.. She was so beautiful and so graceful that for a minute Bhasmasura even forgot who he was. She talked in a way that she caught him in her beauty. He fell in love with Mohini and asked her to marry him.


Mohini continued, 'I am a dancer Bhasmasura. When I was younger I made a promise that I would only marry a man who can dance as good as mine’ .  Bhasmasura readily agreed to learn to dance for his new found  ꒒০⌵୧ ♡ !!


Bhasmasura Vadh:

( How Bhasmasura was killed )

Mohini started teaching two different dance moves to Bhasmasura. Bhasmasura was fully concentrating and was getting better and better in his moves.


Mohini soon won in her trick and kept her hand on her own head. Without thinking Bhasmasura did the same!


Lord Shiva's  boon worked 😇 and he was burned into a pile of bhasma (ashes). Mohini was looking at Bhasmasura's ashes as Lord Shiva appeared before Mohini. Lord Shiva went back to Kailash, thanking Lord Vishnu.



What can we learn from this story :


  • Beware of friends & followers , not everyone might be a real friend or a follower. 


  • Be generous , but not too much. Understand and anticipate potential implications of any act.  Think before you act!


  • Everyone makes mistakes , even the most powerful and brilliant people. 


  • You must cultivate friends , if Lord Vishnu did not come for Shiva's rescue…




I leave this great indian mythological story for your further interpretation , as that's what indian mythologies do -  i.e. spark our imaginations and derive a learning out of it !!  :)



Until next time .. •ᴗ• !!

Sunday, July 30, 2017

'Optimism Bias' leads to poor decision making!


Effective Time-management and Time-boxing is a concern for 'always ready people'.  Being from a background that I am from,  I am probably one of them!  While doing project planning , factoring in some room for the unknown or unseen is very helpful , but that might not be possible all the time. 

Today I came across  Hofstadter's Law and then it naturally took me to read more about "Planning Fallacy

Hofstadter's Law states : 

 It always takes longer than you expect, even when you take into account Hofstadter's Law. - Douglas Hofstadter

The planning fallacy, first proposed by Daniel Kahneman and Amos Tversky in 1979, states it to be 
 -  "a phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed" ( ref : wikipedia )

 If we analyze the pattern why many of us often tend to miss the project deadlines ,  you will find that - we usually fall prey to this "planning fallacy" , which is nothing but our tendency to underestimate how long it will take to complete a specific task . 

Its because , we have an optimistic bias  ( TED Talk by Tali Sharot ) towards the task that involve us. 

Optimism bias,  or  unrealistic optimism is the tendency of individuals to underestimate the likelihood  that they will experience adverse events, such as - incomplete or delayed projects , serious diseases or road accidents etc. . As a consequence of this bias, some individuals underestimates the need of precautions that might curb such risks. This bias leads us to believe that we are less likely to get affected from misfortune and more likely to attain success , while the reality might be otherwise.

Planning carefully and conservatively can save us from lot of consequent / unwanted frustrations.

We must remember -  the risk of  'Optimism bias'  is -   poor decision-making!

Friday, April 25, 2014

Ops : Opposite of Luck?



Running effective and efficient Operations is definitely NOT an easy task!! And I do keep on saying that -  “Ops is against Luck!”

Lets consider the below scenarios: 

  • No one is  complaining and  you also don’t have a readily available report on how healthy your systems are , you actually might be in  trouble..
  • Or customers may be too angry , busy or confused to bring up issues - you should not count these days as your lucky ones!!
  • 'No  news' is NOT a good news !! 
  • Assuming  unresolved issues won’t reoccur again..  Also the strategy of duck and cover in the hope that the problem will disappear is a recipe for catastrophe

Someone rightly said - luck is just a thin wire between survival and the worse!!

You may consider them as Luck , while may be so - diligence probably  is what we need along with our willingness to act for consistent efficiency.

But How..?  below may be couple of real life scenarios:

If you own production - negotiate your own production readiness and excellence with ‘Why’, ‘When’ and ‘What’.  It might be overly cautious, BUT we should apply a lens to understand whether the said change ‘now’ will bring real benefit or it can wait for a favorable time. 

Does your PD consider operations as their customers? If NOT speak up.  Set expectations correctly so that you don’t have to struggle to setup monitors and metrics overnight to support production from early next morning.

Also - we should know when to pull the brake on projects , and prepare for actual traffic and earn $

Relying on your firefighting superhero and showering praise on their heroics should be handled with a diff mindset of permanent resolution by getting into the root.

Yep!   Sin kills….!! and Luck is always to blame :-)

Friday, March 28, 2014

Curiosity for Subsistence



Most of us hold ourselves back when we should be reaching out and most of the time we never see a need to change. Every such picture tells a story , that - we have somehow landed in a comfort zone and not giving that extra. Extra effort,  extra hour, extra question , or that extra feedback..

This 'extra' thing followed us from our school life itself. Remember ? Yeah ECA :-) (extra curricular activity !! ). These activities helped us to learn the values of teamwork, individual and group responsibility, physical strength and endurance, competition, diversity, and a sense of culture and community. Extracurricular activities provided us a channel for reinforcing the lessons learned in the classroom. Debating was one of them, which found very less participants (at least in my school) - a very few students opted or was leading in this area. Personally I never liked those guys! I felt they got into a habit of 'extra' questioning and was very irritating. Well, that was my own personal perception. 

Now when I look back at those days I believe this  probably helped those kids to inculcate that spirit of questioning at things. Either in open forum or silently under their mind and the leading cause was 'knowledge' - which is what probably they gleaned. Class teacher always used to encourage saying - Q's are Q's, there is not right or wrong Q.

I follow Buddhism as a philosophy where it tells one basic thing - that "everything in the universe embodies the law of cause and effect".  So if "Questioning OR curiosity" is the cause - the effect is "knowledge".

In school,  my sitting choice was the second row bench (even though I make gangs now also proclaiming that I was also always a 'last bench-er' ;-)). Let me admit, I used to hesitate to ask Q's. Fear was - what the other will think about it !! But I was always self-aware about my own personal growth and  used to cover it somehow. But that reverse model took hell lot of time from me, and I did understood it very profoundly that - curiosity is the leading cause of knowledge and that extra curricular activity was part of a well-rounded education.

Today when I look at our youngsters coming and joining us as a freshers or intermediate in the corporates, less or more I do see that tendency there as well.. where they DO  NOT  show enough curiosity to learn that 'extra' thing or question much and tend to settle down. This eventually cost us very heavy and that wrong pick demands lot of your bandwidth and becomes an overhead. This probably because we hire for skills and ignore attitude? .. right hire is always a mystery to me though!


Anyway - lets be curious , admit (an eager confession!) , learn , assess and learn - otherwise the real pressure that keeps us on the wrong path will be our self-generated one!  I am sure this will definitely help us to be creative in our word, action and deed :-)  !!


I am not sure how many 'W's or 'H' can satiate your curiosity while putting your question across, BUT just remember -  curiosity (not that rover!)  can KILL the cat , however we probably just wanted to experience how curiosity freed that cat! :-) 



Tuesday, November 26, 2013

RPO and RTO




RTO = Recovery Time Objective tells how quickly you  will able to resume the normal operations back by connecting users to the data. This measurement is called RTO.

RPO =  Recovery Point Objective describes the point until which data will be recovered when a disaster strikes. Generally the time between last backup and the event.  It tells us how fresh or stale the data is.



These terminologies mostly are pertain to DR (Disaster Recovery) or backup solution. These measurements are mainly based on two things:

  1. The expected loss to the business with the objective. 
  2. The cost of achieving the objective.


Friday, November 1, 2013

Maintanace Calander for IT Operations




Problem Statement:      Multiple maintenance(s)  gives us tough time towards our  availability ,  better manageability and eventually improper resource alignment. 


Trying to solve:    Better communication, better visibility.   With visibility rest will follow.

What we want to Solve:
  1. Because emails aren't just letters anymore, they're tasks.. Specially in Operations.
  2. YOU might have been in the original email BUT got missed in the calendar invite by maintenance driver
  3. We need a ‘one stop view to see all the upcoming maintenances.
  4. Easy to analyze (dis)agree/ postpone  these maintenances proposed by multiple team with this single view.
  5. From top of Pyramid view - path from scarcity to visibility and which will facilitate and clarify us the  action part.

How:

Say you already have a kinetic calendar  OR  confluence cal and such…. where multiple teams lists their upcoming maintenance.  But it’s for various teams and looking at multiple places you need to derive your schedule.  Or else someone will have to maintain one of your own which will be nothing but parts/extracts from all those. So will have maintenance overhead.

We can have yet another  tool…  I almost started working on one and stopped by this idea  - 

  1. Let’s have an outlook calendar  for EBS which is shared across all team members.
  2. **Outlook  calendar which will have  “ONLY” maintenance listed.
  3. Forget everyone BUT just add this email id in the calendar invite - maintanace@yourcompany.com
  4. By default it will display with your calendar, OR   you can also Display on a floating TV Screen extended in your teams work area.

What we need:

We are proposing an email id which will give us a calendar also:  maintanace@yourcompany.com
We will  use  JUST  the calendar  part of this mailbox and all of us have a  shared view.



Security:

We will see if sending  email from this id can be restricted ,  if NOT possible we will put strict security disclaimer for this email id. I guess it is possible.
Everyone should have permission to have shared access that calendar.


Enforcement:

If someone is  calling a maintenance, AND any of your  entity is involved ( which attracts risk or needs your attention)  , please  just have this email id included in the calendar invite.  That’s it!! 

Even If someone missed,     one of us just can forward the invite so that it gets listed in the calendar.

Q & Comments:

How does it sound??  

  
-DK



  🔭 First Impression: Exploring Grafana Mimir              ... After Years with Thanos! Not an observability( OE ) purist, but I do appreci...