This idea of this post started off with a mail thread from someone who has a knack for sending amazing links which nudge you to do some serious soul searching every time you click one of his links. This one was a post about the iPad.

To be honest however, it was more than just an iPad post. Peter Bregman in his post on why he returned his iPad in less than a week, talks about the importance of boredom in your life. He explains:

The brilliance of the iPad is that it's the anytime-anywhere computer. On the subway. In the hall waiting for the elevator. In a car on the way to the airport. Any free moment becomes a potential iPad moment.

The iPhone can do roughly the same thing, but not exactly. Who wants to watch a movie in bed on an iPhone?

So why is this a problem? It sounds like I was super-productive. Every extra minute, I was either producing or consuming.

But something — more than just sleep, though that's critical too — is lost in the busyness. Something too valuable to lose.

Boredom.

Being bored is a precious thing, a state of mind we should pursue. Once boredom sets in, our minds begin to wander, looking for something exciting, something interesting to land on. And that's where creativity arises.

My best ideas come to me when I am unproductive. When I am running but not listening to my iPod. When I am sitting, doing nothing, waiting for someone. When I am lying in bed as my mind wanders before falling to sleep. These "wasted" moments, moments not filled with anything in particular, are vital.

They are the moments in which we, often unconsciously, organize our minds, make sense of our lives, and connect the dots. They're the moments in which we talk to ourselves. And listen.

To lose those moments, to replace them with tasks and efficiency, is a mistake. What's worse is that we don't just lose them. We actively throw them away.

"That's not a problem with the iPad," my brother Anthony — who I feel compelled to mention is currently producing a movie called My Idiot Brother — pointed out. "It's a problem with you. Just don't use it as much."

Guilty as charged. It is a problem with me. I can't not use it if it's there. And, unfortunately, it's always there. So I returned it. Problem solved.

Go ahead, click the link and browse through the entire post if you haven't done so already. The valid point Peter seems to be making here, is about slowing down. Giving your brain some boredom so that it can figure out creative, genuinely fun and innovative things to do to avoid that boredom.

It's more than just the iPad.

I have talked about this before. Firefighting for instance gets you in a mode where you are least creative.

With a zillion gadgets, MP3 players and twitter on our phones, we are insanely connected to random people all around the globe but it does the exact same thing to your brain that firefighting does. It gives you an easy convenient way to make yourself busy and indulge in activities which are 'seemingly productive' but result to nothing other than a truck load of time getting wasted in the long run.

If you work in a field which involves creative work or are connected with the process of building software that is supposed to make big or small dents in the universe, the first thing you need to do is slow down and give your brain some boredom.

Boredom is important,  because when your brain experiences boredom and feels restless, it starts thinking of productive ways to keep itself busy. That's when some of the best ideas and solutions emerge. The last time I checked, ideas and amazingly interesting solutions to complicated problems, typically don't emerge when you are watching an action movie or a soccer match for instance.

Go ahead, slow down.

Experience a little bit of boredom today.

Use this boredom to let you mind wander and come up with a genuinely innovative idea or two.

I wish you good luck.

Folks at Multiplitaxion Inc are gathering in small groups and talking every time I walk through the cafeteria. There are whispers all around. It's in the air. You can quite literally feel it. There is drama in the air and it looks like the drama has a drama queen.

Or should I say, a drama king.

It seems like Fred just had a hugely vocal argument about why he cannot be working from home on a certain day. Fred it seems is not willing to accept the fact that HR isn't comfortable with the whole idea of working from home. Fred is also not willing to have a logical objective conversation with the HR folks and convince them of the benefits of letting folks work from home at times.

He chooses the vocal loud revolt instead, creating a loud conversation which turns into a heated argument.

Very soon, every single engineer, in every nook and corner of the office knows the incident and is talking about it.

Fred's intent is pure. His approach however is destructive because it involves a simple ingredient which single handedly is capable of destroying teams and organizations.

Drama.

A few days later, one of our scrums, begins with a joke involving a senior manager. Everyone in the scrum takes a stab of cracking a joke at this manager. Soon, a decently normal scrum now involves a lot of talking. It has almost turned into one of those meetings where nothing gets done. This dear manager of ours, has fired three innocent hard working programmers and has given us something to discuss.

