free html hit counter
Posted on: Saturday, April 10, 2010 by Rajiv Popat

TEDxCalcutta 2010 - Announcement 2.

We have been working on getting one TEDxCalcutta 2010 video out every two weeks. This week we started with the very first talk of the event which was given by Gurbux Singh.

The talk is online and can be viewed from the videos section of the TEDxCalcutta website.

Join Gurbux Singh in this discourse as he takes you through the journey of his life and his experiences of winning the Olympics gold medal and then later an Olympics Bronze medal. 

The paths you take in life are often a combination of so many different things. When questions are asked hands have to be raised and decisions have to be taken. Impediments and problems exist but do not last long if you play your game and play it really well. Nothing replaces consistency and focus. Knowing every individual in your team and what moves them is hugely important. Forgive and Forget is true sportsmanship.

Gurbux Singh uses a friendly, casual and spontaneous discourse to give you his gems of wisdom acquired after years of sportsmanship which he ends by showing his Olympics gold medal and receives a standing ovation for it.

You can see the video here and leave your comments or ratings of the video on the Uploaded YouTube Version.

posted on Saturday, April 10, 2010 4:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, April 9, 2010 by Rajiv Popat

The Perils Of Finding Harry Potters Of The Software Development World.

If you build software, you work in a business which is controlled by simple concrete fundamental rules which are just as real and just as invisible as gravity. That is not to say that these rules cannot be bent, bypassed or broken, but then when we are talking about breaking these rules we are either talking sweat, blood and time or we are talking simple magic. Put simply, we are either talking about taking the Wright brothers way or taking the Harry Potter way.

The Wright Brother way involves having a culture where people understand the existence of these simple fundamental rules. Then they work on a slow, steady, scientific approach to taking small steps towards twisting and bending these rules.

The 10x productivity rule for example offsets the iron triangle rule but then it takes about ten thousand hours for a developer to be able to bend the rule. No different that building a airplane step-by-step.

A good ten years of committed focus and hard work goes in. Expertise is developed, you slowly move away from typical CRUD applications and build something that is genuinely innovative.

That is when an overnight success that takes years is born.

The Harry Potter Approach on the other hand involves no respect for the fundamental rules. It typically involves a bunch of clients or managers using all their management arrows to hunt out a few Harry Potters within the organization and then hoping that these Harry Potters pull a magic trick and just get things done consistently without failing.

You know that your manager is expecting a Harry Potter when he is not 'listening' to what you are saying. Instead of realizing the practical problems and the productive constraints which force you to remove excess fluff and focus on what is important, he is busy reminding you how important it is for you to do what he is telling you to do, within the timelines in which he is telling you to do it.

What he is doing is that he is genuinely hoping you are his Harry Potter and that you can pull a rabbit out of your hat for him.

As someone who was once a Harry Potter early on in his career I have witnessed how bad pulling magic tricks in projects can hurt.

After my first successful failure where I pulled a few magic tricks, I recovered, healed rather quickly and resolved that I was not going to repeat my failure. I also learnt the finite rules that exist in the world of software development and then I set on a path to break these rules with consistent and focused commitment to at-least try to get better each day.

Personally, I do not know if I have been successful at my self-commitment but I am definitely trying to take continuous steps on the path of self development.

So as a young and budding manager, or as a regular ass-hole, as much as you hate that guy who tells you the practical realities of your business, your team's limitation or brings you face to face with realities you did not want to encounter, remember, that this is not the guy who will get your project to fail or your career to take a steep nose-dive. In fact, if you can give this guy a serious pat on his back and make him your friend, that is what you should do.

Then there is the Harry Potter who never says no, pushes 'harder' to get things done and pulls out magic tricks without any respect for real constraints that exist all around him and his team. This is the guy you need to be seriously careful of.

This is the guy who will take both you and your project down if you keep trusting him to pull his magic tricks for you.

Why Pops, you ask. What is so wrong with a little bit of magic?

Remember that magician who used to make your coin disappear into thin air when you were young? The coin wasn't really gone. It was sitting somewhere under his sleeve and the art of shitting canning things under your sleeve is exactly the kind of art and talent that you need to get your next project to fail in the long term.

So if you are a young and budding entrepreneur, vice-president or a manager, stop looking for Harry Potters within your organization and start looking for people who remind you the practical realities or rules of life and then show you how to overcome, bend or break these rules with step by step hard work, one track focus and relentless commitment.

I wish you good luck.

posted on Friday, April 9, 2010 8:36:07 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, April 4, 2010 by Rajiv Popat

