Software Disaster Virgins.

When it comes to programming, they say that you are a virgin till the time you have seen at least one nasty COLLOSAL F@#CKUP.  I'm not talking about "Oh we are really sorry about the 15 minute downtime last evening" kind of a f@#ckup here. I am talking about the f@#ckups which have the potential of costing you your jobs, your project and at times even winding up your organization.

A DISASTER! That's what I'm talking about. That's what this series of posts is about.

Now, the thing with these software disasters is that they are not exactly out there looking for you. Most developers are going to see just one or two of these in their entire lifespan and if you are a consultant let's face it, you are going to sense this disaster coming, upload your resume on a job portal, send out a few mail blasts, run to find a new job and as soon as you do, never look back.

Let's face it, most programmers haven't seen even one of these f@#ckups in their entire life. Which is why when they bump into one, they are so utterly confused and lost that they either blank out or do something stupid like try and blame it all on the other programmer who also happens to be one of their best buddies. Most managers it seems have also not seen these f@#ckups either and my theory on why they have not seen these disasters is because their resumes are usually the first to hit the job portals when things begin to heat up. Talk about leadership... managers are notoriously famous for leading from the front when it comes to scrambling away like rats when things start going wrong.

For all those of you little boys and girls out there who have not yet lost their developer virginity, I thought I'd give you a list of things to not do, a list of things to do and most importantly a quick guide to the various mindsets that you will need to decipher and deal with if you find yourself in the middle of a software disaster. Now, if you are one of those who go running to a job portal or a placement consultant at the first sign of trouble (I interview about a dozen of these every couple of months) this article is not for you. For you, we have job portals like this one.

However, if you are someone who understands that surviving it makes you a better developer, a better manager, a much nicer person, creates long term memories and fundamentally changes the way you see your team, your work and your work life, sit back, relax and read on. There is going to be way too much information so make sure you are awake and are drawing your own conclusions because all I have for you today is just some random thoughts and you are going to have to do the hard work of gathering them in a coherent stream and making sense out of these thoughts yourself.

So, things you should know, things you should do and things you should not do during a software disaster. Before we get to that bit however, its important you understand a typical software disaster really well, primarily because when you understand what you are dealing with, you automatically tend to get better at dealing with it. Lets talk about the disaster itself and how it typically shows up. Ready? Let's begin!

Discectomy Of A Software Disaster.

It typically shows up as a simple support phone call. Usually during the evening. You are sipping your coffee, playing low music and in the flow when the phone rings. You don't want to get it. You ignore it. A couple of minutes later a simple support email drops in your inbox. Some user is not being able to login to your application. "He's probably forgotten his password or something", you tell yourself. You are about to brush it aside, when you blink. Something tells you there is something wrong. You decide to take a look. You try to login with a test user. No luck. Maybe it's just bad configuration which has locked everyone out. The problem, has your attention now. You take a look. Everything on the configuration seems fine. You hit the database server. A quick select from the User table on your production database. Then you sit there for a few minutes, wondering what just happened there, watching the screen with zero rows and a blank user table.

F@#CK! - is all you can say or think of.

It takes you about 15 seconds to realize what just happened here. The data is gone. Zip! Just like that. No users in the user table. A tiny little parallel thread spawns up in your head. You are using that thread to think about your argument with your business analyst where you were telling him that administrators should not be allowed to delete a user if the data for the users exist, but he insisted on deleting all data of a user when a user is deleted. You are wonder, maybe (just maybe) you argument would have prevented this. Another parallel thread. This one is thinking about the day when your DBA added that Cascade Delete option after telling your Business Analyst that he wasn't happy doing it and that he was strictly recommending that it not be done. But it was done and everyone had celebrated the release of a new version with all requirements met.

The Backup! The primary thread in your brain shouts out loud. Your daily automated incremental backups and the log backups you run every two hours. The sheer effort the team had put into the backup strategy is going to pay off now.

You snap out of your panic mode, try to shut down all other parallel threads in your brain and focus but you can't. You are calculating the damage. Even with the backup you are going to loose a couple of hours of data. You are going to say sorry to your user, maybe send an email. It's going to be fine. Thoughts like this one racing through your head as you log into the database backup server. A fifteen minute restore operation is going to set everything back to normal, if only you can find the incremental backup for today... you scroll through the files... to find the latest incremental backup... which is... about a couple of MONTHS OLD!

Turns out your automated backup process ran out of disk space a couple of months ago. It would have sent you an email notification when that happened but the IT guys changed the IP address of the email server without bothering to tell anyone and the DBA didn't change the SMTP configuration in the automated backup job, so the email code had been sitting there quietly, logging stuff on your Event Manager when  you were expecting an email if the backup didn't happen.

F@#ck - is all you want to say now, but you lack the words or the processing power in your brain to say that out loud. The primary thread in your brain is fumbling for alternative options of recovery. Its trying to think of an answer... frantically.