More drama.

Some idiot somewhere has sent condescending emails with a threat to one of his managers at the time of his resignation. The email seems to have gone to everyone in the group and a truck load of people seem to be involved in discussions on the topic.

Insanely massive drama.

During my early days at Multiplitaxion Inc, I loved going to office every day, but then there was a part deep down within me which wished that there was no drama the next day. It was stressful. Seriously stressful and non-productive.

But then, to be honest, there was also a deep dark secret part of my brain, which uncontrollably liked observing drama as it unfolded. Like everyone else in the organization, I often got involved in discussing the drama as it was unfolding.

That, to an extent, is what we all do. At different levels. When there is drama unfolding all around, you are likely to get sucked in. The spice of the drama, happens to be much like the oil in the McDonalds French fries. It surely won't kill you in a shot or two, but then when it sneaks up on you, you hardly know what hit you. That is exactly what drama does to your productivity, your work ethics and your professionalism.

It turns you from a productive programmer to a drama queen before you even know it.

I have talked about this before. Relationships and circles based on criticisms don't last long. Work relationships based on dramatic situations are even worse. So I totally understand that you had nothing to do with Fred sending out that flame email to his manager and copying the entire group while he was at it, but even then, might I suggest that you disconnect from the drama and focus on being productive.

Might I suggest that when a colleague takes you to a cup of coffee and then starts bitching about a mutual boss, you gently change the topic and focus on what you can do to fix the situation rather than whining together like babies.

It's hard.

But I didn't become a programmer because I wanted to bitch, whine, moan, cry or experience a lot of negative drama. If I wanted that, I would have given my shot at the films or television. I joined programming because I wanted to work with the sharpest, smartest, wildest, wittiest and some of the most creative people I could find and then join forces with them to build stuff or tell stories about what they do or how they do it.

The lesser drama you see on a day-to-day basis, the more you will get done, the more productive you will be, the happier you will be, the more flow you will experience and above all, you will be able to build more stuff and get more done.

Go on, the next time you start experiencing random negative drama, say no to it.

Seriously.

Start saying no to it.

Chances are high that you will get much more innovative, creative and above all productive, instantly.

I wish you good luck.

You have spent days observing Jack. He is awesome when it comes to dealing with pressure situations. Never looses his cool. Has shown perfect leadership qualities when talking to you, even in the most pressure prone situation, giving you a strong vibe that everything is under control.

You are impressed.

Months later, you find yourself sitting across the table with a bunch of developers telling you how Jack is throwing his shit their way, bossing them around and making them do hardcore deadline driven development.

You cringe.

A few days ago I posted a small tweet.

You thought you knew Jack.

Human beings happen to be hugely polymorphic. They are insanely different creatures in different situations and in different groups.

Jack, as it turns out, happens to be a seriously kick ass programmer and a very good person to have on your team. Give Jack a couple of additional programmers to mentor or work with and Jack measures them with the much higher level of critical outlook that he measures himself with. This is not about qualities or talents that Jack lacks when working with or mentoring a small team.

When he happens to be seating in a status meeting or dealing with crisis situation Jack happens to be a very different human being than what he is when his team is facing a crisis. Observe carefully and you will be able to literally see Jack morph from a quite, calm, cool headed individual sitting in front of you, to a angry, loud micro-manager when working with his team.

This is not the only situation where people in your teams and organization will morph though. Another classic case of morphing that human beings often go through is when they have given you their resignations.

This is when folks will give you a truck load of suggestions about how your organization needs to improve, how it has been missing out on certain areas and above all, all those dozen tiny little areas which he just did not seem to care about before he resigned.

The same individual who tells you how much he loves working in your organization or your team morphs into a totally different human being when he interviews for a different company next week and answers the famous "three things that you don't like about your current organization" question in that interview.

When you are working with a team of three individuals, you are probably dealing with a team of more than thirty personalities, constantly morphing from one to another.

This is important. So important that I am going to say it again.

When you are dealing with a team of three individuals, you are actually dealing with thirty different personalities, not three.

