If creative endeavors involve so many unknowns and problems why doesn't everyone seek refuge in the known and the safe?

Why make your weekends miserable by working on a side project?

Why spend a huge part of your organization's revenue on research?

Why leave the comfort of a safe job and work for a startup?

Why contribute towards an open source project?

Why spend hours every weekend putting down your thoughts into concrete words and then publishing them out? 

The answer really boils down to two things. One is because of the way all creative brains are wired. You cannot help but get attached to these creative endeavors. If you are basically creative at heart, tasks seem boring and challenges are fun.

The other, which I believe is a bigger reason, is that creative people, are constantly looking to surprise you and then be, right!

You cannot write a book on how the brain works and make it interesting enough for masses to like it?

Economics cannot be interesting?

No one is going to pay fifty bucks a month for a project management tool which is nothing more than a simple task list or pay you for a system which lets them manage their contacts?

"Ok, now watch us!", The creative minds want to say.

If creative minds break rules it is because there is a naughty neuron in their brain which sees how lame the rules are. That neuron wants to bend the rules, twist them, break them, shatter them into pieces and then have you accept that it was right.

Acceptance is the gift you are giving the creative person when when you buy a book, when you pay fifty bucks for a darn good task list, when you tweet a URL to a blog post or a product on twitter, when you comment on a blog post, when you blog about a product or when you share the idea of a creative mind and help it spread.

This week, start by being an artist who gives the gift of his work to an audience and by being an audience who gives acceptance back to the artists it likes. And yes, I said an artist and an audience not an artist or an audience. Because you cannot be really good at one without being good at the other.

As always, I wish you good luck.

Creativity, quite literally probably means the art of  building things, or services or thoughts that have not been thought of before. When you are trying to be creative, you are in unchartered territories because, umm, well, the territory hasn't been chartered before. This means that you have no clue about what works and what does not. You are what doing what Nassim Nicholas Taleb describes in his book as, looking for the black swan.

The problem with being in this unchartered territory also means that you are going to be spending most of your time being, lost, clueless and failing. A process that can be rather psychologically taxing. If you are in the business that involves constant long term creativity, social gatherings around friends and acquaintances or discussions around what you do, or how successful you are, given the mainstream definition of success, can be rather painful.

Nassim Nicholas Taleb describes this Artist's Dilemma in his book the Black Sawn rather articulately. He explains:

Every morning you leave your cramped apartment in Manhattan's East Village to go to your laboratory at the Rockefeller University in the East Sixties. You return in the late evening, and people in your social network ask you if you had a good day, just to be polite. At the laboratory, people are more tactful. Of course you did not have a good day; you found nothing. You are not a watch repairman. Your finding nothing is very valuable, since it is part of the process of discovery—hey, you know where not to look. Other researchers, knowing your results, would avoid trying your special experiment, provided a journal is thoughtful enough to consider your "found nothing" as information and publish it.

Meanwhile your brother-in-law is a salesman for a Wall Street firm, and keeps getting large commissions—large and steady commissions. "He is doing very well," you hear, particularly from your father-in-law, with a small pensive nanosecond of silence after the utterance—which makes you realize that he just made a comparison. It was involuntary, but he made one.

Holidays can be terrible. You run into your brother-in-law at family reunions and, invariably, detect unmistakable signs of frustration on the  part of your wife, who, briefly, fears that she married a loser, before remembering the logic of your profession. But she has to fight her first impulse. Her sister will not stop talking about their renovations, their new wallpaper. Your wife will be a little more silent than usual on the drive home. This sulking will be made slightly worse because the car you are driving is rented, since you cannot afford to garage a car in Manhattan. What should you do? Move to Australia and thereby make family reunions less frequent, or switch brothers-in-laws by marrying someone with a less "successful" brother? Or should you dress like a hippie and become defiant? That may work for an artist, but not so easily for a scientist or a businessman. You are trapped.

He also goes on to explain the risks associated with creativity, the artist's dilemma and the toll constant, small failures take on you. He explains:

Many people labor in life under the impression that they are doing something right, yet they may not show solid results for a long time. They need a capacity for continuously adjourned gratification to survive a steady diet of peer cruelty without becoming demoralized. They look like idiots to their cousins, they look like idiots to their peers, they need courage to continue. No confirmation comes to them, no validation, no fawning students, no Nobel, no Shnobel. "How was your year?" brings them a small but containable spasm of pain deep inside, since almost all of their years will seem wasted to someone looking at their life from the outside.

Then bang, the lumpy event comes that brings the grand vindication. Or it may never come. Believe me, it is tough to deal with the social consequences of the appearance of continuous failure. We are social animals; hell is other people.

