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.

Jack has been having a hard time in his personal life. Its been days since he been able to ship anything. I am worried. Not because of the fact that we would miss out on a timeline or because the project would slip.

None of that worries me.

The project is fully covered either ways.

Yet there is something about Jack not shipping for a long time that bothers me.

I decide to leave Jack alone for a while, waiting to see when he would be fully back instead of rushing to take his band-aids off.

A week later Jack approaches me. He wants to take over a new module and start working on it.

What makes my day is the fact that Jack is thinking of shipping again. He is back to doing what he is most known, liked and respected for doing in the organization. Soon he is shipping again. He is picking up the hardest of the problems and then getting them done.

But there is still a small gripe that is bothering me deep down inside as I monitor the check-ins on a pet open source project Jack had been working on for two years.

Nothing.

A couple of weeks later however, I see a new post on Jack's blog and a new check-ins on his open source project.

Jack is his usual self again.

I heave a sigh of relief.

Not because Jack is doing his job again or because he is contributing towards the project again, but because smack in the middle of work and personal problems Jack did not give up his commitment to his pet project or or his blog which was making him the kick-ass programmer he was. He is back in no time. He is participating and contributing, again.

While Jack's story has a happy ending, every once in a while, I see programmers, budding entrepreneurs and even bloggers go down the path of a personal or professional tangent so much so that they switch to a do-my-job-and-nothing-more mode for weeks, sometimes even months at a stretch.

The problem with pet projects, blogs, talks that you do at developer conferences and training sessions that you conduct in your organization or your local developer community, is that these are things you do not get paid for. Your immediate life, does not depend on these things and because you see no direct impact of stopping these things, they are the first to get impacted every time you get the smallest hit on your personal or professional life.

You have a really difficult project at work which is keeping you busy for ten hours a day. Why not just stop working on your pet project and focus on work?

You are having a small fight with your girl-friend. You don't feel like blogging about software development right now, do you?

Going on a holiday this weekend. Your blog can wait till next week, can't it?

Wrong decision.

What most developers around the world fail to realize however, is that as a developer, you are not just shipping within your organization. There is a different category of work and shipping which you do that ultimately defines who you are or who you become. These are those concrete, tiny, small deliverables that you ship to your people. Your tiny community. People who hang around in the same third place as you do.

These are those deliverables that rest on nothing more than a thin string of personal commitment. Deliverables that ultimately help you form your weak ties,  deliverables that land you with job offers and most importantly deliverables that help you learn from the best of people out there, overcome your insecurities and become a better programmer, even in your work life.

The next time you have a minor digression, in your work life or professional life and you feel like stopping work on your open source project or not sticking to your blogging schedule, remember that these activities are just as important as your going to work every morning.

If you can go to office and work, your digressions or your problems are probably not big enough for you to stop shipping outside of your work life.

Whether it is work connected to your work life or outside your work life, as far as you can, always be shipping.

We know you because you ship. The day you stop shipping for long enough, we might stop caring about you, your blog or your product.

Yes, of course we know your cat is sick and you need to take it to the vet this weekend, but we are still expecting you to stay up a little late and do that blog-post or that check-in to your pet project. Now, go pick a schedule for blogging or a schedule for checking-in to your pet project and be honest to yourself about trying really hard to stick to it.

I wish you good luck.

Jack in engaged in a deep conversation with his manager. The topic of the conversation is hugely stereotypical. Here is the story so far: his manager wants to know how much time a module will take to build, Jack has given an estimate, his manager is a little surprised and has asked him why it would take that much time. Jack is giving explanations and his manager is giving counter arguments on the but-we-already-have-that-code-in-a-different-module line.

The scene should have resembled exactly the kind of haggling that you would need to do in an Asian or Indian fruit market.

But sadly enough, it just resembles something I have seen so often, that I don't even find it remotely funny.

Every other day I see countless young and budding developers cribbing about how their manager does not understand their problems and does not give them enough time to get things done. Then I see the same developers struggling day and night till they emerge victorious as undefeated heroes who saved the day for the organization. 

As a developer, if you have ever allowed your manager to get into a haggle mode with timelines you have made three classical mistakes which will just make things worse moving forward.

Firstly, you have told your manager that you are not sure of your own velocity and that its OK to haggle.

Secondly, if you have compromised or changed your schedule (even by just a couple of days) you have actually told your manager that haggling helps. You have told your manager that you are typically the kind where it requires 'pushing you harder' to get things done.

Thirdly, if you have managed to complete everything you were supposed to in the newly haggled time frame, you have reconfirmed your managers belief that he was right in pushing you a 'little harder'.

Next time, before you see a negotiation meeting coming, think hard on the estimates you have given. If you have unrealistic estimates behave with integrity, fix them before you attend that meeting and send them over to your manager. If however, you believe that you have realistic estimates and that you are doing all you can to get a quality job done, have the spine to say 'no' to haggling. 

Realistically, finding yourself in a situation where the sky is falling, once or twice is unavoidable. Having said that, if you find regularly yourself working in a fire fighting mode and the reason is haggled deadlines, chances are that you are not acting responsibly and you do not have the spine to say no.

When you allow haggling over timelines, you reconfirm was your managers belief that if he gets you to a meeting-room and uses all the arrows in the management quicker, he can get you to perform magical acts which you otherwise do not perform.

Next time you find yourself haggling over timelines, do some soul searching and ask yourself if you are doing all you can to get the release out without impacting quality.