Utilizing Your Intellectual Surplus On Something That Is Useful And Fun.

TEDxCalcutta speaker Sarvesh Tiwari, first introduced me to the idea of Intellectual Surplus. According to Sarvesh its the part of your brain that is left un-used after you have done your days work at your organization. This is the part of your brain or your intellect that individuals often do not pay any attention to.

Given my contention, that no-body works for more than 80% of his time spent at office, the idea of intellectual surplus was something that was not just easy to understand but was actually rather simple to connect to.

If you think about it however, the idea of an intellectual surplus goes beyond utilizing that 20% of time where you are involved with doing nothing in particular.

What your brain is doing for example, when you are seated in a bus, in a subway or driving on your way to office is a classic example of intellectual surplus getting wasted. Pop in a podcast CD or MP3 and chances are that you suddenly started using your commute time to utilize, exercise or stimulate your brain a little more.

Another way to think about this concept is that you are utilizing your intellectual surplus all the time. You are even utilizing it when you are watching the newest Hollywood movie and admiring the special effects or the acting of your favorite actress. You are taxing your brain and the kind of entertainment that you pick also ends up deciding the amount intellectual surplus that you use.

As someone who finds discotheques utterly boring and an excessive dose of television utterly depressing, I've learnt that I am often fairly happy when I am using my intellectual surplus to do or build something meaningful.

Whether it is organizing TEDxCalcutta, talking at a local developer community conference, taking a knowledge sharing session at my organization or doing a blog post for this blog, I tend to fairly happy when my intellectual surplus is getting used to create meaning. For parts where my brain needs to relax I have learnt that I am way better of going on a long walk with friends or having meaningful discussions and arguments with folks I can really connect to.

The real trick is to realize that, as a developer you have this huge part of your brain which is not really getting utilized to do or produce anything meaningful. Once you have realized that sit back, relax and reflect on your day to observe how much of that intellectual surplus is being wasted on nothingness, the idiot box and insanely meaningless activities like daily commute.

Now that you have an idea of the amount intellectual surplus you are squandering away, the next step is to think on what you are going to do about it. Audio books for commute? Language classes during weekends? Take up a hobby that you always wanted to take up? Start a pet project that you always wanted to start? Do a few blog posts each week?

The choices are yours, make them wisely, but then any choice that you make will be better than not even knowing that your intellectual surplus exists and it is getting wasted every single day of your life. Go make a choice and utilize that part of your brain that was often wasted gazing out of the bus window on your way to commute or watching an utterly depressing and boring television program.

I wish you good luck.

posted on Sunday, April 4, 2010 9:51:01 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, April 3, 2010 by Rajiv Popat

Programmer Tip: Becoming Cover-Fire Worthy Matters Quite A Bit.

In my earlier posts I gently nudged young and budding developers to be there and not evacuate the pond when boulders are getting thrown at it. Feel the ripples, deal with the pressure, get your work done and while you are at it, also try and have some fun.

Of the many reasons why staying the pond when boulders are being thrown at it, one of the most important reasons can be explained in one word: cover-fire. Cover-fire is what I do when my manager hints at the fact that I am running slow on a project. Cover-fire is when I know the fact that Jack is not in the flow and isn't shipping but I decide to keep my gob-shut and not explicitly mention that during the discussion with my manager.

As members of the same pack we tend to give cover fire to others in the pack. The cover fire is based on trust that has been developed over time. It is also a personal thing.

You know Jack has a problem on his family front, you also know that he is trying his level best, he is showing up, he is putting in his hundred percent. All he needs is some time and that some time is not going to kill the project. You decide to pull your management gun out and give Jack some cover-fire.

There are times when you know that Jane is going to propose an architectural approach that will rescue your project, but then she is not very articulate at describing the approach to the folks sitting on the other side of the table. You decide to drop in at the meeting, take sides and explain the long-term-ROI of the architectural solution Jane is proposing. The 'managementese' that most people in that meeting-room understand really well. More cover fire.

Then there are times when you receive cover fires. Remember that vacation that you took or that holiday that you took to get your personal-pet-project wrapped up. That is when someone from your team chimes in and works on getting the next sprint shipped exactly on the same day as you had planned even if you are not around. No-one misses you. You come back from the vacation only to find that everything is exactly as you would have wanted it.

That is your team giving you exactly the kind of cover fire you need and keeping you out of trouble.

Cover fires are built on mutual trust, respect and an unspoken pact that if you are not performing to the best of your abilities, you will revive, recover and come back soon. When people you work with understand this about your work ethics, you are what I call, cover-fire-worthy.