Nasim is attending to the same problem Elizabeth Gilbert tried to attack in her TED talk on why do artists go through a lot of torment. Nasim's take on the solution is rather interesting. He calls these creative actives where the results and outcomes are unpredictable and non-linier Back-Swan-Dependent activities or activities that depend on spotting what he calls "the black swan" and advices:

We are local animals, interested in our immediate neighborhood—even if people far away consider us total idiots. Those homo sapiens are abstract and remote and we do not care about them because we do not run into them in elevators or make eye contact with them. Our shallowness can sometimes work for us.

It may be a banality that we need others for many things, but we need  them far more than we realize, particularly for dignity and respect. Indeed, we have very few historical records of people who have achieved anything extraordinary without such peer validation—but we have the freedom to choose our peers.

If we look at the history of ideas, we see schools of thought occasionally forming, producing unusual work unpopular outside the school. You hear about the Stoics, the Academic Skeptics, the Cynics, the Pyrrhonian Skeptics, the Essenes, the Surrealists, the Dadaists,  the anarchists, the hippies, the fundamentalists. A school allows someone with unusual ideas with the remote possibility of a payoff to find company and create a microcosm insulated from others. The members of the group can be ostracized together—which is better than being ostracized alone.

If you engage in a Black Swan-dependent activity, it is better to be part of a group.

A rather innovative form of shielding yourself from moral discouragement which anyone who has tried to do anything unconventional with his life, or a part of his life, picks up rather instinctively.

Now you know, why, if you are one of my far off acquaintances who bumps into me and announces to me in all his glory, how successful you have been with your life and ask me what it is that I do, I might hold a straight face and tell you, "Who me? I'm just studying law. I never quite got to doing anything yet".  It's not personal. It's not meant to be an insult to you or my attempt at hiding specifics of my profession from you. It's a small joke. A prank. A way of shielding myself from your way of evaluating success and happiness.

This is also the primary reasons why I also ask companies to hire people not just by talent or capability, but by matching overall thoughts and beliefs. If you are an organization who believes in looking for black swans or doing any activity which is remotely black swan dependent, hiring people who form a like minded group and nudge each other to continue even when you are encountering constant short term failure and frustrations each day is hugely important.

That is your only chance at spending the ten thousand hours on something and crossing the dip without breaking down both emotionally and psychologically. Go on, build or join a community other black swan spotters and surround yourself with them. That way, you can focus on your work without being taxed for it, emotionally and psychologically.

I wish you good luck.

A few friends and I have been working on a little free service which will allow a few like minded people to connect on a completely different level. I'm not going to talk about the service yet. Not because it's a secret. Actually, it's not. My idea is probably out there. Besides, Ideas are a dime a dozen and you should continue building your product even if your idea is taken. I am not going to talk about the service yet because we have no plans of making it public till March. We expect to be in private Beta by end of January.

What I want to do however, is share a few life lessons that I picked up while working on this product and that is what this series of posts is all about.

General User Applications And Services: A Completely Different Form Of Workout.

The folks at 37Signals have wise advice for young startups and individuals on their way to building their first product. The advice: Build a product that is Half, Not Half Assed.

With this in mind, once you start looking at every single enterprise project that you have worked on in the past, you realize that most of them have been half assed in one way or the other. No, seriously.  I have gone so far as saying that most consulting companies use "enterprise software" as an excuse for being lame and boring. Others just bitch about Enterprise Applications.

What's your top most priority when you are working on your project?

Sticking to the specifications? Getting to a feature complete state by the deadline? Completing a successful UAT? None of these needs will push you or your business to spend countless hours so that you can reduce the number of post backs on your page and provide your end user with an enjoyable experience. None of these needs are going to nudge you or your business to build a simple sexy likable lovable user interface. Every single feature that can make a product kick-ass is going to be move to the "Nice to have" list in some meeting somewhere and eventually never ever get built.

Lets face it, unless you work with hugely passionate clients, your enterprise clients probably pay for features not for how a product "feels". Unless your business is a Google or a 37Signals, your business is probably going to evaluate you on how quickly you delivered stuff which was "good enough" for the client to pay for. If you are a consulting house, the general standard of this "good enough" is going to be even lower and is going to be measured by purely economic factors and matrices.

Once you step out of the world of enterprise and start building for the general audience, you are likely to discover that the demands and expectations from your applications are going to be very different than the kinds of demands or expectations you are used to.  All the Visio you know it utterly useless in this world. Your ability to think in terms of use-cases and actors can give your product a quick premature setback. Even some of your design patterns will dig you a big fat hole on a cheap hosting account. You might discover that the world is suddenly judging your work on the strangest of factors that you did not even think were important.