The parallel threads in your brain are all busy doing damage calculations now.  What you do not know is that this is just the beginning of it. From this point on Murphy's Law is going to kick in. Colloquially speaking, from this point on everything that can go wrong... will.

The phone rings again. You glance at your phone's display. It's your manager calling. You realize that he had called a few minutes ago when you blissfully ignored his call because you were in the flow. He is probably getting countless calls from your users by now. You want to focus on fixing the problem. You do not want to pick up the phone. But you know you have to... and you do.

The Disaster that can change you forever has begun.

I have witnessed a few of these in my life and have at-least been a part of more than one of these myself. During my consulting days I have also played the firefighter who people hired to clean up their shit when these disasters occurred. If there is one thing I have learned by observing all of these disasters, it is that all of them (Every single one of them) have one thing in common: They are like airplane crashes.

Airplane disasters, the ones which cost lives and millions of dollars, are typically not just a result of pilot's error. If you have spent any time reading up airplane disasters what you will learn is that most of them are caused by a series of small events. Some company somewhere manufacturing spares decides to work on the brink of the lowest quality allowed by safety standards, some purchase officer who wants to maximize profit orders these parts, some maintenance officer doesn't inspect the parts seriously enough between flights, one of the latches gives, the pilot panics, someone uses mitigated speech while communicating with the control tower... the list of things that go wrong in any given incident is almost endless. At any given point there are at-least eight or nine things which are wrong, none of which single handedly would have been capable of causing a disaster but collectively they do. That right there is how airplane disasters work... Software disasters (if you have been reading my description of the software disaster above) are no different.

A manager thinks that he can push the programmers, programmers think they can work on the brink of quality and get away with it, QA thinks it's OK to work under the assumption that the programmer must have done some basic sanity testing. Your backups fail, configurations change... add a few more tiny mishaps into the picture and one small broken window turns into a torn down warehouse or a bashed up car over time, slowly and steadily. By the time you find out, the disaster has already happened. A young college kid, just for the kick of it, just snaked up on you, did a quick SQL injection attack and wiped out all your users. You are now heading towards the ground on your first spiral dive and you have no clue about how bad things can get from here.

While airplane disasters can be attributed to a series of small things going wrong in precise order and time, and it is almost never caused by any mistake from a single individual, a pilot's way of reacting to the disaster means the difference between crashing or recovering. Inexperienced pilots either choke or panic. The ones who have seen a spiral dive before, do not choke or panic, tend to survive.

Do you think you can survive a disaster of this sort? Do you think your organization can? Do you think your team can? The answer really depends on how closely you know these disasters, what to do in them, what not to do in them and above all, how well  you understand how these disasters work and how people react when they are in these disasters, which brings us to our first item on the checklist. Stuff you should do when you find yourself in the middle of the disaster... a perfect topic for the next post.

Stay tuned.

Here is a classic (and rather stupid) Project Management question that you are bound to stumble upon if you are interviewing for the role of a project manager. The question: You have a very important deliverable on Monday. You suddenly realize on Friday that a huge task is still not done. You have a developer who is supposed to complete that task. However he seems to be having some family problems. What will you do? Will you make him stay late or come on weekends and finish the task or will you ask the management to delay the deadline?

An acquaintance who was recently asked this question snickers funnily as he describes how he "smartly" reacted to the question, told the interviewer that he will ask the developer to stay late and have him finish the problem. The interviewer as it turns out was VERY pleased with the answer and this acquaintance was offered a job after the interview ended. "I just reacted smartly, gave an shrewd response and made the idiot happy", the acquaintance of mine laughs as he tells his story of getting selected in this organization.

I could do a long rant on why this question is a hugely stupid question to ask in an interview. The question assumes that you can either be nice or productive. It assumes that there are no other developers who can pitch in and contribute. It assumes that you cannot code yourself and pitch in. It assumes a whole lot of other things. Like I said, it is a stupid question and I could do an entire post on criticizing it but instead, I thought I'd rather do the jerk conducting the interview a favor and talk about something that he was doing right during the interview.

Surprised? No Seriously! The Jerk was ACTUALLY doing something right! Honest! Want to know what it was? Grab a bag of pop corn and read on.

Interviews are complicated. They are also a completely outdated, funny and ineffective way of finding out if someone is productive or effective. Of course you can ask the person how delegates and lambda expressions work in C# and ask him to show you a real example of why you would need a delegate. That tells you if he knows his shit. It tells you that he is smart. But then most kickass companies need two things in the developers they are hiring. The developer being smart is just one of those two things. His being smart does not mean a thing till the developer Gets things done.

Smart and Get things done - Joel Spolsky wrote a book on it. Marissa Mayer, also believes it. Even Steve Yegge also believes it in his own different Kinda-Sorta-way.  

