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.

Most managers typically go through the periodic phase of being an asshole. Its the time when you play the blame game. Its typically the time when you forget that you are not getting paid to screw people left and right.

The difference between a-fun-to-work-with-person and a prick is that while the prick never snaps out of that adolescent stage of being an asshole, the fun to work with manager often gets sick of it, disconnects and learns from those times. He looks back at those times of his life as painful moments and treasures everything that he learnt during the conversion phase.

He probably has a Not-To-Do list for himself which is bigger than a to do list for his team.

He is serious about the idea of being nice at workplace.

I call these folks, converted assholes.

Now, a truckload of things might have caused the conversion to happen, starting from a tragedy to just finding a pet, but a guy who was once an asshole and is now raging a war against the idea of prickdom at workplaces, is invaluable for your organization.

This is the guy who understands how prickdom works inside out.

This is the guy who can smell prickdom from miles and can spot an asshole in an interview.

This is the guy who can identify assholes in your organization.

This is the guy who can give the assholes in your organization a hard time. Sedate the monkeys. Confuse the jargon idiots with more random jargons. Attend meetings and sit through them without dozing, guarding the ground from folks pooping on your organization or team through funny decisions that are usually taken in these meetings under the name of 'working for the best interest of the organization'.

Put simply, he knows how the game is played, he plays it well and can be a bigger prick when dealing with pricks in your organization.

If you are a young and budding entrepreneur looking to have a kick-ass environment at your workplace, go hire a few converted assholes and get them to rage a war against prickdom within your organization.

I wish you good luck.

I have always nudged young and budding developers to try and turn themselves into one man armies. I have also often gone ahead and said that a good programmer is formed when, as they say in martial arts, the warrior and the weapon become one.

In a recent conversation with a young and budding programmer regarding how most office environments are nothing more than cubical farms for breeding incompetence, I stuck to my point, that most awesome programmers who know what they are doing will figure out ways to communicate and collaborate without needing a common physical location.

They will find quite islands, homes, cafeterias and corners of the world to work from. They will continue to thrive even as more and more loud or lousy workplaces continue to get built around the world.

The seriously kickass programmers will turn into one man armies and software cells that can function from anywhere and anytime. They will carry their weapons and most importantly they will carry their ability to become one with their weapons anywhere and anytime.

The Dell Mini 9, was given to me by eFORCE to try out when Netbooks first came out. I have had this thing for more than a year now and my assessment of it is that this is one rather peculiar weapon in the hands of a developer.

When I say that the Dell mini 9 is a very different kind a weapon, what I really mean by that, is that Net-books by their very nature, screen size and keyboard layout are a very different kind of a weapon in the hands of a developer.

To begin with they tend to make any developer worth his salt get a serious headache when you try to work on them. After a while, you start questioning the whole idea of working on a tiny oddly laid out keyboard and a tiny screen.

It is purely because of this peculiar nature of these devices that the Dell Mini 9 practically sat unused for months lying at my home.

I would occasionally use it to load and work on Ubuntu, but as far as practically using the device was concerned, I would cringe at the very thought of typing at the small keyboard and staring at the small screen.

I used it so little I even managed to lose its power cable.

It was not until recently that the idea of being able to work from anywhere and harnessing the power of mobility started getting discussed, that I thought I'd give the Netbooks another shot. The idea was to get a new internet access data card and use the Netbook to work from anywhere.

Today is about my first day of seriously trying to work on the Netbook and things aren't really as bad as I had expected them to be. For starters, I am getting used to working long hours on the smaller screen and the headaches are starting to disappear rather rapidly. In fact, I am no longer experiencing those headaches and bouts of irritation anymore.

The keyboard layout on this thing is slightly weird, but then I am getting used to it rather fast as well.

I have a Window 7 Ultimate loaded on this thing, along with a couple of image editing software, windows live writer, Microsoft office and a text to speech converter so that I can proof read my blog posts.

This would be my second post from the Mini 9 and as strange as it might seem, I am becoming one with this tiny weapon that lay unused at my home for months.

On the work side, I tried remoting into a office machine and tried writing some code on the remote box. It was not as bad as I had expected either. It's definitely not the only machine you would like to have, but then, it is a very different kind of a weapon for a very different kind of an attack that every software programmer must learn.

One major gripe I have with this machine, specially while programming is the position of the double-quote and a couple of other keys on the keyboard. Having said that, a little bit of practice and I think I might be able to get over these annoyances.

The funny thing about these devices, specially if you can tune yourself to become one with them and use them productively is that you can exploit the heck out of them. For once, you could be writing code on a remote box located at a data center in California as you drive through the plush green pastures of India on a  weekend vacation.

No fear of denting an expensive laptop. No worries of wearing off the battery because of excessive use. Toss it in your bag, carry it everywhere with you, exploit the heck out of it and get work done like never before, from anywhere, anytime.

Go learn the art of mastering tiny weapons, tune yourself to them and become much more productive.

I wish you good luck.

On a side note, for a detailed technical review of Dell Mini 9, see Scott Hanselman's post on the review of the device. I consider Scott to be a rather worthy maven of the software development world and his post on Dell Mini 9, to an extent, nudged me to try out my Dell Mini 9 again rather than letting it gather dust. I am happy it did.

I will continue to post updates if my opinion on Netbooks changes again but for now, I am loving the idea of being able to carry these devices anywhere and doing some serious damage using them. What is your experience with Netbooks?

Discuss.