And even though this world of general user applications and services is hugely different, brutal and unforgiving,, I would encourage every developer out there to spend at least a couple of hours every weekend, to weave a small remarkable story and release it out there. Because, that is your only way to find out how messed up your priorities had been all along and how mediocre the world of enterprise development is.

In the fitness world they have a theory. As you continue working out, your body starts getting used to the exercises you do regularly and their impact on your mussels start diminishing over time. Fitness experts around the world will tell you that doing the same exercise every day is stupid. No one ever gets smarter by solving the same math problem every day and no one gets leaner or stronger by doing the same exercise every day. Every now and then your mussels need a sudden shock of a new exercise. That's how they grow stronger. That's how you get out of your fitness plateau.

A few years into enterprise development and if you are a smart developer you are going to realize that you are doing the same exercise every day when it comes to your professional life. You are just building CRUD screens and completing tasks.

You cannot expect clients and businesses to change overnight. But what you can do is shock your mind with a completely brutal and unforgiving world of end user applications and services where people will love you if you get your priorities and work right or give you a cold shoulder of ignorance if you don't.  Either way, you would have shocked your mind and made it stronger, even if you just do it a few hours every week.

What are you doing this weekend? How about starting a small application or service for us and letting us try it out for free when you are done for a few months? Huh? Huh? Huh? Try it! It will not make you an accidental millionaire but it will make you a way better programmer than you already are.

I wish you good luck.

With software disasters, what you say when you are talking is HUGELY important towards deciding if your team will survive the disaster. Remember that phone call from your manager that I advised you to pick up in part 2 of this series of posts? Chances are that as soon as you pickup the phone he would want to know the root cause of the disaster. Put simply, the what happened part of the story.

Things You Should Not Be Talking About.

Before you pick up the phone there is one hugely important thing that I want you to do. I want you to tell yourself that no matter how ugly it gets (and things are going to get a ugly from here) you are not going to act like a Jerk.

Remember the famous "These Fish have manners. These Fish... have manners." speech from Jerry Maguire? What you need to do, is think of yourself as the fish. No seriously! Think of yourself as the fish in the tank. With the disaster in place the resources in the tank are going to be limited. But you cannot be bumping into other fishes or stamping on them. If you hurt them and they bleed its just going to make the water stink for everyone else in the tank. You have manners and bitching and whining in times like these are off limits.

That part is common sense, but it seems most young and budding engineers and MBA's fresh out of college do not seem to understand the part well enough, so I thought I'd put it down as a gentle reminder. Now, having said that the No Whining rule is pretty much common sense in disaster scenarios there is another kind of discussion that you need to be specially careful about avoiding.

"Oh I told the Business Analyst we shouldn't allow Cascade Delete! That right there could have prevented the delete from happening because every single user in the system had profile data associated with themselves."

Yeah! You were right all along. So why not blame the dolt who was not. There is nothing more your lizard brain wants to do right now, but again, that is not manners.

The moment you say the lines above, you are as good as crashed. Done. Finish. Game Over. You might as well shout at the client and tell him to FU@#CK  OFF. That way when this client is gone you can go looking for another client and hopefully work together using the same team to build a better project, but once you start the blame game it's over. Not just for this project, but for every single project that you are going to work on together as a team. You have lost the essential trust that forms the magic sauce of functional teams.

You have announced that either you team is not cover fire worthy or you are not going to provide any cover fire. In-fact you are going to turn around and fire at them when your ass is on the line.

So while it is perfectly fine, be a part of a few meetings and discussions which resolve around the disaster, but make sure that every single discussion revolves around what caused issue and how to fix things. The Who caused the issue discussions are completely off-limits, specially in difficult situations. They are a perfect recipe for unrecoverable and hugely political spiral nose dives.

And if you are a manager, who genuinely, truly and honestly wants the project to recover from a disaster there are things that you can do to help people steer clear from these discussion, which brings us to the topic for the next post.

Read On.

If you have not read the first part of the post, you might want to go through it here to understand the context of this post. Just in case you are too lazy to read it we are going to give you a little bit of a background right in this very post.

You know the disaster I talked about in the first part of this series of posts. Lets assume it has happened. You are staring at the blank database tables which were probably deleted using a SQL injection attack or a developer who was working on production but thought he was working on a development box. You are staring at the blank tables and a one month old backup which you are not even sure will restore. Your manager is calling you. Your phone is ringing. You know you have to pick it up right now. People will start freaking out if you don't.