Are you behaving with integrity and already putting in all you can?

If the answer is yes, don't be bullied or intimidated and have the spine to say no to haggling.

I wish you good luck.

If you read this blog you have probably seen me cite Steve McConnell mention that optimism is one of the biggest reasons for projects failing in the software development world. You probably have also seen me mention that I am basically a pessimist.

Jokes apart, I do not truly consider myself a hardcore pessimist. What I like doing however, is listening to the critic inside of me. Michael Lopp explains this thought approach rather articulately in his legendary book, Managing Humans. He explains:

This is your internal voice, which does careful and critical analysis of your life, and he’s gained a powerful place in your head because he’s saved your butt more than once.

He’s the one who told you that offer from the startup smelled too good to be true. You remember that company, right? The one that simply vanished three months after you declined that stunning offer letter. It was the Critic who said, “How in the world can they afford to give anyone this type of offer when I don’t even understand their business model?”

The Critic was the one who calmed you inner nerd and convinced you to not buy HDTV three years ago, and he told you not to trust that fast-talking engineering manager who emphatically guaranteed his team would be done on schedule.

The Critic said, “People who talk fast are moving quickly to cover up the gaps in their knowledge.”

The Critic was right.

If you have ever worked with a team when the sky is falling you probably know that the first part of the deal with getting out of the shitty situation is that you do not panic.

The second part is weaving an inspirational story which you yourself believe in and then telling it to your team. Its the absolutely amazing inspirational pep-talk that you see in Hollywood movies after which the team goes out and wins the game. 

Its the third part that is actually more tricky. While your entire team is pepped up and working the third part involves listening to the critic within you when he starts calculating the possibility of your team not being able to make it in time.

It is your critic who nudges you to start thinking of alternate ways of getting out of shit.

It is your critic who tells you to start talking to the customers in advance and let them know that the cute user interface you promised them is not going to be a part of the next sprint.

It is your critic who tells you to start talking to the right people in the culture chart and tell them that you might be missing out on features in the next release.

It pays to listen to your critic, because when Jack comes to you a day before the release and tells you that the last three items in the backlog might not ship, you don't give him that intimidating look. Instead, you smile back and tell him it is not a problem at all.

Your critic can be really helpful at times.

When it starts mumbling in its usual soft voice, it is time to shut up and listen.

I wish you good luck.

Have you ever sat in one of those meetings where really senior people get together and scratch their heads on aligning the organization under one process? If you have, then chances are, you know what trying to create an army of clones feels likes.

Every now and then I see countless young managers and even budding entrepreneurs of startups make this mistake.

Here is how the story typically unfolds:

During the early startup days of the organization a team is usually seen as out performing. Members of the team and the team as a group seems to stand out. Very soon the team seems to have everyone's attention and anything that they work on seems to get done successfully.

This is when the managers in the organization get together in meeting rooms and start asking each other questions like - Can we not have all other teams in the organization replicate this process and achieve success too?

Asking this question, dear reader, is a big fat mistake that even I, in my early management days have been guilty of. As it turns out, there are multiple issues with trying to replicate success using one standard process across the organization. 

For starters, this approach is flawed because while you are trying your level best to copy the process and everything else that the successful team is doing, you can hardly replicate their secret sauce or their flocking patterns. Both the culture and the flocking pattern of the team is usually the hardest to copy because it is based on silent, subtle, unspoken factors like respect and mutual trust for each other.

Secondly, a successful team is constantly morphing. Which means that by the time you get to copying it, the team has already morphed and discarded its older practices and processes. One example that instantly blazes through my mind and I write this, is my experience with Agile. 

As a team, a bunch of developers and I were the first at Multiplitaxion Inc to adapt agile and swear by it. But then, by the time the decision to copy and replicate what was working for us over to other teams was made, we were actually done with using Agile by-the-book on our project.

We had stopped having daily scrums. We did not need them.

Communication was flowing freely and lucidly throughout the entire team and daily scrums had been replaced with random coffee breaks where team members were discussing the backlog items. The items were also getting closed. When people wanted help or were getting stuck they were just getting up, walking over and asking for help. Everyone knew what the others were working on and code was truly becoming a shared asset for us.

We, as a team, had morphed before we could be replicated and copied. Clearly, it was not just Agile that was making this team tick. It was their ability to form a creed that had to be copied here and that in essence is not an easy thing to replicate across teams.

Thirdly, when you copy and replicate a process or a team across the organization you close your eyes to other processes and approaches to success. Yes of-course something works, but then something else could work even better. Allow each team to take their own approach. Allow each team to encounter their own set of failures. Allow each team to address their own issues in their very own personal ways and if they cannot, help them.

Remember each team is different. Some are more professional then the others. Some have a strong personal touch element that glues them together and some even have political aspects built right into the core of the team.

Your first responsibility as a manager, leader, entrepreneur or whatever it is that you call yourself, is to accept this diversity. Once you have done that, utilize their strengths and even their weaknesses without constantly feeling the need to change them into one big army of clones.

Embrace diversity and allow your teams to take their own approaches. Let them stumble, fall and recover. If the team consists of kick-ass developers who know what they are doing, they will figure it out, eventually. If you are stuck with incompetent idiots, no amount of replication or process will work anyway.

Go ahead, let them figure out their own problems, work on their own chemistry and form their own approaches to solving problems.

I wish you good luck.