Saturday, May 23, 2015

the end is where we begin ..

What we call the beginning is often the end. And to make an end is to make a beginning. The end is where we start from - T. S. Eliot

I have noticed in some meetings,  which are limited recurrings in nature - say: brainstorming , idea-jam's etc. where the entire 97% time goes very structured way.  But due to whatsoever reason - the last 3% of the time we rush so much that,  we actually end up very abruptly.   It defeats the whole momentum for the upcoming next, because you as a leader - did not think enough, and realize enough that its NOT the end of the ongoing series. And you will actually have to address the same audience in the very next upcoming one(yet again!).  Moreover,  if you missed to appreciate someone's effort in the current  in this hurry sickness  - you got a whole diff problem on hand now :-).  And I bet - you will be embarrassed on this act of yours!

By now you know where I am coming from.. Yes,  we should be very conscious about that last few minutes on such meetings, . and also create a visible and transparent agenda along with the need and importance of why we will be meeting again.   Leaders sowing the seed of curiosity!!

Also lets not forget to reiterate once , on - what is expected out of whom for the next and lastly - name the person who is going to send out the minutes ( MoM)  for today. Hope you had a official scribe ? :-)

So.. please try to maintain that momentum and enthusiasm - so that you  actually get a very good participants and some focused minds for the next one.  

Is not this 'end' is actually a beginning of the 'next'? You never know - those 'focused' minds may come up with some brilliant ideas by knowing -  what we are doing in the next huddle. This is looking forward and preparing ahead..  YES! the end is where we start from!!


Separating alert DL from regular team DL

Most IT organizations usually keep it simple by sending all the alerts to everyone. This is still a sustainable model 10's or 20's of  systems.  However with more monitoring s added , the noise increases and the focus , attention and the rigor needed for the same ,usually starts dipping. 

Alert management and distribution is a real pain when done via email way. Hence , in absence of a dedicated DL for alerts there can be a lot of assumptions or unnecessary noise onto who is attending those or is it actually being taken care of.  We also get engaged in a unnecessary back and forth on query and answering mode - rather then paying attention to the real issue in hand.

Typically in any organizations - we just have a few dedicated resources who jumps onto such incidents/issues real fast , and that too -with an honest intention to solve it for the organization. Hence providing a conducive environment for their work is indeed a prime importance. 

Moreover , separating alerts DL from the primary email DL could be a very good practice,  specially when you have other people who are not responsible for attending OR acting on such alerts. Also on the flip side - it can be so very noisy for those members,  who will go on an never ending stride being part of that DL. Because - important emails might get lost when there is are flurry of alerts.  Of-course you can filter those alerts - then why should you be part of that DL(alert) anyway?


1. Keep a primary group DL , which is for regular business communications and discussions.
2. Keep separate DL for alerts - and keep ONLY those engineers, who is accountable for triaging day to day alerts or OnCall related issues.


Git (Vs) GitHub

Git is a revisionor version  control system, a tool to manage your source code history.

In the SVN analogy, Git replaces SVN, while GitHub replaces SourceForge.  So , essentially - GitHub is a hosting service for your Git repositories. And , most notably, GitHub is a consequence of the existence of git and not the only hosting service.

For folks who are new to GIT , this is an absolute awesome 15 min. refresher.


Why Database CI/CD?

Making the Database Part of Your Continuous Delivery Pipeline The database, unlike other software components and code or compiled co...