If there is one thing years of working with human beings has taught me, it is that you cannot be banging your head over being nice to all thirty of these constantly morphing personalities. Focus on the three that work with you.

Go ahead, talk to Jack about how much his team hates working with him, even if it means rubbing him in the wrong way.

Go ahead and stop worrying about the personality that is constantly looking for a change because irrespective of how much you or your organization tries there are always going to be some folks who will occasionally morph into individuals who are so dissatisfied with small things that you cannot just retain them in your organization or your team.

Stop worrying about rubbing two-hundred-and-ninety seven morphing personalities the wrong way and focus on the three that work with you.

Be nice to them and do all you can to make their work experience a pleasurable one.

I wish you good luck.

Multiplitaxion Inc, was a technical training provider where I happened to work for a few months. Multiplitaxion Inc, as it turns out was very open to change and as far as getting approval for change was concerned, if you knew the right people to talk to, getting your ideas approved for implementation was easier than you could think. But then, getting your ideas approved was just a small part of the brining-about-change game.

If medical science ever discovers such a thing as organizational procrastination, let it be known to mankind today that you read about this condition here first. Multiplitaxion Inc, was a master at it.

This was, in more ways than one, very similar to silent disagreement. In fact, it was worse because it worked at an organizational level. Projects that had been approved took days to get started, policies took weeks to get applied, rules took months to actually get changed and even project parties for successful projects took countless number of days to get planned.

Approvals were quick.

Actual implementation however, took months, even for the smallest of decisions.

Amidst all this procrastination, one thing that we as young and budding engineers learnt was that procrastination at an organizational level often also leads to organizational amnesia. Before long, we realized that some of the best ideas that would have otherwise turned into innovative products, were not even seeing the light of the day, because people were approving them and then procrastinating over them till they dropped out of everyone's memory.

If you happen to run an organization or have the power to get things done within your organization my advice to you would be, don't create organizations or teams with procrastination and amnesia. Think hard over an idea till the time you back it and approve it. Once you know you need to get something done, stop your procrastinations and get things done as a fast moving team or organization.

I wish you good luck.

If you have ever worked on anything that was used by more than one user, for more than a few days of their lives, you probably get a truck load of hugely random and weird feature requests at work. If you have worked with a bunch of marketing and sales folks responsible for demoing your product to 'potential customers' you probably know this even better. 

I have talked about avoiding the Perils of Demo Driven Development through heavy use of YAGNI before. But then having said that, every once in a while, a random critic will convince your marketing and sales team that if you could just build that chat application that allowed the point-of-sales team to interact with each other and integrate it with your billing system your billing system will sell like hotcakes.

If you have ever thought of giving in to temptation and building stuff that the competition is building just so that your product could compete with your competition, Paul Buchheit of Gmail has sensible word of advice for you. He explains:

I believe this "more features = better" mindset is at the root of the misjudgment, and is also the reason why so many otherwise smart people are bad at product design (e.g. most open source projects). If a MacBook with OSX and no keyboard were really the right product, then Microsoft would have already succeeded with their tablet computer years ago. Copying the mistakes of a failed product isn't a great formula for success.

What's the right approach to new products? Pick three key attributes or features, get those things very, very right, and then forget about everything else. Those three attributes define the fundamental essence and value of the product -- the rest is noise. For example, the original iPod was: 1) small enough to fit in your pocket, 2) had enough storage to hold many hours of music and 3) easy to sync with your Mac (most hardware companies can't make software, so I bet the others got this wrong). That's it -- no wireless, no ability to edit playlists on the device, no support for Ogg -- nothing but the essentials, well executed.

We took a similar approach when launching Gmail. It was fast, stored all of your email (back when 4MB quotas were the norm), and had an innovative interface based on conversations and search. The secondary and tertiary features were minimal or absent. There was no "rich text" composer. The original address book was implemented in two days and did almost nothing (the engineer doing the work originally wanted to spend five days on it, but I talked him down to two since I never use that feature anyway). Of course those other features can be added or improved later on (and Gmail has certainly improved a lot since launch), but if the basic product isn't compelling, adding more features won't save it.

On his assessment on whether iPad is a great product or not, or if all the critics shouting at the top of their voice about the lack of features in the iPad are justified in doing so or not, Paul gives useful advice to young and budding product designers. He explains:

