I work in the high-tech business and being a programmer I am often surrounded with more programmers. Now we as programmers, as it turns out, are incredibly amazing and weird people who believe all problems on this planet can be solved by writing code and building a system for solving the problem.

This is probably why, I also get into frequent discussions with young and budding web 2.0 (whatever that is) enthusiasts asking me if I have seen this cool and happening site which will help me promote my blog and help thousands of more people find it.

I on the other hand, seem to consider this blog to be my true-third-place. A quite dimly lighted corner of the web where I can meet the kind of people I wanted to meet and start real online and offline discussions with them. Through my very own personal thoughts on software development, what I am really trying to do is not to change the world, but make a very tiny little dent in my very own personal universe.

I am not trying to sell to an audience of millions. Just trying to find one individual I can connect to and have meaningful conversations with over a mail thread or a cup of coffee. As I have often said, I am happy with this blog as long as it has three readers, me, my mom and you, dear reader.

I am not trying to start a movement here. All I am trying to start through this blog, is small threads of conversations with the kind of people I would like to connect to. Having said that, even if it was a movement that I was trying to start, I am not so sure if trying to sell your ideas to a million users and trying really hard to get a million individuals attached to your cause is the best way to start a movement.

Derek Sivers in his TED talk describes the importance of finding just one true follower or even being that first true follower rather than 'leading' the whole wide world into following a movement. He puts his  point across through a video of a shirtless guy dancing like a manic to start a movement. He explains:

The first follower is an underestimated form of leadership in itself. It takes guts to stand out like that. The first follower is what transforms a lone nut into a leader.

If you are the type, like the shirtless dancing guy, standing alone, remember the importance of nurturing your first few followers as equals, so it is clearly about the movement, not you.

But we might have missed the real lesson here. The biggest lesson, if you noticed, did you catch it? Is that leadership is over glorified. That yes, it was the shirtless guy who was first and he will get all the credit but it was really the first follower who transformed the lone nut into a leader.

So as we are told that we should all be leaders,  that would be really ineffective. If you really care about starting a movement, have the courage to follow and show others how to follow and when you find a lone nut doing something great have the guts to be the first one to stand up and join in.

If you haven't clicked on the link to the video yet, I strongly suggest you do.

So the next time you think of starting an organization, starting a product or even something simple as starting a blog, stop worrying about search engine optimization, getting your site up on that popular website or using the quote-unquote 'social media' to publicize what you are doing.

Be the lone shirtless dancer, prepare to get ridiculed and continue to do your remarkable dance consistently.

Chances are that you will stumble upon at-least one genuinely lone nut who will decide to join you as a partner in crime or better still you just might find a few other lonely nuts that you can join and that is the start of a small conversation. Maybe even a tiny little movement.

When that happens you are on your way and you know it from within.

You don't need a system.

You don't need to go shopping for Google Ad-words to increase you site traffic anymore.

I wish you good luck.

Just how much time do you spend in meeting rooms, conference calls and web conferences? How much time do you chit-chat with fellow developers? For how long do you have casual conversations discussing your family and your last vacation with your team? How many hours a day do you spend discussing people issues, organizational issues and project issues? Put simply, how much talking in any given day do you do?

I have been observing people in the business of building software and the conclusion that I have come to is that the software programmers and managers around the world are quietly turning into chatterboxes who chatter more and do productive work less.

"Come on Pops" - you tell me - "Talking is important. It is how communication between programmers happens".

Of course talking is important. Hugely important. But then there when you find yourself spending more and more time just talking rather than doing anything productive, there are some serious reasons to worry and do something about it.

The thing with talking, specially when you do it in a professional setup like an organization and when you are talking to your fellow programmers, inside an office meeting room, is that it seems like work. The reality most of the times however, is that It is either inspiration, collective thinking, entertainment or just plane and simple whining. Talking, in more cases than not, is not work.

I am not saying that inspiration, collective thinking or entertainment are not needed, but when you confuse them with work, you tend to do more and more of those rather than working and that is what makes talkers addicted to talking.

Jeff Atwood describes this rather articulately in his post on the topic. He explains:

In software, some developers take up residence on planet architecture, an otherworldly place where software is eternally planned and discussed but never actually constructed. Having endless discussions about software in a conference room or mailing list feels like useful work-- but is it? Until you've produced a working artifact for the rest of the world to experience, have you really done anything?

To be honest, this is not just an architecture or development thing after all. This is a huge problem even with Leadership, Quality Assurance, Entrepreneurship, Documentation, Marketing or virtually any field that you can think of. Even genuine management is much more about getting things done than it is about talking. It is about empowering people rather than just sitting in meeting rooms and discussing how things 'aught to be'.

If you find folks in your organization who spend a lot of time talking about how someone should change the culture of the organization, chances are that these individuals will not be that 'someone' who ultimately changes the culture of the organization.

Ever been through a long meeting where everyone discusses how-the-morale-of-your-team-can-be-improved for hours and comes out with no resolution? Bad Management.

Want to do something real?

Send out an email asking for a small budget for Logo-ware. If you get no response, spend some of your own money to get a really small quantity of seriously appealing Logo-ware printed and give it out. Do not spend countless hours talking about the implications of giving out logo-ware how people will react to it, how much morale increase you will get out of it or if it will even work. Do it. Try it out.

And then move on to doing something else which you believe will positively impact the morale.

Do one thing at a time and every time you hear the word call or meeting cringe.

I have watched programmers, managers, business analysts, testers and even entrepreneurs and I have come to a conclusion that might seem rather strong and harsh but it is indeed true. Those who cannot do things, talk about doing them.

Focus on 'doing' and while it might seem really tempting to call all your programmers in a meeting room and start 'discussing' a serious problem, ask yourself if you can get everyone to do something about the problem rather than just 'discussing' it.

I could have said this politely and I could have mitigated my speech, but then it probably would not have had the same impact that it would otherwise have. So here is my advice for today which I hope nudges you on the path of productivity - Try to see if you can shut The F-Up and Go get some real work done.

I wish you good luck.

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.

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.

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.

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.