Most attempts to find both of these aspects in three two hour interviews are futile, funny and down right stupid. You can't do it. All you can do is do some basic sanity checks on your candidate, filter out the hundred other stupid candidates that fail the sanity test and hope that the one you hire works out because he knows how delegates work in c# and is able to show some signs of basic ethics and goodness during the interview. But you have no idea of his effectiveness what so ever. Stop fooling yourself!

Now, for a second, lets assume, that you were to magically find a perfect interview process which lets you measure how effective the person is can be at his work. So now you rejoice about your new found interview process, go to a bar, get drunk, eat chocolates, call your family (or do whatever it is that you do to celebrate success) and get ready to reap the rewards of this process the next day. You now have a well defined process to find out candidates who are smart and who are capable of getting things done. You are now going to have a 100% success rate at hiring amazing guys in your organization!

And then you hire your first candidate using this newly found process. And he is really smart. And he can pull new algorithms out of his ass and throw them at you every five minutes. And he is really effective. And he can get an entire million dollar project done in like a... month. And all he wants is average compensation. You celebrate! The process works!

But then on the very first week of his work you see that this new hire of yours is not effective at all. Actually, he is smart. Really Smart. He can also be really effective. But he is just not feeling it. You know, you are into building really simple, clean interfaces and simple applications that people love and this guy loves building complex enterprise applications with a zillion options and features. He thinks you are a stupid little software development shop that is not doing any serious work. You are just an insignificant 37Signals who doesn't even exist in front of an IBM which is what he wants to build software for or do a job at.

Your so-called full proof interviewing mechanism failed because it did not consider a hugely important thing most interviewers fail to consider while interviewing folks. Time to bring in the third thing into the equation.

Beliefs.

Now, let's go back to where we started off with. This is where the Jerk interviewing my acquaintance was doing something right. By asking the famous project management interview question "will you make your team member work late when he is having some serious family issues or will you ask us to delay the deadline", this Jerk was making two points: 1. That he believed in being a Jerk. 2. That he was only looking to hire others who believed in being a jerk.

Nah! I am not talking about cloning yourself here. But if the Jerk knew that his organization was built on prickdom, he probably did not have any use for a nice guy who was willing to pitch in, help, contribute, participate, innovate, ship remarkable stuff... YAAAAWN!  He was looking for a Jerk, to control a bunch of Jerks who had also gone through similar rounds of interviews and were a perfect fit to the culture of his organization.

In being smart and hacking this interview, this acquaintance of mine, violated a basic rule. He basically told the interviewer that he was a Jerk when he was not. But then, I digress. That is not the point here. The point here is that the Jerk was doing something right. He was guarding his beliefs. He was making it very clear that you are only allowed to be a part of the organization if you were a bonafide asshole.

I am not saying that you have to be a Jerk. Neither am I saying that you have to hire Jerks. But you still need to learn the concept of protecting your beliefs just like the Jerk was protecting his beliefs. And that effectively means, that if you believe in the power of small and employees being smart individuals who when left alone do the right thing, then you should NOT be hiring anyone who is into managing your employees with a Gantt Chart.