By focusing on only a few core features in the first version, you are forced to find the true essence and value of the product. If your product needs "everything" in order to be good, then it's probably not very innovative (though it might be a nice upgrade to an existing product). Put another way, if your product is great, it doesn't need to be good.

Making the iPad successful is Apple's problem though, not yours. If you're creating a new product, what are the three (or fewer) key features that will make it so great that you can cut or half-ass everything else? Are you focusing at least 80% of your effort on getting those three things right?

If you are working on a product, go ahead. Pick those three small and simple things which your product is supposed to achieve. Write them down in easy to understand sentences on a whiteboard.  Now, do some serious soul searching on if your product does these three things flawlessly. Is your product the best in the world at doing these three things? With consistent effort and hard work, can it become the best in the world at doing these three things?

If you answered no, adding features to your product will not help. If you answered yes, put in that consistent effort and hard work to make your product a great product, because if it is a great product, you won't have to slog your ass to make it a good product.

I wish you good luck.

During my work at a client, who for the purposes of this post, I shall refer to as Multiplitaxion Inc, I saw an amazing example of management and HR policies, backfiring in ways that no-one had expected them to backfire.

Multiplitaxion Inc, was an amazing place to work at. Even for me as an outsider or a consultant who was just visiting, the folks at Multiplitaxion Inc were not just nice, they were super nice. They got me my very own personal cabin, gave me printer access and even had a name plate with my name printed even though I was just going to work with them for a few months.

Multiplitaxion Inc, happened to be one of those places where a group of like minded people gather, not just to work but to live a like minded life. These were bunch of rather amazing oil engineers and software engineers who worked for twelve to thirteen hours a day. Walk into Multiplitaxion Inc at seven in the evening and chances were that you would see a bunch of engineers flocked together trying to solve a problem.

During my stay at Multiplitaxion Inc one thing I noticed was that people hardly ever took leaves. During my first three months of stay, no-one from my team ever took a leave. 

This story however, begins on a bright sunny day when someone high up in the pecking order who had access to the time card logs and no real work to do decided to glean though the logs and discovered that people were coming really late to office. Soon strings were pulled and decisions were taken for the best interest of the organization.

Emails went out informing the employees that folks entering office after ten would be marked absent for the day and that people were 'requested' to be at office on time. A policy that was supposed to put some sense into office timings and increase employee productivity. A policy that started backfiring on the very first week on which it was imposed.

Turns out, Jack, who happened to be one of the youngest and the brightest programmers in our team, stumbled on a scenario which caused the policy to backfire on the very week in which when it was imposed. One first morning, as Jack prepared to leave from office, his eyes fell on the watch and seeing that it was nine-thirty already, Jack realized that there was no way he was going to cover a one hour drive and make it to office by around ten. 

Jack, gave the situation due thought and given the fact that he had a ton of leaves cumulated with him because he never took any, decided to go for the idea of taking the day off. From that point on, the idea spread like wildfire. Folks who had never taken leaves in years, suddenly started going missing. Passion that had once driven folks to come to office, turned into confirmation towards rules. Leaves that were never utilized were now used up rather quickly.

A policy that was designed to make people spend more hours at the workplace turned into a policy that made them spend the least number of hours that they had spent in office during their entire careers.

What had happened here is very articulately describes by Dan Ariely in his book Predictably Irrational. Dan explains:

My good friends Uri Gneezy (a professor at the University of California at San Diego) and Aldo Rustichini (a professor at the University of Minnesota) provided a very clever test of the long-term effects of a switch from social to market norms. A few years ago, they studied a day care center in Israel to determine whether imposing a fine on parents who arrived late to pick up their children was a useful deterrent.

Uri and  Aldo concluded that the fine didn't work well, and in fact it had long-term negative effects. Why? Before the fine was introduced, the teachers and parents had a social contract, with social norms about being late.

Thus, if parents were late—as they occasionally were—they felt guilty about it—and their guilt compelled them to be more prompt in picking up their kids in the future. (In Israel, guilt seems to be an effective way to get compliance.) But once the fine was imposed, the day care center had inadvertently replaced the social norms with market norms.