Now, If you have been a developer for a good part of your life and you still write code, I am assuming that you are going to cringe when you see your manager's name on your phone display on a time like this. "This is NOT the time to be talking"  - the programmer deep down inside who wants to fix things as quickly as possible is going to tell you. There are customers out there not being able to login. You need a plan that will get you out of this mess, Not Another Meeting about what happened and why, Not Right Now! And you are going to think of disconnecting the phone.  Here is an advice: Don't. Want to know why? Read On.

You Need To Say... Something (And Say It With Confidence).

The basic management deal with disasters is that there are going to be Meetings. Lots of them. Like it or not, you are just going to have to deal with the fact that you are going to have some explaining to do. You are going to be doing a lot of talking and that is going to make things worse for you while you are trying to stay focused on fixing things and putting mechanisms in place that will not let the disaster happen again. But this is something you are going to have to get used to. Really Fast. Because all of a sudden, the amount and the quality of talking that you do, is going to mean the difference between survival and a fetal crash.

It's like you were on a dark stage thinking you were just doing the maintenance work... like cleaning up the stage. Then the next second, before you knew it, the spotlight was turned on and there you were in front of a thousand faces, staring at you, expecting you to say something. Expecting you to... perform! Give them a show! As a typical programmer who doesn't see the point of meetings and talking this is going to be a difficult time. But you still need to talk.

As far as talking is concerned here is one time when you need to do one thing and do it really well:

Things To Do #1: Attend all the meetings (at least the important ones): It's like this, your manager, unless he is downright sinister, which I am assuming he is not, is calling you for a reason. You see, as you sit there staring at the blank database and seeing a month old backup, the parallel thread in your brain calculating the damage, your manager who was working at a five thousand feet level, has no clue about what is wrong. With all the support calls and the client calls going to his cell phone, he is probably freaked out. He wants to do his version of damage calculations, using word documents and excel files, map them up with your SLA, see how bad things are. He wants to then work on a PowerPoint which he will need to present to some of your most important clients in a meeting next week. He just needs to know what you already know merely by looking at the database and the logs. It's not personal, but right now, you are his only source of information and that right there is why he wants to talk even in a time like this.

The second reason why a lot of managers go into the Hyperactive-Talk-Mode and sometimes even Micro-Management mode in disasters is because they are paranoid and they lack tools to measure how bad things really are.  It's almost like - "Look, you said things are fine! I trusted you! Now look what happened!" - Again, it's not personal. He means no harm. Its just a normal, natural, lizard brain reaction that you need to understand, respect and address. And the only way you are going to address it, is by being in these meetings, by being honest, by being completely open and by answering ALL his questions with a level of confidence.

If you want to learn how to do that, learn it from the best of the doctors out there. One of them also happens to be a friend. Working on a very minor operation involving my teeth, my doctor suddenly looks at his partner, who is also a doctor and goes "Oops!". I freak out. He smiles. "Don't worry, I slipped a little. We do it all the time. We just don't say it. It's not serious". He laughs. His partner laughs back. And then they gets back to work. That's the kind of insight you get when you are working with kickass doctors. Even when they are being brutally honest. They are able to 1, tell you the truth and 2, tell you with confidence that they know what they are doing and that it's going to be fine (or at-least they are going to try their level best to make it fine).

Another important thing here is because you are going to have too many of these meetings it is HUGELY important that you keep them as short as you possibly and politely can. Convey your message, explain things, give people the confidence that they need and are expecting from you and then get out of the meetings, as quickly as you can. Think of the meetings as the announcements the crew is making as your plane is losing altitude or when your flight is experiencing bad weather.  No announcements mean panic, but announcements are not the only thing the crew needs to be doing. There is a whole lot of additional work that goes on behind the scene. While you need to make sure that while you attend all important meetings and keep people informed about things it is also important that you leave enough time for these other things.

The phone call is where most engineers and software developers go wrong. This is no time to talk! - their brain tells them and they focus on fixing the problem by not picking up the phone, or even worse, doing something stupid like lying about how bad things are. This is where most developers go downright wrong and make the disaster worse.

Where most managers go wrong, is plain old insecurity because of lack of information. Imagine, you are on a plane which is going through turbulent weather and you are buzzing the attendant every five minutes to ask for a personal update on how things are. It sounds stupid, doesn't it? Yet that's what most managers tend to do when they find themselves in the middle of a disaster.

The key in any given disaster, is understanding that you are going to have to do a little bit of talking and explaining. Just how much of it you do is going to decide if you survive the disaster or blow it up completely. Also, it's not just how much talking you do that is important, it's also what you talk about, that is equally important, which creates a seamless transition to the next post.

Read On.

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.