Heck! Maybe you should be asking the same question (even though It's stupid) and kicking people right off your doorstep if they say they'll make someone who is going through a problematic time in his family, stay back all weekend to fix a stupid bug. I'm just saying.

The fundamental problem here is that most managers do not do that. Most managers even find it difficult to stand for their own believes. "Let's focus on innovation", the Vice President of engineering in your organization shouts and then the next day he adds, "Oh and by the way, can we ship these three features and seventeen reports for the road show next week?"

When this well meaning, good hearted vice president sets out to conduct interviews, how much importance do you think he is going to give to his beliefs? Enough to reject someone who does not TOTALLY believe in what he himself and the organization believes in. "He has a really good education. He comes from a different background, but he seemed smart and he is willing to learn, so I think he should be able to pick up our culture", ever heard that? That's the kind of bullshit you hear the vice presidents saying all the time.

So, protecting your beliefs is really important. But what is more important than that is having your belief's. Apple has a belief. 37Signals has a belief. And so does IBM. Even if these are completely contradicting beliefs. For example, compare what a 37Signals believes in with what an IBM believes in. But both of them protect their beliefs and guard them passionately.

The lousiest organizations are the mediocre organizations that believe in nothing and oscillate from one thought process to another depending on the market trends and what is profitable. The lousiest managers are the ones who have no opinions and are not willing to take sides.

When you are running an organization without a belief, all you are doing is hiring based on technical knowhow and some basic character evaluation. Prepare to land up with some serious conflict of interests within your employees, within teams, within divisions and within every single individual in your organization. And then when you see people bitching around and getting all political, don't complain.

After all, one of your Vice Presidents is busy drooling over 37Signals, the other wants to get your organization CMM certified and the third one doesn't even care to take a stand. He is busy oscillating between both every other week, because he is totally confused about which one gets him more business and which one gets him more productivity. And your employees are watching these Titans fight and wondering what the hell are they doing.

Maybe this sounds like an Exaggeration, but the point is, unless you have a single belief which is larger than life that governs your organization, unless you have a closed Tribe of people where the one mandatory criteria for joining the Tribe is believing in what the rest of the tribe believes in from the bottom of your heart, you are just going to keep going round and round in circles, fighting, bitching and arguing with each other every time you need to take a decision and most of your kick ass developers are going to be utterly confused about your direction, your progress and your end goal.

So the next time you conduct the interview, build a few questions that test the beliefs of the candidates and kick them out if their beliefs do not align with the beliefs you are looking for. If you can't think of any other question, start with the infamous "will you ask your team member to work on weekends when he is having a family issue" question. Instead of giving him only two choices leave the question open ended and see what he would do in that situation. See if the candidate's answer is similar (in belief and approach) to what you might have done in the situation. I know It's a stupid and a common question to evaluate belief, but then but something is better than nothing.

I'm just saying.

One of the things I love with this blog is that I can go back, read my older posts and see how my writing has evolved over time. When I wrote my first post on September of 2006 after working on a fix for DasBlog that would let me run it on a cheap hosting account (with medium trust settings on IIS), I wrote for an audience. Within a couple of months I understood that I was not going to have an audience. It's funny how everyone realizes that after he starts blogging. That's when most of them quit. Others who absolutely love writing, even if they have to write for a very small audience, continue.

Then somewhere, after a couple of months, people started coming to this website in small trickles. That was around the same time where I had gotten used to the idea that I was going to blog for three people, You, My mom (who still reads everything I write) and me myself. Even though my writing was morphing into casual writing, I was sprinkling my posts with an overdose of "Dear Reader" all over my posts. Something for which I was heavily criticized.

The look and feel of the blog and the font was also a reflection of my writing style. The font's of the blog were carefully designed to look beautiful and professional. Verdana is supposed to be one of the most readable fonts out there. It's not esthetically beautiful however. So I decided to go ahead with a 9.5 to 10pt Tahoma (which is nothing but a slightly compressed, skinny and better looking version of Verdana, though not as readable). The idea was that if my blog looks beautiful, you might stick around and read stuff.

The entire blog ran on a DIV based design, because Graphic designers around the world told me that if you cannot do a DIV based design YOU SUCK. Yeah, Right. So I landed up with a DIV based design with strange CSS positioning which made the blog look slightly different on Internet Explorer and Firefox. That is a whole different post there, but the point I am trying to make here is that everything about this blog, was planned to be 'technically correct'.

But what is 'technically correct' Isn't always the most pragmatic thing to do. Of course the blog has to look beautiful. Of course it has to have a single consistent font across the website and of course the design has to be DIV based, but then when a few more people start showing up and someone leaves a comment telling you that he wants to print your stuff on a printer and your DIV based design is chopping stuff off in his printer, 'technically correct' is no longer the right thing to do.

This weekend a couple additional funny things happened which nudged me to go out there and make some changes to the design of this blog. This weekend, I had some time so I started writing. The topic that I picked however, was how most managers love the idea of pushing their team to make them work harder and what they can learn from parenting. Because this topic happens to be near and dear to my heart, it turned out to be one of the longest posts that I have ever written till date on this blog.

When I had prettied it up, proof read it and published it, I started reading it. That's when I realized how everything that was so carefully designed to be 'technically correct', was so utterly wrong. I was starting to feel sorry for anyone who was reading this blog in-spite the 9.5pt Tahoma which was just making it impossible to read anything more than barely midsized post.

I decided to go hunting for fonts. And after a lot of reading, hunting, trying out stuff (and soul searching) I've landed with Georgia as the default font for the post text. Here's why:

1. Georgia is sexy! I love the look of it.
2. Georgia is fun to read. I actually ended up reading the entire blog post on the slap and push technique to management on both internet explorer and Firefox and no it did not cause me a headache.
3. Georgia is preinstalled in both Windows and Mac machines. Which is where most of my traffic is based out of. If you are running Linux and do not have Georgia preinstalled, I highly recommend you get your version of Georgia from here.

Besides Georgia as a font does not break or look hideous when I blow it up to a size of 12pt to make my posts easy on the eyes of the readers who are actually going to read it. In fact it looks just as beautiful at a 12pt size which is what you are reading at right now. Oh and yes, did I tell you the italics on Georgia look beautiful and get the point across. Not like the italics of Tahoma which... suck.

Just in case you were wondering about how the end result is different, here is the before and after images on a paragraph on the older blog post for you to compare side by side. It's a scaled down, low resolution image but even with these images you should be able to make out the difference between overall readability.

The old font:

The new font:

I don't know about you, but I would pick the new design any day.

With the text of the posts changed to Gerogia, it was time to think about the left navigation. I picked Verdana there, primarily because I wanted you to focus on the content text than on the left navigation. If you need to look for a link however, Verdana, being one of the most readable fonts out there helps you spot stuff easily.

The idea was to tune the blog for the small audience that is logging in everyday and reading stuff and not for the casual lurker who lands on the site through Google and decides if he is going to stick around depending on how the site looks.

With the font and the font size settled, I set out in search of a good "line-height" that I should be using to be easy on the serious readers eyes. Looks like most BlogSpot out of the box themes are pretty generous about the line height. I settled somewhere in the sweet spot between 170% and 190%. What this means is that you are probably seeing enough vertical space between two lines so that you do not have to strain them or move your face closer to the monitor to read stuff even in really high resolutions.

I have been reading some of posts after these design changes and I feel that some one these changes are actually nicer to my eyes. Oh and while I was at it, I moved back from a DIV based design to a table based design. It's much easier to control and It seems to be giving me a consistent look across browsers. Besides a table based design makes it really easy for me to spread out my design in percentages and utilize maximum real estate on the page. I know its not the best approach to designing a website but it is way better than having to maintain different CSS files for each browser. After all, the technically correct answer is not always the right answer.

Put simply, I've broken every single thing on this blog that was supposed to make it look good and what we have here is a blog that is much nicer to your eyes. Given the choice between looks and readability, I would pick readability any day. If there is a way to have them both, I would love to. If you have a few tips or suggestions on how the design can be improved, drop me an email or use the comments section below.

Oh... and... sorry for hurting your eyes all these years and thanks for continuing to read. #Grins.

The post is slightly long winded. You might want to grab a pop corn, sit back and relax as you read through this one. We are going to talk about about a horribly wrong management approach that a LOT of managers out there seem to be using even today despite of it's obvious disadvantages.

I could just tell you what the management approach is but I thought I'd take you all the way to India and introduce you to how Indian parenting worked when we were young, how we grew up and what civilized, educated parents in India are starting to learn about the human mind that the MBA graduates with their fancy courses in Resource Management just do not understand.

Ready? Let's start.

Unlike a few other countries out there, in India slapping your kids is perfectly acceptable and allowed under the law. This means that Indian parents are set loose and are free to slap their kids to discipline them every time their kids are found creating a ruckus. With upbringing of the kids mostly considered a social responsibility of the family where the government or law enforcement has very little involvement you would think that most Indian kids get slapped all the time.

The reality of it however, is very different. More and more civilized, educated parents of the Indian middle class family are starting to realize that even though you are "technically" allowed to, slapping you kid more even a couple of times in his enter lifetime is a stupid thing to do. All you do with beating is create rowdy goons and hoodlums.

This was not always the case however.

When we were young, casually slapping your kid to quite him down was considered pretty normal. Our neighbors for instance (who for the purposes of this post, we will refer to as 'The Fredsons') had no problem in slapping their kid once in a while when the kid was acting like a brat. Little Fredson played with us and as youngsters it was not an uncommon site for us to see Mr. Fredson come out and give his son a mild slap every time we hit someone's glass window with a ball and shattered it into pieces while playing. The game of Cricket would end instantly, Little Fredson would be slapped smack on his cheeks, though not very hard. He would cry for a few minutes, our parents would call us to our homes and that would be the end of the game (for that day).

Even in those times my parents took a slightly different approach of "talking" with me and my brother when we made stupid demands or acted rowdy. Instead of traditional slapping we received perfectly rational explanations on why we were not supposed to be doing whatever it is that we were doing. It would be a perfectly legitimate grown up discussion. Explanations were provided. Logic was used extensively. If we lost the argument, we obeyed, if we won, we had our way. It was that simple. Heck! It was a meritocracy where your ability to present your side of the story and use logic could actually let you get away with stuff that other kids our age did not even dream of getting away with.

Even back then, my parents understood a fundamental rule of parenting that most Indian parents did not understand. Slapping your kid has two aspects to it that stops your kid from doing the same thing again. The psychological aspect of it, which is to say, the kid feels really bad about having disappointed his parents. This aspect is really powerful. If you are a kid who loves his parent, their slapping you tells you beyond doubt that you have let them down. Then there is the physical aspect. Slapping can hurt, one, your body and two, your ego. It is this pain that is supposed to prevent a kid from doing the same thing again.

The problem with slapping your kid however, is that once you have done it a couple of time, the psychological impact of it wears out. Here is why this happens. You see, we (human beings) calibrate ourselves depending on the world around us. As human beings we are not very good at seeing ourselves as pathetic creatures who keep hurting others all the time. Our self esteems are much higher than we think they are. If you were the kid who was getting slapped, the first time you were slapped you would feel really bad psychologically. You just let your parents down.

The next time it happens, it feels just as bad. The third time it happens you begin tuning yourself. If it happens a little more frequently, your perspective starts changing and your mind tells you, "Bullshit! They seem to see a problem with everything I do. You know what? Maybe there is something wrong with them. Maybe they are just being too hard on me". There. The psychological aspect that was supposed to make you feel bad and stop you from doing the same thing again is gone. After all, there is something wrong with them. It's their fault. 

With the psychological aspect of it now gone, the physical aspect of it kicks in. This is the part where Aristotle often held an opinion that fear is synonymous to lack of habit. Scared of going on a battle? He asked. Fight a few battles, get used to the idea of being in a battle field, survive the battles, get habituated to the warfronts and your mind will stop getting all scared and worked up when you find yourself on the battle field. It is the best way to overcome your fear of public speaking if you ask me, but I digress. The point is, this is yet another example of the human brain tuning itself to the situation.

Once the psychological aspect of the beating has been thrown out of the picture, your getting habituated to the physical aspect of beating is just a matter of time and that just means your parents have to now increase the intensity of the beating to keep you from creating a ruckus again. Slaps have to get tighter. Grounding durations have to increase. And if your parents are to do that, chances are that you are going to tune yourself to the new intensity pretty soon. Your mind is going to get habituated to it. It's a vicious cycle capable of tarring relationships and creating goons or hoodlums out of perfectly smart kids.

With me so far? Good! Now let's get to the point.

Remember Little Fredson? Or the other kids who did get beaten up all the time. Let's replace them with your development team, the parents with the classical managers and the slapping with the classical "push" that the mangers apply on their team to make them work hard. You know, the classic, calling them in a meeting, putting them on spot or being "strict" with them to make them "work harder"? The push where you are constantly creating artifical deadlines, having three meetings a day and running around with Gantt Charts in your hand. Yeah! That push.

The problem with that push is that, just like beating up the kids to discipline them, there are the exactly two elements (the psychological aspect and the fear aspect) that are at play here. Your engineers (assuming that they are decent human beings and good programmers) want to do the right thing. Once you have applied the "push" on them a couple of times and used the carrot-or-stick to motivate them, you have tarred their psychological desire to do the right thing. Put simply, you have destroyed their intrinsic motivation and have replaced it with extrinsic motivation. You have turned perfectly smart human beings into animals who think with their lizard brain.

With this intrinsic motivation and the psychological element of doing the right thing, out of the picture, the only thing that is going to make them work hard next time is a "harder push". It's a vicious cycle capable of tarring relationships in a team and creating goons and hoodlums out perfectly smart, kickass ethical programmers which is EXACTLY similar to beating up your kids to discipline them.

With me so far? If you are a fresh pass out from one of those business schools you are knitting your eyebrows already. "It's easy for you to say Pops! You probably work in an organization where everyone around you tries to be reasonable with each other. We have to make our programmers ship. What do you suggest we do? Pamper them?", you ask.

Well, do exactly what my parents did while bringing us up. The approach was somewhat unconventional at that time but it worked. Actually, it did not just work, it did magic in our relationship and even today I feel just as comfortable in sharing most of my problems both in my personal and professional life with my parents. When they started these conversations, they moved from being parents to being peers. They became friends. And I didn't exactly drop out of school, become a goon or a thug. So I am going to assume that the approach they used worked and try to tweak it for you so that you can use it in your workplace. Ready? There are two simple steps involved here:

Step One: Listen

Ok, back to the basics. Step one is listening. Most managers (me included) don't know how to do this. That does not mean you stop trying. When someone approaches you with a problem, there is a devil in your mind saying, "I don't care about this microscopic shit he is talking about. All I care about is the ship date. It's just a effing database configuration! Surely they can figure out how to speed up the application, If I can just push them to...".

BAD MANAGER!!!

You developer is telling you something. Like I said, LISTEN.

Yeah, I know that devil is speaking in your head right now as you try to think of arguments and how this does not apply to your team and how your programmers are lazy scumbags who want to take you for a ride and you are thinking about those examples where Jack just took a leave three weeks before the ship day... and... and... and... he did not even pick up the phone when you called... you are thinking about your arguments. You are NOT listening to what I am telling you. You are NOT listening! And that means you probably do NOT listen to your developers when they come to you expecting help. See what I mean?

Stop Talking. Now! Start Listening.

Step Two: Talk With Empathy And Trust.

Empathy. Steve Yegge thinks that this the only thing you need to be a good manager. I think Steve Yegge is not just an awesome writer but he is also one hundred percent right. Your developers will bend over their back to rescue you out of a situation if you are open, candid, honest to them and are asking for help as a friend or a candid colleague.

"We are trying to expand the organization and get a bigger office by the end of this year, which is why we need new clients to sign up. Three of them have asked for a feature. I know you said it was going to take three months and I am going to try my level best to talk to them and see if we can make them wait for three months but if they do not budge and insist on getting it faster what do you think is a good estimate to give him? Also what are the features that you think we need to drop if we are to do it in a couple of months?"

See? That wasn't hard. The key here is, saying it with empathy. Add a little bit of genuine trust in your developer's judgment when he gives you a list of ALL those other features that you will have to drop. Don't argue with him telling how all those features are also important. Congratulations! You now have a programmer who is going to give you the best possible timeline without putting your project in danger, without going into hibernation, without writing F@#CK YOU Code and without shipping crap.

Do you really trust him? Are you just taking him for a ride? Is this a genuine urgency? Have you genuinely tried you level best to make sure that the urgency did not happen before you asked for help? Are you going to try your level best to see to it that this situation does not happen again?

Your developer is looking at you as you talk and these are the questions he is asking. He is going to be looking at everything you say very closely. Here is another advice: Don't try to fake empathy. Its like this: You'll get caught. How? Because you interviewed a hundred candidates and hired that smartest F@#cking candidate that you could find. You can't just expect him to isolate his intelligence to that time of the day when he is coding and leave it outside your office door when he enters your office. That's why, silly!

The Point

If you were lost in the digressions of the post and made no sense out of it what so ever, I feel your pain so I am going to make it simple for you and sum it all up. Striking similarities exist between good parenting and good management. If you want to learn good management, go watch a couple that has raised kids who respect them, love them, consider them to be friends and have not turned into goons, thugs or hoodlums. You will find ingredients of decently good management are all there.

Oh and every time you try to "push" your developers to work harder, might I remind you, that all you are doing is slapping your kid. I don't care how mild the slap is, you are adapting to a life style where your slaps are going to have to become tighter, your relationship with your team is eventually going to get tarred and you are going to turn perfectly responsible, ethical, smart working programmers into goons, thugs and lying scumbags who just do not give a damn. I'm just saying.

I wish I could give you a perfect recipe for teaching you how you can hire the best programmers out there or a perfect recipe for how you can stop being paranoid or how you can learn to trust human beings in general and your team in particular, but I can't. Teaching anyone how to trust someone else is hard. I suggest you start by unlearning everything about managing resources that you learnt in your stupid MBA course, throwing out your Gantt Charts, giving up the idea that you can control anything (leave aside the idea of controlling other human beings) and like I said, start practicing how to listen.

Yeah, that might get you started on the right track, but then it's a long way ahead and you are going to have to walk a few miles everyday. Oh and the journey does not have a exact well defined destination so if you are one of those managers hoping to find the end somewhere in the next three months and land with a team that has complete trust in you, super human output and unthinkable productivity, don't even bother to start. You are just going to wear yourself out.

On the other hand, if you see this as a life long journey and are willing to walk on this path of listening, caring about and trusting your team, for the rest of your life, you might go a long way, get a lot done and earn a few friends along the way. As always, all I can do is wish you good luck.

There is a restaurant in my neighborhood that has been around since 1922. They serve the most delicious Indian food you could possibly get. When I want to pick up some food to-go that is my default destination.

When I am with my office colleagues or people who I do not know really well however, I might choose a different place with a brighter ambiance.

The restaurant owners don't worry as much about opening an Italian restaurant in the same block where there is another Italian restaurant because they know that there are so many things that sets each restaurant apart from the other one.

The dishes you serve. The chefs you hire. The ambiance you create. Your menu. Your price. Your secret ingredients.

Even the kind of people who eat (or hang out) at your restaurant can be a deciding factor into who else eats there.

Every single factor complements every other one to decide who walks into your restaurant on a Sunday evening.

And invariably, each restaurant that stays around finds it's own niche and enough customers to keep going, within the couple of years of it's inception.

Software programmers, it seems, are different than restaurant owners.

We obsess about if our idea has already been built. And if we stumble upon someone who is doing something even remotely close to our idea we quit building stuff. We bitch and moan about all ideas having been taken. "Anything worth building has been already built", you say. "I had a great idea once, but there were already two huge companies out there doing exactly what I had thought of".

That's like saying that there is already an Italian restaurant round the corner and that means there is no room for my restaurant, even if I can serve the most delicious, thin crust crispy pizzas and build an ambiance where young college students will love spending evenings. So what if the other Italian restaurant does deep dish pizzas and caters to families.

When you think of building something, the only essential question you need to ask yourself is not if someone else is already working on the problem. The only essential question you need to ask yourself is, can you see the problem from a completely different perspective.

Can you add a little bit of you, to your solution?

The user interface, the feel, the number of clicks, the features (and even the non features), the people who hang out on your website, the niche, people who build your website, how your website feels. Just like the restaurant business, there are way too many factors that complement way too many other factors, which will decide who logs on to your site on a Friday evening. Can you tweak just one or two factors really hard to make your website stand out.

If you can, you should think of serving us your delicious crispy fresh software or service.

You don't need everyone. Just a few of us will keep your site (and your organization) going.

Go on. Start something, even if someone else is already doing it.

If you do it well, if you do it differently and if you keep doing it with consistency, we will come and we will keep coming.

I wish you good luck.

Building CRUD screens is a task.

Shaping a brand new idea into existence is a challenge.

Forwarding emails is a task. Mentoring a team that is capable of flocking and liking each other ... a challenge.

Checking the status of your project with your team is a task. Inspiring your team to move things and to avoid mitigated speech is a challenge.

Writing Module Specifications is a task. Making requirements interesting enough to get people to give a shit about them is a challenge.

Attending meetings is a task. Applying an innovative solution to fix the problem you were going to discuss in the meeting is a challenge.

Your organization, almost invariably, will give you tasks. That is what organizations do. Organizations do that because that is what they are really good at doing.

Your only (of course, I mean "only") hope for survival is taking on challenges not tasks.

If you are stuck with nothing bust tasks learning the art of morphing those tasks into challenges is a crucial ingredient for your survival.

The tasks you do will define your job role and your paycheck.

The challenges you undertake will define you.

How much of your day job is made up of tasks? How much of it is challenges? How much of it is tasks with hidden challenges vs. how much of it is tasks you can outsource to the cogs in the Indian body shops? There is a task on your task list right now. There is probably a hidden challenge in it right if you look under the hood.

The real question is, can you see it... are you man enough to pounce on it.... or are you just going to focus on getting the task completed so that you can move on the next task?

Just a little something to think about.

The moment you have an idea for an application, if you're like most people, you get really excited about what the product will be called. As you fancy a world where the product exists and people love it, you tell yourself, "Hmm, I wonder what a good name for the product will be".

Now, for those of us who have tried to name anything, from a baby to a website, we know that naming is hard.

"I wonder if this one is taken", you think of a name and before you know it you are spending your mental cycles in thinking a happening name and giving in one futile attempt after another only to find that all those names that you can think of are taken.

Then you get lucky and get a domain name, but then the twitter account for that name is taken.

"Those pathetic twitter squatters! I mean he is not using this account. I wonder if I can email him and ask him if he would be willing to sell the account to me.", you tell yourself.

See where you are going with this? Again, if (and I am just saying if) you are like most people, you are going to run thought loops in your brain, think of dozens of hot happening name for your product and wear yourself out before you even write a single line of code.

Naming a product you do not have is just about one of the stupidest things you can do. Ok, wait, actually there is one thing even more stupider than that. You know what that is? Naming a company that you do not have.

No, Seriously. How difficult is it to stick a logo with a sexy name on your template file once your product is built? How difficult is it to register a company after you have your first customer willing to pay you for your work?

If you spend days thinking about the name of the product, before you even write a single line of code you are a dreamer.

Wake up kid.

Write the damn product first. The pleasure of naming a product is supposed to be a reward for nearing the shipping of your product and you, are nowhere close to shipping your product yet. So snap out of it, open that IDE and start working. Let's see if you can build something which is even worthy of being named.

Oh and by the way, now that you have the IDE open, I wish you good luck.

When you hired Fred he was one of the few fairly productive employees you could lay your hands on.

There were a few minor glitches during the interview but then he seemed technically competent.

His demands were simple and very legitimate:

1. Some autonomy and ownership over his own work.
2. Good work with the latest technologies and frameworks out there.
3. A pay package that does not insult his capabilities.

A couple of years in the organization and you can see clearly that the cost of keeping Fred happy and satisfied is increasing steadily. Fred now just wants to work with the European clients because he has never visited Europe and is expecting a nice little business trip there. All of a sudden he cares little about the technology this European client is using or the autonomy that he has in his work. His primary focus is a big extravagant business trip to Europe.

You Cringe.

Fred in the last couple of years has morphed from someone who was highly innovative and driven by intrinsic motivation into someone who is high maintenance, low productivity and highly calculative about extrinsic factors. 

Once the barrier for being low maintenance is broken, it is a slippery slope down the hill. Fred suddenly feels that he is underpaid and overworked. Autonomy and quality of work mean nothing for him. Oh and by the way,  Fred also expects a promotion in this year's appraisal, even though he did not do a lot of 'real work' this year.

He is a borderline case of venting his frustrations on the employees and the organization.

Like it or not, when these symptoms show up, chances are, that you are going to lose Fred.

And then one fine morning Fred knocks on your cubical to talk about his resignation.

Your instant impulse? To offer him a raise. Match the offer that he is getting in his new organization.

After all he was once a productive member of your team.

My advice: Don't even think about it.

You lost Fred, the day his productivity curve started going down. In fact, you lost Fred, the day he stopped working for intrinsic motivation and starting whining like a baby for that European trip.

You can either take my word for it or you can try and match Fred's salary. If you went the later route, chances are that within six months to a year, you are going to see Fred knocking at your cubical, wanting to talk about his resignation again, this time with a higher offer letter.

Instead of trying to get Fred to stay, you are much better off letting him move on and letting someone else in his team take up his responsibilities, even if Fred is your alpha geek.

As scary as it seems sometimes new faces and thoughts are good for your organization. Stop your negations with Fred, let someone else in the team take up his responsibility and  let life get back to normal. Or you can go hire but if you choose to do that, do it like your professional life depends on it.

Either way, I wish you good luck.

Oh and if you are sitting there negotiating with Fred you are just wasting your time and energy.