Now that the parents were paying for their tardiness, they interpreted the situation in terms of market norms. In other words, since they were being fined, they could decide for themselves whether to be late or not, and they frequently chose to be late. Needless to say, this was not what the day care center intended.

In the same book Dan goes deeper into the concept of why this fine did not work using the idea of two worlds that each one of us live in. He explains:

As Margaret Clark, Judson Mills, and Alan Fiske suggested a long time ago, the answer is that we live simultaneously in two different worlds one where social norms prevail, and the other where market norms make the rules. The social norms include the friendly requests that people make of one another. Could you help me move this couch? Could you help me change this tire? Social norms are wrapped up in our social nature and our need for community.

They are usually warm and fuzzy. Instant paybacks are not required: you may help move your neighbor's couch, but this doesn't mean he has to come right over and move yours. It's like opening a door for someone: it provides pleasure for both of you, and reciprocity is not immediately required.

The second world, the one governed by market norms, is very different. There's nothing warm and fuzzy about it. The exchanges are sharp-edged: wages, prices, rents, interest, and costs-and-benefits.

Such market relationships are not necessarily evil or mean—in fact, they also include self-reliance, inventiveness, and individualism—but they do imply comparable benefits and prompt payments. When you are in the domain of market norms, you get what you pay for—that's just the way it is.

Dan holds the opinion that when you take a social norm and try to replace it with a market norm you typically, for lack of a better word, f@#ck things up. He explains this much more articulately that I would be able to describe it, using what happened with the fining incident in Israel:

But the Real story only started here. The most interesting part occurred a few weeks later, when the day care center removed the fine. Now the center was back to the social norm. Would the parents also return to the social norm? Would their guilt return as well?

Not at all. Once the fine was removed, the behavior of the parents didn't change. They continued to pick up their kids late. In fact, when the fine was removed, there was a slight increase in the number of tardy pickups (after all, both the social norms and the fine had been removed).

This experiment illustrates an unfortunate fact: when a social norm collides with a market norm, the social norm goes away for a long time. In other words, social relationships are not easy to reestablish. Once the bloom is off the rose—once a social norm is trumped by a market norm—it will rarely return.

For the passionate software and rig engineers who worked at Multiplitaxion Inc, coming to office in the morning and working passionately for problems that were thrown their way was a social norm. What the time-policy at Multiplitaxion Inc did, was to take the social norm and mix market elements to it.

What Multiplitaxion Inc did with this policy, in the words of the book was much like, paying your mother-in-law for a fantastic thanksgiving party or for that matter paying your wife for her love.

Mixing social and market norms usually creates odd situations for everyone involved. If you lead a team or run an organization, it is hugely important that you realize the social norms that exist within your organization. There are things that people might be doing as a part of their existence in the 'social world' and the moment you try to reward or punish them using market norms, you are likely to create awkward situations and policies that backfire in ways you never thought.

Go ahead, use social norms heavily in your organization and when they are in place, don't ever try to replace them with market norms, because if you do, you just might f@#ck things up.

I love writing on this blog. For me this blog is more of an opportunity to stand back, evaluate the experiences of my life and write about these, by adding a little bit of myself to this blog. The very fact that I post multiple times a week, turns this blog into something which allows me to exercise my writing skills and develop my writing mussels.

Having said that, this post has developed a very different audience than what I initially expected. Besides programmers, this blog is read by managers, business folks and even my mom. One of the thing that I try to pay special attention to, while writing, is the timelessness of each post.

I try to add content here which usually does not tend to become obsolete when the next version of visual studio comes out. Of course, there are one or two  exceptions, but then, most of it happens to be timeless. At-least I try to make it timeless to the best of my ability, even though when I read my older posts, I do realize how much I sucked.

Because this blog is read my more than one reader, it often means that I end up spending a lot of time adding graphics, hyper linking, formatting and proof reading all content that goes out here.

To be honest, I love doing all of that.

A huge part of my life includes working with other human beings and that is what this blog is all about.

But then, there is another part of my life. A different persona, so to say. One that deals with bytes. One that likes to fiddle with technology, explain design patterns using wild examples and whacky home made philosophies and the one that likes to tinker with the code-base of crux in my free time.