You live up to that trust and respect by honoring that pact. By getting back in the flow and helping the team move forward.

Of the many situations where you lose your cover-fire-worthiness one is when you break the trust and respect that was causing your fellow programmers to give you the cover fire in the first place. Take cover fires for granted and be rest assured that you will find yourself smack in the middle of the battle field all alone.

You also typically tend to get lesser cover fire when you are constantly not around when your fellow programmers need you. I have seen this theme over a dozen times in my life. I have observed it rather closely and I think I understand how a team of seriously kick ass developers works in times of crisis. Take a team of kick-ass developers when every team member is closely knit with another and put them in a crisis situation.

Chances are that you will see very little finger pointing. Problems will be discussed, ideas will be brainstormed but no specific names of developers causing delays will come out during management meetings and status calls. You will never hear Jane saying for instance, that the project is late because Jack is not doing his work as quickly as the team expected him to do it. In fact, you might actually see Jane defending Jack.

Now, get Jack to go to a few parties with friends when the entire team is struggling and getting the sprint out or keeping the sky from falling. Then get him to turn his cell phone off. Do this a few times over and what you have done is shattered Jack's cover fire worthiness to pieces. Now do a management meeting and chances are that you will hear a couple of developers hinting that Jack is causing the sprint to get delayed.

What is going on here is simple. The team is booting Jack out and refusing to give any him cover fire primarily because they know that Jack is no longer cover fire worthy.

If you are a young and budding engineer doing your job, kicking some serious ass with your programming skills and moving up the corporate ladder of promotion watch your cover fire worthiness very carefully because everyone needs cover fire once in a while and if you have lost your cover fire worthiness, you are going to have some seriously difficult battles up ahead.

Cover fires are good and if you see someone in your team who genuinely needs them, go ahead and give them some. On the other hand, if you notice someone losing his cover fire worthiness or taking your cover fires for granted, look at him in the eye and tell him he is losing the trust that made him a kick ass programmer in the first place. This is one issue you are way better of confronting rather than avoiding. Go ahead, talk about it, openly and candidly.

I wish you good luck.

posted on Saturday, April 3, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, April 2, 2010 by Rajiv Popat

Programmer Tip: Trying To Be There When The Sky Is Falling Or You Are Needed.

Jack is a seriously kick ass programmer who gets his job done. He is not a hard worker in the conventional way but he works smarts. Put really simply, he gets things done.

Over a period of a couple of years he climbs the steps of promotion and becomes an integral part of our core product development team. Every single one of us respect him for the volume and the quality of work that he puts in. For some of us, over a period of time, Jack seems to have become a the rock-star problem solver of the team and we find ourselves depending on him every time a particular kind of problems need to be addressed.

But then as the sky starts to fall, I notice a tiny-fundamental problem with Jack. The first time I see it, I ignore it as a lousy co-incidence. Maybe I am just being paranoid. Maybe it was just bad luck. The second and the third time I see it, the problem worries the heck out of me.

Jack, as it turns out, has the habit of moving out of the pond every time a stone is thrown at it and ripples are formed. Michael Lopp describes the idea rather articulately. He explains:

When I think of communication in a large group of people, I imagine a pond. Small, round, slightly green water. You can see the edges of this pond and there’s a willow tree over there looking both informed and sad. Metaphorically, all the people in the organization are standing somewhere on this pond. Our positions are based on whom we know and where we are in the organization chart. When something happens in the company, when something noteworthy is said, a drop falls in the pond and creates a ripple.

The ripple is the piece of information traveling from one person to the others. Big drop, big ripple… travels further.

With me so far?

There is a constant flow of information in your company. That means there are constant drips in the Pond, creating various-sized ripples traveling every which way, bumping into each other, and transforming each other into slightly mutated ripples. These mutated ripples are the rumor mill, gossip, and all those small pieces of slightly bizarre information that cross your path during the course of the day.

If you’re in the Pond, you’re gathering data, whether it’s intended for you or not. It’s inevitable. It’s what we do as curious humans; we receive information, digest it, alter it, and then send it on its way tweaked to our own personal wavelengths.

A remote employee is not in the Pond. Yes, he’s on the mailing lists and he aggressively updates the wiki, but the subtle, unintentional, tweaked, quiet information that is transferred throughout the Pond doesn’t leave the Pond.

Ripples are getting formed all the time. Then there are also boulders, both big and small ones being thrown at the pond and your job as a team, is to deal with those ripples and boulders without switching to the panic mode or doing something stupid like killing each other or more specially, without getting each other fired.

