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.

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.

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 ideas@tedxcalcutta.com. 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.

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.

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.

Those of you who follow my twitter handle are probably aware of my involvement with TEDxCalcutta.

The last few days we have been working really hard in organizing the event, picking the right participants, getting the right speakers and doing a truckload of work that is associated with organizing an event.

The event was an absolutely stunning experience which ended up teaching me much more than what I had initially expected.

If you are reading this and you were an organizer, a speaker or a participant, here is big fat thank you for being associated with the event. We were touched by your involvement with the event, the passion and the encouragement that you guys have given us.

As a small team of organizers start working towards post-event activities like publishing the videos and getting you to give a feedback about the event, some of us have already started thinking about how we make the next year's event even better than this year.

Pictures and videos of this years event coming soon.

More information about the next years event will also start coming out on the website in a couple of weeks. If you were there at the event and liked it, go spread the word. We look forward to having you at the event next year as well.

Stay tuned for more announcements.

We will be publishing them on the TEDxCalcutta website in the next few days.

As developers who believe in participating and contributing one of the things that I do often is tweet using Tweetdeck. 

As much as I love Twitter and Tweetdeck, one of the things I find deeply painful is keeping Tweetdeck or any twitter client open as I work. I have tried it over a zillion times now and if I have Tweetdeck or for that matter any twitter client open on my desktop I just cannot seem to get anything done.

It is the very core of the twitter design, the very thing that makes twitter tick that starts playing against you when you are trying to focus on a piece of work and get it done while keeping a twitter client like Tweetdeck open.

At the very core of the twitter design lies a fundamental component that makes twitter tick and makes you addicted to it: your ego.

Human beings by their very nature are playful beings.

We love playing and above all we love the idea of winning.

Winning allows us to feel good about ourselves and pampers our self-ego.

What twitter allows you to do through its one-forty-character-long-text-box and showing you your twitter mussel power on your timeline dashboard, is that it allows you to take a shot at the game of finding one more follower. You post an random tweet and if someone is searching the topic, likes what you say you get a plus one on your follower count. A minor boost of self-ego.

Of all the reasons that we tweet, one is that tweeting is almost like gambling where your prize is new followers.

Every time you do not have a meaningful insight or a meaningful piece of information that just has to be shared with the world and you go ahead and decide to tweet anyway, all you might be doing by publishing a tweet is taking a shot at the twitter-slot-machine where the reward is a bump-up on your follower count.

Stop playing the twitter-slot-machine while you are trying to get a focused piece of work done. In fact, I may even go so far as suggesting that you stop playing the Twitter Game all together and go tweet about something meaningful.

I wish you good luck.

After weeks of deliberation we have run out of time. Decisions are being taken, things are moving and work is getting done – really fast.

What had taken us three weeks to discuss is getting built in less than a week. What seemed hugely important during deliberation sounds utterly useless now. Priorities are changing. People are focusing on the right things and they are not wasting a lot of time, talking.

When that happens you know - It is the last hour.

The last hour is the time when you start running out of time. It is the time when you stop, take a gasp and you tell yourself – “shit, there is no time left!”

You are scared.

You are holding your ground.

Things are getting done.

Last hours are tremendously productive times. The good thing about them is that they test your limits. They provide you with some real constraints to work with and constraints are good.

Think of last hours as an exhaustive exercise for your brain. Too little of it, makes your brain weak. Too much of it can push you into a fire fighting mode.

Last-hours are often also an indicator that you are doing something new, or at-least something that you have not yet become very good at doing.

If you have never faced a last hour, chances are that you are playing it safe.

If you face too many of them you might be working in a reactive mode.

So, if you have just come out of a last hour and it made you stronger, smarter or wiser, pat yourself on your back. Then go and work harder so that you do not face another last-hour. Well, at-least not when you do the same thing next time.

I wish you good luck.