Unlike most software developers, I have been fairly open about my experiences with other developers or what I learn from these experiences but then unlike most developers who write blogs, my close encounters with code and technology often remain undocumented.

The idea is not new however. I have been thinking about this for a long time. The whole concept of learning like a teacher and teaching like a student is something that I have talked about before on this blog.

I think it is time when I can introduce a different part of my personality on a different blog all-together.

People, here is presenting, my code-persona.

Think of code persona as my personal little wall to scribble things on as I work. Just bought a new cam-coder, you might read a review that I slapped together rather quickly there. If I just learnt a neat way to solve a programming problem, you might read it on code persona. The posts on code persona might not be as well formatted or as minutely proof read as this blog, but that's the whole point. Like I said, its my personal little wall.

So What Happens To This Blog?

Nothing. It continues. Just as before.

I am not stopping to write on this blog.

This blog will continue to have posts added to it, just like before.

So if you like the kind of content that you read here, you will continue to find more of it. But if you are a hardcore programmer and you are more interested in curly brackets and semi-colons, code-persona is the blog you also want to subscribe to.

It's been quite some time since I did some serious hardcore technical blogging.

I feel like a little child again and that, I believe is a really good thing.

Feel free to hang out with us on code-persona.

More content will start getting added there soon.

Wish me good luck.

My team at Multiplitaxion Inc, happens to be a group of really seriously kick-ass programmers where even some of the weakest in the team can kick some serious butt. Fred clears multiple rounds of interviews for Multiplitaxion Inc, and wants to join this team.

I cringe.

As far as I am concerned, if you are joining my team, I prefer that you have, either gone through my interview and met my criteria or have proved yourself within the organization in one way or the other before you are made a part of my core team.

Fred as it turns out, has done neither.

He is a young and budding programmer fresh out of college who has taken an engineering degree, answered a few math questions and a few puzzles correctly and cleared the Multiplitaxion Inc, interview with flying colors.

A few mails back and forth, the really awesome folks at the Human Resources department Multiplitaxion Inc, allow me to screen the guy and they give me the liberty of taking him in my team or letting him move over to a different team.

I spend some time talking to Fred, asking him a simple question - We have a month to build anything that you want to build. Can you spend a day thinking about what you want to work on and let me know tomorrow. We will start working on whatever you pick and I'll help you as we move on. After a month we will evaluate what we have built and if it's good enough you join the team.

Fred looks at me like I just dropped a rodent on the table.

The next day he comes back with three things that he would like to work on:

1. A brand new operating system - which is what you often fantasize about building when you are in an engineering college and if you are lucky they even let you build a small theoretical kernel as your college project.
2. A brand new security algorithm - again a hugely academic project I am sure a million mediocre students in a million colleges around the world are working on.
3. A Patient tracking system for a hospital - this one, I'd rather not comment on, for the fear of sounding very nasty and mean.

Then Fred basically tells me that even though he has thought of these, he is not going to actually work on any of these. Put simply he is not up for this whole lets-innovate-idea. He wants an assignment and he wants to start working on it right away.

On any given day I get bombarded with dozens of ideas which I tend to put on the back-burner till they find me, grab me by my collar and make me work on turning them into realities. In our days, we became programmers, because it was fun and because it was empowering. It allowed you to think of stuff you could build and turn this stuff into reality.

I see, talk and work with countless programmers around the world and while the niche still gets it, I think, overall we are just breeding 501 programmers who join the software business because its good money or because their friends are joining it. Of all the things that young and budding programmers coming fresh out of college these days tend to lack, is the ability to find their own sources of motivation.

We are screwing the software development world and letting it loop in the infinite loop of failure by turning it into factories where clones are produced. If you are reading this and are responsible for hiring folks in your organization, might I suggest that you turn this into an interview question.

Ask a candidate what he would build if he was given one month of free time to work on anything that he wanted to work on. His reply may or may not impress you, but it will tell you a lot about why he wants the job. Now make an objective decision on if you really want him on your team.

Go hire programmers who can drive themselves rather than folks who want to be driven like a folk of sheep.

I wish you good luck.