Not being around when the ripples are formed is not just a problem with someone who works remote. It actually a bigger problem when someone who works with you actively chooses to move out of the pond every time a ripple is formed.

If you want a really hip and enterprizy way of describing the process of moving out of the pond, you can describe yourself as someone who acts professionally and keeps your personal life separate from your work life. Which effectively means that if hell breaks lose after six and the entire team is struggling to fix a bug in production you not just decide to leave but actually turn your cell phone off so that you cannot be disturbed.

That is you acting professional. But then, any programmer, manager or leader worth his salt will tell you that there most things that decide your career path or your organizational culture chart, are not professional. They are insanely personal.

If you are a young and budding programmer on your way to becoming someone who people will eventually look up to and if there only one advice that I can give you from all that I have learnt out of my professional life, it would be this -  when the sky starts falling, don't run away, don't disappear and cancel your personal parties if you can. When someone in your team or your organization needs you, show up. Consistently.

You may not be the best developer in your organization, but if you are dependable, people will depend on you.

On the other hand you might be the best developer in your organization, but if your team cannot depend on you to be around when they need you the most, chances are that they will not give a rat's ass to your talents very soon.

So the next time your personal life calls and your team is out struggling to keep the boulders off the pond, the least you can do for them, is leave your cell phone on, walk out of the party and take the call if they need your help. Or better still, go ahead and reschedule the party if you can. Be approachable, be dependable and above all, be there when people need your help because that is what makes you special or wanted.

I wish you good luck.

posted on Friday, April 2, 2010 9:00:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, March 28, 2010 by Rajiv Popat

TEDxCalcutta - We Want To Listen To Your Ideas And Learn From Them.

One of my earlier posts was our first announcement for TEDxCalcutta. I absolutely enjoyed and loved being a part of the event. Besides the speakers, who were of-course amazing and absolutely fascinating one of the things that I also loved about TEDxCalcutta was the participants who attended the event. We had folks from all corners of the world and all walks of life doing amazing things which were not just innovative but hugely inspirational.

During the event I was able to connect to a few participants and get a conversation going about some of the genuinely inspirational and innovative work that they were involved with.

As we work on editing, publishing some of the speaker videos and deciding a schedule which will be used to upload the talks on the website, one of the additional things that we want to start as a parallel thread is listening to you.

If you are working on something that is ground breaking, genuinely innovative and at the same time is truly inspirational, if you have an idea that you believe is worth sharing and if you would like to share the idea with a community of really smart individuals, we would like to know more about the idea.

We would typically prefer this to be in the format of an un-edited video where we have a casual discussion with you about your idea or your work, preferably in your work place but if you are working out of places where we cannot get someone to interview you, we can also do it as recorded podcast, a recorded webcast or web meeting.

The email to send in your ideas or more details about the work that you are involved with is We will start looking at some of the emails that we receive and start prioritizing the order in which we cover these. We expect the first recorded cover to happen around mid April.

Its always a pleasure to come across smart people who inspire you and connect to them. This, is just one of our attempts at getting the discussion going around the year instead of just turning TEDxCalcutta into a once a year event.

Go ahead, send in your ideas.

We are waiting to hear from you.

posted on Sunday, March 28, 2010 9:00:00 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Saturday, March 27, 2010 by Rajiv Popat

Programmer Tip: Wearing What Makes You Comfortable And Happy.

While organizing TEDxCalcutta I received tons of phone calls and emails asking me if there was a dress code for the event. With that question, what people were really trying really ask was this: Is TEDxCalcutta a suit-and-tie event or is it an event where you are allowed to be yourself and wear what makes you comfortable.

For us, personally, it was really important that the answer was later. The best events are where people look at or get inspired by your ideas and personality, not your dress code.

But then this was not the first time that we were hearing the whole dress code question. I have had the pleasure of facing and answering this question on multiple occasions, starting from my early days at Multiplitaxion Inc, where one of my early managers had actually insisted that I stop wearing slippers or floaters along with casual t-shirts and jeans to office, only to receive a polite but an out-rightly-flat 'no' from my side.

To be honest, it did feel a little scary to say no at first, but then, I figured that I was way better of saying no and being myself rather than spending eight hours a day being someone who I was never meant to become.

A casual, informal dress code that makes you feel comfortable and lets you be who you are seems to have become such a rare thing that companies like vertigo actually mention it as one of the intangible employee benefits. Placed smack under employee benefits section of the vertigo website are words which are both interesting and funny: 'Acceptable office attire includes shorts and t-shirts; unacceptable office attire has yet to be identified'.

Personally, I seem to consider myself really lucky to have been employed in a work environment where we do not waste hours talking about the dress code and most people come to office in jeans, t-shirts or any attire that make them comfortable. Yes, we do have a manager or two who would be bothered by someone wearing a pair of jeans to work, but that overall thought process is on its way to a slow, painful extinction and that to be honest, is a good thing.

The point of the post is not to tell you that suits are bad. If they make you feel at home and if you like them, by all means, go ahead - indulge yourself. If you are not comfortable in them, wear what you are comfortable and at home in.

As long as you do not end up embarrassing others and can carry yourself well, wear what makes you feel at home and settle down. Focus on your overall personality, ideas, work and what you bring to the table rather than being overly conscious about what you are going to wear to your next client meeting.

Be at home. Work hard. Focus on consistently giving your clients a kickass product that simplifies their life or brings a smile on their face. Give them the best of the products that can get and then if they cannot stand your pair of jeans or the fact that you do not wear a tie to meetings, they are just going to have to deal with that.

I wish you good luck.

posted on Saturday, March 27, 2010 9:00:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, March 26, 2010 by Rajiv Popat

Programmer Tip: Being The Best Purple Cow You Can Become.

Honest confession about my professional life: I am not the best programmer out there. To be honest, I am not even the best of the programmers to exist in the team of programmers that I work with. In fact, most programmers I help are already way better programmers than I am. The problems I have been playing with tend to be way bigger than what a programmer of my caliber usually ends up playing with.

Most of the times when I am giving a training session within my organization or to an external group of developers and I see eyes staring at me almost as-if I am this super-alpha-geek who know so much, deep down inside, I know really well that it is not the 'knowing so much' that is making my presentation tick. It is the articulately explaining what I know with a hugely different perspective that is keeping people's asses glued to their chair.

Then every once in a while, during these discussions or training sessions, depending on where I am conducting them, absurdly strange but rather funny and appropriate analogies will come out of my mouth. I will come out and pass random but relevant statements which were heard years ago or which are just formed at the runtime.

Things like, 'exchange of ideas and excessive dose of inspiration is nothing more than masturbation for your intellect' or 'knowing what interfaces are, is like knowing what sex is; truly realizing what they are and using them is what I call loosing your programmer virginity'.

Maybe this explains why Scott Berkun's video on Attention and Sex is one of my favorite videos on the topic of multitasking.

When it comes to technical discussion, maybe it is the philosophical, psychological and sometimes event the down-right weird perspective of looking at things which my mind tends to deploy, that comes to my rescue.

Maybe there is nothing very 'technical' about my 'technical' presentations after all.

When it comes to my work life, I tend to get approached by seriously kick-ass programmers who are looking for solutions to complicated problems. Or should I say problems begging to be solved with a really simple solution that no one seems to be thinking about. People also tend to come to me with problems that do not require solving in the first place. Problems where no one has even asked why the problem needs solving before they got down to solving it.

Maybe the techniques that I employ to solve the most 'technical' of the problems that I get approached with, are also not that 'technical' after all.

As someone who is a programmer at heart, a huge part of my programming life has been about realizing that programming languages are means to express your intent and while it is important to become really good and articulate at expressing your intent, working on having a really interesting intent in the first place is also equally important.

Even this blog, is my humble attempt at asking the questions that I would have otherwise never had the time or the spine to ask. Why for example, is using the F-word in a meeting considered so very sinister, why do you really need more features in an application before you go out to sell it, why is it so bad to suck at things and a truck load of other questions that I was never allowed to asked during my painful school life.

School taught me that being weird or different was a bad thing.

But then, I became a programmer early on and started doing a full time job while doing my college. What I learnt from the very first day of my very first job was that you actually got rewarded for being different. Since then, a huge part of my life has been about realizing that it was ok to be a purple cow at heart. That being a purple cow was in fact a good thing and it did not require fixing.

As a matter of fact, for months now, I have been consciously keeping some time every week to exercise my brain and allow it to wander into unchartered territories. I am not so sure you realize it, but I am doing it right now as I flip the keys on my keyboard and try to bring this post to life.

To a young and budding programmer who might be reading this, or to a veteran programmer who might be too busy building enterprise applications and who might be skimming through this post,  I leave you with a gentle suggestion: As you pick up programming languages, tools and technologies, be sure that you set some time aside and that you spend this time at becoming the best purple cow that you can become.

I wish you good luck.

posted on Friday, March 26, 2010 9:00:00 PM UTC by Rajiv Popat  #    Comments [3]