Silent eyes staring at the monitor for hours doesn't make good Television.

Maybe that is why Television is littered with glamorous stories of success.

Maybe that is why all Steve Steve Jobs has to do is steal from Xerox.

Maybe that is why all Mark Zuckerberg has to do is steal an idea and diddle a friend.

Every time TV shows you success chances are, the true reasons behind the success story have been camouflaged and overshadowed by spicier distractions.

The story of silent people staring at computer screen for hours and typing away silently day after day for weeks, months or years, doesn't make a best selling novel or a movie that tops the charts or good television.

But it does make a successful business.

And sometimes, history.

When equals in talents and contributing capability get together they get down to business.

The question of doing elaborate agreements, putting things down on paper, getting signatures on the dotted lines, doesn't come up. No lies, no complicated contracts.

The entire focus is on building art, shipping stuff and at times, even changing the world. Not on writing CYA documents or haggling about who gets an extra five percent on profits.

Every time you hear excessive stress on agreements or documents even before you've started something gorgeous it is often a sign of insecurity.

Or an indication that one or more (or all) parties are incompetent.

I am not saying every agreement is a sign of incompetence but if you can connect on a shared cause that is larger than pettiness, you'll see magic.

People working for free to get the project live, people contributing in open source projects they like, entrepreneurs putting in personal money to keep the business alive, developers responding to support requests on forums.

Why?

Because all parties are competent. All parties are just as capable of making it on their own. All parties don't have insecurities about being diddled out of a deal.

Or maybe, its because everyone understands, that it isn't a deal that they are working on.

It's a dream.

And that's fundamentally different.

Famous dialogs from Godfather, which is one of my all time favorite books and movies, form the foundations of business and management.

Take for instance this dialog for example spoken by the Drug Mafia, Sollozzo:

''I don't like violence, Tom. I'm a businessman. Blood is expensive.''

Taking the crime aspect of it out of the statement, the point, is a compelling one: when you grow, you give up stuff.

The aspect of giving stuff up as you grow holds true in virtually anything you do, particularly management and leadership.

Grow as a leader and you end up giving up stuff like:

1. Drama (No shouting or public intimidation even if you are on the right side of the situation).
2. Power (No use of power to make them them work late or to do that classic "push").
3. Politics (No bitching. No whining).
4. Insecurities (No information hoarding. No blind copied emails, no blind forwards, no keeping records of chat conversations and then forwarding them to irrelevant people. No randomly including new people in email trails to embarrass the ones who started it.)

The list of stuff you need to give up in order to lead with conviction is long but the point is short and simple:

If you want to lead you need to give up on your pettiness and believe in a cause that's larger than you.

I am not talking morals, ethics, emotional maturity or general goodness here.

What I am talking about is simple *economics* of leadership.

Take the godfather dialog for instance, translate it to the context of leadership and it will quiet literally translate to:

''We don't like pettiness. Pettiness is expensive.''

Like it or not, if your organization or team wants to indulge in meaningful leadership people need to drop their pettiness.

And you know it has to start with you.

Ted Dziuba's post on the pain associated with cloud based virtualization and how we continue to live with the pain even after Amazon service degradation bludgeons Reddit to death every few weeks is a must read for anyone who has hosted anything on cloud based virtual servers.

Ted talks about the general issue of promises being made around cloud based services and virtualization. He explains:

Amazon EC2 has a stated service level agreement of 99.95% uptime, yearly. As of right now, EC2's uptime is 99.23%, well below the SLA. Since computer programmers like to take a pathologically literal interpretation of the law and contracts, they usually don't understand the reality of such matters.

"But, but, EC2 is violating their SLA! That can't happen!"
"It just did."
"But, but...Segmentation Fault (core dumped)"

The trouble with SLAs is that shit happens is not yet in the vernacular of modern jurisprudence. You should never try to compare hosts based on SLA, compare them based on how they respond to downtime, because it will happen everywhere you go, without fail. For example, the machine that is serving you this web page is a physical box hosted by SoftLayer at a data center in Seattle. Last week, I had about an hour worth of downtime because of some networking problems in their data center. Whatever, like I said, shit happens. What I'm really looking for is communication. I logged a ticket with support, and in six minutes they updated me about the situation, how widespread it was, and an ETA on the fix. The tech also asked if there was anything else he could do for me. They restored connectivity quickly, but did not keep me in the dark about what was going on.

Try that with Amazon. There's a thread on the AWS forum where some genius decided to host safety critical software on EC2, and can't get his data up. The thread was posted on Friday, it's now Saturday, and with Sunday coming afterward, I'm pretty sure that nobody whose safety depends on EC2 is looking' forward to the weekend. Now, maybe it's a troll, but not even a "we're working on it" reply?

The post has three highlights that every developer should be aware of before they deploy on a cloud based Virtual Machine:

1. SLA's are totally meaningless.
2. Databases aren't designed for magical logical writes. They are built under the assumption that there is an atomic way to commit data to a physical disk.
3. Virtualization has it's uses and the only sensible criteria where you should use cloud based virtualization (in Ted's words) is, "if the machine eats shit, nothing of value will be lost".

Go read the post, even if you're just a blogger who doesn't have a million readers and are running your tiny little blog off an EC2 instance.

You need to read the post because what you know usually doesn't kill you. Having realistic expectations of downtime and data loss, doing sufficient backups, developing the ability to move to a different server and the ability to change your DNS host record at the snap of a finger doesn't hurt one bit.

Finished reading the post?

Good. Now go ahead use EC2 if meets your needs. I do it too.

As long as you're aware of the pain involved and as long as you have a switch to flip when the pain gets out of hand, we're good.

There is always an unfair side of things that happen in life.

"I was not given sufficient resources!"

"I was not given sufficient time!"

"I didn't have the money to fund an idea that I had!"

"I was born in the wrong country!"

"The economy crashed in the wrong time!"

"The markets are going through a bad recession!"

Look back and you might see how unfair life has been to you, your business, your career or your organization.

What's amusing however, is that "unfair", is often an opportunity to do something that you wouldn't have done otherwise.

An opportunity for larger than life solutions and stories to come into existence.

Of course when you see things that way, everything changes.

Suddenly, there are no excuses and nothing to bitch about.

Now what?

We are creatures of acceptance. It is why we smile at people on the road. It is why we make friend, connect to our colleagues at work and build stuff.

Like it or not, acceptance is probably one of our fundamental needs. It is as real as food, water, survival and reproduction.

There are two different ways of seeking acceptance though.

Compliance is when a large group (the society, relatives, an organization, a body of professionals, customers) tells you what they need from you. You sacrifice parts of your personality, your gut, your desires, your vision and you give them exactly what they want. In return the group grants you acceptance. Only as long as you continue to comply.

Standing out is another way of seeking acceptance. Standing out is saying, "Sorry! I don't have what you want from me. But look what I've got here!" And then wowing them with your talents, your personality, your gut, your desires, your vision, your way of doing it, your approach to solving a problem or your product.

In the short term, standing out attracts more rejections. Standing out is scary and lonely. In the short term it also seems risky and expensive. But in the long run, the kind of acceptance that you get by standing out is very different from the kind you get by compliance.

Standing out gets you acceptance from people who genuinely respond to your weirdness. Standing out gets you acceptance from people who share your core values. Standing out connects you to people who see your stuff and say "we totally get it! Give us more of just that!".

Standing out brings you in touch with the best of friends, the best of family, the best of colleagues, the best of customers.

Put simply, standing out brings you face to face with, your people

Your initial groups may not be large, but in the long run, the encouragement and the support you get from them makes standing out worth so much more than the price you pay for it.

The returns of course, aren't instant. It takes some time and patience and commitment and work to find genuine acceptance but if that is what you are seeking as an individual or as an organization, there is no reason to settle for less.

Every programmer goes through a part of his life when he is at the most enthusiastic phase of his career.

You know exactly what I'm talking about. It's the "Of course we will work weekends even if we don't need to" phase. Typically happens in the first two years of their career for most programmers.

This is the time when they impress their bosses, bag promotions, score hikes and sometimes even develop deeper roots.

Then they invariably tend to get tired of trying to impress their managers.

Or they just realize that they have a life.

Or they go through phases in their personal life which start demanding more attention.

I've seen managers change opinions of individuals when this happens.

"She was amazing when she joined but she has totally lost that spark now. She's never going to be as good as she used to be".

When you say you are working with people who are incompetent what you often mean is you are working with highly competent people having bad days and instead of trying to help them you've given up on them.

When you've seen someone peak their career with your own eyes, you know exactly what they are capable of doing.

When you say they are incapable of reaching that peak again, you are not putting a hard limit on their capabilities. You're putting a hard limit on your leadership style instead.

Just a little something to think about.

My YouTube videos on Entity Framework have resulted in more heart warming comments than anything that I have ever done online. Even more than this blog.

For me the videos and the response they received were a solid validation about some things that I've always talked about.

1. Social media (if you must call it that, I hate that term) isn't about broadcasting what you had for lunch or how depressed you are; because at the end of the day nobody cares about you.
2. Social media is about providing serious service to the best of your ability. Service that has the potential of touching someone's life by helping them with a problem, teaching them something, entertaining them or inspiring them.
3. Services that add genuine value aren't produced by someone tweeting about how sad they are. Genuine services that add value are built by slogging at something.
4. Focus on building amazing stuff and stop worrying about your subscribers or audience. If you build it, they will come.

With everyone asking for a part 4 of the video I have gone ahead and uploaded that on you-tube as well.

(The volume on these videos is a little low so you might have to use headphone and crank up your volume to a high level).

Some weeks ago I said that I was going to talk less and ship more. While I continue to strive to do that I wish you just the same. Every tweet, every post, every facebook status update, every you tube video that you publish is your chance to indulge in the act of adding value and ultimately changing the world.

Publish small. Publish consistently. Publish with others in mind. Publish the best of you even when you are publishing for fun. Publish responsibly.

I wish you good luck.

Jason Fried describes usage of small yet powerful products built by 37Signals in Fortune 500 companies.

He explains how 37Signals with it's stack is starting to sneak in on the fortune 500 organizations:

We’ve always been about the Fortune 5,000,000 – the small businesses of the world. The mom and pops, the freelancers, the small shops, and the small businesses with fewer than 10 people are our bread and butter.

However, recently we’ve been seeing more emails and signups from people who work at bigger companies and organizations. Lots of governmental agencies are showing up on our customer radar, too.

So about a week ago we dug into the data and discovered some interesting stats:

Basecamp is being used at…

1. 35 of the Fortune 50
2. 68 of the Fortune 100
3. 321 of the Fortune 500

Highrise is being used at…

1. 23 of the Fortune 50
2. 41 of the Fortune 100
3. 127 of the Fortune 500

Remember, we don’t have any salespeople here, so just about all of these signups are self-service/self-discovery or through word of mouth referrals.

We often hear from folks inside these companies. They’re beyond frustrated with the software/solutions they’re supposed to use. So they turn to our products because they just plain work. Sometimes they expense them, but often it seems a team or department head just pays out of their own pocket. The cost is insignificant compared to the productivity they receive in return.

We salute these insurgents!

While from a 37Signals perspective, the data seems to suggest that they're sneaking into the Fortune 500's, my interpretation of this data is that the fortune 500's are sneaking in on organizations like 37Signals and their products in an attempt to find out more about being effective with less. With companies running out of cash, VC's being super careful about funding, organizations trying to reduce cost and products or projects running out of free money, spending millions of dollars on projects and products is going to continue to get really difficult even for the biggest players out there. If the software industry was a party this far, with the changes in economy, the party is coming to an end. You can see that as a bad thing or a good thing.

Bad because it is going to get increasingly difficult to sell products worth millions. Sales cycles are going to get that much more complex and the fortune 500s are going to be that much more paranoid about spending millions and millions of dollars on your offering.

Good because the tools of guerilla entrepreneurship are out there for anyone who cares to use them. Use them wisely to serve the fortune five million. When these fortune five million flock to you, so will the fortune five hundred.

The take away is simple, build with passion and ethics. Build to serve and add value. Don't worry about the fortune 500 and focus on your craft because if you do it well, they might eventually sneak up on you.

Tribal Leadership By Dave Logan, John King and Halee Fischer-Wright is an insight into some of the best cultures out there and how these cultures are formed over time.

It is also a study of evolution of the mind of a typical tribal leader and the transformation a product or a project into a cause or a calling.

The book breaks any culture into fundamentally five stages:

Stage #1: Undermining: The behavior often seen in street gangs where the members of the team are united by a negative thought (usually, "Life sucks") and are in alienated relationships with everyone outside of the team to an extent where they even see the rest of the world as opposition or competition. Inter team competition for power also exists within the team.

Stage #2: Apathetic Victim: After outgrowing stage one, the team starts seeing that life in general does not suck. The focus in this stage slowly moves from "Life sucks" to "my life sucks" resulting in a realization that things can be improved with time and effort. People in this stage often continue to see their own team and the world as competition.

Stage #3: Usually happens when a person fights the phase of getting bullied by his boss and masters a skill thereby becoming productive. In this stage as the person becomes effective he shifts from "my life sucks" to "I'm great (and they are not)" approach of thinking. If you find yourself taking credit for your teams work or bossing people around, or even "pushing" or bullying them to get more work done out of them you are in this stage. If you find yourself criticizing your team members you are in this stage. You are still competing with people in your team and see them as a threat to your progress and growth.

Stage #4: Is a stage of Tribal Pride and happens when you've played the stage 3 game for a long time, have won and have had a series of epiphanies which have given you the realization that stage three doesn't scale. You've also realized that the unrelenting quest of power and competition is holding you back from making a larger impact or spreading your cause. In this stage your focus slowly shifts from "I'm great" to "we're great". Your teams are self sufficient and information is flowing smoothly within your team. You are no longer competing with your own team and have moved to competing with other organizations.

Stage #5: Is a point of time in your life where you finally get over the concept of competing with others and bump into innocent wonderment. When a medicine company stops competing with other medicine companies and starts competing with diseases. A stage where the entire company is driven by a cause that is larger than life. In this stage your focus slowly shits from "we're great" to "life is great!". You work because you experience the wonderment of a baby.

The division of organizations today more or less looks like this:

What the book does not explicitly state but makes very evident if you read between the lines is that all of your work life is a journey from "life sucks" to "life is great". What is rather tragic if you notice the graph above, is that most organizations and leaders are stuck in the "I'm great" stage. Only about 2% of the organizations and individuals manage to experience true wonderment of a toddler or a baby.

The biggest barrier to reaching wonderment is getting stuck at stage 3 where you are constantly busy portraying how amazing you are. Managers controlling who sends out emails and to whom, leaders hording information because they believe information is power, team leads constantly criticizing their own teams and teams constantly stepping on each others toes for their next promotion.

Stage 3 is important because it makes your stronger, but once you have lived it, your goal should be to grow out of it and move on to stage 4 and eventually to stage 5 where you experience true wonderment in work. A stage where are making a dent in your universe and the universe of people around you.

Which stage of leadership do you stand in?

Before you answer that question however, keep in mind that one of the most prominent features of stage 3 leaders is that they think of themselves as being on stage 4.

Go get the book (or download the free Audio book) and do yourself a favor by reading it. You might find yourself nodding your head in approval. You might even find yourself thinking about the times when you were fighting for growth and power. You might find yourself reflecting on how stupid you were. That or you might have to stand face to face with your deepest insecurities and admit you are a level 3 leader. Either ways, it is time for some serious soul searching if you want to eventually want to live the life of honest wonderment.

The book, Delivering Happiness by Zappos CEO, Tony Shieh is moving on more fronts than one for anyone who has ever tried to work on building a team, a product, a business or an organization. The book is an insight into Tony's mind and his core values which continue to drive Zappos towards success.

But what is even more fascinating about the book is the openness with which it addresses and describes the fears of the early entrepreneurs or anyone who has ever tried to walk a different path.

Tony tells the tale of his quitting Oracle to chase a dream of starting his own organization. The story is fascinating because it provides a chilling account of the brutal reality of walking a different path and at the same time reassuring because of the way it ends. Tony tells the story with a remarkable blend of facts and emotions:

As it turned out, the adventure we were waiting for to happen to us didn't end up happening on its own. We ended up sitting around in our apartment, occasionally doing some Web design work, and going out every once in a while to try to drum up some more sales.

By the end of the first week, it dawned on me that neither of us was actually passionate about doing Web design work. We loved  the idea of owning and running our own business, but the reality ended up being a lot less fun than the fantasy.

My parents were not exactly thrilled that I’d quit my job at Oracle without a real plan for what to do next. When I told my dad that Sanjay and I were planning on running a Web design business, he told me that it didn’t really sound like that could ever become a big-enough business to be meaningful.  And now, one week into it, both Sanjay and I were starting to wonder if we’d made the right decision to leave Oracle. The next few weeks were tough and somewhat depressing. We started to spend most of our time just surfing the Web to combat the boredom and to keep ourselves entertained.

Watching Sanjay go into the coat closet to nap there in the middle of the day was only sort of funny the first time. We were starting to get a bit stir-crazy.

Luckily, we both had enough savings from the jobs we had in college that we didn’t need to worry about whether we would be able to pay the rent for the rest of the year. We didn’t know what we wanted to do, but we had learned what we didn’t want to do. We didn’t want to work for Oracle. We didn’t want to do any more Web design work. We didn’t want to make any more sales calls. And we didn’t want to be bored out of our minds. So we spent our days and nights trying to figure out the next great Internet business idea, but we really couldn’t come up with anything that sounded good.

One weekend, out of sheer boredom, we decided to do some computer programming to test out an idea for something we initially called the Internet Link Exchange (ILE), which we eventually renamed to just LinkExchange.

What Tony and Sanjay had stumbled upon out of sheer boredom, would later be acquired by Microsoft for 265 million dollars. On one hand the book describes the Zappos values and culture and on the other it also has stories which form  a constant roller costar ride of up's and down's in Tony's life where on multiple occasions Zappos was inches away from getting wound down because of lack of finances. From overcoming his fears of failure to selling his assets to keep Zappos afloat, the book is not just an insight into Tony's mind but and insight into why entrepreneurs and developers build organizations and products.

More often than not, artists and builders don't work on building stuff just for the profits associated with building stuff. They build stuff because they have an unstoppable itch that they have to scratch. The itch of delivering happiness.

The television teaches you stereotypes of fun. The television teaches you that entertainment is junk that gets thrown at you by media companies which you learn how to enjoy over time.

Television teaches you to pick from a couple of hundred channels and then just hope that your channel is playing something you are truly interested in. If not, television teaches you to settle for what you get.

Television is junk food for your mind.

Television is about learning to enjoy wandering generality instead aiming for of a meaningful specific.

Go on. Keep the batteries just twenty seconds away from immediate reach and tweak your brain to seek other constructive meaningful forms of entertainment.

Why?

Because Television, quiet literally, is one of the biggest metaphors out there today that actually represents "the box" and your job is to think outside it.

With iPhone, blackberry, android and phone 7 one dollar applications are changing the way businesses did business.

It is easier than ever to be a guerilla business. You are suddenly depending on low costs and high volumes to keep you going.

In this market, what happens when we download your four dollar application (a little over a cup of coffee) and run into trouble.

When we walk into a coffee joint, pay four dollars for a cup of coffee and end up not liking it, we twitch our eye brows and forget the bad experience with a couple of passing comments.

But what happens when as users, we expect you to support us for a product that is priced at the range of a cup of coffee and doesn't do what we expected it to do?

This is when deep down inside, we really don't expect you to wow us with quick responses. But then this is also your chance to do just that. After all even the best coffee shops are the ones that listen.

If you are going to be the next software development coffee shop around the block, be the one with a friendly guy who greets you with a smile and listens when you don't like his (or her) coffee.

We've come full circle and the rules of making your customers happy have not changed all that much.

Are you building the next one dollar application? That is no excuse for lousy customer support. There was never a reason to not listen, even when all you were running was a coffee shop around the block.

We are calling your bluff.

Now go, surprise us.

Who's driving the innovation in your organization? How many products or projects are on the ideas of individual engineers?

I'm not talking about allowing programmers to introduce minor features in the product. I am talking about full blown products here which take sizable time and organizational support to build. Engineers building full blown applications like teams of artists painting amazing pictures based on their own visualization.

There are two benefits to letting your programmers drive innovation in your organization.

1. They have built in bullshit busters in their heads and can sense what will sell and what wont.
2. They tend to be much more intrinsically motivated when they are working on their own ideas.

Go jot down the list of products that your organization is offering. How many of these product ideas came from "management" Vs. how many of them emerged out of "engineering" teams?

If you are wondering why your engineers aren't creating products that kick some serious butt, or why your products miss that final "wow factor" your answer might lie in the fact that your engineers aren't intrinsically motivated.

When you see engineers as cogs who build ideas that others think of and occasionally make a few changes here and there, that is exactly how your engineers work.

When you see engineers as artists, they will paint awesome pictures that make a dent in the universe.

What do you see your engineers as?

Just a little something to think about.

After countless days of slogging J's team ships the build. In a few minutes of sending the email out they receive this response from their manager:

"The release notes had lots of typos. I had to fix those before sending the build out to the client. We need to be careful about running a spell-check before sending out project documentation."

When your team slogs for days shipping a build and all you can see are typos in the release notes you my friend are acting like a fully qualified asshole.

Here's a free advice if you want to get better at working with geeks: Open Microsoft word, fix the damn typos, don't bitch about them, thank the team for their hard work and move on.

Most managers cannot resist the temptation of whining about small mistakes which they can easily fix themselves in no time.

Reasons why most managers say they "have to" whine:

1. People need to know about these mistakes so that they don't make them the next time.
2. People need to be trained so that they don't always depend on the manager to do last minute fixes.

Reasons why most managers really whine:

1. Managers are inherently good at advertising work. That is a huge part of what they do for a living. When it's their own work, expect the advertisement to be louder than ever.
2. Most managers have a complex about not being productive enough OR not contributing enough. "I was able to find an issue and fix it! MYSELF! I finally showed those pesky developers that even I can contribute!" – this opportunity is often too tempting for most managers to let go.

Success breeds success and while it is OK to point out mistakes objectively, when you give out the vibe that says "you have failed me but that’s okay, I fixed it anyway" on every small mistake your team makes, you are diminishing their chances of success in the long run.

Acknowledge success, stop discouraging people by focusing on their mistakes and start motivating them by focusing on their success.  Even if you had to fix their mistakes or provide cover fire to a team worthy of it, in most cases, they really don’t need to know about it. So stop bitching and do a little bit of clean up yourself.

Just saying.

"I am looking forward to join a Multinational with a larger employee strength and more structured process".

When 'R' says this in an interview, she hasn't even bothered to glean through our website to know that we don't believe in large teams and our process is lighter than most BDUF shops.

That makes our organization a misfit for her.

Since interview is a two way process where candidates should reject the organizations that don't fit their needs, would she like to end the interview immediately and reject our organization?

When asked this question, she reacts as if we just dropped a dead rat on the table and asked her to clean up the stinking carcass. Clearly, the interview isn't going well for her.

After some more probing a switch turns somewhere and she flips into a totally honest mode.

You can feel it. She stops lying and getting stuck. Now she describes her real reason for looking for a job.

A higher paycheck.

During the course of the interview we figure out that she is in fact underpaid and her reasons for an expectation for a higher salary are absolutely valid.

I am guessing that what had happened here was that she was 'mentored' and told to stay away from mentioning salary as a reason for quitting because that is a cliché.

When interviewing the only two rules that often work are honesty and openness.

In situations like the one 'R' was in, staying away from Cliché's is also a cliché.

If you genuinely believe that you are underpaid and if that is your sole reason for changing jobs, having the ability to stand up for it with honesty and openness doesn't make you sound bad. Lying or trying to make up reasons does.

When you are honest and open, you showcase yourself in an as-is condition.

If you can carry your true self without being ashamed or trying to hide who you are and what moves you, your chances of getting selected in a mature organization are that much higher. If you get rejected for who you are or something that you truly believe in, your chances of finding another organization where your core values are aligned with the organization's core values are that much higher.

Don't bitch in an interview. Don't whine. Don't cry. Don't keep constantly complaining.

At the same time If you are genuinely underpaid and you truly and deeply believe that you deserve a respectable salary, don't try to sugar coat the situation with random made up reasons for quitting which people tell you will 'sound good' during an interview.

Salary being the only reason for leaving is a scar on your face, but then depending on how you carry yourself, scars can also look good.

The nitpicking saga between J (real name withheld for obvious reasons) and his team lead had been on for months. Every small mistake J was making was being highlighted and all his contribution were not even being discussed.

J had been working late nights for a few weeks at his workplace.  On the last week of his project J having nothing on his plate decides to call it an early day and heads home at around 8:00 in evening.

The next day his technical lead escalates the issue of J not being proactive about his work. Leaving early when you are on a critical project is unacceptable.

Unable to understand what is going on, J tries to patch things up by having an open candid conversation with his team lead who isn't in office for the entire day.

At around 10:00 in the evening J sees his lead on IM and summons up enough courage to send him a message asking him if he was mad at J and if there is anything J could do to improve a sour professional relationship between them.

And the response from his team lead?

It goes like this: "Are you sending this message on a high? Are you drunk!?"

As J narrates this incident to me over a casual conversation some highlights emerge:

1. In J's organization open candid one on one conversations are so rare and unheard of that nobody believes that is what you are trying to do even if you start an open conversation with your manager.
2. In J's organization cases of IM flames by drunk employees to their managers are so common that most team leads see precisely that even when you are trying to have a perfectly healthy discussion that can bridge gaps.

Makes you wonder if the cases of drunk IM flaming that J's organization is so concerned about are really cases of drunk IM flaming or  just perfectly sane employees trying to summon up enough courage to have perfectly sane conversations over IM?

Wow! Talk about invisible gorillas!

When you come face to face with monkeys in their natural habitat most animal experts will give you one advice. Do *not* smile at them.

Monkeys (and most other animals) interpret the display of teeth as an act of aggression.

Showing teeth is way of scaring the enemy before a monkey attacks.

Smile at a monkey and he will show you his teeth back. Keep smiling and you are instigating the monkey to strike.

Human beings on the other hand use smiles to connect to others and to make each other feel good.

Even though we share some behavior patterns with primates our reasons for smiling are very different than there. A simple lesson that most managers it seems need to be taught explicitly.

"No, No, No, No, there is nothing I can do about it. You need to finish this in the given timeline." - how many times have you seen your manager give that response with a stupid grin on his face.

Management Advice: This is not a time to be smiling.

The least you can offer as a manager in times like this is empathy. An inappropriate grin in situations like these is an indication that you still see a grin as an act of aggression or intimidation.

And no, developers don't like working with monkeys.

When you are leading teams, your smiles, your body language, your tone and a whole lot of other aspects are being judged implicitly and automatically by the people you work with.

So, if you are wondering why no one tells your about their quitting plans or why no one ever invites you to team parties, maybe that is because you give us that stupid grin when you should be empathizing with your developers.

Just saying.

He is detail oriented. He takes care of every single little detail while writing his code. He sees slightest of deviations between the design and the implementation. He is the kick ass alpha geek in the team.

Attention to detail is a major  plus in his professional life and that is a GOOD thing, till the time he starts leading a team as a technical manager.

Then before you know it, he is knit picking on how many days people in his team should be taking time off. Why do you need eight days for a vacation?

He is estimating how many man hours an engineer should take to get a task done because he himself could have done it in a day.

The same attention to detail that makes you an amazing engineer usually ends up making you an amazing asshole when you start managing people.

There are two lessons to learn from this. 1) Before you promote someone and give him a team to work with, measure their ability to detach themselves from the level of detail that they should not be bothered about. 2) When you are working as a technical manager most of the time your ability to trust others, empathize with their problems, helping them out when they are stuck and your ability to provide intrinsic motivation which makes people want to excel and do the right thing is much more important than your attention to every single insignificant piece of information floating around in your universe.

I'm not saying switching attention to detail is essentially always a bad thing. When you are a geek attention to detail comes naturally to you. But when you are managing teams sometimes "actively forgetting" that an Engineer said he was going to check in his code today but ended up taking one extra day to do an awesome job, is also equally important.

Just saying.

As programmers we spend countless hours getting thrilled by tweaking small things which have huge impact on the applications we build. You want to run the same application, with the same hardware and load, 10x faster? Put a kick ass programmer on the problem and give him all the time in the world. Chances are that he will come up with better code that takes lesser memory, lesser processing cycles and runs blazing fast. And he would have done it by tweaking small things here and there. Tweaking things to make them better is fine grained in our brain as a programmers. We cannot resist the temptation of tweaking things when we know that they are going to have a huge impact on the overall product.

Practitioners of positive psychology do just  the same kind of tweaking but with your brain which is why I find books on positive psychology hugely fascinating. Shawn Achor in his book the Happiness Advantage talks about understanding the tweaking the human mind to cultivate new good habits and to turn your resolutions of changes into success stories rather than stories of failures with a tragic end.

Shawn's premise is two fold. 1) That we are creatures of habit and habits are how our brains are wired to work. 2) we have limited amount of will power in our brain. He explains the first premise that we as human beings are bundles of habit:

In my mind, though, the greatest contribution William James made to the field of psychology is one that was a full century ahead of his time. Humans, James said, are biologically prone to habit, and it is because we are “mere bundles of habits” that we are able to automatically perform many of our daily tasks—from brushing our teeth first thing in the morning to setting the alarm before climbing into bed at night. It is precisely because habits are so automatic that we rarely stop and think about the enormous role they play in shaping our behavior, and in fact our lives.

After all, if we had to make a conscious choice about every little thing we did all day, we would likely be overwhelmed by breakfast. Take this morning as an example: I am guessing that you didn't wake up, walk into the bathroom, look quizzically into the mirror, and think to yourself, "Should I put on clothes today?" You didn’t have to debate the pros and cons.

You didn’t have to call on your reserves of will power. You just did it the same way you probably combed your hair, gulped your coffee, locked your front door, and so on. And, excepting the exhibitionists in the reading public, you did not have to remind yourself all day to keep these clothes on. It was not a struggle. It didn't deplete your reserves of energy or brainpower. It was second nature, automatic, a habit.

None of this seems particularly groundbreaking to us today. But what William James concluded was indeed crucial to our understanding of behavioral change. Given our natural tendency to act out of habit, James surmised, couldn’t the key to sustaining positive change be to turn each desired action into a habit, so that it would come automatically, without much effort, thought, or choice? As the Father of Modern Psychology so shrewdly advised, if we want to create lasting change, we should “make our nervous system our ally instead of our enemy.” Habits are like financial capital forming one today is an investment that will automatically give out returns for years to come.

Shawn also goes on to explains how our brain uses our practice and habits to form neural pathways which ultimately make us really good at an activity:

This is also how we become skilled at an activity with practice. For instance, the first time you try to juggle, the neural pathways involved are unused, and so the message travels slowly. The more time you spend juggling, the more these pathways get reinforced, so that on the eighth day of practice, the electrical currents are firing at a much more rapid pace. This is when you’ll notice that juggling comes easier, requires less concentration, and that you can do it faster. Eventually, you can be listening to music, chewing gum, and having a conversation with someone else, all while those three oranges are flying through the air. Juggling has become automatic, a habit, cemented in your brain by a solid new network of neural pathways.

Armed with this new knowledge Shawn sets out to form a new habit of playing Guitar every day and encounters a humongous failure.

I decided to take up the guitar once again, since I already owned one and knew that I enjoyed playing it. Because common wisdom has long proposed that it takes 21 days to make a habit, I decided to make a spreadsheet with 21 columns, tape it to my wall, and check off each day I played. By the end of the three weeks, I felt confident that (a) I would have a grid full of 21 check marks, (b) daily guitar playing would have become an automatic, established part of my life, (c) my playing would improve, and (d) I would be happier for it.

Three weeks later, I pulled the grid down in disgust. Staring up at four check marks followed by a whole lot of empty boxes was more discouragement and embarrassment than I needed. I had failed my own experiment, and worse, I was no closer to telling potential dates that I was a musician. Worse still, I was shocked, depressed even, at how quick I had been to give up. A positive psychologist should be better at following his own advice!  (Of course, the feelings of failure only deepen when you realize you’re now a depressed positive psychologist.) The guitar was sitting in the closet, a mere 20 seconds away, but I couldn't make myself take it out and play it. What had gone wrong? It turns out that the telling words here are make myself . Without realizing it, I had been fighting the wrong battle one I was bound to lose unless I changed my strategy.

This failure of course leads Shawn to a second realization that we as human beings have limited will power with us.

The point is that whether it’s a strict diet, a New Year ’s resolution, or an attempt at daily guitar practice, the reason so many of us have trouble sustaining change is because we try to rely on willpower. We think we can go from 0 to 60 in an instant,  changing or overturning ingrained life habits through the sheer force of will.

In one of many studies on the subject of willpower, Baumeister and his colleagues invited college students into their lab, instructing them not to eat anything for at least three hours prior to the experiment. Then he split them into three groups.

Group 1 was given a plate of chocolate chip cookies, which they were told not to eat, as well as a healthy plate of radishes which they were welcome to eat to their heart’s content. Group 2 was presented with the same two plates of cookies and radishes, but they were told they could eat off whichever plate they liked. Group 3 was given no food at all. After enduring these situations for a significant length of time, the three groups were then given a set of “simple” geometric puzzles to solve.

Note the quotes around simple. In truth, this was another one of psychology’s favorite tools: the unsolvable puzzle. As I learned the hard way through my Help the Elderly experience, psychology researchers love using impossible games to see how long participants will persevere at a task.

In this case, individuals in Groups 2 and 3 long outlasted those in Group 1, who quickly threw up their hands in defeat. Why? Because the students who had to use every ounce of their willpower to avoid eating the enticing chocolate chip cookies didn't have the willpower or mental energy left to struggle with a complex puzzle—even though avoiding cookies and persisting on a puzzle are seemingly completely unrelated.

The point of these experiments was to show that no matter how unrelated the tasks were, they all seemed to be tapping the same fuel source. As the researchers wrote, “many widely different forms of self-control draw on a common resource, or self-control strength, which is quite limited and hence can be depleted readily.” Put another way, our willpower weakens the more we use it.

Armed with this new knowledge of how we are creatures of habits and  how our will power weakens with time Shawn now decides to reduce the activation energy it takes to start something and experiments with his own mind to see how it reacts:

I thought back to that initial experiment. I had kept my guitar tucked away in the closet, out of sight and out of reach. It wasn’t far out of the way, of course (my apartment isn’t that big), but just those 20 seconds of extra effort it took to walk to the closet and pull out the guitar had proved to be a major deterrent. I had tried to overcome this barrier with willpower, but after only four days, my reserves were completely dried up. If I couldn’t use self-control to ingrain the habit, at least not for an extended period, I now wondered: What i f I could eliminate the amount of activation energy it took to get started?

Clearly, it was time for another experiment. I took the guitar out of the closet, bought a $2 guitar stand, and set it up in the middle of my living room. Nothing had changed except that now instead of being 20 seconds away, the guitar was in immediate reach. Three weeks later, I looked up at a habit grid with 21 proud check marks.

This is a profound discovery for anyone who has ever made a new years resolution and broken it in days. Anyone who has been on a diet regiment or anyone who has ever promised himself that he was going to get more effective starting next week but the next week never came.

The book has pages full of interesting advice on how you can reduce choices that bog you down and how you can make preemptive decisions way  in advance by changing defaults.

Planning on learning how to play an instrument? Just reduce the activation energy by having the instrument handy.

Planning on going to the gym every morning? Sleep in your gym clothes to reduce the activation energy of heading out the next morning.

Planning on quitting television? Take the guitar experiment described above. Flip it by taking the remote batteries out and keeping them in a closet twenty seconds away.

Planning on being more productive at work? Close your mail client and hide it's shortcut inside 4 levels of folders such that it takes you multiple clients to activate it.

The basic premise that Shawn works with is that we are creatures of habits with limited will power. So if you are trying to form a habit don't just rely on your will power. Use your brains creatively to reduce the activation energy to do something and once you do it for sometime it will automatically become a habit forming new neural pathways in your brain that will not even require any will power to keep doing it. So if you're often faced with a blank wall on how to start your day, why not just put the visual studio shortcut on your startup list and have your computer boot to open a project you should be starting your day with?

Once you have done that why not making starting anything else that much more difficult.

Do it long enough and then distractions like Facebook and Twitter would suddenly stop being distractions. They will eventually become tools of forming connections that you use wisely during limiting times and not addictively.

The experiments and the insights that Shawn provided in this book are huge. The real question you need to answer is, how are you going to use these insights in your life to become a better programmer and a better human being.

Go tweak your life and program yourself to pick up some good habits. I wish you good luck.

(And Why Most Programmers Don't Start Something New)

If you've landed with a safe job the excuses for not blogging or not starting a side project are numerous.

No one is going to read what I write so why blog? No one cares about what I build so why build? I don't get enough opportunities in my organization so I am out of shape. And the best of them all, I am just too busy to start anything.

The real answer as to why you don't start initiatives outside of your work life however, may be hidden in the experiment on dogs that Martin Seligman, now the father of positive psychology observed in his years as a graduate student. Shawn Achor talks about this experiment in a rather intriguing fashion in his book The Happiness Advantage. He explains:

To understand the psychology of failure and success in the modern business world, we need to step back briefly to the tail end of the Age of Aquarius. In the 1960s, Martin Seligman was not yet the founding father of positive psychology. He was only a lowly graduate student, studying the opposite of happiness in his university's laboratory.

Older researchers in Seligman's lab were doing some experiments with dogs, pairing noises, like a bell, with small shocks to see how the dogs would eventually react to the bell alone. Then after this conditioning was complete, the researchers would put each dog in a “shuttlebox,” a large box with two compartments, separated by a low wall. In one compartment, the dogs would get shocked, but on the other side they would be safe from shocks, and it was easy to jump over the wall.

The researchers predicted that once the dogs heard the bell, they would immediately jump into the safe half of the box so they could avoid the shock they knew would follow.

But that's not at all what happened. As Seligman now tells the story, he remembers walking into the lab one day and overhearing the older researchers complaining. "It' s the dogs," they lamented. "The dogs won't do anything. Something’ s wrong with them."

Before the experiment started, the dogs had been able to jump over the barriers just fine, but this time they were just lying there. While the researchers contemplated what seemed to be a failed experiment, Seligman realized the value of what they had just stumbled upon: They had accidentally taught the dogs to be helpless.

Earlier, the dogs had learned that once the bell rang, a shock was sure to follow, no matter what. So, now, in this new situation, they didn't try jumping to the safe half of the box because they believed there was nothing they could do to avoid the shock. Just like the workers at the Johannesburg construction company, they essentially figured, "why bother?"

A follow up experiment by Seligman talks about how this idea of learned helpless translates to offices and work environment of today. Shawn explains:

The fact is that in our modern, often overstressed business world, cubicles are the new shuttleboxes, and workers the new dogs. In fact, one study shows just how closely we humans resemble our canine counterparts.

Researchers took two groups of people into a room, turned on a loud noise, and then told them to figure out how to turn it off by pressing buttons on a panel. The first group tried every combination of buttons, but nothing worked to stop the noise. (Another example of devious psychologists at work!)

The second group, acting as a control, was given a panel of buttons that did successfully turn off the noise. Then both groups were given the same second task: They were put in a new room, the equivalent of a shuttlebox, and were once again treated to an obnoxious noise.

This time, both groups could easily stop the noise by simply moving a hand from one side to the other, just like the dogs could easily move to the other side of the box. The control group quickly figured this out and stopped the blare.

But the group that had first been exposed to a noise they couldn't stop now just let their hands lay there , not even bothering to move them or try to make the noise stop.

As one of the researchers said, "It was as if they’d learned they were helpless to turn off noise, so they didn't even try, even though everything else the time and place, all that had changed. They carried that noise-helplessness right through to the new experiment."

These experiments educate us that each one of us is vulnerable to learned helplessness. Understanding it, is the first step to avoiding it, both in your personal and professional life. 

So the next time you think of working on changing the culture within your organization, or starting a blog or taking up a side project during the weekend, or starting that product that you always wanted to start and there is a voice in your head which starts talking about those excuses or telling you how helpless, non-talented, busy or tied up you are, remember the helpless dogs.

Maybe (and I am just saying maybe) the real reason why you are not starting is that deep down inside you probably know that you're going to fail. The voice full of doubt is just your way of telling yourself, "why bother?".

Are you really prepared to fail early fail often or are you just letting your learned helplessness get the best of you? Just a little something to think about.

PC and Mac arguments have existed since the beginning of the software development world. Zealots have spent countless decades arguing about who will rule the world, the PC or the Mac. Jokes about Windows and Mac have also existed for a long time. Videos of both Windows crashes and Mac crashes have been out there for years.

With a strong community of Zealots on both ends of the spectrum you're often left to wonder what the relationship between Bill Gates and Steve Jobs would be like. Arch enemies wanting to get each others organization destroyed like you see in movies? Not really.

In a series of videos on youtube (links provided at the end of the post) you see both Bill Gates and Steve Jobs on the same stage sharing an interview. The amazing thing about the videos is that they provide a deep insight the pragmatism that both these leaders of two rival organizations share.

The even more amazing thing about the videos is that you can see a strong unspoken respect for each other that both these individuals share. For example when asked to talk on one thing in Bill Gates that Steve Jobs admires Steve has this to say:

Bill built the first software company in the industry. I think he built a software company before anybody in our industry knew what a software company was, except for these guys and that was huge. That was really huge. And the business model they ended up pursuing turned out to be the one that worked really well for the industry.

Building a company is really hard and it requires your greatest persuasive abilities to hire the best people you can and keep them at your company and keep them working doing the best work of their lives and Bill's been able to stay with it for all these years.

Gates on the other hand has deep rooted respect for the contributions Steve Jobs has made to the industry. He explains:

Steve gave a speech once which is one of my favorites where he talked about, in a certain sense we build the products that we want to use ourselves so he is really pursued that with incredible taste and elegance that has had a huge impact on the industry and his ability to always come around and figure out where that next bet should be has been phenomenal. You know, Apple literally was failing when Steve went back and re-infused the innovation and the risk taking that have been phenomenal. So the industry has benefitted immensely from his work. We've both been lucky to be a part of it but I'd say he has contributed as much as anyone.

If you listen closely enough the interview is full of pragmatic moves these leaders and their organizations have taken in spite of their age old rivalry.

For example Jobs tells the story of how Apple seeks help from Microsoft in their early days.

Jobs interrupts Bill Gates in a fit of excitement and the words, "Let me tell this story!" and goes on to tell it in his classic story teller style:

Waz, my partner, the guy I started out with Steve Wozniak, brilliant brilliant guy. He writes this basic that is like the best basic on the planet. It does stuff that no other basic has ever done. You don't have to run it to find your error messages, it finds it for you when you type in stuff. It's perfect in every way. Except for one thing which is that it is just fixed point. It is not floating point. And so we're getting a lot of  input that people want this basic to be floating point and we're begging Waz, Please Please make this floating point and he never does it. And so Microsoft had this very popular floating point basic that we ended up going to them and saying "help".

To which Bill Gates adds:

It was thirty one thousand dollars for the floating point basic and I flew out to Apple; I spent two days there getting the cassettes. The Cassette tapes were the main way people stored things in those days. That was fun but I think the most fun is later when we worked together. The team that was assembled to do the Macintosh was a very committed team and there was an equivalent team on our side that got totally focused on this activity. And we really bet our future on the Macintosh being successful and then hopefully graphic interface in general being successful. First and foremost the thing that would popularize that would be the Macintosh. And we were working together and the schedules were uncertain, the quality was uncertain. And so we had made this bet that the paradigm shift would be graphics interface and particularly the Macintosh would make that happen.

The video shows how objectively and closely the two companies and their leaders worked to shape the industry and make it what it is today. When asked about what both would like to learn from each others Bill Gates is quick to respond and say "I'd give a lot to have Steve's taste". What Bill Gates is referring to is this video of a young Steve Jobs floating on YouTube where Jobs is seen ranting recklessly on Microsoft and why they have no taste in his early adamant days. The audience roars into a laughter at Bills Gates joke on Steve Jobs to which Gates adds:

(I'd give a lot to have Steve's taste) No, this is not a joke at all.... I think in terms of intuitive taste of both people and products. I mean we sat on Mac product reviews where there were questions about software choices, how things would be done that I viewed as an engineering question and that's just how my mind works and I would see Steve make the decision based on his sense of people and product that is even hard for me to explain. The way he does things is just different. And you know, I think it is magical.

The videos are an inspirational insight into a rich rivalry which is not just about brutal fights but also about helping each other in the times of trouble and making the most pragmatic decisions beneficial for the industry.

Steve Jobs for example tells his story of seeking help from Microsoft during his comeback where he  also talks about how descriptive and stupid the whole Apple is superior in everything or the whole Apple Vs Microsoft mindset is:

You know, Apple was in very serious trouble and what was really clear was that if the game was a zero some game where for Apple to win Microsoft had to loose then Apple was going to loose.

A lot of people's head were in that place at Apple and even in the customer base because Apple had invented a lot of this stuff and Microsoft was being successful and Apple wasn't and there was jealousy and there were just a lot of reasons for it that don't matter.

But the net result of it was that there were too many people at Apple and the Apple ecosystem playing the game of 'For Apple to win Microsoft has to loose' and it was clear that you didn't have to play that game. Because Apple wasn't going to be Microsoft. Apple didn't have to beat Microsoft. Apple had to remember who Apple was, because it had forgotten who Apple was. And so for me it was pretty essential to break that paradigm. And it was also important that Microsoft was the biggest software developer outside of Apple developing for the Mac.

So it was just crazy, what was happening in that time and apple was very weak and so I called Bill (Gates) up and we tried to patch things up.

The relationship between the Mac development team at Microsoft and Apple is a great relationship. It's one of our best developer relationships.

Then there are excellent displays of pragmatism on both sides. For example, Microsoft ordering Mac processors for their XBox 360 and Steve Jobs being realistic about the Apple market share. He explains:

We don't have a belief that the Mac is going to take 80% of the PC market. We become really happy when our market share goes up a point. And we love that. We work real hard at it.

By the time the interview ends both these Stalwarts come out sounding as not just rivals with deep respect for each others but friends who have fought just as many battles together as they have fought with each other.

The video is a good watch not just once but every time you find yourself bitching about either Windows or Macintosh. The videos act as a gentle reminder that real people who do real work and solve hard problems have equal level of respect for other people who do the same irrespective of the path they take.

On the other hand, those who do nothing, bitch or become Zealots and stupid fan boys who fail to see the downsides of the company or person they follow and continuously bitch about the other side.

So go out there, pick a platform you love working on. I don't care if you pick a Windows or a Mac. Just stop bitching about how bad the other side is, stop comparing the two and get down to doing some real work. Jokes or random criticism about the other platform are just not as funny as they used to be once. Besides, we are getting bored of these anyways. I am just saying.

And just in case you want to see the videos back to back here are the links:

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 | Part 9 | Part 10 | Part 11.

Elite's documentary on YouTube (part 1 and part 2) is an inspirational look into the history of the video game industry and the history of one game that changed the world. Well, at-least the world of video games. Elite was a spark that set the world of video games on fire and sent it on a mind blowing accelerated evolutionary trip. 

If you ever played Pac-Man you were pretty much aware of what to expect from all other video games in the early eighties.

Every video game had the basic set of expectations. David Braben, the co-creator of Elite explains what these expectations were and expresses his frustrations with these rules:

There was an expectation that for example, a game would take 10 minutes to play through. There was an expectation that it would have three lives. There was an expectation that it would have a score. And all of these things had almost become written in stone; which is utterly ridiculous.

The founders of Elite challenged every expectation and dared to question the status quo. They decided  to question the premise on which big guys like Atari worked. David explains this in his interview:

I was very excited about 3d graphics even before I had a computer. Because I thought it can't be that hard. You know, as an arrogant teenager might do. But the received wisdom of that time was that you couldn't do it on a home computer.

We were possibly the first people to do what would now be called a big game. A game where the player has to put a lot of commitment into playing it as well as we to writing it.

But changing the world and making a dent in any universe isn't easy. It is a constant struggle against rules and constraints.

A measly 18k of usable memory on the BBC Micro meant that the programming duo would have to make custom changes to earn an additional 4k of usable memory to squeeze entire multi dimensional virtual universes into it.

Having limited usable memory meant that they would have to revert to innovative techniques like Fibonacci Formula to draw the universes and the movement of objects in these universes instead of storing these pieces in memory.

Lack of tools meant they the programming duo would have to draw the objects on graph paper and type in the numbers.

No error checking meant that they would have to debug the code line-by-line.

EMI's rejection letter to back them up based on the grounds that they were breaking every conventional rule meant that they would have to move to Acorn.

Running out of time meant squeezing in last minute changes like introducing a radar system two weeks before the release date.

For Acorn; the company that backed up the programming duo; backing a game that was changing the world of gaming meant that they would have to change their production; marketing; packaging and even their launch techniques.

The story has a happy ending with 150,000 copies of elite sold in UK itself; an incredible one copy for every BBC Micro that existed in the UK. Elite was the First Non-US game to not just get into the billboard charts but get to number one on it. Elite's story is a textbook example of a success story with lessons ranging from programming, marketing, venture funding, vision, leadership, dedication and success.

Here are the links to both parts of the documentary:

1. Part 1.
2. Part 2.

The videos are a must watch for anyone who is the process of building or marketing anything innovative. Elite was a game that inspired thousands of programmers to join the gaming industry and placed Britain on the map of game producing nations. It was the game that changed every rule of how games were built and what games were supposed to do. It changed the basics of how games were marketed and released. It might even be appropriate to say that it was a game that changed the world of gaming. To say the least Elite was an incredible game with many incredible lessons that will continue to inspire programmers for ages to come.

(Left Justification Vs. Justify Alignment & Facts About Text Justification Every Programmer And Designer Should Know)

When you look at the world from the eyes of programmer who cares about text alignment on the web, his own documents, his website and his applications, the whole of the human species can be broken down into these groups:

And If you don't care about your text-alignment all I can tell you is that you should. The basics are fairly straight forward and knowing them can make your output (blog posts, applications, web sites and articles) that much more sexier. How you align your text on your web pages and your blog has a bigger impact on your readers than you can think. So close your IDE's for sometime and invest just a small part of a couple of your days in reading a few posts on how text alignment works. This one is on using justified alignment in your articles, blog posts, applications and websites.

The idea for this post started when I sat down to revamp the design of this blog and was faced with a Hamlet like question that just held me by my collar and would not let go. The question was on this line:

To justify align or not; that is the question.

Turns out; that most information you can find on forums where this question has been asked is subjective. Someone comes in and says, "Yeah! You should justify everything. It's sooo freaking cool!" and then someone else responds with, "No Dude! Justification sucks!". There is very little objective data available out there and the information that is out there is spread across umpteen number of disconnected information sources like Wikipedia, hidden research papers and cryptic paid articles.   

The attempt here is to give you the basics about justification of text using one consolidated post so that you can state researches, experiments, facts and sources in meetings which are organized to decide if you should left align your text or justify align it and then you can end up sounding like a genius or a rock star or an alpha geek or a design guru! Well, not exactly, but then you can still use this information to improve your website, application, blog or other documents.

So read on.

Ready? Let's start with the basics first. The Kids Stuff. The stuff everyone knows and then we can build on that. So let's assume you are one of those guys (or girls) who doesn't give a rat's ass about justification and you don't even know that the two basic kinds of justifications that you can have are Left Justification and Justified Align. Here are their examples:

The left justification is also called the "Ragged Right" because the right end of each line doesn't align with the line above and under it. Put simply the right margin (where the lines end) is ragged. On the other hand if you look at the justified text example above the left and the right margins are perfect aligned. In documents or paragraphs that are justified aligned each line begins and ends at the exact same spot on the horizontal axis.

Designers dig justification because justification makes your articles look professional. Justification has had an aesthetic appeal to it and has been used in professional newspapers and magazines for years.

This is stuff you probably already know.

The process of justification looks fairly simple on the surface of it but if you scratch the surface and move a little deeper there are quiet a few moving parts which give it the sex appeal it has in the publishing world. Justification mostly  plays with spacing between words and between characters to align both margins.

You could spend hours studying Wikipedia links on the topic to see how it works or we can just do a quick typography 101 course right here to cover the basic concepts we need to move forward.

I am going to assume that you're a lazy dude who wants too be spoon fed in simple English so instead of linking to ten lengthy Wikipedia articles on typography we're going to do a quick Typography 101 digression right here and talk about the basic stuff that you need to know about typography in the context of text alignment. Then we will start talking about the intricacies of text justification. So; on to a quick typography 101 course.

Digital Typography 101 and the Stuff You Need To Understand Before Moving Ahead.

The world of digital typography primarily contains two kinds of fonts. Mono-space fonts and Proportional fonts. The Wikipedia article on the topic is here but the basic premise, in the context of justification, is that mono-spaced fonts give the same amount of space to each character in the font where else proportional fonts give each character in the font just the space it needs and no more. Here's a picture from Wikipedia that explains the concept:

See how the pink and blue boxes (which represent space each character takes) are of the same size in case of Mono-spaced character but their sizes vary in case of proportional characters? That's the basic difference between these two font types. Now a days, unless you're coding on your IDE or using the terminal window chances are that you are using proportional fonts because they just tend to look sexier than mono-space fonts and everyone seems to be moving over to proportional fonts. Proportional fonts and Mono-space fonts are the first piece of the puzzle that you need to understand in order to appreciate how the justification process truly works. Serif fonts and Sans Serif fonts are the other piece so let's talk about those.

The world of digital typography also has two basic kinds of fonts that you need to know about. The serifs and the sans serifs. Serifs are tiny strokes that you give to the loose ends of each letter to make them look sexier.

As you can see from the picture that I borrowed from Wikipedia, Serif fonts have these strokes which are shown in Red, Sans Serifs do not have these strokes. An easy way to remember this is the fact that "Sans" in French means "without" so Sans Serifs practically means without the serifs or without those sexy strokes at the end of each letter.

Back To Justification

Ok, so it's time to end that long typography 101 digression and get back to justification. Now that you are a little smarter and you know what monospaced and proportional fonts are and what Serifs are and what Sans Serif fonts are lets go deeper into some of the tricks that are used to increase the spacing between words and characters to get evenly aligned margins in justified documents.

Tracking And Kerning Algorithms

In justified text the application that gives you the justification feature needs to align the left and the right margins. In order to do that in some cases the application needs to increase the space between words and characters of a line to make the lines look broader than they already are and in some cases it needs to squeeze the spaces between the words and the characters to make the lines narrower than what they would be otherwise. The lines which are stretched to occupy more space than they would normally occupy are called loose lines and the lines which are squeezed to occupy less space than they would normally occupy are called tight lines.

Two techniques that the justification process uses heavily to create these loose lines and tight lines in order to align the margins are Tracking and Kerning. Tracking involves adding even volume of space between each character of a word to create a loose word or to create a loose line. Because Tracking only involves adding equal space between words it works on both Mono-spaced and Proportional fonts.

Kerning on the other hand increases and decreases space between proportional fonts based on multiple factors. This picture (again, from Wikipedia) illustrates the difference between Kerning and Tracking.

Kerning works on proportional fonts and it also uses a host of factors like whether a font has Serifs or not to bring the fonts closer to each other. Here's another picture from Wikipedia that explains this concept:

Notice how the serif's are brought over each other to decrease the spacing between two letters in the above picture. Of course you cannot have kerning on mono-spaced fonts because each charter has a fixed space it occupies. You can increase the space between words by adding extra empty characters (i.e. tracking) but with mono spaced you cannot do things like move a character juuuust a little bit to the left to align it's serif with it's previous fonts. Because mono spaced fonts give exactly the equal amount of space to each character funky arrangements of letters like that to make the overall output look sexier is just not allowed. That's why kerning only works on proportional fonts.

You can read the entire article on kerning but the point in this context, is that most browsers and word processors use their auto kerning algorithms to increase or reduce spaces between proportional fonts when you turn the justification of a paragraph to on. And justification in one word processor or browser may not be exactly same as justification in another word processor.

Ken Adams for example is a firm believer that the kerning algorithms of Microsoft Word suck and that you should never use justify align in Microsoft Word documents.

Long story short, the look of your justified text is going to be just as effective as the tracking and kerning algorithms of word processor, the browser or the reader where the user is going to read the content. That of course is the beginning of all the problems associated with justified text. Justification can create another problem which is often made worse by bad kerning and tracking implementations. The problem is spaces which align and stack right over each other. This problem is called "Rivers" by typographers.

Rivers

Another issue that digital Kerning and Tracking often produce is the problem of Rivers. When you increase space between all the words to align both sides of the margins the spaces in the middle of the words can often tend to align creating long stretches of white areas which make it difficult to read the entire paragraph. These white stretches are what are called Rivers in typography.

The above diagram shows some rivers in a word document with just a couple of paragraphs that I used earlier in the post to illustrate the difference between left aligned and justified aligned text. The rivers are marked in yellow. They get much worse when you are doing complex documents. Rivers makes reading documents and content that much harder especially for people with dyslexia. Rivers can be avoided by a typographic technique called Hyphenation.

Color And Hyphenators

The fundamental reason why most people are tempted to use the justification setting in their word processor when writing documents or in their CSS when blogging or writing HTML pages is because they have been seen books and magazines that have been justified. The tight look and the amazing visual appeal of justification in these books and magazines makes developers and budding designers believe that justification looks good just by it's inherent nature.

What people often forget is that most typographers who are responsible for publishing magazines and books don't just give attention to outline of the rectangle space which holds the content but they also pay a great deal of attention to the fonts and the evenness of space within the rectangle. In the world of typography this is called the color. Typographers go to great lengths to maintain the color of the document. One of the tricks they commonly use is referred to as Hyphenation. In fact H&J (Hyphenation and Justification) is the technique used while type setting most books and magazines.

In his excellent article on the topic of Justification and Hyphenation Richard Fink describes the process of hyphenation  using the example below:

Notice how the lines in the above paragraph could have been too tight or too loose to create rivers and how words have been broken up using hyphenation to avoid the problem.

Hyphenation is good when it is used in the print media but in most word processors and browsers hyphenation tends to have it's own set of problems. Most latest browsers out there support soft hyphenation. With soft hyphenation you give the browser a permission to insert a hyphen if the kerning, the size of the page, the content and the layout is going to result in lines which are too loose or too tight. Put simply, the browse has the permission to break a word with hyphens if the situation demands that the hyphenation be inserted.

The way to hard code this is using "­" HTML tag or using "&#173" HTML tag in the right place. So if you wanted to allow the browser to break the word "equal" after "e" you would write it as "e&#173qual".

Of course anticipating and hard coding every word for hyphenation is not the most practical of solutions so folks have been coming out word press plug-ins and Java-Script libraries for auto inserting the hyphens.

When you automatically insert hyphens to align your margins and to maintain high typographic color in the page you start running into issues pertaining to copy / paste. The hyphens (even soft ones) have their Unicode characters and when you copy content from a website that uses auto hyphenation script chances are that you might end up copying the hyphens along with the content. Similarly when you are searching for words which have been auto hyphenated you are left on your browser's ability to understand the soft hyphens and ignore them during the searches.

Richard's article on the topic is an excellent resource on Hyphenators and the hyphenation tools and scripts that are out there. If you haven't clicked the link already, you should. Once there spend some time there understanding hyphenation.

Richard highlights some of the annoyances with hyphenators and ends his article on an optimistic note:

The solutions to these annoyances lie squarely with browser makers. High-res displays like the iPhone Retina, convenient e-reading devices like the iPad, and web fonts have brought a new focus on web typography. Hyphenation and justification is an important and time honored technique. Hopefully the information here will help make it an option for onscreen reading sooner, rather than later.

These tragic reality of life right now is that that even though H&J (Hyphenate and Justify) is a time tested technique in the publishing world, most devices and browsers are yet to fully catch up with seamless automatic hyphenation support.

The basic esthetic appeal of justification attracts many designers and web content writers to it, but given the current set of problems is the esthetic aspect of justification even worth chasing? This question was answers by a set of very interesting surveys.

How The Human Mind Perceives Justified Text

Based on most research that has been conducted so far, even though justified text does have esthetic value it is not the most reader friendly alignments out there. The British Journal of Visual Impairment (PDF link) (Accessibility assistance for visually-impaired people in digital texts) covers a list of surveys which provide more specifics:

Harrison was unconvinced that larger spaces between letters, words and lines increased legibility (Harrison, 1980, cited in Davies, 1989). However, according to Gaster and Clark (1995), increased leading, or white space between lines of type, makes a document more readable for people with low vision. According to Arditi (1999a), spacing between lines of text should be at least 25 to 30 per cent of the point size. This is because many people with partial sight have difficulty finding the beginning of the next line while reading.

Additionally, letters that are too close together are difficult for partially-sighted readers (Gaster and Clark, 1995), especially those with central visual field  defects. Spacing needs to be wide between both letters and words (Arditi, 1999a; Gaster and Clark, 1995). Harrison thought that the most important
factor for children’s books was the unjustified line (i.e. the printer has not varied the space between the words to produce a straight margin down the righthand side of the page) (Harrison, 1980, cited in Davies, 1989). Unjustified text may be easier for poorer readers to understand because the uneven eye movements created in justified text can interrupt reading (Muncer et al., 1986).

David R. Thompson, a PHD student at the University of Texas at Austin and the president of SENSS Publications and Seminars, Inc, conducted another survey with 40 undergraduate students where these students read 12 text samples from randomized reading tests. The tests involved different simulations of magazine pages in four column formats. One of the conditions in the survey was the comparison between flush left and ragged right justifications. David describes the results on his tests in his paper (PDF Link):

In a justified (even left and right margins) format, the eye "knows" through repetition, how far it must travel to perceive a line of print. Thus, the justified format may minimize pauses in eye motion following backward eye movements, regressions, within a line of print (Bayle, 1942; Rayner & Pollatsek, 1989). This suggests that the longer the look, the longer the processing time (McConkie 1989).

By extension, flush left / ragged right margins may force the reader to process each line's end point and re-evaluate the distance of each sweep (Rayner & Pollatsek, 1989). These assessment strategies may require "extra" time to process information presented with flush left / ragged right margins (Glass & Holyoak, 1986).

The Graphic elements Model predicts that an increase in the amount of mental effort required for visual and spatial analysis of textual cues will result in enhanced memory for information derived from that input.

This by all means is an interesting result. Even if you were able to avoid all the inherent problems of justification, like issues with kerning algorithms and the river effect, justification might give faster reading speed on text but then you might end up with lower recall of the content. Put very simply your readers might be able to glance through your content very quickly but they might end up remembering less of your content than they would if it had a ragged right margin.

The "Improving Validity of Large-scale Tests: Universal Design and Student Performance" report by National Center on Educational Outcomes sums some of the above and a whole lot of other researches that have been done in this area. The observations are simple:

Staggered right margins are easier to see and scan than uniform or block style right justified margins (Arditi, 1999; Grise et al., 1982; Menlove & Hammond, 1998).

Justified text is more difficult to read than unjustified text – especially for poor readers (Gregory & Poulton, 1970; Zachrisson, 1965).

Justified text is also more disruptive for good readers (Muncer, Gorman, Gorman, & Bibel, 1986).

A flush left/ragged right margin is the most effective format for text memory. (Thompson, 1991).

Unjustified text may be easier for poorer readers to understand because the uneven eye movements created in justified text can interrupt reading (Gregory & Poulton, 1970; Hartley, 1985; Muncer, Gorman, Gorman, & Bibel, 1986; Schriver, 1997).

Justified lines require the distances between words to be varied. In very narrow columns, not only are there extra wide spaces between words, but also between letters within the words (Gregory & Poulton, 1970).

With all it's inherent complexities and problems both technical and comprehensive; text that is justified aligned continues to be something most digital publishers are so attached to that they cannot let go. People who love justified text are all around us. If I can honestly confess here, I am one of them. Which is why this blog was justified aligned for years. There is something to be said about the beauty of justified text and the science of it.

Having said that once you understand the problems and realities associated with content that is digitally justified using HTML and word processors; and the impact it has on readability and recall of your content, given the choice between ragged right and justified text, chances are that you would lean towards a simple ragged right alignment.

Stating that you should never use justified text might be an overkill but before you do use justification, understand how justification works, understand the problems associated with it and use it wisely. Of course, the folks who are justification zealots would tell you that if it's not justified it just doesn't look right, but as of now, if it's on the web and if it's justified, it probably just doesn't read right.

And it's not about how you do justification. It's about how justification works, the issues that surround it and the state of current technologies built to handle it. As of this writing, in most cases today, as far as online content is concerned, justification seems to be esthetic value in lieu of easy readability. Of course justification gives your text a professional looks but this is the online world, and if it is professional you should probably be working on changing it anyways.

Blogs are cool. Blogs can be awesome. Blogs allow you to participate in this amazing thing we otherwise refer to as the internet. The content from Blogs feeds Google, keeps it alive and helps it grow.

From a personal aspect; blogs are important because blogs allow you to continue jabbing and help you hone your writing talents; and we all know how important writing talents are; even if no-one reads what you write.

Seek blogging advice from anyone who has blogged for more than ten posts and the advice you’re going to get is: pick a schedule and live by that schedule.

It is the single best advice anyone can give a young and budding blogger.

It works; till the time it doesn’t work and then you need to tweak it.

Think about this advice in terms of plain old mathematics. It’s like this; you become a better writer by reading more and writing more and given that you are reading as much as the other person; if you are cranking out four articles a week your chances of getting better at the craft of writing are four times more than someone who cranks out one article a week. Right!?

Well, the statement is moooostly right.... for you.... if.... you are starting out a blog or want to get into the flow of writing consistently. A regular stream of blog posts on a well-established schedule gets you in the flow for writing.

Besides it makes life simple for the Google crawler and your readers because they know exactly how much content to expect from your blog and when to expect it.

It forces you to show up even on the most depressing of days.

Like I said, the advice of writing regular blog post works.

At-least till the time it works.

And then comes a point of time in your life when the advice stops working and you need to tweak your schedule.

Here are some reasons why you might end up tweaking your publishing schedule:

1. You’ve done enough jabbing for a couple of years and now you want to move into deliberate practice of writing by producing articles, books or relatively longer essays which will need your concentrated effort for a week, sometimes more than a week, sometimes a month and sometimes even multiple months before you can publish them out to the world. Posting four posts every week might not be possible here.
2. You’ve done enough writing about code and now you’re going to be writing even more awesome code or doing something life changing. A classic example of this being Jeff Atwood who is the primary proponent of the “one step success” for your blog which was blogging regularly. Jeff started Stack overflow (now called Stack exchange) and slowed down publishing posts on his own blog.

Like I said, the advice works and it has it's own benefits while it works.

Then you reach a point in your life when you realize that just jabbing is not taking you to the next level in practicing your craft. You realize that just doing a given number of posts a week isn't enough deliberate practice of your craft.

When you have that realization it is time for you to slow down and focus on what is most important to you.

I’ve been blogging about three posts a week for months now. I've been contemplating the idea of longer articles on topics I feel strongly about, working on the book I said I would be working on, trying out some serious humor and doing some serious bullshit busting.

With those intentions in mind I am going to relax my publishing schedule down from three posts a week to sometimes two and sometimes even just one post a week.  On any given day the writing I do is probably going to increase. The frequency of publishing however might slow down a little in the weeks to come.

What that means that while the quantity of the posts might go down the quality of the posts that you see here might shoot up.

These posts will be edited much more meticulously. Some of them might be long enough to warrant turning them in articles that you can download in PDF or Kindle formats. You might also continue to get a full blown eBook or Kindle book every few months.

In the fitness world they say that nobody ever gets stronger by doing the same exercise again and again.

In the world of neuroscience they say that nobody gets smarter by solving the same kind of math problems again and again.

Continuously publishing three posts a week was a commitment I made to myself for months and it was a commitment that taught me a lot of things. It has now become a part of my life.

Having said that however, I feel I have grown out of and it is now time to master other aspects of writing. Even if that means reducing the number of posts I publish every week.

Long story short, the blogging frequency of this blog ‘might’ go down from three posts a week to two and sometimes even one a week. But I will hopefully continue to show up without fail. Every week! Consistently. And with lesser number of posts and more effort the content is expected to get better.

Expect to see posts with more content, more research, more fun and more takeaways. Expect to see PDF or Kindle versions of articles and occasionally also expect to see some eBooks once or twice each year.

Now, if you are a young and budding blogger seeking advice on how you can become a better blogger, here’s my advice:

1. Pick a schedule that you are comfortable with and stick to it!
2. And Do NOT change your schedule frequently.

More often than not any temptation to change the schedule is out of hidden laziness and your lizard brain playing tricks with you so be very careful before you decide to change yours. And when you do reduce your frequency; make sure you double your efforts.

That by the way is EXACTLY what I intend on doing on this blog; so do keep reading.

There is something to be said about saying something you believe in without feeling the need to defend it or argue for it. Controversial arguments are generally very interesting and hardly ever productive.

Most online flame wars (through email, facebook comments, twitter comments, blog comments etc.) work on the premise that person posting the last response wins. In most online flame wars, your decision of not replying is often considered synonymous to your not having a reply.

The online heckler often expects you to shout back to quiet him down. Once you do that, you have started a controversial argument and it doesn’t matter what the logical outcome of the controversial argument is, the heckler wins.

All a heckler needs is a lot of free time and the persistence to keep replying.

You cannot win this game if you play it by it's conventional premise.

But you have an option of not playing the game to begin with; or taking a decision of not replying even when you have a reply; or quitting the arguments in the middle even when you’re not the person with the last response.

Just say what you truly believe in. If that triggers an argument; make your points. Once you’ve made your points (or voluntarily chosen not to make them) leave the topic and the argument. Say something else. A brand new post. A brand new thought. A brand new idea.

The hecklers can continue heckling about what you said. They will eventually get tired and stop when they realize that you’ve already moved on to something else. After all, In the long run the hecklers and the critics just don’t matter as much as you think they do.

Hiring young and budding teams that can kick some serious ass has always been one of my life long passions; something I consider much more important than any process out there.

If you don't screen and pick people like the life of  your organization depends on it, you won't have an organization soon.

Jarka on the Project Management site of stack exchange has a question on "The most effective attractors and motivators for young highly skilled people".

My answer there pretty much condenses a lot of what I have talked about on this blog as far as hiring is concerned, in eight simple bullet points.

You can read the answer here.

If you are a young and budding entrepreneur or a budding manager these eight points should give you a head start at hiring and building teams that can kick some serious ass.

Here's wishing you good luck with attracting and motivating teams that kick some serious ass.

Every airline is like the other. Same ticketing, same announcements, similar good looking cheesy air hostesses and stewards who are busy smiling and getting you stuff you ultimately end up paying for.

The aviation industry is also the only industry that has your complete attention when you are flying.

Why not make most of that attention?

Why not build systems that allow people in the same plane to connect to each other?

Why not allow them to play video games on a network? You know who you are playing with by their seat numbers.

Why not have a separate channel with a live stream of the cockpit with someone from the crew providing explanations on the basics of what the pilots are doing which you can listen to on your head phones?

Why not have an on plane chat room where you can connect to crew members and passengers?

Why not let your cabin crew engage with customers, talk to them and collect first hand feedback about what they liked and disliked?

They say that you meet some of the most interesting people when you fly. 

Most airlines go out of their way to avoid that.

Procedures? Security? Safety? Cost? None of the ideas I talked about are expensive. None of these pose any threats.

Except of course a threat to the convention of what airlines companies are supposed to do: which is to take you from one place to another and treat you like very expensive and fragile cargo.

And that is exactly why most flights are boring; even for someone like me who enjoys flying.

The world of software development today is very different than what it was when we started programming. Back in those days if you asked a question like this one the so called Java experts would grill you, nail you and crucify you publicly on the forum. Those were the days of the purist.

Then; Microsoft happened.

Languages like GW Basic allowed the existence of the hobbyist programmers who would then move on to more serious languages like C / C++ master those and move on to MFC or Win32 API on VC++.

That; or these programmers would pick simpler and much more productive languages like Visual Basic.

Both paths that would later converge to a .NET language which would hugely just be a matter of preference, C# or Visual Basic.NET. Back then however most purist found it inconvincible that any business worth their salt would run a Microsoft Stack on their production servers. 

The purist of course; were wrong.

When you're a geek grinning at how stupid Visual Basic is or passing comments like "Oh but Ruby on Rails doesn't scale!" or when you are busy reminding someone on a forum how stupid his question was, what you often forget is that the survival and the success of languages (both human and programming) depends on the adaption they receive. It is eventually the community behind a language that builds or breaks a language. Something that a huge part of the Java community completely missed out on in the old days.

The Java community and the other communities of purists decided to keep the bar of entry high and look down on all who were not born with an out-of-the-box IQ that met their standards of intelligence.

The hobbyist programmers in those days were pretty much expected to forego their self respects and keep getting booted from forum to forum before they found the answers to the simplest of questions that someone could have helped them in ten minutes or they were expected to move to a simpler language with a vibrant community of similar hobbyist programmers where no question was stupid.

Back in those languages like Visual Basic which were easy to learn, easy to pick up, fun to work on and fairly productive created a whole community of hobbyist programmers who were smart, passionate about their art and were willing to go that extra mile to build successful applications. Yes these languages may have been responsible for creating programmers who cannot program but they also created passionate communities of programmers who would make big and small dents in the world of software development. What these programmers lacked in talent they made up in intensity.

Needless to say that these programmers and communities reciprocated back. As of now, the Microsoft developer communities are by far the richest, strongest, loudest and most fun loving communities out there.

Languages that evolve survive. While the purists were busy grinning about the fact that Microsoft was copying ideas from Java, the java language, which was hardly changing in years except for introduction of new API's in their JDK (there were hardly any changes to the core of the language itself), was running out of ideas to copy from. Microsoft of course was moving over to languages like Ruby to introduce ideas like Closures and Lambda expression right into the core of their own languages.

The idea was simple: keep your languages simple and do everything you could for your developer communities and to make their lives productive. In the process, if the purist shouted, bitched and whined, so be it.

This is not a Java Vs. C# blog post and I have no intentions of starting a never ending discussion controlled by Zealotry here but if you are a programmer one important lesson to take away from this rift is that you have a responsibility towards the language of choice that you use to make a living. Remember, the success (or even the existence) of the language you use in the long run depends on the community of programmers that program in it. And you are a part of that community. So go on and talk passionately about the language of your choice; make you tube videos on new features; blog about new tools around your development platform.

Stop being the anal purist who has no respect for starters. Stop giving us that stupid grins about how Linux is more reliable than windows; how Java is faster than C#; or how J2EE scales better than RoR because thanks to the ignorance and the arrogance of the purists, none of those statements are remotely true in most real life scenarios anymore.

The purists are dead. Long live the purists. Just don't end up being one of them.

Move over to a pragmatic side, try your level best to learn and respect all languages and when you see someone trying hard but asking questions which seem way too simple or even slightly stupid to you, treat the person with empathy.

That would be the biggest favor you as a developer would be extending to your developer community and the platform that you work on. The days of the technology purist are over so try practicing a little bit of humility the next time you are in a forum answering questions.

Kole McRae of Office Buddha, talks about getting rid of 15 blogs that he owned:

Four months ago, I had 15 blogs. I had blogs about net neutrality, writing tips, technology news, and more. They were all things I was passionate about and loved writing them but one day I deleted them all.

All but one.

I didn’t back them up. I didn’t think twice about it. I simply clicked Delete and never thought about them again. Each one had an audience. Some of them even brought in a little money. But none of that mattered.

That day I discovered a simple truth about myself—a truth that expands to absolutely everyone. The idea was simple, which is kind of the beauty of it.

The idea that Kole is talking about works on these basic premises:

1. The less you spread yourself the better you work - you have less time for each additional task that you take up, so focus on one thing and do it well. Dedication to a single cause is often better than many.
2. Do one thing at a time - work on only one thing at a time and focus all your energies on that single thing. Once it meets your definition of complete move on to trying other things if you must. But keep the number of projects running on any given time to the lowest number possible.

Of course, the idea isn't just limited to your blogs or your side projects. Most young startups and mid-sized companies make this mistake. Go on and take a look at how many open projects your organization has right now.  Are you truly developing a Niche as an organization or jumping from one branch to another like a drunk monkey? More often than not, doing one thing and doing it really well will not kill you or your organization. The psychic weight of trying to do too many things at once and the desire to multitask both as an individual and an organization will.

How many products or projects do you have running in your organization? How many initiatives do you have running in your personal life? Maybe it's time to get rid of some of them and focus on the ones you really love working on. Deleting something, dropping something, stopping something or even putting something you started, on an indefinite hold is a really hard thing to do. It involves closing doors; something which we as human beings are not hardwired to do. But then, it's your only shot at being really good at something.

Go on. Pick a few stale projects in your work life or a few initiatives in your personal life and shut them down. You'll feel better and chances are you'll end up being much more happier and much more productive in the long run. I wish you good luck.

Al Pacino's Inspirational Speech from Any Given Sunday about the game of football and the game of life, is a life changer.

You know when you get old in life things get taken from you. That's, that's part of life. But, you only learn that when you start losing stuff. You find out that life is just a game of inches.

So is football. Because in either game life or football the margin for error is so small. I mean one half step too late or to early you don't quite make it. One half second too slow or too fast and you don't quite catch it.

The inches we need are everywhere around us.

They are in ever break of the game every minute, every second.

On this team, we fight for that inch On this team, we tear ourselves, and everyone around us to pieces for that inch. We CLAW with our finger nails for that inch. Cause we know when we add up all those inches that's going to make the FUCKING difference between WINNING and LOSING between LIVING and DYING.

I'll tell you this in any fight it is the guy who is willing to die  who is going to win that inch. And I know if I am going to have any life anymore it is because, I am still willing to fight, and die for that inch because that is what LIVING is. The six inches in front of your face.

Joel's take on building commercial software in similar:

Commercial software—the kind you sell to other people—is a game of inches.

Every day you make a tiny bit of progress. You make one thing just a smidgen better. You make the alarm clock default to 7:00am instead of 12:00 midnight. A tiny improvement that will barely benefit anyone. One inch.

There are thousands and tens of thousands of these tiny things.

It takes a mindset of constant criticism to find them. You have to reshape your mind until you're finding fault with everything. Your significant others go nuts. Your family wants to kill you. When you're walking to work and you see a driver do something stupid, it takes all your willpower to resist going up to the driver and explaining to him why he nearly killed that poor child in the wheelchair.

And as you fix more and more of these little details, as you polish and shape and shine and craft the little corners of your product, something magical happens. The inches add up to feet, the feet add up to yards, and the yards add up to miles. And you ship a truly great product. The kind of product that feels great, that works intuitively, that blows people away.

Michael Lopp calls writing a game of inches too:

Writing is a game of inches. No author I know sits down every morning in their home office and steadily produces three pages a day. I’m sure they’re out there, but these annoyingly efficient and profitable authors aren’t doing this on the side. They’re doing this because they’ve written enough to make it a career.

While the idea of writing books for a living is appealing, my impression is that if I stopped being a software engineering manager, my voice would quickly become an echo of how things used to be rather than how they are. Thanks, no.

You have time. In fact, you have lots of time. There will be weekends where all you will find is a paragraph. There will be a week where all of your progress will circle around finding precisely the right title for chapter 12.

In writing a book, you’re going to find all sorts of interesting ways to mentally beat yourself up. You’re going to consider new tools and different writing schedules. You’ll discover that inspiration can be encouraged, but never created. You’re going to find constructive ways to procrastinate and your friends are going to stop talking to you because all you talk about is that damned book.

You move an inch ahead when you decide to stop whining about how your job doesn't give you enough opportunities and you write just a few additional functions of code on your side project.

You move an inch ahead when you decide to skip that movie and write that blog post that you always wanted to write.

You move an inch ahead when you switch off the television and spend that one extra hour adding a couple of paragraphs to that book you are writing.

You move an inch ahead when you logout of online chat, facebook and twitter and read a book on how to get better at your craft.

You move an inch ahead when you decide to open the IDE and refractor just a little bit of code,  or open the word processor and edit a chapter of your book, on a depressing day where you thought you were not going to be able to do anything.

You move an inch when you reach out for a tiny tool that lets you practice your craft when you're in a meeting or in commute.

The inches are all around you and in the long run they are going to add up.

The hard question that you need to ask yourself is, have you given up to the television, the facebook, the twitter, and the countless excuses about your not making it or are you willing to work your ass off for those inches?

Just a little something to think about.

Of all the MBA's I've worked with I respect a handful of them and find the rest of the majority hugely amusing. If you've ever sat there and wondered what it is that those business schools out there really do to suck empathy and common sense out of people, you are in good company.

David Heinemeier Hansson at 37ignals and the writer of RoR goes expresses his thoughts on MBA students gives wise advice to young and budding MBA students at Stanford:

Before you can even get started I think the most important thing for you to realize is that you have to unlearn your MBA. And I am treating MBA here as a sort of a general grab bag for business school management theories. I spent three years and Copenhagen business school and I would probably say that according to my estimations 96.7 percent of the time was completely wasted. It has NOTHING to do with what I actually do today and it has NO impact on what I actually work with everyday.

In fact, I came out slightly damaged. I came out with a head that had been soaking in management theory for three years and it was actually a little off. It was not very well suited for the real world of just building a product, pleasing customers and making profits as a business because that's really not what you learn and you have to just sort of readjust and recalibrate when you come out of school to that reality.

Nobody cares about a 20 page report on five forces. It just doesn't matter. There is none of your customers that's going to think, "Oh well did you do your five forces for this setup? No? Alright then we're not going to buy your product. So all of these tools that you've learnt are only for you. They are not going to impress anybody else when you start your own business. And what you learn is, when you are starting your own business.... and all businesses start small.... is that none of it is relevant.

The context of the talk resolves around fundamental flaw of business schools which are all about teaching students everything that is big and clunky. Big words, big reports and big documents, big plans, big clients, big projects, big teams.

When these students end up starting a business which has to start small or joining a small yet innovative organization they invariably find themselves fumble and going round and round in circles too proud to admit that they are fumbling.

David's advice is sound: before you start your own business, do yourself a favor and unlearn your MBA.

But then the real question you have to ask yourself is, do you see yourself running a small yet effective organization that makes a dent in the universe or do you see yourself working for the big blue?

If your answer is the former and if years of business school management theories often make you delusional and dysfunctional when it comes to running a small kickass profitable organization, why enroll to begin with?

Just a little something to think about.

Software development is all about glamour. The smiling faces of Bill Gates and Steve Jobs bring countless programmers (both good and bad) to the field of software development. The same smiles of successful entrepreneurs have also inspired movies like the Social Network and Pirates of the Silicon Valley.

Every startup story that tells you how a young kid made a million dollars adds spice to the equation.

Glamour is a two sided sword because on one hand it motivates the competent and helps them continue practicing the craft of building software without quitting on the other hand it attracts programmers who cannot program to the software development world.

Any glamour based industry, Hollywood, Music Albums, Writing or Software development has an inherent problem. In these Industry it is easy to overlook the amount of effort that goes behind a success story.

In each one of these industries it is easy to be charmed by smiling faces of startup CEOs, actors, authors, Entrepreneurs and not look at the pain, the hard work, the risk and the mental turmoil those faces went through.

"All we need is an idea! Let's look for a Venture Capitalist! Let's find an Angel Investor! Let's spend time on Twitter and facebook all day long!"

And then when things don't work out blame it all on bad luck, not having the first mover advantage, lack of the vision on the part of the investor or worse.... on your development team.

Perfect recipes for failure. All of them.

The stories of colossal fuckups aren't new in the software development world but we don't hear them as attentively as we watch movies like The Social Network or Pirates of the Silicon Valley.

Your only chance of survival. The only one you have, is that you realize how the quest for glamour, acceptance, attention and power destroys lives. Lower your expectations. Focus on doing something that you love doing and please stop worrying about the outcomes of large scale adaption and success.

Separate out the cash part from the sex part, find pleasure in practicing the art with cheap tools and stop dreaming about being the next Mark Zugerberg.

No you're not going to make the next facebook. No amount of bullshitting and power points presentations will help you become a millionaire. Yes they don't give a shit about you and your product and yes, you are going to be the only user on your product, service, tool or blog for a very long time.

The sooner you realize that and the sooner you drop your expectations, open the IDE and start working on something you love the happier you will be.

I'm sorry I am breaking your cute little dreams, but I hope you realize that shattering them into tiny bits is your only chance at materializing them.

Here is wishing you good luck.

Windows live writer is a classic example of an awesome software hidden inside bad packaging that yells "influenced by marketing weasels" in every screen of its website and installer.

I relate to stories and in this case I am assuming the story runs like this:

1. Someone at Microsoft has an idea about building an offline blog writer with preview feature.
2. Microsoft manages to get a team of amazingly talented designers and developers who start working on the product.
3. This team ships the first version of their product and gets a lot of appreciation from their user base.
4. The marketing weasels at Microsoft wake up and decide to take charge so they ask the team to "tweak" the installer slightly.

As of this writing, the installer of live writer is bundled with a zillion other crappy pieces of software that you are never going to use. More than half the time the installer executable posted on the site is broken and getting live writer installed (especially if you have a bad internet connection) is a nightmare.

Enter Zoundry Raven.

Zoundry Raven is free, open source and has a feature which has been a primary selling point of windows live writer for all these months.

After you've gone through a basic wizard and have configured your blog account, you can ask this application to download your blog template which it can then use to give you a preview option which in turn allows you to see how your post will look after it is published without having to actually publish the post.

Zoundry Raven is not totally clean either and has some minor annoyances. For example:

1. You have to manually turn on spelling checks when you start using the software. This is just a one time annoyance which makes sense since it needs to download the dictionary for your language. But then why don't the Zoundry guys just ship the English dictionary with the installer? That one beats the heck out of me.
2. You have to click the spell check button once after you are done writing each post since there is no auto spell check like Live writer or word, but once you get used to the habit of doing clicking the spell check button once before you post is not as bad as it sounds when you hear it for the first time.
3. You have to go into tools / preferences / affiliate links and turn the "Don't mess with my links" option to stop Zoundry guys from changing your amazon links to use their referral id and earn money from those links. A slightly shady way to make money I would think, primary because the installer did not seem to ask me if I want Zoundry Raven to change my link. A quick advice to the Zoundry guys: Either ask me upfront or turn off this feature by default.
4. Zoundry Raven has a slightly longer startup time compared to live writer but given the fact that you are not going to be opening it up as frequently as notepad the slightly longer startup time does not have a major impact on your decisions to use this nice little application.

On the plus side, Zoundry Raven has the option of running as a portable application and carrying your profile (along with your posts) on a portable drive or moving them from one machine to another is rather easy.

Put simply, Zoundry Raven is a decently good alternative to Windows Live Writers (and a particularly easy option to get away from Live Writers slimy installer).

For me windows live writer is a classic example of how an amazing product team and an amazing product can loose adaption just by letting the marketing weasels control even a small aspect of the product (in this case the installation wizard). The strategy of bundling some of your lousiest products with some of your best products and hoping that your customers will start using the lousy ones because they need the good ones desperately almost never works in a free world. The people who claim that this approach worked for windows and internet explorer often forget that the internet explorer and windows bundle worked because both of these were amazing products and they complemented each other. Put simply, bundling lousy products with good ones don't help in adaption of your lousy products.

The best that these marketing gimmicks do is take away your existing users and your credibility as a company.

How many marketing weasels exist in your organization? How much power have you given them? Just a little something to think about. If you don't think about it, your competition will.

This post is written using Zoundry Raven and I am liking it.

I will continue to switch between Live writer and Zoundry Raven. As of now, I like what I see as far as Zoundry Raven is concerned.

Assuming that you are like most people what do you think are the things that you will find most frustrating when you sit down to reflect about your life on your death bed.

I know the thought is slightly morbid, but humor me. Go on. Think about it.

What are you going to be sorry or sad or angry or depressed about when you are on your death bed?

No, it's not going to be your failures.

If you are a decently good human being, it's probably not going to be all the things you did.

Chances are, that you are going to be the most angry about the things that you wanted to do but did *not* do.

That opportunity to implement an idea that you chickened out of.

That opportunity to make friends that you missed out on.

That opportunity to make a difference in your life and the life of your loved ones that you did not work on.

That friend you did not make, that terrain you did not trek, that mountain you did not climb, that business you did not start....

All because you were too scared of playing hard and failing.

Of course you have limited resources, limited time, limited opportunities, limited talent, limited courage but if you can build a life where you can truly say you genuinely tried your level best, you will not just die happily but actually live happily and be much more effective as a person than you currently are.

Of course you might have a larger list of failures, but you will have no "could haves", "would haves", "should haves" in your life.

So the question to ask yourself every night is, did you give that personal or professional opportunity your level best? The answer has to be deeply honest.

And if the answer is yes, you are going to have a good nights sleep.... even if you failed.

At least, it will be one less thing to worry about when you are alive and one less thing to whine about when you are dying.

This less than eight minute video from Jason Garfield has everything you need to learn juggling with three balls. It has:

1. Education.
2. Information.
3. Humor.
4. Inspiration.

Go look at the video. Click the link and go through it before you continue reading. I'll wait. Honest.

Back? Now of each one of you that saw the video we are going to have two groups of people, the ones who learn how to juggle three balls in the next one month and the ones who watch the video (maybe even try once), realize how hard juggling is and then get on with their life.

Juggling, pretty much like cycling, roller skating, ice skating, dancing, clicking good pictures or any hobby involving a serious skill for that matter has one attribute. It is incredibly frustrating when you start with it so it's easy to quit and find something simpler to do.

But if you keep working hard, it slowly becomes.... fun. 

The process of picking up hobbies of this sort has a name. It's called playing hard.

People who play hard at fun often play hard at work.

Besides, if you aren't playing hard, are you even playing? Or hiding from failures and spending your leisure time sheltering your fears and doing things which are safe and boring?

Are you just responding to friends on facebook or surfing channels on television aimlessly? Or are you playing hard and having rich meaningful fun? Just a little something to think about.

The best of managers often manage by building self sustaining teams.

The best of managers often manage by building self sustaining cultures which attract the best of the best and repel the whiners away.

The best of managers often manage by weaving stories which are true and remarkable and which spread within the corridors of the organization and nudge people to do the remarkable.

If there is one thing that is common in the best of the managers it is that their management styles are all about.... managing by not managing.

How do you manage your team, organization, project or product?

Just a little something to think about.

Choosing Between Nothingness or Attempting To Change Lives.

"Nothing" is just about the riskiest thing you can do today.

Lack of resources or opportunities is not the biggest of your problems. Your personal fears are.

Everyone knows this. But most of us spend most of our time doing nothing and being afraid.

There is a funny sitcom you bump into while aimlessly surfing channels. That's nothingness.

A funny discussion on facebook. That's nothingness.

Tweeting about where you ate yesterday and how you hang out with friends. Nothingness.

A long phone conversation on politics with a friend. Some more of serious nothingness.

Why don't you drop nothingness and work on something meaningful that has a "potential" of changing lives? Maybe you do not do that because:

1. Your lizard brain is afraid of failing?
2. Your lizard brain is afraid of succeeding and things around you changing too rapidly?
3. You are just way too comfortable doing nothing and your lizard brain doesn't want to give up that comfort?
4. Nothingness gives you a temporary high and your fears allow you to feel sorry about yourself?

Failing, being made fun of, being doubted, being questioned, being criticized and being called a looser are all better than letting your fears get the best of you, hiding behind discussions, meaningless conversations on facebook and doing.... nothing.

Is facebook, television, conversations and endless arguments a back door for your fears or a hiding place for your lizard brain?

Be honest to yourself when you answer that question and if the answer is yes, try to drop these and work on something meaningful.

Next weekend you're going to have a choice between doing something meaningful and  aimlessly surfing your television.

Which one are you going to pick?

Just a little something to think about.

A Configuration For Getting In The Flow.

Is there a set of songs that you love listing to when you are coding?

Is there a particular corner of your home that triggers ideas when you sit down to write in that corner?

Is there a setting or a set of configurations in your life where all your depressions, anxieties, questions and fears are put aside?

A setting where you can focus on practicing your art?

If you answered no, why are you not working on creating these settings? Picking a soft song and listening to it every time you are distracted while coding. Picking a tiny corner of your home and moving there every time you want to write. Picking a small weapon and switching back to it every time you are unable to focus.

If you answered yes, what are you doing to increase the recurrence of these settings in your life.

After all, productivity often brings happiness. Why not work on building settings and configurations in your life that make you productive especially when you are distracted, depressed, scared or confused?

Just a little something to think about.

What's Your Contingency Plan?

Just a little something to think about from the trenches on the Cricket World Cup 2011 that India Just won.

What's your plan for the day when your star performer is unable to perform (falls sick, is not in the form, if going through a bad time or for any other reason)?

Build contingency into your project plans? Include buffer time into your project plans? Consider everyone a resource and do generic planning? Start Feeling insecure of your own team? Look for another hero?

That's what most managers and captains do.

Genuine managers and captains know that none of this is not contingency planning.

Having a team where every individual in your team can and often does morph into a star performer is usually your only human contingency plan.

If you don't have that all the other contingency that you provide for is just random documentation and a truck load of bullshit.

You know what a stale product is, right? We've all worked on them. Every product company has a portfolio of products where some products click and some gather dust on a beta build waiting for the first set of users to show up.

Even Microsoft had the classic Microsoft Bob. There is nothing wrong with having stale products started within your organization. Ideas have to be implemented before you can test their validity.

Having said that, your ability to identify a stale product early on, defines your awesomeness as an organization or a software development team.

Here are some rather simple guidelines which might help you figure out if the product you are working on a stale product or it needs more effort.

You know you are working on or dealing with a stale product when:

1. None of the best people in your organization want to work on the product.
2. When every potential client you show the product to says, "looks good" but doesn't sign up or really use the product everyday.
3. When more than two really capable marketing guys who have sold other products in the past are unable get any customers for the product.
4. When you have been working on a problem without any real user feedback for more than a couple of years.
5. When you try eating your own dog food but other departments within your own organization find the dog food too yucky to eat or too hard to digest.
6. When you find the team building more and more features in the product to impress the management or the marketing department instead of building features your customers will genuinely need.
7. When you see managers discussing technology instead of what the product should do. "Search is going to be hot. Let's see if we can integrate lucent with this product".
8. When you find your business analyst building fictional requirements based on common sense mixed with their fetish. "Let's integrate the advertising module with the time and expense module to keep a track of the time spent on advertising. Yeah! That's going to be so fu@#king cool! I bet no one out there has anything like that! That's what we should do in the next version."
9. When your development team moves to auto pilot or hibernation and stops asking why they are building the features they are building.
10. When the marketing department starts telling the development team that adding this one User Interface enhancement before next week will help them land their first customer. i.e. When you are continuously doing Demo Driven Development Cycles.
11. When one quick sniff at the product tells you that it is rotting and stinking beyond repair and everyone is just busy ignoring the problems instead of getting down in the sewages and cleaning up the mess.

Anytime you start seeing more than half of the above in a single product, you are probably working on a stale product. You are better off quitting or surrendering. Quitting is not such a bad thing after all.

How do you spot dead projects in your organization?

How do you convince your management to move these projects to the graveyard?

Just a little something to think about and discuss.

Random Thoughts On Policies:

Someone 's downloading movies.... lets block the internet!

Someone 's coming in late and leaving early.... lets punch timecards!

Someone 's taking a CAB instead of a subway.... let's do a travel policy document!

Someone 's wearing T-Shirts instead of ties.... a policy on dress code!

The folks at 37 Signals have this to say about policies in their book Rework:

Don't scar on the first cut. The second something goes wrong, the natural tendency is to create a policy. "Someone's wearing shorts!? We need a dress code!" No, you don't. You just need to tell John not to wear shorts again. Policies are organizational scar tissue. They are codified overreactions to situations that are unlikely to happen again. They are collective punishment for the misdeeds of an individual. This is how bureaucracies are born. No one sets out to create a bureaucracy. They sneak up on companies slowly. They are created one policy--one scar--at a time. So don't scar on the first cut. Don't create a policy because one person did something wrong once. Policies are only meant for situations that come up over and over again.

The classic story of most policies is the same:

1. Someone does something stupid.
2. The organization over reacts and writes an equally stupid policy.

It's a classic two way street for turning intrinsic motivation into hard core ruthless professionalism.

It's like paying your mother in law for a gorgeous dinner and a surprise party she planned for you.

Between steps one and two are all other innocent clueless employees wondering what the f@#ck just happened and scrambling for information.

Every time you find yourself making a policy, your management and  recruitment teams have failed pathetically and hired a bunch of moronic sheep who need herding instead of hiring engineers.

That or your organization just doesn't know how to talk to people and communicate problems openly, candidly and act strongly in certain situations.

Either ways, it's a problem that no policy can solve in long run.

Most of your policies aren't going to fix anything. They're two way streets for stupidities involving a couple of stupid employees and equally stupid organizational reactions.

Replace every single rule or policy in your organization with an intrinsic social norm which appeals to the goodness of your people and you'll have an organization that changes the world.  And if you can't appeal to their goodness, why are they still working in your organization?

Just a little something to think about.

A fat obese middle aged American guy munching on his packet of potato chips and commenting on that pass in the soccer match.

A skinny under weight Indian munching on his packet of lays and describing how the batsman should have played the shot in the cricket match.

Both would probably collapse on field if asked to play just a single complete match of soccer with their kids.

Everyone loves sports. Everyone loves commenting on sports. Playing the sport, is a completely different ball game all together.

Talking like an expert is so much more easier than, "doing" something, even if the doing only involves just meeting the basic standards of a novice.

People love giving expert comments on everything that they see.

If you are a builder or a story teller, your job is to play the game, be a starter, learn the basics and then get better at it.

Can you do that? No? Then shut up and enjoy the game. And  stop giving us your expert opinions on everything.

Now, translate this analogy to managing teams, the advice you give them on how easy a task is, how much time something should take and the volume of code you yourself write. Get on the field. Hit a few shots. Score a few goals.

If not, stop scoring fouls and stop giving your expert opinions. Seriously.

Agility In Your Tools.

Your tools are a reflection of your passion for your art. The world conspires against you when you sit down to write a book.

The universe morphs into a perfect tool of distraction when you sit down to write code for your next side project.

You get a thousand random thoughts when you sit down to focus on one and write a blog post.

Or... You are just having one bad day after another.

Agility in your tools will keep you moving.

Cartoonist Hugh MacLeod draws behind business cards. The medium sets him free to practice his art anywhere. Everywhere. Scott Hanselman talks about the power of the Netbooks. Something I talked about as well. It is all about picking the right weapons and then becoming one with your weapons.

This post was written on my blackberry on a bad depressing day with a wet running nose, a dehydrated body and a tired mind. Some others are written on my phone when I am moving and feel inspired.

The point is that the world will not exactly mould itself to give you the best  possible environment to practice your art. Introduce agility in your tools so that you can continue jabbing and utilizing small windows of time to practice your art.

When you are in a guerilla warfare tanks and fighter planes are not effective.

Pick tools that let you practice your art, anywhere. Everywhere. And then use these tools, ruthlessly, to fight your own lizard brain.

I wish you good luck.

If you are a kick ass programmer, you're probably  working in one of the two modes:

1. Working for your manager mode.
2. Working for your product mode.

The difference seems trivial at the first glance. You are getting stuff done, right?

In the short run this hardly matters as long as your motivation factors are intrinsic (you're not working for a twenty percent hike, a promotion etc.).

In the long run however, working to get a pat on the back from your bosses often means that you are not giving your best to your project.

You want to show your manager you're working late hours so you work late hours.

You want to show your manager that you take all support requests even if they aren't critical so you rush to close  a non critical support ticket in the middle of the night.

And you're constantly worried about what your manager thinks about you.

In working long hours you are often not your productive best, in taking every single support ticket in the middle of the night you are just firefighting and not innovating enough, in worrying about what your manager thinks about you, you aren't saying no or expressing your opinions strongly and candidly enough.

To make things worse, you are probably burning out and very soon you are going to be sick of it.

Impressing your manager will not fuel your career for long term.

A larger purpose or cause, meaning, a quest for perfection, continuous improvement or even the relentless desire to ship something remarkable to your users or the world might be a way better long term fuel for motivation.

Now stop impressing your boss by saying yes to everything, working like a cog and slogging late nights just because you want to show your bosses how hard you worked. It's going to wear you out in the long run.

Put simply stop working for your manager and start working for your product and your organization.

Chances are you will be much more happier, much more innovative, much more creative and.... even much more productive.

This writing is free form and non-structured. If you feel offended after reading this post, that's just ‘cause you have no sense of humor or the article is about you.... and you my friend.... are a chump!

If you find yourself laughing along for most of the article but you disagree to some parts of it, that's probably because you are basically a productive human being but you've been spending too much time with people who are the central point of this article. You know.... the chumps!

Calling bullshit when I see it is my idea of humor. It's a little dark. A little over the top.  And just about the only advice I can give you is don't take it too seriously.

You have been sufficiently warned. Continue reading at your own risk or close your browser window and leave now!

[This line is intentionally left blank.…to give you some think time to decide if you want to continue].

Still there?

Good!

Let's talk about Social Media.

But before we get to the social media bit, lets talk about the dudes who talk about Social Media with a straight face and claim to be "Social Media Experts".

I don't like the name Social Media Experts so for the purposes of this post we are going to give these folks a cute name.... the "Social Media Dudes" or SMDs. Or if you are like me and you like to keep things simple you can just call them... The Chumps!

In this article I am going to use these names interchangeably.

Most Self Proclaimed Social Media Experts = Social Media Dudes = SMDs = Chumps.

Got it? Clear? Sure? No Questions? Good! Let's move on.

Now that we have given a name to the SMDs, let start by talking about "Social Media".

I. What Is Social Media

"First There Was Print Media"

That's how the Chumps go about explaining Social Media when they talk about it. Most explanations about Social Media are on this line:

"Once upon a time there was the Print Media! Then there was Revolution and then came Online Media! And then there was the time for Revolution 2.0 and some really smart dude somewhere farted the term "Social Media" straight out of his B-hind and there was world peace…. And.... And now Social Media is there to Rule the world!"

It's a pretty compelling story. Especially if you are having a bad day and your mind is vulnerable to stupid memes and thought viruses. That's how all bad ideas that survive (including terrorism) spread. People are having bad days and they are confused, they listen to horse poop and before you know it they are doing stupid things like blowing themselves up. The "Social Media" virus is no different, albeit the story is compelling. You have to give them that.

Print Media > Online Media > Social Media.

That's the story Boy! Got that?

The only problem with this story is that I have been living on this same planet as most SMDs (a few of them are truly out of this world) and as far as I can say, there has never been such a thing as "Print Media".  Nope! Never! Ever! Not on this planet!

There were things which we read. You know, books and that stuff. But we didn't take all of them an club them into a stupid bucket called the Print Media.

I mean I am sure that some smart dude somewhere farted that term out of his B-hind too and then realized that no one cared about it and enough people twitched their noses and looked at him with knitted eye brows which embarrassed the shit out of this dude and he stopped using the term Print Media all together and the world was saved from an idea epidemic.  So yes, the concept of "Print Media" might have existed for a brief period of time.

But in the larger scheme of things as far as most of us were concerned, it wasn't even significant to be noticed by most people on this planet and therefore it is safe to assume that such a tern as Print Media never existed.

I'll tell you what did exist and still does and will continue to exist (at least for a very long time).

Since the renaissance and the invention of the printing press, we had News Papers and Magazines and Journals. Since then, a News Paper was a News Paper, a magazine was a magazine and a journal was… well… a journal! There was no such term as the "Print Media".  Nada! Zip! Nothing at all! Honest! I've been alive for more than 29 years! I've never heard the term "Print Media" to describe a freaking newspaper. Not until the SMDs started showing up on Twitter. Then suddenly I started hearing it everywhere and then it spread like a virus.

Now every time someone asks me "Hey Pops! What are you reading!" I feel the immediate urge to respond with "Oh! Nothing! Just Some Print Media!"

Every time a SMD says "First there was Print Media" with a straight face, he is just full of shit.

Oh and while we are at it, let's also talk about the "Online Media" and "Web 2.0" (though I suspect that is a completely different breed of chumps who deserve a blog post unto themselves, but let's give them just a little bit of love for now. Why should they feel completely left out and ignored? That's so not fair!).

Given that I am starting to feel bad about having to bash everyone today and being so blunt and direct and loud and realistic about things, let's get Tim Berners Lee to do the honors:

When asked if it's fair to say that the difference between the two might be fairly described as "Web 1.0 is about connecting computers, while Web 2.0 is about connecting people," Berners-Lee replied, "Totally not. Web 1.0 was all about connecting people. It was an interactive space, and I think Web 2.0 is of course a piece of jargon, nobody even knows what it means. If Web 2.0 for you is blogs and wikis, then that is people to people. But that was what the Web was supposed to be all along. And in fact, you know, this 'Web 2.0,' it means using the standards which have been produced by all these people working on Web 1.0." He's big on blogs and wikis, and has nothing but good things to say about AJAX, but Berners-Lee faults the term "Web 2.0" for lacking any coherent meaning.

Read between the lines?

What the founder of the world wide web is telling you, is that the Online Media Dudes (OMDs) and the Web 2.0 media dudes (OMDs 2.0) are…. Chumps too!

During the short span of time in which software development as we know it, has existed, there have been a truckload of jargons that have been farted out by a truckload of guys. Some dissipated into thin air. Others like these ones stuck around and continue to stink.

Pretty much like "Print Media", there is no "Online Media" or "Web 2.0" or "Social Media" that is going to change the world.

Of course, there were, and still are, websites, chat rooms, search engines and web applications (like forums, blogs etc.). A website was and still is a website, a chat room was and still is a chat room, a search engine was and still is a search engine, a forum was and still is a forum, a blog was a and still is a…. I think you get the idea!

The SMD's, OMDs and OMDs 2.0 were and still are all bullshitting!

And you are eating their bullshit (gobbling it up) especially if you use words like The Print Media, The Online Media, The Social Media and Web 2.0 with a straight face and claim to be an expert at this game.

We've done a bit of rambling on till now. Lets start getting to the specifics of my criticisms of "Social Media" and where Chumps are taking it.

II. Where Is The F@#king Value?

Somewhere in the mid 1940's there was a really smart lady called Ayn Rand who wrote a book about Architects called The Fountainhead where she used the term the "Second Handers". The chapter where the hero of the novel talks about this idea was a long rant, pretty much like this blog post, but I'll save you the trouble of reading over a thousand pages and cut it down for you.

Second Handers are parasites. People, who mutilate, violate, steal, twist and take credit for the innovators hard work.

The whole "Social Media" movement and the poop that you see getting posted about Social Media is a "second hander movement".

Seriously! Think about it. What do most Social Media Dudes out there really do? They get on a Social Media website and talk about how cool Social Media is. It's information about information. Forget the part about building systems or tools. These guys aren't even building data.

Geeks like me refer to this as Metadata!

No one is producing anything valuable or concrete here.

Folks are:

Blogging about Blogging.

Tweeting about Tweeting.

Blogging about Tweeting.

Tweeting about Blogging.

Posting Questions like "Is Facebook Hotter than Quora?" on…. Quora!

I've got a question that you ought to ask on Social Media: Where is the f@#king value-add happening? What are you building again? What is the percentage of people using the "Social Media" that are doing any "real work" and producing genuine value with it?

And No, Random Meta data or noise and tools to handle that same Metadata or noise effectively so that you can produce more metadata and more noise is not genuine value!

We had a name for this before we started calling it Social Media. We called it "Small Talk". All of us did it. But we were aware of the dangers of overdoing it. Then we had the tools to take it online so we started doing it online which was all fine and dandy. Then someone came in and said it was the "Social Media" and doing more of it can make you rich or help you get laid and suddenly the dam walls gave in and then there was…. REVOLUTION!

Now we have everyone trying to create a revolution by talking about how bad that restaurant down the corner is. That's how we are going to have revolution. Not by putting in the hours and building stuff that's genuinely meaningful, helpful, valuable and touches lives.

Yeah. Right!

III. Word Of Mouth

"Dude! Social Media is Hot! I know which movie I should not watch and which brand of Toilet Paper to use ‘cause my friend tweeted about it!"

Ok we can't beat you at that. So I am going to tell you a little story instead. Back in our school days we had a dorky little guy who loved whining. We're going to call this guy Freddy. Freddy loved to whine about everything. Freddy loved soap operas. Freddy loved the Charmin Ultra Strong toilet papers and he absolutely hated his cell phone company ‘cause those guys were mean to him and they deducted his balance ‘cause he paid the bills late and Freddy had a dog and Freddy loved…. (YAAAAWWWN! Yeah. I know).

Now get a million Fredies on Twitter and ask them to bitch their hearts out and you can be rest assured that you are going to find thousands of tweets by thousands of Freddies when you are searching for the #toiletpaper hashtag on twitter desperately hoping you would find advice on which toilet paper to buy on Twitter. Or let's just say that you are already following Freddy and when he tweets about the Charmin Ultra Strong toilet paper being uber cool you just get that Tweet and you become that much smarter about…. Toilet Papers.

(Side Note: Knowing which toilet paper Freddy likes in a 140 character blurps isn't really directly correlated to your level of knowledge on Toilet Papers, but let's give that leeway to Freddy and the Social Media Dudes for now and let's assume for the time being that 140 character blurps on Toilet paper are really making you the smartest Toilet Paper expert in town).

What this means is that you would have to follow a million Fredies and hear about Toilet Paper all the time to effectively utilize word of mouth online. Or you could just Google for Toilet Paper Brands and land here and read the 14 ratings and 13 reviews on….. You guessed it… The Charmin Ultra Strong! Exactly what Freddy was going to recommend!

I don't know about you but I prefer the later, but maybe that's just ‘cause I am not a chump!  

You know what's word of mouth? True Mavenship is word of mouth. People like Seth Godin, Scott Hanselman, Scott Berkun, Jeff Atwood, Malcolm Gladwell (the list is really endless) do this. I've talked about this before and it involves developing a specialization, honing a talent, working at it, paying your dues, giving in the 10,000 hours, adding genuine value before people start respecting you and listening to you.

That's true communication and connection and word of mouth. Of course no one worth following on Twitter seems to be making a big deal about how "Social Media is going to bring a revolution and how it is going to change the world".

They are all busy adding value and earning your respect. They are busy doing hard work, while the chumps throw Metadata on your face and tweet away to glory.

IV. Everything Is Connected.

This was something someone who might prefer to stay unnamed said over a phone conversation. "You know, if I give you a map and plot two points on it and ask you to connect those two points with a line, how hard would it be to connect those two points? If you want to connect things, everything is connected."

That Toilet Paper Review site that I mentioned above, I can see a zillion SMDs shouting at the top of their voices saying "Pops! No Fair! That Toilet Paper site is Social Media!"

Yeah. Right.

Everything with a comment field and a rating hyperlink is Social Media. I've given you the map with lots of points on it. Just keep drawing the f@#king lines and together we can change the world! We love you! Chumps!

The only genuine threat with drawing these lines is that when you blow your stupidities out of proportion, some famous publishing house picks up your poop, publishes it and before you know it Enterprises are talking about building the next Toilet Paper Social Media 4.0 website using Web 8.0 with a like button and planning on minting millions by building their toilet paper iPhone application and giving it out for free. And then these enterprises go out there and invest a zillion dollars on the iPhone application and a Toilet Paper Service only to find out that while a lot of Freddies were tweeting about Toilet Papers they weren't really passionate enough to yank out a ten dollar monthly subscription to find out more about Toilet Papers. And then you have failed startups and people lose jobs. Nasty things happen.

Congratulations Chumps! You just f@#ked an entire organization and wiped it out of existence by producing Metadata. Or let's just say it was the Organization that blew themselves up. That's what nasty thought memes do when you allow them to spread.

Everything is in fact connected. Let's draw more lines.

Everything is Social Media! Yeah! Right!

Remember the terrorism bit we talked about when we started this post? Yeah. That's what really bad memes do when you allow them to spread.

V.  No Silver Bullets.

I realize that I've been rambling on for about eight pages and it's time I start tying the loose ends and making my points. Every time anyone produces a technology that has the potential of making an impact, we have "Second Handers" who want to jump on the bandwagon and the only contribution they have to offer is a sick and twisted name, lousy noisy publicity and random mutilation of the idea. That's how silver bullets come into existence.

Google produced a grid of computers which formed a truly scalable infrastructure. Amazon gave out a part of their infrastructure for a small fee. The Chumps and the second handers called it Cloud Computing and convoluted the whole idea by making way too much premature noise about it. Folks worked hard on building Ajax frameworks and the second handers were coin the term Web 2.0 and confuse the crap out of everyone to a point where anything with big fonts and lesser page refreshes was Web 2.0. Genuine builders work on deep innovations which have long term impact. Chumps create random premature silver bullets out of these innovations. 

The problem with silver bullets is that they are poison for the confused mind. Most geeks are safe. They have bullshit busters pre built in their heads. These bullshit busters help them steer clear from that automated code generation tool that is going to boost their productivity 10x and make them 10 times more sexually desirable. As geeks we listen to this crap and dodge this crap 10 times a day. So when we hear about Social Media we go "Bleh! Whatever!" and then we forget it and we get on with our lives. Yes, we have our Twitter accounts and our Facebook friends but we know where to draw our lines and how far to take this shit.

But Geeks don't run enterprises and fortune 5000's. Enterprises are run by management teams which desperately want a silver bullet. Every time you post some poop on how Social Media is hot and how it is going to change the world, you run the risk of some innocent reporter with an overused bugged bullshit buster picking it up and running it on an online publication which is read by thousands of people. Most people are going to boo that report and your post. They are going to leave nasty comments on your blog post and then get on with their lives assuming that the reporter was just having a bad day and ended up putting some really bad content out there. But really bad publicity is also publicity and that's going to get you on Reddit and even more popular publications.

And then you are going to have an innocent Vice President of a Toilet Paper Company with really weak bullshit busters, who truly believes in the authenticity of these publications along with the content they put out and doesn't understand that authorship doesn't always equal authority. This Vice President is going to glance through that article, run right past the comments and the booing (we often run past invisible gorillas and often make the lamest of mistakes) and is going to decide to invest in creating a social presence for his toilet paper company and hire more Chumps to help him do that.

The vicious circle is complete. Supply of horse poop now meets demand of horse poop and we have a freaking market! Repeat that a few thousand times and you have an economy. It's really that simple. And then suddenly you are left with all this horse poop and you don't know what to do with it.That by the way is exactly where we are right now. We have an entire economy of Second Handers Tweeting, Blogging and Producing Metadata that solves no problem and just creates noise.

Repeat the same cycle for long enough and you're going to create a colossal f@#king disaster. The kind where companies wind up and people lose their jobs. Even worse is the kind of disaster where every genuine idea and effort capable of having a long term impact is mutilated and taken over, twisted and relabeled by a bunch of chumps or second handers before it can have any impact.

VI. Call to Action

If you are in the business building communication tools that build on Facebook or Twitter, here is your opportunity at not being a chump. Try to inspire people, build genuine content on a variety of topics, build stuff (applications, tools) which reduce this noise, boo at bullshit when you see it and make sure your boo's are loud enough to be heard. After all you are in the Social Media business with a million followers. You can be loud!

Start out by helping people spot the signals within the noise, educate people; and please…. please stop producing random meta data, using words like REVOLUTION and for your own sake stop building stupid presentations like these ones. If you do, we are just going to have to call bullshit on you.

If you are a geek with bullshit busters that can pick up crap like this, buzzers that start sounding when you hear bullshit, noses that start twitching when you smell someone farting utter crap, or eyebrows that knit when you hear a lousy idea, going "Bleh! Whatever!" and moving on with your life, is no longer the right approach. Show your perspective to everyone else. Educate people. Help them develop better bullshit busters in their own heads.

Help them realize that there is no silver bullet out there that is going to change the world and trying to look for one that is going to just change their world in a very strange nasty way.

Put simply, use your Social Media skills to blow the Social Media out of people's mind. There is no Social Media. You have blogs, and applets and web applications and websites and people talking to each other and small talk and.... Chumps. Lots of them.

As long as you can see that clearly, we are good.

Now go to Twitter or Facebook and spend a couple of hours there and then when you are entertained, have built a community, have talked to friends, taken your customer's feedback, talked to  them or done whatever it is that you were trying to do there get back to doing some real work.

Try to go slow on the metadata production. Stop being a chump and please.... please build something meaningful. Something insightful. Something inspiring. Something that solves a real problem that you have. Something that helps people discover new information that transforms them or changes their lives. Something that helps people become more effective or makes them better human beings.

Oh and by the way, if you bump into some Social Media Dudes tell them I said Hi! Tell them to follow me on Twitter and we can send each other tweets. I am on twitter when I have nothing else to do. I think of it as a video game where I poke random strangers and they poke me back and I would love to poke a few chumps and be poked back if it gets me a higher follower count and more mussel power. Social Media is going to change the world! Let there be world Peace!

Have you noticed the serious faces when you travel in a subway?  Or the faces people have when they wait at the airport?

Or The serious mask your manager wears when talking to you?

Or The serious face your organization puts on when publishing an announcement on their corporate website?

You believe that others won't take you seriously if you don't put on a serious face.

Ironically, your serious face is a wall that prevents us (your team, your employees, your users and your clients) from connecting to you.

It stops us from getting to know you and If we don't know you enough to care about you, your blog, your product or your organization how do you expect us to take you seriously?

When it comes to your organization:

If it looks corporate change it and it looks serious spice it up.

And that is when things becomes remarkable people start giving you some..... serious attention.

Most Creative endeavors are insane. They are also unreasonable and lonely endeavors.

Most people who start out on them stop when they discover that are toiling alone on an effort no one else is interested in. They hear the "we are not interested" loud and clear.

And then they quit. The reason? Because they want to stay connected.

If you want to understand our innate desire to  keep connected, try watching a movie, eating in a restaurant, going out on a vacation or going on a log run without having any other human being accompany you.

Uncomfortable?

That right there is the fear of being alone.

This fear is one of the major reasons why you are afraid of silence (even when it is productive) and why you love noise.

This same fear stops you from going on movies that you really want to watch but none of your friends want to, or eat at places where your friends do not want to eat, or go on adventurous vacations where your family cannot go with you.

The same fear of being alone, stops you from implementing brand new ideas and working on those ideas, month after month, even if no one uses your application or reads your blog.

Understanding this fear is the first step towards conquering it.

Changing your lifestyle to stop worrying about others is the next step.

What do you want to do this weekend? Go running? Play a sport? Go on a long walk? Catch a very different kind of a movie or drama?

Everyone around you seems busy, tired, too lazy to get out of the home or just not interested in that activity?

Why not do it anyway?

And the same holds true for the applications that you always wanted to build.

Most artists (even aspiring ones) have more bad days than good ones. Between the two days when your system is rolled live and when your blog post tops reddit there are going to be a whole lot of days which are going to be awfully silent.

On some of these days, you are going to have fights with friends, breakups, failures, depressing thoughts, self loathing, doubts about what you are doing, doubts about your life, physical sickness, invitations to parties you do not want to attend but end up attending, meetings, chores and hours when you find it practically impossible to focus on what you truly love doing.

All artists (programmers, painters, writers, singers....) go through these days.

Most kickass artists even admit going through these days openly.

The big difference, between artist who builds stuff and a whiner who whines is that on these days an artist starts working on what he loves doing to come out of the depressing thoughts. A whiner uses these days as an excuse to stop working on something that he loves working on and crawls into depressing thoughts.

An artist opens the IDE even on a bad day. A whiner closes his open IDE as soon as he encounters a bad day.

True artists show up. Even if its just for an hour every day.

True artists know that if they worry about the bad days, the silent days, the depressing days or the shitty days, they are never going to be able to ship, because there are just too many of these days.

Bedsides, everyone has bad days.

Stop using these days as an excuse to surrender control to your lizard brain.

We are calling your bluff.

Now come out of that hibernation get back to doing what you love doing and start shipping.

I dare you.

After being hired as a visual basic programmer, the early part of my career, for a year or so, involved doing multiple odd jobs besides programming . Ranging from managing servers, installing updates, configuring exchange server, working on database administration and last, but not the least formatting documents.

What this meant was that this was my training time for playing a one man army if the need existed in my future projects.

What this also meant was that on any given time I was reporting to and working with more than half a dozen project managers and their egos. Everyone had a high priority work item for me. Everyone was offended if their high priority work item wasn't addressed before the other manager's high priority work item.

It was multitasking at it's height. I was juggling five tasks and five egos simultaneously on any given day. Missing a task was acceptable, missing to attend to or honor a manager's ego was not. I remember for example, forgetting to place a comma in the right place while updating the content on the content management server and having that issue bite me back in the form of a nasty email from one of my managers. This manager of mine went the extra mile at embarrassing me by copying multiple people in the team.

I suspect the issue had more to do with me not paying enough attention to that manager's commands than it had to do with me missing out the comma. I had spent more time fixing a server that had gone down than I had updating the content in the Content Management Server. Something that this manager had probably taken a note of and then taken care of by writing this email.

The height of it was me getting called into the office of another one of my managers. This gentleman was offended because I had filed just two hours a day of my work time to his project and the rest of the time had been filed to other projects. After my desperately trying to explain to this gentleman that all the work had been done in the two hours that I filed, I was ordered to immediately redo all my time sheets and file eight hours a day to his project. By the end of the month, I was filling timesheets which basically said that I was working twenty four hours a day. Nobody cared.

Multiple clients were billed for my work, each seeing just the hours that I filed to their projects. No one, neither the HR, nor the management noticed anything peculiar about someone working twenty four hours a day. Or maybe they did and I started receiving pats on my back for being a hard working employee. Working for twelve to sixteen hours and filing twenty four was my first realization that the number of hours you put in your work means nothing. Your effectiveness means everything.

I've talked about this topic before. Scott Berkun touches this topic while talking about managers who are never around. He explains:

Everyone in the tech-sector goes through a phase early in their career where they're proud of their hours. At software and consulting companies everywhere, circles of 20 something friends debate, over drinks each night, who's put in crazier hours – "I worked 70 hours last week", "70? I worked 70 hours in 3 days." "3 days? I worked 70 hours this morning, before breakfast." And on it goes.

It's a kind of dumb male pride in size of things, rather than quality or, god forbid, actual happiness. To work 70 hours is a statement of work, not of progress. For every idiot working 70 hours there's a smarter, wiser man who's doing the same amount of work in 50 because he's paying more attention to results than the clock. I'd rather be, and rather hire, that man.

Sadly enough, years ago, for me this realization did not come from watching this super efficient man that Scott talks about or learning from him, but from working with managers who deeply believed in measuring efficiency by looking at your timesheets and seeing how many hours you spent on their projects. More hours, it was believed, was better than less. Back in those times, for me, working smart and doing work which could be filed as, and billed as, twenty four hours of work, in twelve was not a just philosophical thought. It was practical necessity more than anything else. There were two reasons for this.

The first was that after a few months of putting in twelve to sixteen hours a day I had started burning out.

The second was a much more real and practical reason. I was in college back then, and my graduation exams had started nearing. To make things worse, I had also taken up a few vendor certifications which had to be completed. Spending twelve to sixteen hours a day at work meant that I would be able to do none of these items nicely. I had to figure out a way to get enough time to study.

The realization that I could work twelve to sixteen hours a day and file timesheets which showed twenty four hours of work and have these timesheets get approved was a profound one. I had found a hole in the system. A rather scary hole but one that would be used and exploited to its limits. The realization meant that excelling in this organization was all about:

1. Working smart.
2. Pretending that you were working really hard.

Automated word macros that format a huge part of the documents were setup. Automated scripts were set up for odd jobs that I had been assigned to do. Every single work item that was repeatable had been taken and scripted to a level where my manual intervention would be minimum. Very soon I was working for four to six hours a day and filing timesheets for twenty four. A good 50% of this four to six hours went in juggling with people's egos. The rest of it was real work. For the other hours I would sit quietly at my desk, a book or a PDF open and I would study. Most people passing by assumed I was working really hard.

The creepiest twist to the tale of events came when I took a study leave for my final graduation exams. By this time everyone believed that the tasks I was doing were worth about twelve to sixteen man hours a day and so they went ahead and assigned another person on the project.  While I was on a leave two rather strange incidents happened.

The first was that the person who had been assigned to the project had complained that he was overworked and that he was not being able to finish his daily assignments. He ran into a lot of arguments in turn building up some friction between all of these project managers, which was fun to watch when I came back.

The second strange incident was a call I received from one of my managers, "Hey, thanks for working from home while you are on leave, but you know, we are assigning someone else to this project and you do not have to work from home when you are on a leave", he had said.

What had happened, I assumed was that one of those scripts that was supposed to have automated some of my work had kicked in, completed the job and had sent out an email that the task had been completed from my email account. For a few days, I contemplated telling him about the scripts to improve the overall efficiency of the team but then, that would have shattered my image as a hard worker who was putting in sixteen hours a day and was also working from home. So I decided to stay put, shut up and just shut down the script scheduler till the time my study leave was over, letting the substitute bitch about how overworked he was and allowing him to continue doing most of these tasks manually.

These series of events taught me two very important lessons:

1. Recognize results people produce (quality of work, art, happiness, the culture they create, innovation) not the brute force effort without any returns that idiots put in their work. Any idiot can pretend that he is working really hard. It takes a kickass team to be effective and produce working software. 
2. Don't try to squeeze out every minute of someone's free time. If someone is working smart and getting more work done in less time, don't make it your responsibility and your sole mission in life to keep the guy busy with more work. Efficient guys, find out work for themselves and they get down to doing it, even if you are not after them. Get out of their way and Leave them alone.

Do these two long enough and what you start seeing is sheer magic. People develop trust in you. They start sharing their ways of working smart, their shortcuts, their innovation and their approaches with the rest of the team and the organization in turn making everyone more efficient. Once the tables are turned and male egos revolve around how efficiently you can do your work, the man hour discussion pretty much moves out of the picture. That is when you start building a culture that revolves around sound time management, innovative working techniques, efficiency and results.

If you can't build that culture, most of your organizational efficiency is in isolated corners of your office corridors and you probably don't know anything about it.

What is rather ironic is that my first lessons of time management and efficiency came from an environment that was designed to screw any engineer working in that environment and turn that engineer into an automaton executing programmed directions for sixteen hours a day.

But then, you learn most of your management lessons in the strangest of circumstances and by hacking the weirdest of work environments.

Most organizations have ways of keeping their employees motivated.

Most organizational motivation looks like this.

If you cannot drop your carrots and your sticks, we won't drink your cool aid.

If your inspiration is backed by an "Or Else", a written rule, a CYA document or a silent subtle threat, it's not inspiration.

The "Or Else" triggers the lizard brain to finish tasks but it won't result in getting people to ship art.

The results are likely to be mediocre and boring.

If you want to build and ship genuine art, take away the "Or Else" part.

What you have left is a remarkable culture with a tribe of motivated artists.

Birds chirping in the trees told the early men everything was fine.

Back then, silence was usually a sign of trouble. A fear signal for your brain.

Even today. Silence scares the crap out of us. Most people get uncomfortable with any period of silence. You walk up to your colleague's desk. Crack jokes. Pick up the phone and call your friends. Get on twitter. Respond to facebook comments. Your birds are singing and you feel safe.

What you forget however, is that today, silence is often hugely productive.

I am not saying that cracking jokes with colleagues, calling a couple of friends, tweeting or spending time on facebook are a bad thing to do. But if you are doing them just because you are scared of productive silence that surrounds you, then all you are doing is generating noise. For yourself and rest of the world.

You are breaking the silence that was making (or could have made) you productive. There is nothing safe about that. In fact, in the long run, that is exactly what you should be truly afraid of.

True, silence is scary. But if you genuinely want to hear the birds sing in the long run, learn to embrace silence and make the most out of it.

You want to build an interesting product. Start by building an interesting personality.

You want to build a different sort of an organization. Start by living a different lifestyle.

You want the smartest of minds and mavens to help you market your product for free. Start by listening to them. Stop using funny words like "social media", "web 2.0", viral marketing and most importantly, stop insulting their intelligence.

Random buzz words, power point slides and paid advertising won't come to your rescue when you are dealing with smart people.

When we use your product, or read what you write we can see through you, your effort on the product, your mind, your life, your character and your personality.

The real question is, can "you" see us seeing that or do you think we are idiots?

Most businesses, product managers, marketers,  PR guys and social media experts think its the later.

The others, are successful.

Doing anything is risky. Doing nothing is riskier.

Roll the dice.

Take a chance.

The downside is you might fail. The upside is you get smarter and stronger...

even if you fail.

Why is every occasion in your life just like everyone else's?

Why do you celebrate your birthdays in the similar restaurants as everyone else?

Why do most parties you invite us to follow the same predictable patterns?

Why are most of your conversations the same when we meet for the first time or every time?

Why do you strive so desperately... to fit in?

Most of the times you fit in and settle for boring safe mediocrity because you have the fear of the "different" letting you down.

The irony of it is, its the mediocrity that almost always let's you down.

Your desire to "fit in" is why you throw boring parties, engage in boring conversations, build boring applications and above all lead a boring life.

Do you really want to continue trying to fit it or embrace the different? If your answer is the later, start by not being afraid of the different when you see it.

After all, different is a way of life and once you embrace it, different shows up in just about anything you do.

Most HR, PR, Managers and organizations like to pretend they know how they can recruit and drive the best of the employees.

The fact is, that a whole lot of it is just luck.

Most managers and organizations around the world, get lucky....

And then they blow it.

A fully functional team is shipping kick ass version after version... yes, but they aren't updating the low level design documents, or punching their time cards.

Someone high up in the pecking order feels like scratching an itch and scratches it.

Tweaks are tried, policies are made, rules are created and before you know it, you are trying to fix something that is not even broken.

And then all you can do is read articles on how to hire the best and bitch about why its difficult to retain the best of the best.

All I can tell you is that you are just wasting your time.

You really want fit in and gain acceptance from the most people around you.

Simultaneously you really want to show them how wrong they had been all along.

The thing with the seeking acceptance is you almost never prove anyone wrong while seeking acceptance (and you don't get much acceptance either).

The thing with proving them wrong is that you have a strong possibility of gaining lot of acceptance after you have proved them completely wrong.

Here is the really ironic part:

If there is a voice of a misfit disagreeing with the crowd and a conformist struggling to fit in within you, your best chance at gaining acceptance in the long run is listening to the misfit.

I have nothing to say... I am really busy... I don't believe in writing... I don't have the time.

Lame lies people tell themselves (and others) about why they cannot don't want to write.

In order to write you need to:

1. Accept and face the deepest of your fears.
   (you have a boring product, a boring life, a boring personality, an abnormally powerful lizard brain, problems you are too scared to accept).  
2. Overcome these fears and find your own voice.

These are the two real reasons why most people do not want to write.

Of course, these are also two very important reasons why you should write...

Even if no one reads your blog.

"Be Reasonable. Be Practical. Grow up. Be Professional" -- this or just another form of this advice is what you probably received when your teachers and acquaintances wanted you to stop playing around and tow the line.

Seth Godin's recent blog post, is a slap on the face of people who want you to toe the line and act "reasonably":

It's unreasonable to get out of bed on a snow day, when school has been cancelled, and turn the downtime into six hours of work on an extra credit physics lab.

It's unreasonable to launch a technology product that jumps the development curve by nine months, bringing the next generation out much earlier than more reasonable competitors.

It's unreasonable for a trucking company to answer the phone on the first ring.

It's unreasonable to start a new company without the reassurance venture money can bring.

It's unreasonable to expect a doctor's office to have a pleasant and helpful front desk staff.

It's unreasonable to walk away from a good gig in today's economy, even if you want to do something brave and original.

It's unreasonable for teachers to expect that we can enable disadvantaged inner city kids to do well in high school.

It's unreasonable to treat your colleagues and competitors with respect given the pressure you're under.

It's unreasonable to expect that anyone but a great woman, someone with both drive and advantages, could do anything important in a world where the deck is stacked against ordinary folks.

It's unreasonable to devote years of your life making a product that most people will never appreciate.

Fortunately, the world is filled with unreasonable people. Unfortunately, you need to compete with them.

Fortunately, being unreasonable is not as hard as it used to be. Fortunately you can be a guerilla entrepreneur where you practice the unreasonable, experience the sex part of your development life and let your day job handle the reasonable realities and the cash part.

That or become a part of or build an organization where being unreasonable, is totally reasonable.

If you are one lucky son of a gun, you can end up doing both too.

Either way, you have no excuses for towing the line and living by the rulebook.

I wish you good luck.

Most engineers who are passionate about what they do love programming and yet only a few venture out of ship anything outside of their work life.

Extrinsic Motivation is probably not a problem here.

The bigger problem is developing a critical mass where you can see something take shape.

Fitness experts will tell you that there are really two states in which a human being can exist. Sedentary and moving. The biggest challenge you face when working on fitness is moving from sedentary state to the moving state.

Once there, you will probably get addicted to working out and you will not need extrinsic motivation to hit the workout room.

Most of what you do at work, is driven by deadlines, fear, consequences and pats on your back.

Unless you have tasted the joy of owning and working on a small side project, you are in, what I call the sedentary state of the software development world. If you really want to experience the state where you are moving and loving every bit of it, get out of that couch and push yourself to build something.

You don't need years to build something huge. Just ship the first sprint.

Build just enough to have a critical mass of something which has a life of its own and an ability to morph into something gorgeous. What I can tell you, is that you wont need this blog or any extrinsic motivation to keep you working on to it.

You will look forward to your weekends, fantasize about working on your project, squeeze out hours during late night, tweak and optimize your life and even get more productive at your real job.

Shipping the first build, publishing the first few blog posts, doing the first few workout sessions, reading the first few books. The first few attempts at anything that is worth doing, are going to be pathetic, tiresome, depressing and sometimes even downright frustrating.

All I can say is, Keep jabbing.

You might not become the best boxer out there, but you might find out what you truly and genuinely love doing.

You have the venture funding covered.

You have an exit strategy.

You don't mind getting sold to a Google or an Amazon. In fact you have already thought about it.

Here is the bad news: Your venture is going to fail.

You are going to wait for your first million users to show up, and they wont.

You are going to wait for your first five, million dollar clients to show up, and they won't either.

You are going to wait there hoping a Google or an Amazon buys you and Google or Amazon is not going to give a shit about your product.

And that is not because you are a looser who could not start an organization or take it to a successful completion. That is just because you are playing a game where you are the rules are designed to help you loose.

When your organization is lean enough to survive on just ten hours a weekend, a tiny desk in a tiny corner of your home and less than three digit dollar amounts for hosting charges, you are on to something.

That is when you suddenly, you don't need your first million users to show up within a year or your first five million dollar clients to show up, or Google and Amazon to drool over your product and buy it.

Now suddenly, you are working on something that is gorgeous and has a life of it's own.

And the most amazing part of it, is the realization that you don't want an Amazon or a Google to buy you.

You have an organization, that can survive without a whole lot of users, without a lot of clients and without any venture capitalist and that my friend, is a gorgeous thing.

You are what I call, a Guerilla Entrepreneur, working for an organization that does not need a whole lot of capital or external confirmation to stay afloat.

I cannot tell you if you will be sold to a Google or not, I cannot tell you if a million users will show up or not, I cannot tell you if you will bump into the first five of your million dollar clients.

I don't know enough about that part. I haven't played that game yet and I have no intentions of playing it in my life because it is designed to make you lose. I can't tell you anything about that game. I'm sorry.

What I can tell you however, is that you will be happy, because every weekend, month after month, you will get to work on something you really love working on. And that in itself it a gorgeous feeling to have. Anyone who has experienced that feeling hardly ever talks about an exit strategy.

If you do, chances are, that you just don't get it.

Most programmers who love the craft of building software and are deeply passionate about it seem to find strange avenues or third places to channel their creativity.

Most of them are also faced with a life long contradiction Hugh MacLeod explains rather articulately through a cartoon drawn behind a business card.

He refers to the contradiction between shipping genuine art and paying the bills as the Sex and Cash theory in his book Ignore Everybody. Hugh explains:

The creative person basically has two kinds of jobs: One is the sexy, creative kind. Second is the kind that pays the bills. Sometimes the task at hand covers both bases, but not often. This tense duality will always play center stage. It will never be transcended.

A good example is Phil, a New York photographer friend of mine. He does really wild stuff for the small, hipster magazines— it pays virtually nothing, but it allows him to build his portfolio. Then he’ll leverage that to go off and shoot some retail catalogues for a while. Nothing too exciting, but it pays the bills.

Another example is somebody like Martin Amis, the bestselling British author. He writes "serious" novels, but also supplements his income by writing the occasional newspaper article for the London papers, or making the occasional television appearance (novel royalties are generally pathetic—even rock stars like Amis aren't immune).

Or actors. One year John Travolta will be in an ultrahip flick like Pulp Fiction ("Sex"), another he’ll be in some forgettable, big-budget thriller like Broken Arrow ("Cash").

Or painters. You spend one month painting blue pictures because that’s the color the celebrity collectors are buying this season ("Cash"), you spend the next month painting red pictures because secretly you despise the color blue and love the color red ("Sex").

Or geeks. You spend your weekdays writing code for a faceless corporation ("Cash"), then you spend your evenings and weekends writing anarchic, weird computer games to amuse your techie friends ("Sex").

This tense duality will always play center stage. It will never be transcended.

And nobody is immune. Not the struggling waiter, nor the movie star.

As soon as you accept this, I mean really accept this, for some reason your career starts moving ahead faster. I don't know why this happens. It's the people who refuse to cleave their lives this way—who just want to start Day One by quitting their current crappy day job and moving straight on over to bestselling author—well, they never make it.

Anyway, it's called "The Sex & Cash Theory." Keep it under your pillow.

Sound advice for both young programmers as well as veterans who have spent years depending on their organization for every ounce of creativity that they are allowed to demonstrate. I know you probably know the part of your career that is connected to the cash part, do you really know the sources of the sex part?

If not, now is a time where you start separating the two and focusing on both of them fairly seriously. The sex part of your career needs just as much attention as the cash part. Start giving it the serious attention it deserves.

I wish you good luck.

Talking is an art. A long candid talk can clear things up within a team.

Talking is also an addiction.

Like in every art, the trick with talking is knowing when to stop.

Are you talking because you are connecting to someone, clearing confusions, spreading your thoughts, sharing an idea or doing something productive?

Or are you rambling on and on because it feels good and it lets you get away without having to take up scary challenges or take up efforts where you might fail?

If your ideas are compelling they do not require very lengthy conversations. (One of the reasons why TED talks are really short).

If your ideas are not compelling all the talking in the world will not cause them to spread.

And the talking will keep you from working on them and actually making them strong enough.

Keep a casual eye on each conversation you have and when you feel you are dragging on and on merely because you are afraid of ending an conversation.

Every time you find yourself doing this, you are not talking, you are probably moping.

Stop it. Move to some real work and get productive.

You might actually feel better. Seriously.

In one of my earlier posts I talked about not worrying about a name for your product till you ship the first sprint.

Last Saturday we shipped a fully functional private beta for a free online hobby project of ours.

One way to think about what the application does, is think of it as a third place for book lovers and book readers. It's designed to help you share what you are reading, bump into people who are reading similar stuff and then have meaningful conversations with them.

(We believe that discussions around books tend to be much more engaging than using "Social Media" and "Web 3.0" to tell the world when was the last time you used the bathroom).

With the first sprint under a private beta, we have about a month to name the website before it starts boarding more people.

If you are a book lover interested in beta testing the application we would love to hear from you on the email address rajiv AT thousandtyone.com but the primary place where we need your help right now is the naming.

Got any suggestions for an awesome name? Email me at rajiv AT thousandtyone.com or by clicking the Mail image link on the left of this blog post.

Got any links or pointers on naming products? How about an awesome book on naming products? You can use the comment field below.

Naming is a part of the celebration of shipping and I would love it if you can join in this little celebration of ours.

You have been officially invited. Seriously.

Start by helping us name the website.

A couple of months ago we started working on a little project of ours in our free time. It was mostly a weekend thing. Not connected with my professional work or my organization. Just a little fun service you can use for free.

On Saturday this little website of ours went live.

We have decided to keep this site in a private beta for a month and not tell you much about it. Not because it is a secret (I know ideas are a dime a dozen), but because we would rather have you try out the application when it is out rather than us talking about it.

This series of posts is not about the service or what it does. It's about the things I learnt from building this side project and one of our biggest realization as we worked during the weekends was about excuses people (me included) give about why they do not start side projects during weekends.

Honestly, there is no reason not to.

Hosting infrastructure and tools are cheap. They are cheaper than you can think.

Anyone who says that he is not building or implementing an idea because he does not have sufficient resources is bullshitting. It is that simple.

Hosting accounts that are good enough to get a full blown implementation going can be less than fifty dollars a month. Yes, I know. Its ridiculous. Yes I know you probably might not scale with that infrastructure but scaling it is not your biggest problem when you are getting started, getting people to give a shit about your blog or application is.

With the plethora of open source tools out there, the Microsoft Bizspark program and the base installations that most hosting providers are giving out now a days, if you go out looking for a venture capitalist to fund your idea there is something fundamentally wrong with your approach.

If you need venture capitalists, it probably means you are not lean enough or it probably means you are not embracing constraints.  

With the productivity that most development environments and databases provide you now a days, if you cannot build a small implementation of an idea or a hobby, without quitting your day job or making a big deal about it, there is something fundamentally wrong with the way you manage your weekends.

With every passing day, the reasons for not implementing your idea into a concrete working application, are diminishing.

Reasons like No Funding, No Resources, No Time, No Venture Capitalists are probably not the things that are holding you back. Laziness, Fear of Failing (or succeeding), Bad Time management and your lizard brain are.

(Honest confession: At least these were the things that were holding me back from pursuing and completing this project).

Ok, now that I have confessed, I am calling your bluff. Accept it. With lesser and lesser reasons to hide behind, chances are that you are going to get your butt off that couch, fire up that IDE and work on something that fascinates you.

A couple of months ago, we called our own bluff, got our own butt off the couch and if there is one thing I can tell you after launching a private beta for this system, it is that, if you have an idea lingering in your head, you are doing yourself a disservice by not implementing it.

Shipping a hobby feels good.

Go on. Start this weekend. I wish you good luck.

Besides programming, writing and reading are my life long passions.

Are you having a baby?

I cant wait to plug this book to you.

Trying to become better at software development?

Try starting with this one.

Want to understand how your brain works?

Why not start with this one.

In a whole lot of conversation I have with my colleagues, acquaintances or even friends, I tend to quote from books. That is what book lovers do.

Books are a means to draw inspiration, ideas, fun and above all, they provide a means to glean into another book reader's mind and connect to a real person. I continue to be amused by just how many conversations you can have with random strangers over a book at a local bookstore.

Most of those discussions are way deeper than using "Social Media" and "Web 3.0" to basically announce that you are now going to go to the bathroom.

If you aren't reading books, you should.

If you find reading difficult you should consider listening to audio books.

Either ways, if you aren't reading or listening to a couple of books every months, you are doing yourself a disservice.

Go on.

Take a walk to a local book store or grab a copy of something you would like to read from Amazon or Audible and start reading. Its fun. Seriously.

You need your own mountain.

A set of challenges arranged in a coherent never-ending stream with constant sequential milestones where you can celebrate your doneness.

Each challenge focused around deliberate practice.

Unless you happen to be working for an organization that has a steady revenue stream through search and encourages your research project to stay alive for a year, deliberate practice, when you are constantly shipping is hard.

Spending a week on tuning your Ajax calls using JQuery instead of the ASP.NET update panel, when there is no concrete Return On Investment, is deliberate practice.

It is also hard to propose in a management meeting.

But you still need to learn how to do those Ajax calls and use them seamlessly in your application. Which is why you need your own mountains to climb. And you need to climb them, every week. Even if you climb just a few inches every week.

If you keep at if, after a while, the inches you climb might just start adding up.

The mountain can be a long running side project. A constant stream of training sessions you plan on taking. Or a series of technical articles you plan on writing. What ever it is, pick something which involves a series of coherently arranged never-ending challenges and constant sequential milestones.

So, what's your mountain?

If you haven't found one yet, might I suggest that you keep your eyes open and start climbing it as soon as you find it.

I wish you good luck.

If you are somewhat naturally inclined a few years of mucking around in a field can make you decently good at it. Good enough a get a job and start making a living out of it. That's exactly how far mucking around will typically take you.

From that point on you have two options:

1. Keep looping: where you keep writing the same CRUD screens for seventy years and keep making a living out of it.
2. Move to the next level one step at a time with Deliberate Practice.

Deliberate Practice is where you meticulously and carefully examine every aspect of what you do and what the best people in your field of work do.

For authors deliberate practice involves not just writing, but reading the works of other authors who happen to be better than them. For musicians, it involves listening to the music of other musicians. For software programmers it involves reading code and learning from other Alpha Geeks and kickass programmers around the world.

But deliberate practice doesn't end at meticulous observation. It involves stepping out of practice using your comfort zone and moving to practice using your learning zone.

A classic example of this would be, spending a week to figure out how to tube, tweak and improve your JQuery based Ajax calls to make them faster. Deliberate practice is hard work. Deliberate practice is painful. Deliberate practice is scary because the first step is a silent acceptance of how little you know.

Deliberate Practice, or lack of it thereof,  might also be the reason behind why most programmers cannot program.

What did you do today? Complete your tasks the entire day? Or did you indulge in the act of deliberate practice using your learning mode for at least a couple of hours? Yes we know deliberate practice is hard and painful but that anything that is wroth doing, is. Go on. Keep a few hours a day aside for deliberate practice of your craft.

I wish you good luck.

If you have done this even once, you know that if you are planning on working on an idea that you have, you are going to have to work without the crowd.

There are two reasons for this:

1. The crowd doesn't get the idea. Its going to think your idea is too lame or too impractical or already taken. 
2. The crowd doesn't care.

Both of these are good things.

The first is good because it allows you to build your idea exactly as you see it. As more people join, the vision dilutes. You are way better off working on the first version yourself or just a couple of really close friends who totally understand your vision or people who have similar core philosophies and values.

The second is good because it allows you to work in stealth mode, build something really small and release it to a closed inner circle of acquaintances who do care. This is good news because if you fail or build something that none of your users like, you have just disappointed a really small group who are willing to give you a second chance. You can choose to bury your failure, learn from it, move on, fix it, tune it, work it up and add more people really slowly.

Releasing a product live till you are done with a couple of complete sprints is almost never a good idea. If you are going to release a product live, do it when you are pretty darn confident the product has enough meat for people to love it, because otherwise they are just not going to care and that is not such a bad thing after all. Go on, ship something to your inner circle first and then slowly and steadily, surprise everyone else with a kickass product.

You don't need a big bang release date and press releases. Start with a slow and steady release instead.

I wish you good luck.

Hugh MacLeod's book Ignore Everybody, is a classic collection of well written articles and hugely funny cartoons:

One of the most interesting parts of the book is Hugh's explanation on power and the people who crave it. He explains:

Power is never given. Power is taken.

People who are "ready” give off a different vibe from people who aren't. Animals can smell fear. And the lack thereof.

THE MINUTE YOU BECOME READY IS THE MINUTE you stop dreaming. Suddenly it's no longer about "becoming". Suddenly it's about "doing".

You don't get the dream job because you walk into the editor's office for the first time and go, "Hi, I would really love to be a sportswriter one day, please".

You get the job because you walk into the editor's office and go, "Hi, I'm the best frickin' sportswriter on the planet." And somehow the editor can tell you aren't lying, either.

You didn't go in there, asking the editor to give you power.  You went in there and politely informed the editor that you already have the power. That's what being "ready" means. That's what "taking power" means.

A rather interesting read for anyone who has ever craved for, asked for or haggled for a promotion. You know the kind I'm talking about here. The kind that graduates from a MBA school and expects nothing less than a private cabin and a team they can boss around.

You cannot be expecting the world to give you power just because you want it.

After all, anyone who wants power should not be given power, for obvious reasons.

Now go focus on the taking up more responsibilities and adding a little bit of passion to everything you do.

Stop worrying about the power bit. Seriously.

When it comes to personal life and parenting, making someone you truly love wait, to teach him or her ability to delay gratification and self discipline, can be a good thing.

When it comes to business however, how long you make me wait has a inverse correlation to how much you care about me.

Please wait, our customer care executive will attend you shortly, is translated as: we have more customers than we can possibly care about and you are just one of them so talk to a machine instead.

When a restaurant makes you wait for a table or makes you wait after taking your order it sends a similar message. We have more customers than we can handle so wait in queue and stop bothering us.

When your website makes your visitors wait, its even worse.

We know its hard. We know sometimes the message isn't intended but we are all busy and if you make us wait, we are just going to assume you don't care and go somewhere else.

The best you can do is speed things up for us. Hire more trained executives like zappos does and have a human being answer the phone. Allow people to book a table in your restaurant over their mobile devices and give them a time to arrive at. Tune your website to work faster or buy more processing horse power. If financial constraints prevent any of those, the least you can do is explain it with true empathy, say sorry, mean it and work your ass out to fix it as soon as you can.

Relationships are a two way street and treating your customers like replaceable parts of your profit making machine is stupid.

Please don't make me wait, because I won't anyway. If you do I might but only as long as I can find a different option.

I am just saying.

Do you love what you do?

What if you were forced to take a couple of weeks of off time each year. Not a vacation where you go somewhere. Just random couple of weeks of time off.

A few rules apply:

1. You cannot work on anything connected to your organization.
2. You cannot be talking, emailing or getting in-touch with people at work.

You get up in the morning, no emails, no fires, no colleagues, no tasks. Just silence.

Most people who claim to love what they do would freak out if this was done to them. If you are one of them, chances are that you do not truly love what you do. You just love your job. That or your job is just keeping you busy.

People who love what they do hardly have time for insecurities and freaking out. Most of them have activities other than work that allow them to workout their creative mussels. This is why countless kickass programmers spend their time blogging, coding on open source projects, launching free products and answering questions on free forums.

These folks would be just as happy if you brought them out of their work environment and gave them a month long unplanned time off.

Others will freak out and resort to nothingness.

Which of these two groups do you belong to?

When you have nothing to do, what is it that you usually do?

Just a little something to think about.

There is an attack of cheap Chinese and Indian smart phones with cool features in the Indian cell phone markets.

Every cell phone shop is littered with tongs on these. Every television channel seems to be running advertisements featuring some of these phones.

Even when Indian and Chinese cell phone companies try to woo customers with the lowest of prices and more features, any Indian who wants a smart phone eventually buys a Nokia or a BlackBerry.

Why are the Chinese or Indian cell phone companies with better pricing and more features failing this badly?

One reason is quality but the bigger reason is the lack of a story.

If you buy a simple cheaper model of Nokia that is not a smart phone, your story is that you are not interested in smart phones. You just need something that lets you talk. You are just not into smart phones and that is a perfectly acceptable story you can tell your friends and colleagues at work.

If you buy a Nokia or a BlackBerry your story is that you love smart phones and you have a good smart phone.

When you buy similar features sluggishly stitched together by a Chinese or an Indian brand your story is, you love smart phones but you cannot afford a good smart phone.

The result?

Even in the Indian market, which is hugely sensitive to the price advantage, no one seems to like this story.

You almost never win product battles by throwing in features hastily stitched together and then by competing with just price.

The Wallmart model is starting to work less and less with every passing day, even when it comes to selling your product in India where people are super sensitive to price.

If your product is not backed by a concrete story that make people feel good about buying or using your product, no one cares about your product. It is that simple.

What story does your product tell?

Just a little something to think about, if you work on a product or are planning on working on one.

"If no one monitors their work timing and the quality of their work closely enough why will they take their work seriously?"

An acquaintance asks when I am talking about the team I work with, our no policing work culture.

If you want to build great teams ask the right questions.

Why will they take their work seriously, is a wrong question. Why won't they, is the right question.

When you ask the wrong questions you get policies. When you ask the right ones, it becomes easier to trust people and you get innovative life styles with kick ass work cultures.

Before you ask a question, ask yourself if you are asking the right question.

Pick your questions carefully, for they decide your lifestyle and the answers that you eventually find.

There are times where we (the collective we, involving anyone who has ever been associated with the world of software development) silently enter the unspoken agreement of leaving a few things unsaid. These are what I like to call white lies.

Hope is often the root cause of most white lies.

The developer checks-in the code, hoping that if there is a bug someone from QA will catch it and report it.

The tester rushes through the test cases and then does no ad-hoc testing, hoping that the developer would have written decent code.

The manager provides a push, hoping that if there is an issue the team will let him know.

The team provides a hushed up feedback sugar coated with a truck load of mitigated speech, hoping that the manager will read between the lines.

Hope driven white lies where everyone knows they are fu@#ked but no one says so are dangerous, because 1) you're lying 2) you are paving the path to a perfect text book example of a disaster caused by too many small things going wrong in the right sequence and order.

Irrespective of who you are, a developer, a tester, a graphic designer, a business analyst or a manager, this week, stat by calling bullshit on quite lies. Stop hoping and start doing what you do with passion, conviction and a strong spine.

I wish you good luck.

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.

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.

You have gathered for a meeting. This one is not the casual sitting around the fire, chatting about the meaning of life and discussing the movie at the theatre in the next block, meeting.

This is serious business. You know it. Your boss knows it. His boss knows it too. They are all there. Pumped up. There to take a decision about the features that we will need to build in the next one month to wipe out the competition or maybe to pick a framework for your next project.

"So, do you think we can ship by end of this month?"

"Which framework do you think we should build this using?"

"How many more people do we need to get this done by the end of the month?"

Yeah. I know. Its tempting.

"Gee Boss, I think we should build this using Dot Net Nuke and hire about three interns and a senior engineer on the team."

Bad move.

Shut up!

When you are in a meeting your job, as a manager, leader or whatever it is that you call yourself or see yourself as, is to avoid decisions from being taken over a single meeting. Classical business analysts and managers will tell you that this is because you need to protect the team from your upper management. That explanation is almost always bullshit. Your team does not need protection from the upper management.

If your upper management is getting you on a meeting and asking you these questions chances are that you are one lucky son of a gun who has landed with a really strong senior management team who cares enough to ask you what you need.

That doesn't mean that you have to give them an answer right away though. Like I said, Shut up. You need some think time on the time your team is going to take working on this. You need to see if Dot Net Nuke really fits what you are trying to build, or will you just end up building yet another Frankenstein.

Overall organizational decisions taken in a single meeting are equally risky. So Fred miss utilized the corporate credit card. You are in a meeting discussing the problem. Someone three levels above you hastily panics. "So, do you think we need to stop the corporate credit cards for everyone? Are they really needed?" - Again, temptation to give your instant opinions. This is one isolated incident. Maybe it needs an overall organization policy change. Maybe it does not.

Whatever it is, the only thing that I can tell you is that you do not need to decide the solution over that meeting.

Breathe. What you need to do in this situation is protect yourself and your management from one of the biggest threats of the software development world: Panic.

When you are in a meeting, the pressure to take the right decision is  immense. Chances are that you are not going to be able to Blink well in this scenario. The solution, the right solution to the problem is most likely to show up tomorrow morning, in the shower.

When you answer in a meeting, your management listens to you and decides to move in a particular direction, all of it happening during that one meeting, you block the possibility of the best solution showing, in the shower the next day.

As tempted as you might be to open your mouth during that meeting, shut up. Sleep over the problem. Give it some soak time. Chances are that the solution you have the next morning will be much better than the solution you have during the meeting .

When it doubt, choose silence over spontaneous reactions in meetings. You are not going to make the best of the decisions in a meeting when you are surrounded by people and have precisely a couple of minutes to react and take a decision. Go on. Defer your decisions. Ask for soak time. Most of your important decisions deserve at least a night long think time and what you need to do, is learn how to ask for it. Blatantly and clearly.

I wish you good luck.

Neuroscientist around the globe now believe that human beings can be classified into two primary groups when it comes to their sleeping habits and productivity. Some of us are much more effective during the day while others are much more effective at night struggling to get up every morning.

The whole idea of having a common work time where everyone does a nine to six is really counter productive as per this theory, but that is not what this post is all about.

One of the building blocks of the theory that some people are much more effective during the early morning while others are much more productive during the late night dates back to the days where our ancestors were living in the woods and were gatherers.

It is believed that during that rather large number of years of evolution, the human race had figured out how to collaborate better for survival. Each tribe was comprised of typically two kinds of human beings. There was a group that was responsible for getting up early and gathering food for the tribe. Then there was the group that was responsible for staying up late and guarding the tribe against attacks from wild animals.

Years of evolution, morphed the neural pathways of these two groups in such a way that the first group was much more attentive and functional during early mornings, while the other group was much more attentive and functional during late nights. This theory, received a lot of attention in a book called Brain Rules  by John Medina

Once you start comparing the modern day world with it's roots from the prehistoric era when our ancestors were barely getting down the tree and lighting fire,  behaviors or individuals and how the human race might have morphed start making a lot of sense.

Take for instance the classic act of gathering in meeting rooms, sitting around a table and talking at length for hours about what is wrong and how we (the collective we) should fix it. The meeting room is typically filled with two kinds of people:

The First Kind: The young and enthusiastic developer, who is clearly not very comfortable there. He is fidgeting in the chair, looking at his watch to see the time, wondering when the meeting is going to get over, thinking about the memory leak in his code and how he is going to fix it and talking occasionally only when asked a specific question.

The Second Kind: The manager from the best management school in town, who is contributing actively to the discussion. Asking a lot of questions. Dragging the meeting longer, is in no hurry to end the meeting and in all probabilities is going to go and watch you tube videos after the meeting.    

Your meeting is a Bonfire from the Pre Historic Era.

No. Seriously. Dive back into the depths of time. Our ancestors lighted up pieces of wood every night and gathered around it too feel the warmth of the fire. The fire was a symbol of safety. If you were a tribe from those days, who do you think would have liked the idea of spending an entire day and night around that fire?

The gatherers had stuff to do in the morning. They had to catch enough sleep, get up and get out there to get as much food for the tribe as possible. The guarders had stuff to do during the night. They had to catch enough sleep during the day, get their spears sharpened and be on the lookout for wild animals during the night. It was the sick and the old, that loved the fire the most and liked the idea of sitting around these fires for most of their time.

Nothing really changes all that much in the formation of the human brain in just a few hundred years. The fundamentals still remain the same. Look around you and you will discover that the people who enjoy the meetings the most are either incompetent, out of shape, out of touch or not very productive. They are not bad human beings.

They are just the 'sick' and the 'old'' of the software development world. The meeting to them is pretty much the bonfire. It is symbolic to safety, because they can almost never introduce a bug while in a meeting. It is symbol of warmth because nobody every shouts at each other in a meeting. It gives them a sense of belonging because they can now contribute (anyone can give ideas) without having to work really hard for it.

The meeting is their only way to stay connected to the tribe and get a share of the food and protection by the gatherers and the guarders.

The point of this post, was to remind you that if (and I am just saying if) you start enjoying your meetings, you are not gathering food and neither are you guarding the tribe against wild animals.  You are just squatting around the warm and cozy fire expecting your share of free food. Contribute. Do some real work. Even if it is small. The least you can do is, stop enjoying those meetings and stop dragging the rest of the tribe into it.

Go on. Say no to those meetings.

I wish you good luck.

Most organizations seem to have an itch for logging timecards of employees. What time did they enter the workplace? When did they leave? Did they spend nine hours at work? Policing is stupid. Number of hours you spend at work have no direct correlation with your productivity.

If you are starting an organization and have an unending itch for logging something, start out by logging the number of hours everyone in your organization spends on meetings.

Nine programmers gather for a 'quick discussion' which blows from a five minute discussion to a one hour meeting is nine man hours wasted.

Being in a meeting is worse than not being in office. When you are not at your workplace there is a possibility you are working from somewhere else. When you are out having fun, your chances of coming back fresh and putting in more productive hours are high.

When you are in a meeting, we know for sure, you are not working and you are getting drained out.

Of all the things that most typical organizations log or care about (time spent in office, processor cycles, dress code), most things do not have any direct correlation with developer productivity.

Number of hours spent in meetings per day is one Metric however, which does have a strong direct correlation to productivity.

If you are not actively measuring and logging this metric your organization is a classic case of an ostrich burying its neck in the sand.

If you are logging this metric, chances are that the three hundred unproductive man hours that you spent on meetings last month are going to make you lose some sleep, specially when the reports are in your face and that is a good thing. Now its time to do something about it.

That something is not another meeting on how you can reduce your meeting time.

Can a ten minute detailed email do what an hour long meeting would have taken? Can you use screen capturing utilities to do videos to give to the clients instead of getting the entire team to demo a new feature to them? Are there any better ways to capture and pass information than people being hustled into meeting rooms. Ask the difficult questions that you avoided for months or even years.

If you can spend three hours to do a video and avoid a one hour meeting, you should. Videos typically just require one person to create them. Videos aren't intrusive. Videos are permanent and reusable. You are much better better off investing the three hours, rather than inviting ten people in a meeting, interrupting their flow and blowing up the talk time of your organization to ten hours.

Meetings are not just toxic. Meetings are emotionally stressful. Meetings interrupt flow.

So here is a golden rule for your startup: Log your meetings. See how man hours you drain into sitting in meeting rooms and talking and then rage your very own organizational war against meetings.

I wish you good luck.

You. Yes, you. You can get fired too.

Years ago, this was one realization that dawned on me during a rather strange project.

I was a talented young engineer, minding my own business, learning, growing and staying as far away from office politics as I possibly could. My chances of getting fired were fairly tiny.

Then suddenly, on a fine Monday morning that I found myself in a meeting room with two other programmers and a rather strange project manager, drawing a line on a white board and pasting yellow post-it notes on it left and right. We had been assigned to a nine month project, which the client wanted done in three months.

The timelines that this guy was pasting the board were not making any sense. He was using intimidation left and right to make us say yes to his timelines. We sat there nodding, telling ourselves: how bad can this be. we will work late nights. we will make it work.

If this was now, I would have just said no. On further intimidation, chances are that I would have gotten up, said "screw you" politely with a broad smile on my face and left the meeting.

When you are young the idea of giving up seems insulting. You think of yourself as a super hero ready to rip off your shirt, jump out of the window, fly and rescue the sexy young girl stuck with the evil guy. Besides the fear of getting fired from your first job is pretty much like being rejected or dumped by your one of your first stupid crushes.

Three months later we were struggling with the project. This same manager was grabbing us by our collars and making us ship. The client was throwing their tantrums and we, like any other software development team, in a typical consulting shop, were trying our best to hurry up, ship shit, run away to the next project and not look back.

At the end of third month,  when a particular memory leak error refused to go and the application kept crashing left and right, the realization dawned on us. We realized that we might be fired if we cannot ship this thing on time. It took me another three months and a lot of good luck to overcome the fear, make up my mind to stick around, clean up the shit, ship a decently acceptable version and get rewarded the best programmer award in my organization.

The award did not mean a thing and even today I preferred to refer to this project as the biggest successful failure in my professional life till date. Even today the certificate hangs on a dark wall of a small room in my home, reminds me, every time I look at it, that:

1. Your organization typically cares much less about the integrity of your work than you do.
2. Your organization typically does not care about differentiating your true successes from colossal f@#kups and failures in your professional life.
3. You can get certificates and recognition by shipping crap, if you just meet the timelines your manager wants you to meet.

But of all the things that the certificate reminds me, the most important thing that it reminds me is this: If your organization expects you to do the undoable, you are already F@#CKED. You are better off, showing some spine, saying you cannot do it and getting fired right now rather than waiting for things to get messy and then getting fired like a spineless, gutless dolt.

Don't compromise with your integrity and lower the basic standards of what you ship. If you are going to get fired, at least get over your insecurities and get fired for the right reasons.

I wish you good luck.

Fred is overworked, underpaid and frustrated. He carries his grievances, miseries and frustrations, both personal and professional, with him to work. Ask him to work on something more than the scope of his official business card and Fred gives you a look that makes you feel sorry you asked.

Fred also has a lot of complaints from life in general and his organization in particular. He is out there to make you, the customer or his colleague, pay for it. 

They are not paying him what he deserves. They are making him slog. They are not professional enough. It is all their fault.

My advice to Fred is to stop. Stop whining like a baby and think. You only have three options:

1. Quit your job and go find a new one.
2. Start something on your own.
3. (And if you cannot do one and two) Shut up, stop whining and leave your frustrations at home when you come to work.

Every workplace is going to have their share of problems. Yours has its problems too. Big deal. Whining is almost never the solution to any problem. Two people gossiping about the problems in their organization but neither one of them having the spinal cord strong enough to do something about these problems, is just a waste of their time and a toxic thing for the overall culture of the entire organization.

Making your organization, customer or manager pay for it by scoring fouls is even worse.

Venting frustrations is a part of whining. It is not particularly difficult to do. In fact, it is really easy to do. It is also the stupidest things that you can do. You are much better off writing a constructive email, bringing up the problem with the right people, dropping your mitigated speech, saying how bad things are openly  and taking the hit for it.

When you work for an organization and you do not like it, there are only two things that you can do, you can change your organization or you can change your organization, either way, going to work with a frowning face and a truck load of frustration so that you can vent those out on your managers, colleagues and customers is the stupidest harmful thing that you can do to your own career and character. Stop knitting your eyebrows now.

Stop. Smile. Say cheese. Now go to work.

I wish you good luck.

I hate rules. Having said that, I also find the idea of "Rules which break all rules" fairly interesting.

So you have thought about leading your own team? Leading an organization? Or starting something on your own?

Close your eyes and imagine that I am handing you your dream organization. Giving it to you. Just like that. What I want you to do instead, is give me a detailed Rulebook of things that you will absolutely do and not do in your organization.

Well not the 'rules' per say but the overall guiding principals.

Things that will become the foundational building block for your organization.

A couple of days ago I asked this question on Twitter:

Scott Berkun one of my favorite mavens on the subject of innovation, responded to the question with a rather interesting tweet.

His interesting response:

@thousandtyone *only* hire people 1) who love to work 2) who like/trust each other 3) who are self-aware 4) have a sense of humor

The response is particularly interesting because even though I have always enjoyed working with folks who have a sense of humor and have always been a little uncomfortable around people who take themselves way too seriously, I never quite saw it as a criteria for hiring individuals.

Sometimes you need someone else to pin it down in exact words for you to realize how strongly you believe in an idea.

A new idea was born.

A collection of really small posts highlighting things that matter to me (and hopefully you) when building your own team or your very own small organization.

It's the organizational rulebook for a kickass environment.

If you had a startup and were to write down a few rules for a kickass environment which rules would you pick?

Time to compile a few of these that come to mind and any others you might think of in a series of post.

Go on. Click the comment link, send me an email or send me tweet at @thousandtyone and contribute.

Three guys building what they love and being profitable at it is a story; five thousand bodies building yet another enterprise software is a factory.

One guy selling a million copies of a one dollar iPhone application is a story; an enterprise bidding for yet another million dollar contract, is just a marketing gimmick.

One funny two minute video on YouTube is a hilarious story; one hour of regular television sitcom is grunt work in the life of a production house.

We don't want to hear about you rambling about yet another enterprise, yet another deal or yet another production house.

We don't want to hear about the big guys again. We know how BIG works.

Big is starting to get really boring.

A small blog post with a brand new thought, a tiny code snippet that makes you a better developer, a small open source utility that simplifies your life, a small you tube video inspires you, teaches you or makes you smile... these are all small stories you can weave.

I am too busy to work on it. I am not big enough to do it. I am not smart enough to do it.

BULLSHIT! Lame. Excuses.

None of these excuses work when it comes to these small stories.

They don't take a lot of effort. They don't take millions of dollars. They don't even demand that you quit your day job. Just a little bit of consistency.

We know you can weave them. Everyone can.

The only real question left for you to answer is, will you?

Go start something really small and celebrate your doneness.

I dare you.

When we landed in her organization as external consultants responsible for reviewing a project, Jane had a business card said that she was responsible for all IT purchases in her organization.Vendor evaluation, comparison and negotiations for every piece of hardware, laptop, server, cable or wiring that her organization purchased.

Buying a book that someone in her team needs, was a completely different thing though.

There was a systematic approval process involved which she had to go through.

The fairly convoluted process involved in taking her team on a quick lunch is even worse than buying a book that they need. Every time her purchase request for a book was rejected her organization silently signaled to her that they did not trust her judgments.

This was not a typical Fred mucking around with code. Someone who wants and needs to be monitored and questioned on every step.

This was not a typical robot.

This was a person with a job role that demanded that she took judgment calls and yet we sat in meetings where her own managers rejected some of her best judgment calls for all the stupid reasons.

The outcome? Detachment.

She had been given two promotions in the last two years. Clearly they knew what she was capable of delivering. And yet there was continuous reluctance in yielding just enough freedom that would let her do her job remarkably.

A promotion is the act of telling someone you trust their judgment with bigger stuff.

Getting out of their way is the act of actually trusting their judgments.

Most kickass builders, story tellers or movers will not judge you by what you tell them, they will judge you by what you actually do.

Trusting someone's judgment calls and getting out of their way so that they can take independent decisions, succeed, fail, learn and grow is one of the best gifts you can give someone.

Are you giving this gift to your team by trusting their judgments?

Just a little something to think about.

How does the data of a project that is hugely successful differ from the data of a failed project? Actually, it is not very different. Most projects are slightly late. Most projects are slightly over budget. Most projects have variances. What sets a successful project apart from a failing one is the story that surrounds these projects.

Even though I did not know how to name it back then, one of the most valuable lessons I learnt as a young and budding developer, was that we become the stories we tell ourselves. That and there was a breed of people who really kicked ass at the art of story-telling.

Besides builders who build stuff, the people who weave remarkable stories are hugely important to the success of any software (or for that matter any) project. In this chapter of the book I introduce you to the special breed of people I call story tellers.

You can get the chapter from here.

The guy who used to score A+ at all his exams in high school bumps into you at a shopping mall and wants to "catch up" with you. He wants to know where you are working. You answer.  You tell him that It is a small startup based out of the valley. He wants to know how many employees your organization employs and cringes at any number less than a thousand. It does not come as a surprise to you though.

You already knew that you had just bumped into a lousy moron who was going to judge your success based on your organizations success and your organizations success based on it's head body count. You knew it the moment you saw this gentleman and your mind raced back to gather recollections of your high school days and your interactions with him.

The mentality is mostly a reminiscent of the individuals upbringing. You instantly dive into a flashback. This fine man in front of me is a classic example of a family and a school that succeeded in turning a perfectly smart child into a lousy moron.

When we (me and my brother) were young, grades and marks were not a huge deal in the family. Of course we were expected to fair well, but our parents did not lower their perception of our intelligence or treat us any differently if we scored a "B" instead of an A+.

Life for this acquaintance of mine, was hugely different though. He had a family which evaluated his intelligence based on his grade. The guy had fierce pressure of topping each test, merely to leave his interactions with his family and their perception of his intelligence un-tempered.

As much as I could never connect to him, I did feel sorry for the guy back then.

He was a classic example of someone who "fits it" and expects everyone in the classroom "fit in". Someone who has all the answers but does not learn how to question what the book says. Someone who never lands in trouble to save a classmate from a prank they pulled together.

When you use lousy numbers with no real correlation to success, to measure and judge not just yourself but everyone you meet, you develop a narrowed vision of reality. You become this acquaintance of mine.

You start hiring employees based on their scores in their IQ test. You start taking certifications  seriously, you let designations define your own net worth in your every own eyes and worst of all you start turning your own kids, who are awesome at the art of exploring, failing and learning into idiots who know how to cheat the system and score even higher numbers than you did.

If you are a programmer my advice to you is seek the most innovative organization that you can find out there, even if it has just three people working for it.

If you are a responsible for hiring my advice is stop recruiting people based on their IQ tests and most importantly, if you are a parent, my serious advice to you is, stop evaluating your child by his grades and stop judging him. Stop it. Now.

Observe what your child loves doing and nudge him to do more of it. If all goes well, you might have kid who grows up to be someone who is happy doing what he does not go around comparing his grades, number of employees in his organization or other random numbers with numbers of other random people that he bumps into at shopping malls, to feed his insecurity. Seriously.

One of my favorite Ted Dziuba post is the one where he advices everyone in the software business and managers in particular to stop using the word "we" and other enterprise words when talking about tasks and responsibilities.

In his classic, loud and highly opinionated way, Ted explains:

Yesterday, I spearheaded a new movement at the office. I stopped using the word "we", and started to say what I really meant to say.  For example, instead of "We should fix that bug", I say, "You should fix that bug", and good God is it satisfying.

There are a couple of motivations for this. Firstly, one of the key things I've learned being a for-pay writer is to show some conviction. Secondly, the passive discussions about defects and delegation and responsibility really started to irritate me. Why not just tell it like it is?

When I worked at Google, I picked up on a really annoying trend in the software industry (or maybe just in Silicon Valley) that I call "fuck-you with a smile".  You never want to outright blame somebody or something, rather, it's best to state the existence of an issue and then ask "the team" to fix it.  We should really move that icon ten pixels to the left. We definitely need to fix that concurrency bug. We should probably have that all done before lunch.

Well then, Mr. Manager, you had better get cracking, because I've got some YouTube videos to watch.

I can see a whole breed of managers knitting their eye brows at the whole approach, but if there is one thing I can tell you after working at countless client offices and observing countless other organizations, it is that it is often the organizations that focus on individuals, the virtues of selfishness and create win-win situations, that are the most fun to work at.

These are also typically the environments which create the best of the teams which are closely bound because every individual understands clearly that their best interest is in complementing the efforts of others, flocking well without bumping into others and giving in their best, because their best earns them the best of appreciation.

An environment where every single achievement of yours is masked under the banner of "the team" often tells the story of an insecure manager spending all his time making sure no particular individual gets more than a certain share of credit.

Every time you plan on using the word "we", the least you can do is make sure that you at-least pick a considerable part of the task you are delegating and actually do it YOURSELF. The "Lets work on this" approach works wonders if you genuinely mean it but if you cannot take up a sizable part of the work, shut up and use "you" or "you guys" instead of "we" because YOU Mr. Manager, are not going to do any real work on this assignment.

The whole idea of only using the word "we" when I am actively contributing in solving a problem is something I may not have always adhered to in the past but it is also something that every single one of us I need to be careful about, specially while working with a team of kick-ass developers.

You want the best to give in their best and add the most value, not assign every task to the mediocre larger "we" or the black hole called "The Team" where everyone is responsible for talking about it but no one responsible for actually doing it.

Stop hiding behind the collective curtain of "we".

Pick up a sizable chunk of the work in the overall task and then by all means use the word "WE", but don't use "WE" to make yourself "somehow" involved in the work that you have not done. If you want credit and involvement, earn it. Go take up a sizable task now and ship.

If you cannot do that, consider shutting up and letting those who are  driving, get the due credit for their work. If you need "them" to work on something, while you wait for them to complete and play online poker or attend meetings in the meantime, the least you can do is be honest about it and say it with conviction. Seriously.

Builders and Story tellers have their own set of problems.

One of the biggest ones is that if you are an amazing builder or an amazing story teller, chances are that you are an artist.

You get ideas in the shower that are so strong that they hold you by your collar and do not let you go till you put them within the curly braces of code functions or on the light grey pages of a notebook or a word document.

You get fragments of inspiration.

You get headaches with multiple threads of ideas running in your brain at night as you try to sleep.

You thrive at creativity but your problem is that you cannot fill your tax forms without mistakes.

Your problem is that you can get an entire system built but sometimes you blank out and forget what it is that Jack in your team is supposed to be working on.

Dam! You said you will put that down in that excel sheet. You said you were going to get better at tracking.

Newsflash: You are just wasting your time trying to become someone you are not. You are a builder. Not a mover. There is a difference between the two.

Every project requires builders.

Every project requires story tellers.

What every project also requires are movers.

A mover is an otherwise quite tester who walks up to the developers desk and casually reminds him what he needs to work on for today without brining a truck load of process in the middle. His business card or title does not entitle him to remind developers what they need to work on.

But he does it anyway, because creating movement is a part of his nature.

Strangely enough, Instead of resisting or saying no, the builder, listens to him because he knows the mover is not bossing around. He is just helping by being himself.

A mover is an otherwise silent document formatter, who points out the critical features the team has been missing for the last three sprints and that you, the project manager have completely forgotten about.

When Jack says he is done and is about to sign off, the mover jumps out of nowhere and reminds him with a smile that there was a bug that he had said he would close but never did.

A mover notices the slightest of broken windows.

A mover is not in your face. A mover is not irritating. A mover is NOT a manager. A mover does not go around with Gantt Charts and detailed project plans. Yet, a mover is ten times more efficient than a dozen managers running around with their Gantt charts.

Being a mover, means that you "have to" be moving. You have to be in a team that is moving. You sense movement. If your team is slowing down you are the first one to sense it. If your team is moving at a dangerous velocity you notice that too.  But you don't freak out. You don't whine asking others to speed up or slow down. You silently and quietly create an environment where more thrust is applied or thrust is reduced.

I don't consider myself to be a very good mover. I am nowhere closed to being organized. I don't remember stuff. But every time I work in a project that has a team size of more than one, there is always a mover involved. My current project at work for example has multiple movers.

Almost every given day I am nudged by a mover or two reminding me about the stuff that I had promised I would do and I did not do. The movers understand that my bosses called and wanted me to work on an urgent document during the weekend.

But then the movers are relentless. The movers will also be at my desk Monday morning, just casually chatting about what they did during the weekend and then just as they are leaving, reminding me that if I am free I can take up that bug that I said I would fix before the urgent document came up.

If you give me the slightest of hints about taking the movers out of my project and I will fight fiercely to keep them in my project, because while the builders are building stuff and the story tellers are weaving stories, the movers are watching the speedometer, the broken windows and the loose ends, rushing to remind you with a smile that you missed that final stroke of brush in your painting.

Have you identified at least one mover in your project? If you haven't, chances are that your project is fumbling right now as you read this, even if you have both, builders and storytellers working on your project. Go find a mover. Then give him the liberty of being himself and let him build some movement with a gentle nudge every time he sees your speedometer fall, your window break or your painting finish without that final touch up.

I wish you good luck.

He bitches a lot. The whiner in your team, I mean. The classic whiner feeds on gossip. He feeds on creating confusion through communication. A whiner usually whines because whining and bitching is easier to do than shipping something.

The classical management folks and people from HR will give you intelligent sounding advice. Talk to him, they will say. Counsel him. Have a discussion with him.

BULLSHIT.

Then there is other breed that will panic at the whining and bitching. Fire him NOW, this bunch of managers will tell you.

More BULLSHIT.

Unless the whiner is a political scumbag, there in a whiner in all of us. The whiner whines because he is lazy. Because whining is easy. He whines because YOUR culture tells him that he can get away without shipping if he whines.

If you want to genuinely help a whiner and your organization, here is the golden advice:

Get him to ship something. Anything.

I don't care how small it is. I don't care how insignificant it is. I don't care if he ships crap. Make him ship. Consistently.

The same advice works for almost anything in life. Small incremental steps. If you have never run before, running just hundred meters will find you panting like a wild dog. They key is to do it. The key is to keep doing it. Then do it more.

Shipping is hard. Shipping means growing out of your comfort zone. Shipping means you take your ass off that couch, stop bitching and actually add value. Shipping, is also addictive. Shipping adds to a sense of well being and once you start becoming good at it shipping is fun.

Get your whiner to work. Get them to ship something. Anything. Leave no room for lame excuses, moaning or bitching. Make it clear to your whiner that you mean business. Chances are that they will either get so uncomfortable that they will leave or they will slowly and steadily become effective at what they do and have much less time for whining.

Repeat the process.

Do it till the whiner has either quit or till you have a fully productive employee who does not have time to whine any more.

Of course, there is a little bit of a whiner rooted deep down in all of us and if you have not been steadly shipping for some time now, the same recipe works for fixing that whiner within yourself too. Try it.

I wish you good luck.

The internet is littered with articles and blog posts by project managers on how they spoke the truth about their project timelines slipping, how their clients loved them for it and how they lived happily ever after.

I have had my share of those stories and I would love to share them with you, but that would be BORING.

I could tell you that honesty is the best policy, but that would be way too CONVENTIONAL.

The reason why you should choose to be honest in your communication and deals is not because honesty always leads to a happy short-term ending. Honesty is not a commodity that you try to market when hell breaks lose and expect to sell it every time. If you think of honesty as a commodity, chances are that you will find it really hard to market.

Honesty is not a last resort escape route.

Its a way of life.

Its your attitude.

Its who you are.

Honesty begins by being honest towards your work. If you have given your hundred percent, being honest when disaster strikes is not a very difficult decision. It's the gnawing guilt of not giving in your best that makes honest communication so much more difficult when the hell breaks loose.

Your honesty test began when you were doing your job when the sky was blue and when the birds were chirping, not when the sky started falling.

What were you doing when the storm of panic had not started? Working to the best of your abilities? Honestly?

Honest communication is not usually very hard if you were. If you know you were not, then honesty becomes that much more harder. You find yourself playing with excuses, jargons and your fingers by pointing them at others.

I have played the blame game before.

Writing about it and admitting it, even years after it happened, was much more difficult than most people think it is but the whole point of writing about it was that it was a lifestyle change. A transition that happened over a period of years, is still happening and hopefully will continue to happen throughout the lifetime.

The good thing about some of these experiences though, is once you have been through just one of them and burnt yourself, the decision of being honest towards your work becomes a hardcoded part of your lifestyle; and once that happens, the decision of being honest in your communication, even when the sky is falling is a no brainer.

If you were a programmer did you write the best of the code you could? Fought to the best of your abilities to avoid crappy decisions?

If you were leading a team, did you do the best leading, keeping an eye on the project without getting in the way and the best mentoring that you possibly could?

If you were a marketer were you honest to your client when telling him about your product features?

Go on. The next time the devil knocks on your shoulders nudging you to take that shortcut in your daily work life, give him a cold shoulder. Being brutally honest, when the hell breaks lose will be that much more easier if you know deep down inside that you were honest all through and that you did the best you could.

I wish you good luck.

When was the last time your team actively decided not to ship a feature that was done?

When was the last time you had a fully complete post sitting on your hard disk but you told yourself it was not good enough and decided to delete it?

There are times when you watch a lousy movie and you wonder why the production department even bothered releasing it?

As creative individuals we like working on stuff.

Stopping often becomes hard for three primary reasons:

One: The more effort you put into stuff the more attached you become with the stuff you are working on. This attachment creates blind spots and an inability to judge the output of your efforts objectively.

Two: When the creative endeavors have financial aspects involved realizing that you need to stop becomes even more difficult. Yes the movie is lousy, but if we release it at-least we make something out of it. Yes the product is lousy, but even if we release it at a reduced price we stand to earn something out of it. Lets just give it out for free and try to get some users.

Three: When creative endeavors occupy a lot of your time, stopping them, becomes an ego issue. Stopping now is just going to mean the world is going to know about it and think you were an idiot to continue for this long. If the product, the blog post or the endeavor was your idea to begin with, the ego at stake is even higher when it comes to stopping.

Gears are switched. You move to an auto pilot mode where you are doing nothing but building mediocre features on an already mediocre framework. Version after version of the product are rolled out. Every mediocre blog post on your disk is published. Every boring movie is released.

Before you know it, its not just your product, your blog or your movie. You are boring. You are mediocre. You are lame. We do not care about you any more. You are that guy with a boring blog, that director who makes boring movies or that software body shop that hires cheap cogs and builds lousy products.

If you have a product that you are deeply passionate about and believe in, don't worry be crappy works, but if you are working on auto pilot and just not feeling it, shipping stuff that is boring, makes you boring.

Stop. Give up shamelessly. Hit the Delete button. Now.

Fred took rounds on the office corridors during the evenings to take a feel of who was busy versus who was reading an online newspaper or playing a video game. If you happened to have anything other than work running on your screen when this gentleman took his rounds every evening, the least you could expect is an email with a list of tasks that you need to immediately start working on. The most you could expect was a taunting sarcastic remark.

I see a young and budding manager somewhere knitting his eyebrows , folding his hands and taking a defensive stance already. Somewhere, in some corner of the world, there is a young and budding manager reading this, talking to himself and saying this: What is this idiot talking about now? I mean resource management and utilization is all about making sure that your resources are utilized at an optimum level. Isn't it? Huh? Huh? Huh?

Actually, you know what, if you have heard this 'resource utilization' line or if you were that young and budding manager who was thinking this, chances are that you have picked it up from one of the two places. One is through your underpaid teacher at a B-Grade management school. The other is through your previous manager who you looked up to.

Now here is the newsflash: Chances are also high that your underpaid management teacher never actually managed a single live project in his entire life. And as far as that previous manager that you looked up to is concerned, well he might just have been a regular old jerk who was managed by other jerks when he was young which is where he picked up the thought process without questioning it.

When you take a team of kick ass programmers and put them on a kick ass project, you form a self sustaining eco-system. Assuming that you have hired correctly, if you leave a bunch of builders free for sometime, good things happen.

Every programmer has "TODOs" in their code comments. Things that they tell themselves they will come back to later. Every designer has design changes that he would like to refractor if he had more time. These are exactly the things which differentiate a remarkable product from a lousy mediocre one. When you leave a kickass team alone chances are they get sick and tired of reading the news in about and hour.

Then they often tend to come back to these changes and they tend to start working on them. Silently. Quietly.

If you have a product that has been running for more than a year now and a passionate team that loves working on the product, try telling them nothing to do for a couple of weeks and see how they react. Chances are that they might either give you a product with a stronger, faster and much more stable foundation or they might come out with features and really small changes that might pleasantly surprise you.

Stop those stupid status meetings. Stop monitoring every hour of your programmers. Stop giving them new assignments as soon as the last assignment on their list is marked as done. If you have hired the right guys and have left them alone, chances are that they are working on stuff that needs attention. Stuff that you might not even be aware of. Stuff that might usually come back to bite you two years from now. If they are free, they won't sit quietly for long.

If you have the right people, they will be much more worried than you are about having nothing to do.

Now go cancel that status meeting. See how it goes.

I wish you good luck.

In this video on BigThink Jason Fried the cofounder of 37Signals talks about interruptions at work.

The video is excellent when it comes to dealing with interruptions and finding out what is wrong with a typical office workspace today. 37Signals by far have been one of the most vocal when it comes to calling out on bullshit of other firms and they are often heard because they are successful.

I have quoted 37Signal so extensively that I have often been accused of being a 37Signals fan-boy.

To be honest, I am one.

The problem with blind fanboyism however is that you often tend to see everything positive about the organization and lose the objectivity to see mistakes the organization is making.

The recent video on 37Signals new office space however, is disappointing, particularly if you take the fan boy cap off and analyze their office objectively.

To begin with the video shows the entire team in a meeting or a conference. I am sure this is a rare occurrence at 37SIgnals but definitely not the right time to be shooting the video specially when you take strong stands on how toxic meetings are. What is actually even more disappointing is that their office seems more like a typical cubical farms with open workspaces designed for interruptions.

When  you are an organization as small as 37Signals who believes in not interrupting your developers and letting them get in the flow, why build classic cubical farms where interruptions are a part of the design?

Why not learn from FogCreek office tour video which seems to suggest that they are putting their money where there mouth is by giving every developer most items on the programmers bill of rights?

I'm just saying.

Okay, enough critical commenting. I am going to wear my fan boy cap again.

By the way, did you read rework? If you did not it is definitely worth a read. Go buy a copy now. #Grins.

Venture Capitalist have been using this technique for years now. There are a few out there who browse through countless PowerPoint presentations and every minute detail of your business model. Others however are more interested in knowing you as a person and every question they ask revolve around judging you as an individual.

As someone who has been given funding offers without any presentations, ideas or even asking for them, the aspects that some venture capitalist use to fund you, confused me, till I learnt first hand from a venture capitalist, that he was not interested in funding an idea. He was interested in funding the people who he thought were right people.

As an organization however, when you hire employees the equation seems to change dramatically and rather abruptly. We are suddenly concerned if a person knows what a Factory or a Facade is. We are so obsessed with skillets that we tend to forget that is it not the skill set you are hiring. It is the person.

Is the candidate smart? Is he upright? Is he honest? Will he go out of the way to help others? How is he going to handle setbacks? Is he a paycheck programmer?

Hiring a "good" human being should be on the top of your list when hiring.

Everything else is secondary.

Of course, the competence, the kickass programming skill-sets and years spent slogging on code helps, but if you are not spending enough time and energy evaluating the basic personality elements of a person, you are just hiring skill-sets, not people.

What would you rather hire? Three years of .NET or a helpful, enthusiastic programmer with kickass programming skills who happens to be really good at .NET?

The choice is yours. Just like the Venture Capitalists who prefer to fund "good people" over "good ideas" I prefer to hire good human beings with a smart mind over hiring a resume or a skill-set.

Ok, I am done with the post.

You can go ahead and call me stupid or impractical now or you can munch on this thought next time you go to take someone's interview.

I wish you good luck.

As a consultant I’ve been on-boarded into multiple organizations during my career. The best on-boarding is not when the HR takes you around the office on your first day showing you toys like Gyms and swimming pools. The best on boarding is when the HR shows you how the organization you are going to work for is going to empower you as an employee.

A beautiful tool for empowerment was a capped corporate credit card which we were handed on the day we joined work. File office expenses directly to this card and you do not have to worry about getting them reimbursed. This is what I call Hassel free empowerment that comes with a lot of responsibility.

Another beautiful empowerment tool was cell phones. Of course you carried your own cell phones to work, but when we joined we were handed a cell phone that was directly billed to the company.  “You can use these to make any phone calls” – we were told.

Of course it meant work related phone calls but that part wasn’t stated explicitly which made it all the more empowering.

Work from home. Casual dress code accepted widely within the organization. Open internet access.

This was one organization that was serious about empowering employees.

Look around you. How many of your office facilities are nice toys to have versus how many empower you? Having a gym is one thing. Letting your employees take an hour off during the afternoon if they want to and work out is another.

When you are surrounded by policies you can smell that. When you are empowered you can feel the empowerment. Toys are nice to have, but if you do not have empowerment in your workplace the toys mean nothing.

Don’t just give your teams and employees toys to flirt and show off.

Empower them.

I wish you good luck.

Small Talk For Geeks

"Am I in the call?" - that is the question someone I knew first asked when he dialed into a conference call with a client of ours. This guy was a geek and like most geeks he lacked the fundamentals of starting a discussion that revolved around small talk.

"Ok, Is there anything else we want to discuss or should we end the call?" - was a question I saw another geek ask smack in the middle of a conference call where folks were discussing the weather in and around California.

Awkward moments.

Sounds of chirping.

Most geeks around the world are notoriously famous for not going with the flow when it comes to discussions leading to an impression that geeks don't give a shit about anything other than programming or code.

The geek on the the other hand is not evil. He expects that sooner or later, as a few awkward minutes pass by, the discussion will steer towards code, design or what he does. That is when he expects to jump in and connect.

This of course, invariably never happens. After you have blurted a few awkward remarks and have created a few silent moments in your first few meetings you have invariably drawn a wall that will keep your clients, your managers or the suits away from you. This is not personal. They just think you are an arrogant pompous jerk.

You made yourself look like a freak.

The beauty of being a geek however, is that you are blessed with a strange way of looking at things from a systemic problem solving perspective. Think of small talk as a problem you need to solve. Don't try to fumble with the problem as a standard human being who sucks at small talk. Do it as a full time geek dissecting the problem with the intent of debugging it. Typically, solving this problem involves three fundamental steps.

First is content. The second is practice. The third is application of that practice.

Content is usually the easiest to part to figure out. This is where what you already know comes into play. Follow the right guys on Twitter and glance through just a dozen tweets a day. Subscribe to a few RSS channels. You have enough information to start discussion on the typical hot news small talk topics.

The second is practice. This is where it gets interesting. This is what close acquaintances are for. This is where daily meetings and status calls become good. These are your own managers. People you know. People you can fail in front of. People you are comfortable with. Of course you don't have to tell them you are using them to practice small talk. 

I'd say it takes anything between a hundred to three hundred hours of discussion before you will suddenly realize that you can talk for hours about things you know nothing about. This is when you will be able to steer the discussion flawlessly and let the other person speak, by just adding "oh really?", "that's interesting", "I did not know that".

You are not just making the other person comfortable but you are doing something which is very important in the system of conversation.

You are now gathering content from discussions.

The same content that will be thrown at your clients and others when you move to the application phase of training.

The application of this practice is rather interesting. If you have spent some basic time and effort in gathering content and have a couple of hundred hours of practice behind you, small talk should no longer sound like small talk. It should seem and feel like a discussion. The geek within you still knows you are wasting your time with quite a few of these discussions, but he has learnt how to hack it. He knows how to hate it without making it evident that you actually hate it.

Chances are that by now you have actually started liking some parts of it. Chances are that you are now explaining parts of the system to your managers and your clients in simple, precise, direct terms that help them understand things. What is interesting is that they are listening to you now. Chances are that they see you as a smart individual with innovative ideas and not the freak who gets on a call and asks when it is going to end.

Then when you suddenly learn something new from these discussions and realize that your clients and managers are just as smart as you are, only in a different way, you have taken your first step at bridging the gap between clients, management and those pesky developers.

Congratulations.

Now the only thing you need to be careful of is that you don't get carried away with it and that you do not overdo it.

One of the things that I absolutely like doing every time I am at an organization, even if I am just visiting it, is getting a guided tour of the organization.

I have talked about my guided tour of Infosys, getting a bad vibe from it and then the bad vibe getting confirmed by a software programmer who joined and quit the organization within three weeks in my earlier post.

A simple tour or sometimes even a blog post or a video of the office tour says a lot about the culture of the organization. There are a lot of these posts and videos out there. Consider for example:

1. The Fog Creek Office Tour Video on Channel 9.
2. A simple blog post by Jeff Atwood which describes a typical office at Vertigo Software.
3. A video tour of 37Signals and Google

The videos will clearly not tell you everything about the organization but there are general indications that are fairly easy to extract out of these videos.

Watch these videos closely enough, read the posts in detail. Chances are that you will be able to draw your own conclusions and facts about these organizations, not just what the tour guide is trying to show you. That is what a quick five minute office tour video can do. An in person office tour says much more.

Malcolm Gladwell explains this approach of extracting information from the environment where people work or live rather articulately in his book, Blink.

He explains:

Imagine that you are considering me for a job. You’ve seen my résumé and think I have the necessary credentials. But you want to know whether I am the right fit for your organization. Am I a hard worker? Am I honest? Am I open to new ideas? In order to answer those questions about my personality, your boss gives you two options. The first is to meet with me twice a week for a year - to have lunch or dinner or go to a movie with me - to the point where you become one of my closest friends. (Your boss is quite demanding.) The second option is to drop by my house when I’m not there and spend half an hour or so looking around. Which would you choose?

The seemingly obvious answer is that you should take the first option: the thick slice. The more time you spend with me and the more information you gather, the better off you are. Right? I hope by now that you are at least a little bit skeptical of that approach. Sure enough, as the psychologist Samuel Gosling has shown, judging people’s personalities is a really good example of how surprisingly effective thin-slicing can be.

Malcolm shows compelling research that sometimes observing the mere environment in which a person functions or lives tells much more about the person than spending time with the individual in person. He explains:

On balance, then, the strangers ended up doing a much better job. What this suggests is that it is quite possible for people who have never met us and who have spent only twenty minutes thinking about us to come to a better understanding of who we are than people who have known us for years.

Forget the endless “getting to know” meetings and lunches, then. If you want to get a good idea of whether I’d make a good employee, drop by my house one day and take a look around.

Peeking into the bed rooms of people you are about to hire might not be very practical advice, but if you are a developer who cares about joining the right organization, one thing you should definitely consider doing is asking your interviewer to take you for a quick office tour before you accept the offer.

Oh and yes, while you are on the tour, pay little attention to what the tour guide is showing you. Keep in mind the cultural questions that are important to you and watch closely for signals you can pick up to answer those questions.

Is the work environment generally quite?

Do the people seem happy?

How much innovation and thought process has gone in building the office?

How much of the budget has really gone in getting the important stuff like developer offices, laptops and rooms where people work right compared to the fluff?

The answers are out there and sometimes a simple office tour will give you enough information to make the right decision on whether you should accept an offer or continue looking. If you are planning on joining an organization, go on, take a tour of the workplace before you accept an offer.

I wish you good luck.

Earlier when I announced my thousandtyone youtube channel I provided a link to a page that would allow the readers of this blog and the subscribers of the channel to add topics on which they want me to do videos and vote topics up or down.

The Web based system that I had used for this was Slinkset.

But then, within a couple of weeks my ADHD kicked in and I forgot the password that I had signed up with.

That should be a simple problem, right?

Having thought that, I set out to look for a forgot password link, only to find out that there was no forgot password link on the Slinkset login page. Slinkset does not seem to believe that their users will forget their passwords.

Instantly I set out to look for a support email or a contact us page on their website, only to realize that they had none.

Slinkset is an useful idea rather well implemented, but there are two major problems that I see with it.

One is the fact that the company does not seem to have a face or a personality behind it. No information on their whereabouts, no contact information, no support links and no support emails from their home page. The second is lack of basic user functionality like forgot password.

When we talk about YAGNI, Less is right and Under doing your competition by building less what becomes profoundly important is that we look at every feature we choose to skip as closely as the features we choose to build.

Skipping features is fine. Letting your customers remind you that features are important is fine too, but if you are a young and budding startup with only a handful of customers, it is also wise to see to it that you build the basic set of features and an application where you customers can function without hitting roadblocks all the time and then at-least provide them a means to reach out to you and provide you their feedback if they are stuck.

On a side note, apparently after quite a bit of Googling it turns out that Slinkset does have a help system where you can ask for help and the password reset issue is mentioned there. You can reset your password here. Makes you wonder why Slinkset chooses to make life difficult for their users when opening up their reset password functionality and making it discoverable is as easy as providing this link somewhere on their login page.

Also makes you wonder why their help is not linked from their home page.

Go figure.

Either ways, when all you are building is an application which is one page with one niche functionality, the packing, help, support, usability and discoverability make all the difference between an awesome product that you stick to or a product that you try just once.

For now, I like Slinkset and I am going to allow them to be crappy when it comes to discoverability and continue using them. I think you should too. Go try them out and see if you like them too.

Knowing The Geek Within And Learning How His (or Her) Mind Learns.

As a geek who has ADHD I am intrigued by the idea of observing the learning process rather closely and hacking the heck out of it.

As someone who had major trouble focusing on a book end to end I realized that my attention span shoots up when I am listening to audio books. This might seem like a tiny little realization to some of you guys out there but for the geek within me this was huge. It was a discovery of a hack that allowed me to break inherent limitations of my mind and push beyond them that intrigued me the most.

This meant that I could grab an audio book out there and be done with it in just a few days.

Heck! I could even turn a text document or a PDF into an audio book.

The same approach even made proof reading for this blog much more easier.

As someone who had strong feelings his entire school life, particularly classrooms or lousy teachers sounding like experts and as someone who recently quit his French classes half way through, classrooms are also one of those approaches to learning that often do not tend to work well for most geeks and yet they exist. A concept Khan Academy has managed to hack the heck out of.

Are you really learning when you attend a training session?

Are you really asking a question based out of genuine curiosity or are you just trying to impress the trainer or other participants?

Do endless arguments on Forums and Blog Post teach you something or are you just better off marking a thread #EOYBD and resisting the temptation to respond once it reaches a point where you realize you have not much to learn out of it?

Are you learning the most when you are talking or are you learning the most in your quite time when you are in a disconnected mode?

Are you learning better with the technical books out there or does more information and spice mixed with technical content helps you understand and recall information faster?

I don't have all the answers here.

What matters however is, are you giving enough time, attention and effort to learning how you learn best?

If not, why not start now?

Chances are that the geek within you that spends hours tuning that database might love tuning the heck out of your mind and figuring out new approaches to learning that might help you move beyond your inherent limitations.

Each mind is different and you will need to figure out what stimulates, excites, motivates, captivates and keeps your mind hooked. Start by understanding the basic rules, learning some basic hacks and then overtime figure out your own hacks, tweaks or workarounds to enhance your learning process and add fun to it.

I wish you good luck.

An acquaintance who recently moved from a small but innovative software development firm over to Infosys tells the story of how the organization runs. He starts the discussion by talking about the plush green and well maintained campus of Infosys.

Something even I have talked about before.

Then he moves to the overall process and some of the facts that emerge during the discussions are chilling to their core. Here are some highlights of the discussion to give you a quick idea of the process that powers Infosys.

Nine hour workdays

Infosys demands that every employee spend at-least nine hours a day in the company campus. The electronic cards record your in time and out time every time you swipe them. This person forgets swiping out his card on a day and gets an email from his project manager letting him know that this behavior is unacceptable and that he needs to pay special attention to these details moving forward.

Talk about working less.

Ties Two Day A Week

Infosys demands that all their employees wear ties in the office complex two days a week. They take this rule rather seriously. So much so that the security guards at the main gate have been instructed not to let anyone in without a tie on the specified days.

Talk about wearing what makes you comfortable.

Compulsory Internal Exams

Infosys demands that employees clear at-least two internal functional exams with a minimum of sixty percent marks. Your failing to do that prevents you from getting a promotion after three years. Promotions cannot be obtained just by giving kickass performance at your project.

Passing the exams is critical. If you do not study for these exams like young college going students and do not clear them your chances of climbing to the next level after three years of service are slim.

These exams are not Microsoft or Oracle vendor certifications and are internal Infosys exams which have no meaning outside of Infosys.

Monitoring Your CPU utilization

Infosys is working on a new system which will monitor CPU utilization of every developer to see how actively they are using their machines. Something that they believe will be a better indicator of if the developers are really working. Just spending time in the office premises apparently, is not enough. They need you to be slamming those keys at the keyboard and utilizing that CPU firing builds.

Internet Access Depends on Your Level

Internet access depends on your job designation and level. Level 300 and below for example are not given internet access around the clock. They just get internet for a couple of hours a day. Senior levels still have personal email sites like gmail blocked. If you are an engineer who is working at or under level 300 and are heavily dependent on Google for your work, you are basically screwed.

Selection Criteria And Client Interviews

Infosys still spends heavy amount of importance on school and college marks even while recruiting candidates with over five years of work experience. They also conduct regular client interviews where their engineers are expected to answer questions that their overseas clients ask them over telephonic interviews.

A huge number of Infosys engineers (in the case of this acquaintance this number was eight out of every ten) fail these interviews miserably because there is a huge disconnect between how much they scored in college versus what their clients expect them to know.

Not to mention of course that over the course of time these candidates figure out means to clear these interviews by collecting questions from folks who were interviewed before them and maintaining their own question banks.

Angry Employees

Even though this was not directly mentioned by the acquaintance after this discussion I set out to find the truth about the level of employee satisfaction and apparently stumbled upon countless examples of the employees venting out their frustrations and anger openly in the comments section of wall street journal blog and the Times of India blog.

All of these articles and the passion with which the comments were posted seemed to suggest that Infosys was not keeping the best of their employees happy either.

Automatons And The Programmers Bill Of Rights

Of course the point of this post is not to thrash Infosys per say. It is by far one of the best consulting body shops India has to offer. Having said that, the state of affair of most software consulting shops in India and around the world is tragic.

Maybe it becomes so hard to find programmers who cannot program because most huge organizations around the world aren't looking for programmers. They are looking for and breeding automatons who punch their time cards, wear ties to office thrice every week, clear three exams every year, learn up answers for client interviews and score high in their high school and college.

If you are a young and budding entrepreneur, Infosys and the similar breed of companies provide a perfect template of practices which you should put down in your "not to do" list.

As you grow your organization, do you also give in to the temptation of hiring and herding flock of sheep who obey your rules or do you have the courage for remaining small in spirit even when your organizational size grows slowly and steadily? If you are reading this and run an organization, remember this, you cannot "Out-Infosys" at being Infosys, setting rules and hiring automatons. If that is all you do chances are that an Infosys somewhere will outbid your business.

What you can do is be small, cater to a niche and hire smart human beings who have talent, individuality, their own opinions and the spine to say no when asked to wear a tie five days a week. Hire the best that you can get. Hire like the life of your organization depends on it. Once you have done that, try sticking to and honoring the programmers bill of rights instead.

I wish you good luck.

There is nothing that pisses your technically savvy and intelligent customers off more than pictures of random men and women in suits grinning away to glory on corporate websites of enterprises around the world.

Stock Photos by their very nature indicate that there is something seriously f@#kuped up within the corridors of your organization.

The sexiest of voices hired to do voice overlays on product videos tell your customers that either the product is built by a bunch of engineers who did not care enough to make a product video themselves or the product is so weak that it needs a sex appeal of a cute voice to cover up its flaws.

Are you hiring smart builders who are also doubling up as wordsmiths?

Are you hiring smart story tellers who can weave such a compelling story that people get gripped and watch the video even if the background does not contain a cute female voice?

Are you building a culture that is so strong that random photographs taken on any given day can be things you can put up on your website?

You do not need stock pictures, sexy voices, men in suits with cheesy smiles or even a corporate look on your corporate website.

Make a remarkable product.

Be Yourself.

Its a lesson all of us learn multiple times in multiple walks of life.

This time, remember it and start living it. You might be pleasantly surprised.

Now go rebrand your website to reflect your true personal or organizational character.

I dare you.

The Microsoft SQL Server 2005 pricing model is transparent, online and in your face for you to decide if the product fits your pockets.

MySQL on the other hand seems like a "call us to find the price" operation when you first Google for its pricing.

The kind I prefer referring to as the Mafia Ransom Pricing Model.

Even though MySQL is in reality not a "call us for pricing" operation I cringe every time I see marketing guys show their famous "call us for pricing" move.

Pricing is hard. Pricing takes a lot of experimenting. You can never price your product to please everyone.

But that does not mean that you run away from the problem all together, hoping that your potential customers will call you every time they want to know the price of your product and then they will spend countless hours haggling with you.

The "call us for pricing" approach tells your customers that you have no clue about what your product should be priced at.  It also tells the customers that you are going to charge each customer differently not on the value your product provides but on how much the customer is willing to pay or a host of bizarre factors.

Consider this line on MySQL pricing page for instance:

With MySQL Enterprise Unlimited, companies with up to 1000 employees can deploy an unlimited number of MySQL Enterprise Servers, with full 24x7 production support for a fixed price of $40,000. You also get unlimited 24x7 access to MySQL Enterprise Monitor.

It does not take a rocket scientist to catch a bad vibe about the pricing model if you are somewhere in the nine hundred employee ball park and are looking to hire more people. What happens when you cross a thousand employees? You call up folks at MySQL and haggle with them?

Ever wondered what the correlation is between which database your project uses and how many employees your organization has? None.

To understand this concept of "no correlation" between what you charge for your product and what the pricing depends on, lets start by assuming that we had an awesome word processor that you were interested in buying. We started off with the "call us for pricing" tagline on our website. Now lets assume that out of the hundred customers that saw the website and the ninety seven who never came back, you fall in the range of three customers who did.

Let's also assume that you actually picked up the phone and decided to give us a call. On the call, we told you, that what we charge you for the product is going to depend on what kind of documents you choose to write with our word processor.

If you write a blog post that no-one reads, we would give you the word processor for fifteen dollars a license but if you were to do the sales deed of your home on it, the price of the word processor would shoot up to five percent of the deed price.

Picking important factors which have strong concrete correlation to how you price your product is also important. Pricing a database license based on the number of users or processers is perfectly fine but pricing it on the number of employees in my organization is as messed up as pricing a word processor based on what I plan to do with it.

MySQL does seem to have a well defined pricing page too and this post by no means is an attempt to thrash MySQL. The point of this post however is to convey the central idea which is this:

Every time I see a product website with well defined versions and price tags attached to these versions, I make a decision based on if it fits my pockets and needs. Every time I see a "call us for pricing" tag on the pricing page of a product, I cringe. I almost never call. But then again, maybe that is just because I am a geek. Pricing is a hard problem but that does not mean you avoid it. Putting a "call us for pricing" callout on your website is not an answer.

Now go figure out your product plans, prices and publish them on your product website.

I wish you good luck.

Of the first few times I recall being addressed to as a geek or a nerd, one was during my high-school days. It was meant to be a slightly derogatory remark passed in a setting which shook me up for a couple of days.

Fast forward a few years. I am called a geek again.

This time I smile inwardly and take it as a genuine complement.

Somewhere between the two remarks a lot of things changed but fortunately the Geek within survived these years. Most of him remaining unchanged.

Somewhere between these two remarks, I was also fortunate enough to bump into dozens of other geeks who had not just survived, but thrived. Flourished. Made small and big dents in their universe and had told the world around them in a loud and clear tone that they were there to exist. On their own terms. Without changing. Their weirdness, their stupidity and insanity turning into their primary survival and growth technique.

As I observed these Geeks not just survive but actually thrive and create a ruckus in their world, one of the things that absolutely fascinated me was the mind of these geeks and how it usually works. There was a pattern emerging somewhere. There was something about their mind.

It was weird. Insane. Wired strangely. And yet, it was rather fascinating.

The more I observed these minds, the more convinced I became that there is a lot to learn from these minds.

We are not talking about the Pseudo-Geek mindset here. The kind whose resume you see floating in Job portals around the world. We are not talking about the kind who can calculate their monthly take-away to the precision of decimal points after tax deductions when they look at the offer letter for their new gig. That is the race of dangerous programmers who often cannot program or professionals who will cheat and rob you at the first opportunity that they get.

What we are talking about is the mind that figures out the intricacies of an encryption algorithm and implements it but cannot get itself to care about calculating his monthly takeaway or submitting his reimbursement forms on time.

We are talking about the mind that spends hours focusing on understanding the universe and everything in it from the viewpoint of a system and the personality that tries countless ways to tweak the rules, hack them, break them or work around them. We are talking about the kind that loves doing this.

Now, if you are a genuine Geek, chances are that you have not tried understanding your brain or your thought patterns, with even one tenth the effort that you put in your last project. Of course you might have gone in and grabbed a copy of Being Geek but then do you take a pause every now and then to dissect and analyze situations where you react differently than a perfectly normal-sane-practical-human-being? No? Hardly Ever? Thought so.

This series of posts is my attempt at doing that. It is my attempt at answering how a Geek thinks. How he works. How he reacts. How he sees things. It is an attempt at understanding the minds that have fascinated me ever since I first realized that I might not be as awesome as them, but I can connect to them and understand what makes them tick.

If you are one of them stay tuned for more on the topic as this series of posts unfolds itself. If you happen to work with Geeks or Nerds and were never quite able to figure them out these articles might help you get a deeper insight into the minds of Geeks and Nerds. Stay tuned for a series of posts where we attempt to understand the minds of the genuine geek that might be sitting right across your cubical or maybe even inside you.

This classic hugely inspirational scene from Glengarry Glen Ross has been one of my most favorite when it comes to getting things done.

Having said that, I am not so sure that this is a scene young and budding software marketers or sales guys should be watching though.

Coming from a consulting background I have been a part of countless sales calls and meetings. After watching countless sales deals that fizz out, if there is one thing that I have learnt about selling stuff it is that, If you want to sell badly enough, you will sell badly. If you try hard selling, selling will become hard.

Recent discussions with someone at work reveled a fascinating story on selling his used car. This person had been thinking of selling his car for a long time.

Somewhere during this time, his friend lands up with a broken car and since this car is sitting unused in his garage, he decides to help his friend and let him use it for a dew days.

"A few days later, this friend of mine comes to me and makes me an offer for the car", this person explains. "I told him that German cars need a lot of maintenance after a few years and if he wants a cheaper used car, he should be going in for a Japanese car, but he kept insisting on wanting to buy my car".

"I guess the one thing I learnt about selling and the whole try before you buy model is that you have to have genuine interest in helping someone when you let him 'try' your product. You cannot be thinking about selling when you are helping.", the person concludes his learning from the story.

The point? If your 'try' part is focused on moving your customer to the 'buy' part you will almost never sell. If your 'try' part is focused on helping the customer and letting him discover for himself if he genuinely loves your product to come back to you and buy it, chances are that you won't sell to everyone, but chances are also high that you will hit a niche of people who will really "want" your product.

Don't try to sell to everyone. Don't try to sell anyhow. Don't try to sell all the time.

If the "Always be closing" model is not working for you, the best you can do is move to an "Always be helping" mindset and then when you see someone who genuinely wants your product, give them the line that is dotted and chances are, they will sign on it happily.

I wish you good luck.

When you are the kickass rock star alpha geek of your team churning out code by the minute and getting things done, you love being in the flow. Then slowly, as more and more people in your team realize you can help and as you accept one promotion after another, somewhere it becomes fairly obvious that if someone in your team is stuck he is supposed to walk up to your desk and cause an interruption often without asking if it is okay to interrupt.

The first few years of this 'helping mode' are fun. You are busy helping everyone. You don't really care if you are not churning out a lot of a real work yourself. Time moves on. Fast forward a couple of years. You have managed to stay deeply connected with code, but on an average you just find a couple of hours of non interrupted work in a day. There are days when the builder within you asks you the question: 'What did you do today?'.

You know the answer to the question instantly.

The answer freaks you out.

There are two knee jerk reactions possible in this scenario.

If you were the geek who always loved code, you are going to go back and assign the most complicated module to yourself, lock yourself in that cubical for days f@#king up your responsibilities as a manager and those emails from your clients are going to sit in your inbox unanswered.

If you are the guy who was never quite good at coding you are going to take it upon yourself to walk up to every developer you can find and ask them the status three times a day. You are going to answer every single email in your inbox and watch your experience as a developer go down the drain as you morph from a capable alpha geek to someone who just answers emails and talks.

Both of these knee jerk reactions are small steps towards big problems.

What you need to do is take a pause. Breathe. Let the question soak in. Reflect.

What did you really do today?

You helped Jack by taking his rather long winded function and using an API that would do the same work in half the lines of code. You researched the API. You tried a quick POC on it with Jack. Of course, it was his work but it was your job to keep him moving forward.

Then you spent time responding to emails and building a story around your product so that the clients don't just look at the data.

You picked a bug or two. Fixed those. Did a scrum. Thought about a couple of new features.

And in the process of these you answered about a dozen questions on a feature, on a decision that had to be made or a problem someone was facing. You have done enough by doing nothing concrete which you can sign off as your work.

If there is a geek within you, he is never going to see any of the above as real work so yes you do need a couple of hours a day when you are logged out where you work on keeping your sword sharp and churning out some real code.

Having said that, the sooner you get used to the idea that at some point of time in your life, you will have to stop adding items to the list of things you personally did, stop showing this list to your bosses and start spending a decently big part of your day mentoring, teaching and guiding others, even though this does not really qualify as 'real work' according to the geek that you still are, the better off you will be.

Go on. Strike a balance between teaching, inspiring and doing.

I wish you good luck.

Project Plans and Gantt Charts have floated around in office corridors since Project Managers have existed in the business of software development.

The thing with folks who run around with these documents and knock on your cubicle three times a day, is not they they are bad human beings.

If they could have helped the developer who is running late at meeting his dead-line they would.

But most of them stopped programming at the first opportunity they found.

Typically here is how a developer manager conversation that I often overhear runs:

Manager: "We are running really late. Do you know what is wrong? Why are we taking so much time?"

Developer: "Not sure. I mean it is pretty straight forward but this nested query keeps timing out for no particular reason. I mean this is a simple cursor that takes the data from a table, throws it in a temporary table and then filters out the data we do not need. We have done similar queries in the past and they all run just fine."

Manager: "How much more time do you think we will need?"

Developer: I'm not sure.

Manager: Can we try to do this by the weekend? Its really important.

Developer: Hmm... okay... I will try my best.

Manager: Thanks. I will go ahead and update the status report.

Can you see what is happening here?

First, none of the parties are at fault here. They are just speaking a different language. The developer is clearly seeking help. He wants someone to sit down and take a look at the nested query. The manager would have loved to help, but he cannot. As much as he would love to help, he knows as much about cursors and queries as the developer knows about the Gantt Charts.

Usually in these cases, the manager also misses an important queue: that the developer is seeking help.

The manager switches to the Gantt Chart mode and talks about how much more time the developer would need.

After a while the developer gets the rules of the game and he stops discussing technical issues with his manager. They try to talk the language of the Gantt Chart, except of course, there is only one problem: Developers suck at speaking that language, specially when it involves saying no.

A disconnect begins.

Very soon, the performance of a developer who was otherwise thriving, takes a steep hard nosedive.

The post is not about criticizing managers or developers. I also don't have a recipe for success here. The only advice I can leave you with, if you are managing a team of developers, is, look for slightest of signs when your developers need help and when you notice that they need help, help them. If you cannot help them because you are not technical enough don't hesitate walking up to anyone in the organization who can genuinely help and ask for it.

Until you do that, chances are, that the nested queries will not automatically speed up by the end of the week.

The story of NewsTilt and why the young startup nosedived its way into failure and eventually shut down sends a chill down your spine as you read it.

As you read the post which describes one of the founder's view of why the organization failed, you start reading between the lines and you start finding dark gaps which give you a glimpse into what the real reason for NewsTilt's failing might have been. Embedded between the lines of the posts you find chilling comments passed with an innocent, matter of fact tone which make them all the more scary. For example, Paul (one of the founders of News Tilt) explains:

Since we needed to build so quickly, as soon as we got some money we wanted to hire another technical person. Nathan had a friend he wanted to hire, who was exactly the kind of great programmer he could work well with. However, it took some convincing to get him to try working on a news website, and he wasn’t sure he’d stick with it. We were sure we’d be able to convince him to stay, and we even waited two weeks for him to move to work with us.

Unfortunately, we were never able to excite him about the project, and we quickly realized he was never going to be intrinsically motivated the way we need for a first employee. There was a point when I was over in Cambridge with Nathan and the other developer, and I noticed that the developer wasn’t working on a Sunday. Now, we aren’t the kind of people who think our employees owe us 90 hours a week, but startups need that kind of work ethic from very early employees–exactly the reason that intrinsic motivation is so important. If your first employee doesn’t love what you do, doesn’t wake up each morning dying to work on HIS product, you have likely chosen poorly, and that’s exactly what we did.

As you skim through the article you begin to understand that the problem with NewsTilt wasn't any of the reasons mentioned in the post. The problem with NewsTilt probably was the fact that the founder believed that by jumping into an unknown domain and hiring idiots who work ninety hours week can make you a shitload of money. Take for instance this quote from the post:

Somewhat surprisingly, the journalists we picked were too good. We made a big deal of only hiring the “best journalists”, something we spent a great deal of time getting right. We had a guy with a Pulitzer, one with an Emmy, and overall a great deal of talent writing for us [3].

In hindsight, this may have been a big mistake. The kind of writer we actually needed was one that was hungry to succeed. Someone who would write five pieces a day, and who wanted nothing more than to be a big-time journalist. We needed a young Perez Hilton or Michael Arrington, people who wrote for 18 hours a day in order to make their names.

Instead, we got journalists who were already successful in their day jobs, and who already had families and other commitments.

Not to mention of course that these journalists were working for free. If this post does one thing, it bring out NewsTilt as a company which expected everyone, their employees and their journalists, to sacrifice their personal life and give in eighteen hours a day behind an idea and a domain that the founders themselves did not know anything about.

Paul explains why his idea was great and that Google could have made it work:

Google could have made this work. I believe that if Google applied the same model they could probably succeed. They have the tech ability, they have the traffic, and they already have a massive news property. They also have have a big problem with whiny news organization, and an elegant solution would be to kill them off by enfranchising their journalists to be their own bosses.

Of course Google could have made it work. But then again, Google is okay with giving twenty percent personal time from their normal five day work weeks to their developers, leave aside expecting them to work Sundays. Besides, Google is also not pointing fingers at their developers for not working weekends when their products fail. Not to mention that most successful developers work less and say no to meaningless slogging.

Let's face it. NewsTilt probably failed because of a lousy founder who wanted people to stop having a life and work ninety hours a week for an idea that he himself did not know deeply.

The entire post runs into pages and by the time you are done with reading it you realize that Paul could have done a way better job with the post by just saying  "I fu@#ked up. I am sorry". It would have been way better than whining about the developer not working weekends and the journalists having families. But then again, saying "I fu@#ked up" is hard.

Besides, realizing how bad you are at something requires the same skills that you need to become good at that thing.

Paul as a founder has a terrible blind spot that most readers of that post can see rather easily.

Go on. Read the chilling story of NewsTilt and it's failure and as you read it be sure to read between the lines and learn exactly the kind of attitude you should avoid while leading an organization, startup, business or even your small team at work. That and when you make mistakes, stop pointing fingers at others and accept the fact that it was you who fu@#ked up. After all, it is always your fault. Seriously.

The topic of a recent discussion that I got into revolved around what made 37Signals, 37Signals to begin with.

Was it their life style?

Was it their methodology?

Was it the fact that they were small?

Was it their book, Getting Real?

The opinion that emerged out of the discussion was that the answer was none of these. What made 37Signal, 37Signals is that they contributed true value in the form of Ruby On Rails, then Basecamp and then truckload of other products.

Ideas are a dime a dozen. Anyone can start a blog and talk at length about how amazing product management should be done.

Of course, anyone does not include the millions of 501 programmers, who cannot even program or muster enough motivation to lurk at a blog or own a book on programming, leave aside writing one, but well, anyone with enough motivation, some basic writing skills and some imagination can talk about software development and do blog posts on wisdom gained from doing years of software development.

If you do not have years of experience in software development, you can talk about social media and pull numbers straight out of your ass and impress people. Or better still, you can just quote numbers others have pulled out of their ass and act smart and knowledgeable.

If even that does not do it for you, talking about Entrepreneurship and how you will run your company when you start it up might do the trick.

Preaching, is easy.

Don't get me wrong. Sharing of ideas and experiences is what this blog has been about since its inception and we need some inspiration and sharing of ideas from time to time. It keeps our creative spirits alive. But too much inspiration can be addictive.

When you find yourself taking shots of inspiration morning, afternoon and evening. When you find yourself seated in meetings about entrepreneurship once every week, you know that you are just talking. Participating in a discussion, even at a world wide scale is good but do too much of it and you get a little sick and tired of it. There are times, when after years of blogging, you look back at your blog and you question if the value that you have added is adequate.

Yes you contributed a few innovative ideas, you sparked a few interesting discussions and you rocked on Reddit a couple of times but are ideas, thoughts and discussions all you can contribute? What about real value? What about a real product? What about discussing real code?

Somewhere months ago I asked myself this question and started Code Persona, my little corner where I document my development experiences. The site of course did not take off primarily because of lack of content.

Within weeks of starting the website it was rather evident that I might be decently acceptable at writing code (who needs talent when you have intensity) my ADHD makes it nearly impossible for me to write technical posts on the web much like I find it difficult to be reading from a physical book all the time.

But recently the desire to add genuine, concrete, value has been driving me nuts. In short, I have done enough of preaching and while I love sharing ideas here, which I will continue to do as frequently as I have been doing, I also really want to get out there and discuss something concrete. Like, say, code for example.

Without going into specifics, lets just say that it was simple divine intervention, that prompted me to grab a microphone and headset that had been sitting on my desk only to get used occasionally for boring conference calls, to start recording a series of videos on Microsoft Entity Framework.

The thousandtyone youtube channel was born.

This is 'not' going to be about thoughts on management, this is not going to be about discussion on process and hopefully this is not going to be about countless arguments on what is right and what is wrong.

This is going to be the IDE and code. We start with a series of videos on Entity Framework and from there every week we will dive into anything and everything that seems interesting. I spend a good part of my day breathing, writing, reading, eating, drinking and thinking about code. It is high time I start contributing something through it.

Like I said, the first series of about five to six videos is going to begin with Entity Framework but from there, we are going to jump into anything that seems interesting. Object Orientation, Inversion of Control, Test Driven Development. If it seems interesting, we might end up doing a quick fifteen minute video on it. If the video does not cover everything that had to be said on the topic, expect the video to turn into a series of videos.

Also expect to see a video series on Getting Started With Programming. I know quite a few business analysts, testers and managers who can benefit from that. Besides, the real motive behind that series is going to be teaching my young eight year old nephew how to write code.

The YouTube format of fifteen minute videos works perfectly for someone with ADHD like me. Besides you can chose to skip the videos, rewind them if you do not understand them or play them at triple speed if you believe we are moving along too slow.

Long story short, here is the thousandtyone youtube channel. We are going to write code on the record mode, we are going to learn how to write better code, we are going to teach you how to write better code and we are going to do that rather often. Hopefully, every week.

Code Persona will get updated every time a video gets published on the channel so if you are subscribed to it, you should get notified every time a new video hits the thousandtyone youtube channel.

Basically, it's like this. I spent all these years talking about good programmers and good programming. Here is your opportunity to see me writing code and tell me how much I suck at it. You are not going to miss that opportunity, are you? #Grins.

Go ahead, hit the channel, take a look at the first video and subscribe to it if you are interested in being a part of it.

What is your role in your organization?

What are you responsible for?

I know you are confused about your existence in your organization.

I know your designation means nothing.

But if you are a kickass programmer these are probably not the things that bother you as much as random stupid unpredictability in your work life.

Lets jump into the depths of time and bring from the ages that have rolled behind, the gist of what pissed off the best of the programmers at Multiplitaxion Inc. It was movement. Unpredictable, completely irrational and sometimes hugely irritating movement.

As a programmer you spent months working on a project. Putting in sweat and blood on the project and getting attached to it, only to be told one fine morning that you are now going to have an idiotic moron leading the project and you are expected to report to him.

Then there were historic moments where some of the most kickass programmers walked into office only to find out that they were expected to move to a different project all together and start their knowledge transfer effective the very same day.

As programmers we spend multiple hours a day talking to the compiler, where we expect the same consistent, coherent results for the same code written over and over again. We look for systems even when we are connecting to other human beings. The best of your geeks are afraid of unpredictability specially the kind that has 'stupidity' written all over it.

As a manager it is your responsibility that you reduce the element of unpredictability that gets thrown in your team's way to a minimum and if there is unpredictability it is positive unpredictability that challenges them and helps them grow stronger neurons. If you cannot do that the least you can do is be open about the changes in your organization and have no secrets. Transmit information openly.

If you must move them to a different project, do you have a genuine cause for doing that? Are you explaining your thoughts and your rational to them before you move them or are you basically passing orders from the ivory towers of management?

It takes years of solid teamwork, multiple streaks of good luck and a lot of stars have to align before you become a part of a project that is awesome, that rocks and that has the potential of making a dent in the universe of a small group of people or an industry.

All it takes to ruin that is a couple of stupid random unpredictable decisions that you impose on your team without discussing things with them, without listening to them and without giving them a chance to react.

There are multiple awesome projects that might be running in your team right now. A couple of programmers are spending their night time to work on aspects of your project that might take your project to the next level. The real question is, are you going to listen or are you just going to take random decisions and move people around like pawns on a chessboard?

Choose wisely, because your choice ultimately decides the future of your team and your projects.

Back in the days at Multiplitaxion Inc, Fred tends to throw random ad-hoc work on our plates every time he sees us passing by the corridors of the office.

More often than once we find ourselves gathered in the cafeteria discussing what it is that Fred himself does.

Michael Lopp explains this rather articulately in his book, Managing Humans. He explains:

“What, exactly, do you do?”

Slack.
Jawed.
Amazement.

This question is coming from someone I trust. A trusted employee who has been working in my group at the startup for years. This guy always tells me the straight dope and now he’s asking me what I do with my day because he honestly does not know.

My first reaction to this question is the wrong one. I want to leap over the table, grab my friend by the shoulders, shake him, and yell, “While you were uselessly staring at that one bug this morning, I was keeping this organization moving, pal.” My second reaction is to take a deep breath, so I do.

This basic what-do-you-do disconnect between employees and managers is at the heart of why folks don’t trust their managers or find them to be evil.

But the real problem here isn't the fact that Fred is incapable of answering the what it is that you do here question.

The most evil of managers are not the ones who cannot answer that question. In fact, the stupidest of managers are also not the ones who do not have much work on any given day. Most developers are used to both these kinds. Add a little bit of empathy to their characters and these two kinds are not really all that dangerous after all.

In fact, they might be adding secret ingredients to your project and your organization, quietly and subtly.

These are not the kinds that typically do the most damage.

The ones who do the most damage to your project, work and your team are the ones who don't have any work and to add to that, don't have a life either.

This is the breed that goes around the office with a printout of a project plan, the breed that buzzes the development team three times a day, the breed that organizes meetings that run hours and the breed that pulls out the stupidest of ideas or features straight out of their ass and then insist that they get implemented even when no one really needs them.

So, if you are a manager, the next time you walk up to someone's desk with a project plan in your hand and ask him the status of his module for the third time in that day because you don't have any other meetings to attend, remember that while you might not have anything to do, others in your team might be busy doing some real work.

Don't have work?

The least you can do is stop inventing random work for others and get a life.

Find a video game, play Farmville, take your son out, spend some quality time with your family, go home and stop bothering your team. Consider working less, even if you think you are supposed to 'drive and manage' the team. Seriously.

We have all seen these emails. Emails from your Vice President where he wants a certain Fred to look at your project and provide “inputs”.

You know the famous architecture team story by Joel Spolsky.

That kind of inputs.

Before you know it, "consultants" with terrible blind spots who are awesome at playing the jargon game and who have zero knowhow about the domain, zero understanding of your team dynamics and zero expertise in the technical space are meddling in every decision your team is taking.

Well not exactly those consultants, but if you have been through an architecture review meeting with external consultants you know exactly what I am talking about here.

Every small change is questioned and discussed in meetings that no productive programmer would want to attend in the first place but then you suddenly find yourself in these meetings spending hours defending the most common sense driven decisions you took.

You know your car is going round and round in circles. You are not getting anywhere. The fact that you are going around in circles is common sense. You have too many drivers fighting to take control of the driving wheel.

Obviously, you are not moving ahead. Obviously, throwing in more drivers is not going to solve the problem. Obviously, you need to pick a single driver to drive your project. Obviously, you need to check his track record closely before you pick him. Obviously, you need to learn how to trust him. But then again, obviously, obvious is not so obvious, especially when it comes to big organizations that are trying to pretend to be even bigger than they really are.

If you run a team or an organization, remember that every time you get more than one driver at the wheel you run the risk of getting nowhere. So the next time you invite those external consultants to review a project that is moving just fine or fu@#k up a department that is moving along smoothly, think twice.

Here is my humble word of advice from the forefronts of software development: Pick a single capable trust worthy driver. It doesn’t matter who you pick, as long as the person is competent and trust worthy.

Then move to the back seat and let the person you picked drive without bothering him.

You may not get to your exact destination. You might get just a little closer to it. But then at least it is better than moving round and round in circles.

I wish you good luck.

Do you want to really see the worst of software that exists on the surface of planet earth? A few funny examples aside, chances are, that you are not going to find it online. If you are looking for some genuine gems of stupidity, lack of vision, bad design or just down right stupid implementations,  go look at the applications that power the intranet of some of the so called big enterprises or the fortune five thousand.

Khoi Vinh takes the famous analogy of duck typing: "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck" and turns it into a rather interesting satire on enterprise software. He calls it: "If It Looks Like a Cow, Swims Like a Dolphin and Quacks Like a Duck, It Must Be Enterprise Software"

Khoi also provides his logic on why he believes enterprise software stinks even after the countless dollars that are poured into the efforts of building these applications. He explains:

This is partly because enterprise software rarely gets critiqued the way even a US$30 piece of shareware will. It doesn’t benefit from the rigor of a wide and varied base of users, many of whom will freely offer merciless feedback, goading and demanding it to be better with each new release.

Shielded away from the bright scrutiny of the consumer marketplace and beholden only to a relatively small coterie of information technology managers who are concerned primarily with stability, security and the continual justification of their jobs and staffs, enterprise software answers to few actual users.

Given that hothouse environment, it’s only natural that the result is often very strange.

Of course, most people who take the buying decisions in the enterprise world are going to have blind spots but If you are a programmer with basic ethics and self respect who happens to build software for the enterprise, the first question you need to ask yourself is this:

How do you take the same software, shred off the elements of complexity out of it, stop bitching about performance and add a touch of genuine magic, simplicity, genuinely kickass speed and interactivity to your applications.

Google Apps does it with its paid offering. They take the simple, easy to use, light weight applications designed for end users, tested by millions of live real life users and offer it to the enterprise with added features, more space and a premium price.

If you look into the approach it is rather simple and straight forward. You build for the end consumer. Then once you have enough people using it for free, you let enterprises adapt it and pay for it. You stop bitching about performance and you actually build fast applications. You focus on simplicity, ease of use, easy adaption and you build with the purest of intent.

As rework the famous book by the guys at 37Signals describes, the suits at enterprises that make the buying decisions and sign off paychecks don't wake up in morning wishing they had more slower, sloppier or complicated applications.

So if you are a developer or a technical manager, stop using the fact that you build an enterprise application as an excuse for slapping together random text boxes, drop down lists and option buttons, frameworks, building weird things and calling them enterprise applications. Continue to master the art of simplification. Even your enterprise users will love you for it. After all, working on Enterprise software is not an excuse for building software that sucks. Seriously.

You there; if you are reading this you probably have something you can teach us; something you can build or maybe a story to tell. Some insightful content, some meaningful software or a product that can change our lives in the tiniest of ways, maybe just for a couple of days.

Maybe you can make us smile. Maybe you can make us laugh. Maybe you can make us take a pause from our routine, mediocre, mundane lives and nudge us to think. Maybe you can give us a tool or a utility that you were working on last week.

The real question is, are you giving us any of that? 

If not, why?

You are afraid of failing. Aren’t you?

Actually, you are shit scared.

You already know that the 'I don't have time' is the lamest of excuses you have given yourself for years, haven't you? 'I want it to be really good before I release it' - that is a lame excuse too.

Of course you want to spend time and sign stuff you put online. Put finishing touches to it. Polish it. Make it the best you can. All you need is a little bit of time. Newsflash – you are never going to have that ‘little bit of time’.

Remember, you don’t have to be the best to have an audience. You don’t even need an audience. Just being loud, being opinionated and adding a little bit of genuine value with an intent that is pure and clean, is all we, you readers, followers, subscribers, audience (or whatever it is that you want to call us) expect from you.

Show us what you’ve got. We don’t want you to polish it for hours. We don’t want a formal website with professionally done videos surrounding it. We don’t want marketing weasels selling us crap. We don’t want impotent words or formal introductions of your product.

Show us a little bit of yourself through your product, service or whatever it is that you have to offer.

Make it Raw. Unedited. Real.

Even if it is as raw, unedited and real as the videos from Khan Academy.

Salman Kahn from Khan Academy explains this rather articulately in his video on the topic.

Normally, I would have quoted from the video, but this one is fairly inspirational and I would rather than you take the twenty minutes and see the video for yourself. 

The takeaway from all of this?

If your intent is pure and you are adding value, we will listen. And if you continue doing it long enough, consistently we might even spread the word for you.

Now go give us something meaningful, cute, smart, sexy, funny, or simple and informative.

Give us a little bit of you.

The you that moo's and the you that is purple.

I wish you good luck.

I have blogged out the importance of consistency time and again.

Kickass builders and story tellers keep jabbing.

The metaphor is that of running or working out. If you are not consistently shipping, you are not in growing.

Having said that, every single one of us, go through bouts of nothingness and depressions where we are just not in the zone. Seth Godin describes the problem and the solution in a rather articulate and concise way in his post on the topic. He explains:

Some days, even the best dentist doesn't feel like being a dentist.

And a lifeguard might not feel like being a lifeguard.

Fortunately, they have appointments, commitments and jobs. They have to show up. They have to start doing the work. And most of the time, this jump start is sufficient to get them over the hump, and then they go back to being in the zone and doing their best work.

Momentum is incredibly useful to someone who has to overcome fear, dig in deep and ship.

Momentum gives you a reason to overcome your fear and do your art, because there are outside forces and obligations that keep you moving. Without them, you'd probably stumble and fall.

Slowly exercising your creative mussels and growing out of your comfort area is a simple way to get started. You can even use you insecurity to nudge you on the path. At times a counter which humiliates you in public might do the trick.  On other occasions a simple turn of switch in your brain or being shaken up by an idea might work too.

The tools are numerous. Pick a few that you are most comfortable with and use them. What ever it is that you do, always remember that nature designed us to become lion lunch the moment we became sedentary and that implementation hasn't been redesigned yet.

So keep the momentum going, even if it is just one step you are taking each day.

Oh and yes, a lot of talking is not a step forward. Do something real. Work on something concrete. Ship.

Consistently.

I wish you good luck.

You look at the stupidity that happens in your organization and you tell yourself, "WTF! Why cant they see something as clear and stupid simple as this?".  And then after a few meetings you stop giving a f@#ck, slip into hibernation and start doing your 'job'.

Scott Berkun describes the situation rather articulately in his post about the topic of fighting management incompetence. He explains:

The big incompetence crime committed by VPs is leaving incompetent managers in place for too long. My theory: by the time the CEO knows a VP stinks, the whole org has known about it for months. The smart people have been making plans to leave or are working to cover their assses. By the time the CEO gets around to taking action, it’s way too late. And often the action taken is whitewashed: no mention is made of how the VP or middle manager utterly failed (e.g. “Fred has decided it’s time for something new.”) The denial lives on, the lie propagates, making it easier for more denials and lies the next time around.

But then the real question that continues to confuse and amuse me is this; why do so many people so high up in the pecking order of really big organizations prefer to live in the state of denial? Are they complete morons, down right idiots or arrogant pompous fools who managed to peck on others and climb the corporate latter of prickdom?

The answer however, might be none of these. John Cleese on his video about creativity might have hit upon the answer using simple science and logic. He explains:

To know how good you are at something, requires the same skills as it does to be good that thing. Which means if you are accidently hopeless at something, you lack exactly the skills that you need to know that you are absolutely hopeless at it.

And this is a profound discovery. Most people who have absolutely no idea what they are doing have absolutely no idea that they have no idea  of what they are doing.

It explains a great deal of life. It explains particularly Hollywood. But it also explains why so many people in charge of so many organizations have no idea what they are doing.

They have a terrible blind spot.

And the problem with teachers may be that the teachers do not realize that they themselves are not very creative and therefore they may not value creativity even if they can recognize it.

The approach mostly explains why kickass developers find it painful when they are asked to work with non-technical managers who had never coded or were never really good at coding in their entire life.  It also explains why so many people high up in the pecking order of countless organizations around the world do not see what every developer who walks the corridor of the organization sees.

So the next time you are asked to lead a team, work on a project, or lead a department take a long pause and ask yourself if you are really good at what you are going to be leading people on. I know there is an impulsive voice within you dying to say - 'of course I know what I am talking about!' - but hold it. Relax. Give it some soak time. Be really honest about it. What are your credentials on that specific topic?

You might have been an amazing programmer. That does not make you a good manager. You might have been an amazing manager, that will not make you a good entrepreneur. You might have been a really successful entrepreneur, but that that may not make you the best programmer. You might have built an amazing system, that does not make you a person who can drive a community.

Before you decide to get actively involved and lead from the front, think. Sometimes handing the driving wheel to someone else who knows how to drive is a way better option. Seriously.

Jack triggers a casual conversation about his need for mentorship

Yes, that mentorship where he is looking for an 'in office mentor' to handhold him and help him grow technically. He feels he is not 'growing' because he does not have a mentor who can train him.

He talks at length about the glory of his past mentors as you listen in silence. You happen to know and respect some of these guys that he is talking about, personally. Five minutes into the conversation and you have realized the absurdity of it all.

Respecting someone for his talents and wisdom is perfect but when people start putting other human beings on a pedestal higher than themselves and start hoping that these mentors will show them the way, strange things happen.

You look at Jack wondering if you should tell him to snap out of the Matrix. You wonder if he is ready for the red pill.

That red pill.

Then you do it. You ask him to name one hugely successful project of one of these mentors that he is talking about actually led from the forefront.

Silence. Crickets chirping.

Ok, how many times did this mentor of his actually conduct a training where he wrote code that inspired Jack?

More crickets.

Newsflash! These mentors were just as lost and confused as Jack himself or me.

Ours is a business where we mix way too many things together. We mix authorship with authority, years of experience with technical competence, a condescending attitude with power or wisdom and respect with mentorship. We see people with power or authority and assume that just because they were able to get themselves in a position where they can demonstrate power or authority, we need stop questioning and start following them.

The red pill in the software development world is about challenging the validity of every human being you learn from. Question everything that they have to say. Look for your own facts, take your own decisions and make your own judgment calls.

As you read this, you are either nodding your head in agreement or shaking it in disagreement. I am not going to try and convince you one way or the other because becoming your mentor is the last thing that is on my mind. I am not good enough to mentor anyone and I have no misconnections about that.

If I can just collaborate with a few interesting minds around the world, learn something from them, teach them a thing or two and exchange ideas worth sharing with them, I have done my part.

Now stop cribbing about not having a mentor at your workplace. Go find the best alpha geeks and loud characters out there and collaborate with them. Mentorship is not a one way street. It's cluster-fuck of hundreds of minds engaging in countless battles of ideas, facts or techniques and learning from  those battles. These battles can cause a few scars but once you get the point they are so worth the scars they cause.

Now the real question you have you ask yourself is:

Are you man enough to put yourself out there and participate?

Go on. Connect with the best of the minds you can find and then learn from them. I dare you.

Remember that book you promised you said you were going to write? Remember that technical blog you were going to post on regularly? Remember the little open source framework you said you were going to work on? Of Course you are working on all of that. But then, do you remember when it was that you first said you were going to write a book? Three months ago? Five Months ago? A Year?

Thought so.

Time has strange attributes attached to it particularly when it comes to the speed at which it moves. You are not going to win the fight against time, so don’t even try.

But then, as a geek you have tools at your disposal that help you realize just how pathetically slow you are moving. One simple tool is using twitter to announce the number of days since you started a task. I recently started doing this with the book project that I started working on:

The idea is to make it a point to go to twitter and post a message with every passing day telling yourself that one more day has passed. You can either leave it at that, or get creative and mix it up with celebrating doneness, announcing frustration at random distractions or announcing nothingness.

Either ways, if you can just logout for just five minutes every single day to remind yourself how fast time is moving by, chances are that as time moves by you will disconnect for longer durations and get something real and productive done.

So go ahead, make a not to yourself and tell yourself how many days has it been since you said you were going to work on whatever it is that you said you were going to work on in your free time.

Of course you will end up making a fool of yourself when the number of days start moving phenomenally high for simple things, but then, at times, self humiliation in public can work really well.  Try it.

I wish you good luck.

Based on criticism of the last chapter I ended up taking it offline. One of the things that I learnt about writing while doing this book is that you need to give each chapter some soak time where it just sits on your hard disk and you spend days looking at it, refining stuff, adding stuff and most importantly, removing stuff. This chapter is my attempt at doing that. The chapter has been made to soak for few days and has been edited with considerable effort.

The purpose of the chapter is to introduce you to the idea of builders without a lot of preaching.

As always, we would love to hear back from you. Feel free to drop us a comment, send a tweet @thousandtyone, email me, ping me or call me if you have anything to say regarding this chapter or the book in general.

Now go get a copy of the chapter here.

If you are interested in the other chapters that have been drafted so far you can also take a look at the table of contents.

Children are absolutely amazing when it comes to taking chances and moving away from the realms of mediocrity. They are also seriously kickass when it comes to the idea of learning things without measuring the exact ROI from learning those. They are good at having fun.

I have had the pleasure of spending some time today with my nephew where we ended up doing a mini research which started with my ADHD driven mind easily getting confused with a kid's question and giving in to countless digressions.

Here is how it begins:

I am in the process of trying to think of an idea to post. It's one of those hours of the day where I crave silence. Serious silence. Varun, who coined the name of this website and is about eight now, walks with his PSP in his hand and is playing a soccer game. I tell him to lower the volume. He does. I tell him it is silence zone and a little bit of quite is good for his brain. Fifteen minutes of silence follows.

Then before I know it, he is goggling videos on the Egyptian history on YouTube using my laptop. I have been removed from my very own laptop by the sheer brute force of an eight year old. We are both watching a YouTube video which is talking about Egyptian history. The video casually mentions the length of River Nile. Now how do you take six thousand six hundred and seventy one kilometers and explain it to a eight year old? Hmm.

So, let's begin with what he knows. He knows the distance between two stations of a local subway. He thinks he can guess the distance between the two other stations. So we Google the distance. Turns out, it is seventeen kilometers. He thinks that is a lot of distance.

Now translate the distance of Nile in terms of number of trips that he would have to do between these two stations. The number of trips roughly equates to: 392.4117647058824 trips. He gets it. Totally.

Now let's Google the speed of the subway in our part of the world.

Before you know it two strange minds are deeply submerged in solving a problem. Our research is taking us to corners of the universe where I would have never even dared to go alone and for those of you who might be interested in this super secret research of ours, read on people.

First of all, we now have the time it would take if you were to travel 'through' Nile using our local subway. By the way, there is a huge disagreement between me and my nephew on whether the right word to use is 'through' or 'across' because depending on the direction and angle you travel in the word to use varies. Anyway, I digress, from Egyptian History, to Nile, to Mathematics, to English my ADHD is now playing tricks with me so we decide to focus and complete the research.

We have the details worked out, which we do not have a plan to publish but here are the end results:

1. Time to travel through Nile using our local subway if it keeps on running without stopping: 9 days 6 hours 14 minutes 24 seconds.
2. Time to travel around the earth using our local subway if it keeps on running without stopping: 55 days 15 hours 50 minutes 19 seconds 19 milliseconds.
3. Time to travel milky way using our local subway if it keeps on running without stopping: 3805175038 years 18 days 21 hours 19 minutes 48 seconds.

We thought of handing this over to the discovery channel and letting them publish it but then we figured that since this is our hard work, we should just publish our research on my website and continue to hold the copyright of the research.

Are we sure if the numbers are one hundred percent correct? Have we accounted for all variable factors when we drill down till milliseconds? If you are still reading this and are wondering what is the point of this post, let me tell you that you have missed the whole point already.

If you are interested in buying our research results, we are not interested in selling them. Thank you so much anyway.

Having said that if you have your very own research we (where 'we' stands for my nephew, me and a couple of really close friends) would love to hear about it. Seriously.

At a shopping mall my mom hands me a shirt which I brush aside as something I don't want to try out. When it comes to dressing most of us have preferences. What is the maximum loudness of the color that you can carry on your shirt with grace, do you wear regular fits or are you comfortable in tights. Do you have the physique or the body to carry the clothes you are wearing.

You probably even know the kind of fit that you are looking for in the first place.

You might even end up spending quite a bit of time trying stuff out.

Every time I interview someone and candidates tell me that they have not visited our website, my ears perk up. What do they know about the organization they are applying for? Have they interacted with someone in the organization? Do they know someone personally? Have they talked to someone? Read someone's blog? What made them apply in the first place? I am already suspicious of their reasons for applying.

The next question, is turning the tables, and letting the candidate interview us. Tell them that this is their only chance to know anything they want to know about the organization and let them ask questions openly and candidly.

Observe.

Their questions say a great deal about the type of 'fit' that they are looking for.

1. How does the appraisal process within your organization work?
2. How can I grow within your organization?
3. What are your salary brackets for someone with similar experience as me?

This line of question says quite a bit about the candidate asking them.

He is neither looking for the personality, nor the texture of your organization. He is not considering his own mindset and mental physique before applying for an organization.

If he was given a job offer would he just join?

If he can somehow get those legs into those jeans, will he buy them?

Or is picking an organization really much simpler than picking your clothes?

Now, all you need to do is go through the interview, but you might want to keep it short with this guy, because from this point on, you are probably just wasting your time which could have been otherwise utilized interviewing better candidates who care.

You are in corporate business meetings where the revenue model of the product is discussed extensively. Meetings where the business wants to visualize and conceptualize every single use case of your product before you even start writing a single line of code.

You are working in an organization where ideas do not “happen” or catch someone by their collars. You are working in a company where ideas are manufactured based on market trends, what is going to be big, what is going to be hot and what is going to have the highest ROI.

The problem with this organization is that when your revenue model, your profitability and your ROI is all you focus on, you build a product which has a hollow sole and a marketing pitch that is full of impotent words.

Put simply, you are trying too hard.

And when the trying ends, you might have a product with a lot of features but you don’t have a story. You have a product that does much more than any other product out there but a product that no one cares about.

Why? Because the really smart consumers, the ones of have the means and the measures to become your unpaid ambassadors also have the common sense to see through your shit and get to the rotten core of your product.

Your product was built by builders who went on hibernation half way through the product because the so called management rubbed them the wrong way and gave them no autonomy, it shows.

Your product was build by 501 programmers who you thought you would just hire and pay to get stuff built, it shows.

Your product was controlled by a team of micro managers, who started five mail threads and had five new ideas for every five lines of code the actual team that was doing some real work behind the product wrote.

Every single act of organizational stupidity that happened through the development of your product is going to show. The folks who can actually tip your product, are going to see right through it and give your product a simple cold shoulder as you sit in meeting rooms and wonder why you are not getting a lot of traffic on your website or why no one is using your product.

What is most ironic, is that these are the same smart mavens who would have joined your team and become your unpaid brand ambassadors, only if you started with a genuine idea of helping your consumers, making a dent in the universe or just adding a little bit of fun to their, and above all your life.

When you are having meetings and politics instead of having fun while building a product, you, your product and your organization tend to become boring. At least, to an outsider. The smartest of your consumers can see right through your product. Of course, the business loves profitable, but the day you stop having fun, you stop being profitable. It’s that simple. Really.

A book I read recently called, Drive, is fundamentally a collection of researches that other authors and companies have done regarding the hidden forces that motivate true builders. The book also talks about thing that do not motivate the true builders.

The book begins with the introducing smart chimps who solve puzzles without the lure of food or direct rewards and introduces you to the concept of intrinsic motivation, which also happens to be the central theme of the book.

This video does an really good job at describing the book and everything the book contains.

One genuinely innovative idea the book proposes is the concept of what I like to call “a quitting bonus”. The idea is fairly simple. Somewhere, smack in the middle of the year, you announce a quitting bonus. Anyone who quits within a month from the day you announce the bonus gets the bonus. It is similar to a joining bonus, only designed with an intention of driving people out of your organization.

The central idea is simple. After a certain level, the truest of the builders in your organization are not moved by paychecks. If you are a truly innovative company, chances are, that you do not want folks who will jump to the next door organization at the first fifteen percent hike that they are offered. So just offer them that much to quit in the first place and see if they stick around.

A quitting bonus gives the jumpers a chance to jump early. After the jumpers have jumped you are left with individuals who are not driven just by a slightly bigger paycheck. You are left with people who are not moved by carrots and sticks. You can now settle down and focus on making small or big dents in the universe through your work rather than constantly worrying about people leaving.

Getting your management to lure people to quit, is a little difficult to describe and sell in a management meeting, but if you think about it, you are way better off paying a small bonus to get rid of a paycheck programmer, rather than having him work half-heartedly for your organization and introducing mediocrity in everything he does.

Go ahead, use money as a carrot to drive people out of your organization and the ones who do not take the carrot might be the builders, story-tellers or people who believe your vision. These are the people you set out to look for in the first place. With the others leaving your organization, you can now settle down, focus and get down to some real work.

A young and budding engineer wants your advice on which of the three job offers he should accept.

Applying for three job interviews and picking from one of the three job offers is a simple “practical” decision for most programmers. Compare the salaries, the perks, the brand name of the three companies that have given you an offer and poof!

By the time they talk to you most programmers have already evaluated, calculated, measured and predicted the pros and cons of each offer. All they seek from you now, is your validation.But the mere premise of seeking validations from others has a problem associated with it. The act of seeking validation is a sign of fear. Validation is boring. Validation is safe.

The person seeking validation is usually scared of the voice that is whispering so very gently in the little corner of his brain.

“But Multiplitaxion Inc, seems like an amazing fun filled work environment”, the voice tells him.

The voice was already hushed by the “practical” thought process long ago.

Multiplitaxion Inc, was paying fifteen percent less than other job offers.

It would have been a stupid impractical decision to pick Multiplitaxion Inc, over a safe, big, high paying job.

But then the upside of listening to that voice, is that after you have heard it and followed it a couple of times, you are no longer scared.

You do not need validations.

You have no “could have" no "would have" and no "should have” scenarios in your life. What you have is a decision not needing external validations. Of course, you can fail, but then in those cases failure usually becomes a part of the learning process, not a reason to quit.

Impractical decisions are sometimes way more practical than practical ones where everything is planned and yet you are scared. Shit scared.

Stop being that practical 501 programmer or an obedient employee when it comes to your career.

We have too many of them already.

Now go do something child-like, impractical and spontaneous.

I wish you good luck.

If you are reading this, you are a reader. By today’s standards, when most programmers do not read books, you can even call yourself a vicarious reader. Chances are that you like to snuggle up in your bed and skim through the crisp pages of a book as leisurely moments glide by.

Books are fun, books are entertaining, books happen to be the source of food for your hungry, possibly hyperactive mind. You love your books so much so that somewhere deep in your mind you actually believe that your books love you back. You even visit the local bookstore during weekends and spend time reading stuff there.

And then you bump across a new book full of new ideas. You are holding it in your hands, snuggling up on a couch and skimming through it. Glancing through it. Hunting for ideas you can take home or ideas you can carry to work and put to use Monday morning. You are moving fast. You are sucking in information like a sponge.

That is not real reading.

Real reading is when you are reading slow, real reading is when you sit with a pencil and circle paragraphs as you read them. Real reading is when you are in crazy war with the book.

Scott Berkun describes his fascination for seeing his book, used, abused and worn out. He explains:

There is something depressing about seeing one of my books high on an office shelf, in perfect condition, covered in a layer of dust. I’m thrilled they were purchased of course, but there’s sadness there too.

Some people keep their favorite books in great condition, and that’s awesome. It’s an act of great respect.

But I admit I love seeing one of books all dog eared, with tabs, post-it notes, or even coffee-stains all over the place. That’s a book that has lived and has spent long hours in use. It’s been lent to many people, traveled in buses and planes, and read by many sets of eyes.

Real reading is when you appreciate the well knit articulate stream of words effortlessly brought together to create equally coherent stream thoughts in your brain. Real reading is when you get so excited about a paragraph that you have to take notes on the margins, a notebook or a piece of paper, right then.

Real reading is when you are not reading a book to finish it, but for the pleasure that you get out of reading it. Real reading is when your are reading is not just supposed to make you a better reader, but a better writer. Real reading is hard. Real reading is slow. Real reading is fun.

So, what did you read this weekend?

A wise man who looked at an email trail between me and my manager once remarked that both of us were misusing the concept of email as a medium. "You are way too long winded", he said, "that is not what email is all about. When you guys have written an email, you should reread it, ask yourself how you can say the same thing with fewer words, delete everything you have written and rewrite the same email this time with a lesser number of words".

The idea was simple. When it comes to writing or reading content, that is supposed to make a point, short works better than long.

While with books the cartoon might seem funny, with emails most people scan your content anyway, and the longer it is the lesser the chances that they might actually read it. After all, people do not read email. They read me-mail.

Years later the same feedback came in for my blog posts. A colleague of mine mildly hinted that I should practice writing shorter. Particularly since all my post revolved around a point which I was trying to make. Making the same point with lesser number of words, was an art, he believed I should start learning as soon as I possibly could.

We're evolving as a race. Twitter imposes a hard limit of hundred and forty characters. Most other mediums are not as controlling and clear about how you aught to use them, but as a general rule, If you want to make a point, keep it short, keep it simple.

If you have a story to tell or a book to write, go ahead and add verbiage. Describe your experiences to your heart's content. If it's humor your are trying your hand at, and you prefer not to use brevity, play with words all you want. There will always be cases where you need to flip those keys for hours but when it comes to an email or a blog post that is supposed to make a point, short is sweet, short is fun, short is powerful.

Ok, done. I think I just made a point. That was short.

Nasty emails that are condescending and / or simply supposed to trigger meaningless arguments are all over the place in the software development world. Some of the best builders I have worked with often think of these as fouls  and believe that you cannot win a game by scoring a foul in answer of another foul.

Given that you are dealing with other human beings and given that you are yourself going to act like an asshole every once in a while without even knowing that you are doing that, chances are that you are always going to face a turmoil regarding the thoughts that you want your brain to focus on and the thought that your brain actually focuses on.

You want to focus on the facebook integration for your product and think about it.

But then, are you truly focusing on it?

Fred is acting like a hardcore asshole. The suit, who you report to has suddenly started acting like a jerk. There are three emails in your mail box that you are just itching to respond. You can shatter the sender of all these three emails right now. All you need to do is hit the reply to all button and slam your keyboard with your fingertips for five minutes.

You are thinking about responding to those emails when you truly want to think about facebook integration.

Aren't you? Huh? Huh? Huh?

Paul Graham has a rather interesting take on the topic. He explains:

Turning the other cheek turns out to have selfish advantages. Someone who does you an injury hurts you twice: first by the injury itself, and second by taking up your time afterward thinking about it. If you learn to ignore injuries you can at least avoid the second half.

I've found I can to some extent avoid thinking about nasty things people have done to me by telling myself: this doesn't deserve space in my head.  I'm always delighted to find I've forgotten the details of disputes, because that means I hadn't been thinking about them.

My wife thinks I'm more forgiving than she is, but my motives are purely selfish.

Some attacks are best defended by funny twitter hash-tags, some are just not worth responding to and some are not even worth thinking about, because all they do is clutter your brain and occupy precious processing time which could have been otherwise used processing way more fun filled ideas that would help you move forward. Thinking of how you are going to respond to Fred? I suggest throwing the idea out and not giving Fred your precious processing time.

Go reserve your processing time for something more meaningful that is going to add some genuine value and ultimately matter in the long run.

I wish you good luck.

There is something to be said about throwing out "work in progress" versions of chapters for your book online. Last week, I published a chapter of my book live and within a week I heard from more than individuals who had important but varied feedback about that chapter. All their feedback basically boiled down to this:  'Pops, the chapter sucks! Take it down and rewrite it. Now!'.

The three primary reason why most people disliked the chapter was because:

1. The chapter was written with a timeline in mind and that showed in the writing.
2. I did not have a lot of fun writing the chapter and that showed in the writing too.
3. The third feedback was a rather long feedback which came down the fact that writing for a book is very different from writing for a blog post. When you are writing a blog post you have an audience that reads you and is aware of the context you write in. When you write for a book you need to tell a story, set the context and help your reader understand the context. If you don't do that you have lost your readers.

I continue to be amazed at how easily and clearly people can see through the work that is done halfheartedly without a lot of passion or work that is just done to meet a timeline.

So as of now, I am taking the chapter down and giving you a big fat sorry for wasting your time by asking you to read a chapter that was half baked; something that even I did not enjoy writing in the first place.

Going forward, if a chapter goes out, you can be rest assured that I have given it my best shot, have enjoyed writing it and that there is a good chance that you might have a concrete take-away or something to learn from the chapter.

And as far as this post is concerned, what you can take away from it is simple.

Whether it is a new feature, a new software or a new chapter of your book, the same rule applies when you are about to publish something online.

Did you enjoy writing it?

If you did not enjoy writing it, they will not be able to stand it when they download it.

Do not publish it live.

Let it soak. Work on it. Make it better.

Bring it to a level where you can get at least yourself to genuinely like it.

I wish you good luck.

If you have been a reader of this this blog, you probably know that I am not a big fan of planning. Having said that, I like to celebrate all forms of doneness. An online version of the Table of Contents is my attempt at celebrating doneness as far as this book is concerned.

You can take a look at the work in progress version Table of Contents by clicking on this link.

The page is slightly crude  in terms of design but the good thing about this page is that it gives you a single URL from where you can download all files associated with this book. Of course, any new chapter added to the book will also get added to the Table of Contents.

The second chapter of the book is now live for download. The point of this chapter essentially is introducing the concept of a builder and what drives builders around the globe. The chapter can be downloaded using this link.

It is funny how the guys who talk about management, hikes, career or rapid professional growth hardly ever understand or get to any of these while the folks who are getting a kick out of building stuff often end up getting good at all of this. What is also amusing is how most kickass developers around the world shrug at discussions which involve these topics but get insanely excited when talking tweaking a for-loop which has a database query inside it.

A consistent doer is much more effective than the talker.

This chapter lays the foundation of some for these ideas and more.

Go get the chapter here.

As always, your ideas, comments and suggestions are always welcome.

Feel free to email them to me or use the comment on this post.

For those of you who might have been following the blog and downloaded the Acknowledgement section of the book, the first chapter of the book where the basic theme of the book is introduced is now live and can be downloaded using this link.

During my years of observing multiple organizations at work, one of the recurring theme that often keeps coming out is that when we get together in large groups and try to organize things, we often loose the ability to thin slice information, organizations and situations.

The first chapter is all about thin slicing the people who work in the business of software development.

You can get the chapter here.

As you read the chapter please do remember that this is a draft version and is open to change. If there are any typos, errors or concerns you have regarding any of these chapters, please feel free to email me or drop in a comment in the comments section.

Now go download the first chapter of the book here.

Don't forget to email me your thoughts, suggestions or opinions. Given the fact that I am not working with a full time editor, these comments, suggestions and opinions genuinely help.

Long Story Short.

For those of you who know about my book project. I have started releasing parts of the book live as and when I get considerably 'done' with those parts. This is the first in the series of posts where the Acknowledgement section of the book goes live.

You can get the draft of the PDF version using this link.

If you don't know what this is all about, read on. You know what, even if you know what this is all about, I would still recommend you read on.

The Story So Far.

Months ago I announced on this blog that I would be doing some serious bathroom singing at a concert and that this was your chance to boo at me. The book, even though I have no clarity about what I plan on calling it, was an idea that caught me by my collar and would not let me go till I had set it down on a white canvas of my word document or blog posts.

After writing a truck load of content and material for the book and making all of it live, I looked back at the content and thought I would just dump it in a word document, publish it and be done.

Then when I started re-reading the content, there was only one thing left to tell myself:

Fu@#k!

I mean seriously. There are primarily three reasons why I was f@#cked. They were:

1. Editing and Proof reading a book is hard. Just like everything else this is the ten percent of the work that is usually the hardest. Which means that there was quite a bit of work still left on the book.
2. Your past work, when looked back, from a point and time in the present always sucks. Which meant that there were parts of the book that would have to be heavily re-written and parts that would have to be edited out.
3. The book was not going to let me go till it had received the final touches and till it was released.

So, after a state of panic and denial which lasted for a few days and then jumping over to a couple of added side projects, I came back to the book and decided to pause all other side projects of my life till I am done with releasing this book.

Your Help And Participation Required.

As always, when I sat down to edit the book and give it the final touches, I thought of releasing parts of the book as PDFs which you can download, read, talk about, blog about, tweet about, criticize, comment on and give your feedback on.

With every release of a new chapter, go ahead and grab a copy of the chapter. Go through it. If you find any typos, let me know. If there are parts that you believe are better left out, let me know. If there are parts that you feel would be better re-written let me know.

You can either leave a comment on the post where the chapter is announced for download or just email me using the mail icon on this blog.

The Content.

I've given a decent round of editing and proof reading to the Acknowledgements section of the book which is now available for download.

More chapters and added parts of the books will start following in the weeks to come. Looking forward to your comments, suggestions and opinions. Given the fact that I am a cheap author working without a real editor your help would mean a lot.

Now get the Acknowledgements section of the book using this link and do start in your comments, suggestions and opinions.

I'm late. We were going to have a product scrum. I worked late and could not get up. Shit. I was supposed to get the scrum started. We were supposed to talk about the features we would address in the next sprint. I overslept.

When I rush to office, my gut reaction is to email everyone and let them know that I am sorry for cancelling the scrum. We can do it later during the evening.

But the scrum has already happened. The team has already met. They have already picked the items they would address in the next sprint. They have already started working on those items.

I glance through the backlog, desperately looking for items that they should not have picked up. Items that are not 'high priority'. Items that are not even 'required'. I am desperately and quickly glancing through the list, looking for every single item in the list that they should not be working on. Looking for any mistakes that they might have made during this morning's scrum that basically happened without me.

Stop it. A voice deep down within me tells me.

I glance through the list.

Stop it. The voice repeats itself.

There, that's the item they should not be working on. It's just packaging. They could have done this later. There are so many other high priority items that they could be working on. I tell myself.

Yeah right. You are scared. Scared of losing control. Shit scared. Deal with it. The voice says coldly and disappears.

It's like being slapped on my face.

The voice, as it often turns out, is correct.

I decide to keep my gob shut, focus on fixing the bugs that are on my plate and let my team do their thing. They are growing. They are learning. They no longer need me to give them direction, and that, in a very special way, is a hugely good thing.

Want to see if your manager is worth his salt? Stop involving him in a couple of decisions. I am not even talking about the overall product direction. Just a sprint which lasts a month. Go pick a few items from the backlog that you feel are most needed for the product and start working on them without involving your manager.

Did you piss him off?

Did he freak out?

Did he just politely invite you to a meeting room that tell you that you are working on items which are not high priority?

Or did he find something bigger and better for himself and let you continue with the sprint without any interruptions?

How you react when your team stops asking you for direction and starts taking their own decisions is your true test of leadership. Go on, give up that insecurity. It's way too heavy and you cannot carry it with yourself in the long run anyway. Go ahead. Throw it away. Shred it off.

I wish you good luck.

Fred is in a meeting. Answering questions about the delay of a project and why things are not moving. He is passing the buck to his team in their absence. Fred as it turns out is acting like a whiner and is getting loved for it.

The others in the meeting room seem to have joined him in their collective criticism of the team and why they are so unproductive.

Every single individual in the meeting seems to be getting a perverted sadistic pleasure out of mentioning how unproductive the team is. No-one seems to be talking about how utterly helpless they are in terms of helping the team.

There is a major bug in the system. Discussions seem to revolve around why the bug was missed during the testing cycles. There seem to be no discussions around what we can do to make the testing cycles better. Not a single person in the room seems to stand up and contribute towards helping with testing the application before it is released to the client.

If there is one thing I have worked on really hard, in the last few years of my career, it is observing human beings in general developers and managers in particular.

In this post I am going to let you on to a little known dark secret that is so well guarded that even most managers around the world are not aware of it.

Before I tell you the secret however, I need you to promise me, that you will not dismiss the secret as stupidity. That you will hear me out. That you will at-least think about it. That you will do some honest soul searching and ask yourself if it is true.

Ready for the secret? Here we go.

Most managers around you. The ones you work with. Irrespective of how amazing they are as managers, get a sadistic perverted pleasure out of a situation where their team fu@#ks up big time. Don't believe me? See a manager describe how unproductive his team is, in a meeting called to discuss why the project is not shipping on time.

Observe a manager closely as he talks about how unproductive his team is. You might actually seem very mild indications of subtle dramatic pleasure and excitement in his voice as he speaks. He will refer to his own team as 'they' instead of 'we'. The idea is to disassociate yourself from trouble, pass the buck over to your team and run.

And this is not about bad management or micro-management. If one of your team members went out and did something stupid, like delete a production database, I bet you have experienced this feeling too. The first gut as a human being is that you want to disassociate yourself from 'him' and then get in a meeting and talk about his stupidity and how to resolve it.

Why mention the fact that giving 'him' the access to the production database was in itself not such a smart thing to do in the first place. After all, that makes you equally responsible for the shit that just happened. No one needs to know that.

For years managers have got away by just blame and whining about their teams and their team's lack of productivity. So much so that, most managers around the globe seem to get a mild sadistic pleasure and a kick out of criticizing their teams.

If you run an organization, go make your managers accountable for their teams. Their failure is your failure. In fact it is the entire organization's failure. Breathe. Let that fact sink in. Seriously.

Stop talking. Stop bitching. Stop whining. Stop disturbing your team and help them any in real, productive ways that you can. Take up a round of testing. Do their documentation. Check every screen of a new release meticulously. Find out other ways of reducing their work and helping them productively.

If you cannot do any of that, just get the shit out of their way and let them function independently.

And if you did not even realize that you get a secret pinch of pleasure deep down inside at the first mention of f@#kup or drama within your team, now might be a time to do some serious soul searching. Go on. Starting thinking about how you can stop getting that perverted sadistic kick of pleasure every time your team fu@#ks up. Stop it as quickly as you can. Seriously.

Every now and then I stumble upon medium sized software development companies which play around with their product and their pricing. Observe these companies closely and you will realize a common trend running through all of these.

Most tend to start a product with a product idea and not a personal pain point that they want to solve to begin with. When you get subject matter specialists in the room and when you start spending hours gathering requirements, about a problem that you couldn't care less about, you tend to build mediocre products that, 'meet all requirements'.

The same subject matter specialist that billed you by the hour, also happened to bill your competition and what you have in your hand right now is a 'me too' product. Your product has screens which are very similar to the screens of your competition. Your product has features which are very similar to your competition. Your product also has pricing which is very similar to your competition.

You are what James Surowiecki describes in his article for the The New Yorker as, Soft in the Middle. He explains:

For Apple, which has enjoyed enormous success in recent years, “build it and they will pay” is business as usual. But it’s not a universal business truth. On the contrary, companies like Ikea, H. & M., and the makers of the Flip video camera are flourishing not by selling products or services that are “far better” than anyone else’s but by selling things that aren’t bad and cost a lot less.

These products are much better than the cheap stuff you used to buy at Woolworth, and they tend to be appealingly styled, but, unlike Apple, the companies aren’t trying to build the best mousetrap out there. Instead, they’re engaged in what Wired recently christened the “good-enough revolution.” For them, the key to success isn’t excellence. It’s well-priced adequacy.

These two strategies may look completely different, but they have one crucial thing in common: they don’t target the amorphous blob of consumers who make up the middle of the market. Paradoxically, ignoring these people has turned out to be a great way of getting lots of customers, because, in many businesses, high- and low-end producers are taking more and more of the market.

In fashion, both H. & M. and Hermès have prospered during the recession. In the auto industry, luxury-car sales, though initially hurt by the downturn, are reemerging as one of the most profitable segments of the market, even as small cars like the Ford Focus are luring consumers into showrooms.

And, in the computer business, the Taiwanese company Acer has become a dominant player by making cheap, reasonably good laptops—the reverse of Apple’s premium-price approach.

While the high and low ends are thriving, the middle of the market is in trouble. Previously, successful companies tended to gravitate toward what historians of retail have called the Big Middle, because that’s where most of the customers were. These days, the Big Middle is looking more like “the mushy middle” (in the formulation of the consultants Al and Laura Ries).

The companies there—Sony, Dell, General Motors, and the like—find themselves squeezed from both sides (just as, in a way, middle-class workers do in a time of growing income inequality). The products made by midrange companies are neither exceptional enough to justify premium prices nor cheap enough to win over value-conscious consumers.

The same article also talks about why it is so tempting and yet so painstakingly non-rewarding to stay in the comfortable middle path:

This doesn’t mean that companies are going to abandon the idea of being all things to all people. If you’re already in the middle of the market, it’s hard to shift focus—as G.M. has discovered. And the allure of a big market share is often hard to resist, even if it doesn’t translate into profits. According to one estimate, Nokia has nearly twenty times Apple’s market share, but the iPhone alone makes almost as much money as all Nokia’s phones combined.

The argument becomes much more dominant if you are launching your own product or service. You are not exactly a Sony or a Nokia and chances are the soft middle in your industry or domain is already taken by someone. Your only chance of surviving is that you make the best freaking products out there. Build awe and surprise by innovating the best product out there.

If you can't build a seriously kickass product that people would pay a premium price for, build something acceptable that works and disrupt your competition with the lowest of prices.

After all, safe is risky, remarkable is fun.

Go on, get out of that circle mediocrity when it comes to products and prices.

I wish you good luck.

How often have you witnessed two or more individuals disagree over something and battle it out over email?

Come on. You have seen the thirty-five email long mail thread where two big Grizzly Bears of your organization were fighting with each other over a technical disagreement. Haven't you? Huh?

If you've been in the business of building software long enough I bet you have been a part of at-least one or more of these email trails. At more than one point of time in my life,  I have been involved with quite a few of these and have specially devised twitter hash tags which can be used to rescue and bail me out of some of these 'yes but' discussions and arguments.

The deal is fairly simple. If it's a productive, objective discussion where the best solution is bound to win and it helps you learn something new, battle it out. Argue. Discuss. Learn. Strain yourself defending your strong opinions weakly held.

At the first indication of things turning personal, the sign of a meaningless flame war, the sign of bozoism or the sign of a 'yes but' discussion, back out. The battle is just not worth fighting.

Scott Hanselman's post on keystroke worthiness, which is inspired out of the original classic counting your keystrokes, by Jon Udell, is not a post which addresses this topic directly but provides some useful advice if you are just about to hit that reply to all button and respond to an email which is soon going to turn into a never ending yes-but discussion. The basic idea is simple. You have a finite number of keystrokes that you can use in your entire life. Scott explains:

Let break it down. I'm 36 and change. I'll live to be 80, let's say, and I can type 100 words a minute (but 50 of that is errors and the backspace key) so let's say 50WPM. If I type for 6 hours a day, 5 days a week, 50 weeks a year, for the next 44 years, that means there are 198M keystrokes left in my hands. Max. Period. And that's generous; it's likely 10% of that.

5.1CPW * 50WPM * 60m/hr * 6hr/s a day * 5 days/wk * 50 wks/year * 44yrs = 1,009,800,000 keystrokes left in your hands.

Let's assume the average length of an English word is 5, plus a space, so six. That's a ceiling of 168M more words I can type in my lifetime. Nothing I can do, short of dictation, or some new brain invention is going to create more keystrokes. I am I/O bound by my hands. The keystrokes they contain are finite. And this assuming my hands don't give out.

Drink that in. OK. So now, next time someone emails you ask yourself "is emailing this person back the best use of my remaining keystrokes?" That includes both 1:1 and 1:many emails. You could even add a little hubris to it and say: "Does this person deserve the gift of my keystrokes?"

If you are working with human beings, by now you probably already understand the fact of life: shit happens. While it is tempting to respond to every flame mail, every nasty comment and every heating discussion, remembering that your keystrokes are finite is your first step towards using them in places where they can have the biggest impact.

Go ahead, back out. Turn the heating mail trail into a objective research driven blog post.

Go on and Present your facts and findings and give the whole wide world the gift of your keystrokes. Chances are, that this is where your keystrokes will make a much wider impact on people who want to learn. Folks who want to participate and contribute.

Chances are that this is also how you will avoid useless stress, learn something new, move on and get stronger to fight much more meaningful battles that matter. After all, you have a limited number of keystrokes. Don't waste them on situations or mail trails which are not worthy of the gift of your keystrokes. Use your keystrokes wisely. 

I wish you good luck.

My early school life started with underpaid teachers who were so cold about the subjects they taught that their passion was hardly infectious. Most of them were faking it, frustrated, depressed with life or were not even decently deep in their subjects.

By high-school, thanks to their combined effort, I had been convinced that there was something majorly wrong with the way I saw the world. Of course, I had my experiences with a few good teachers. Most of the other things that school taught me however, was just through some strange isolated incidents that changed me, rather than a long cultivated respect or admiration for any of the teachers or the school in particular.

One of my high school English teachers for example, was the first to give me amazing grades and break the stereotype that English essay writing in high school was all about how many stellar high profile words you could cram in that essay. That incident to an extent told me that essay writing can be fun, that I could be really good at it and that I could even just write for the fun of writing.

This however, was an isolated incident and if I sit down to look back at the amazing teachers who worked for my school and who have had a lot of influence on my life, I hardly find any. By the time I started college, I had pretty much come to the conclusion that those who seriously, cannot do, teach.

It was then that while continuing college I also landed up with my first job as... a part time system administrator and a part time computer science teacher. It was payback time! Like a rebel I set out to break all rules of teaching.

If someone felt like dropping a class or if he didn't understand something I was teaching, it was all my fault. I knew that back from my own days at school. But even these were just games a teenager plays. I was nowhere close to seriously dissecting and understanding what makes a really good teacher.

It was not until later parts of my career that I met a very different kind of mentors. These were people who were so passionate about their subjects that their passion would transmit over TCP/IP, come off the other end of your monitor and infect you.

These were kick-ass teachers. Not a bunch of underpaid non-doers, but the best in the industry, who were so successful they could not even give you their free time and so thoughtful, that they actually made it an effort to share their experiences with you.

These guys knew how to learn like a teacher and teach like student.

To a large extent, I had completely stopped believing in training programs by now. Anyone who was good at what he did, was online. Sharing his experiences. Teaching you stuff through his writing, podcasts and videos. Others, were just not worth wasting your time or your money on.

It was not until recently that I started taking up a couple of language classes that I started dissecting the difference between an amazing teacher and a mediocre one, who might even be an underpaid non-doer.

My French Lessons

The classes happened in a brightly lighted class room of a plush building, belonging to a very famous organization, which shall remain unnamed. On the very first day the person teaching us French had an issue with some of us not carrying a proper notebook and a pen to take notes. On the second day, we were told that just weekend classes were not enough and that we should study French at home as well.

On the third class, we had already pissed the teacher off by the lack of our involvement. But then, the feeling was mutual for some of us. The teacher, as it turns out, had pissed some of the students off by her slightly intimidating approach to teaching. Things were written on whiteboards. People copied them and then people tried to memorize French. She would read things out from grammar books and then people would take notes.

By the third lesson I had already found a lot of rather amazing French learning tutorials online which were way better than my French class and was having a ball with those. I was hooked to the idea of learning new languages and I was just using the classes as a means to check my progress and see where I was.

The ones who were actually expecting to learn something out of that classroom however, were utterly disappointed. By the fifth class, we had been reminded more than a dozen times that French was a very difficult language and that we must give in hard work to learn it. By the fifth class, a good thirty percent of the class had got intimidated and had either dropped out or just stopped coming.

With all due respect to the person who taught us French, she was a nice person and she was truly trying her level best to teach us French. She was amazing at French too. It's just the 'teaching' part where she was... well... just as mediocre as some of my school teachers.

My Sanskrit Lessons

For those of you who might not know what Sanskrit is, it is a ancient Indian language. Languages for me are a medium of expressing intent. I speak over four of them very fluently and somewhat understand a few more. For me every language has a use. If English is the language of communication, French is the language of romance, Sanskrit is the language for the intellect and the soul.

So when I was asked if I wanted to attend a one day session on Sanskrit I promptly answered 'yes' and attended it even though I had been able to grab just five hours or so of sleep that night.

I walked into the class without a notebook or a pen to write stuff on and then when the memories from my French class flashed back, I thought, since I was there I might as well show some respect to the teacher and go grab a notebook. So a colleague of mine and me went out and grabbed a notebook along with a pen.

There was something interesting about the teacher however. He started the class by asking us how many of us had never studied Sanskrit in our entire lives. I raised my hand promptly. Then he smiled and asked us which language he had asked us the question in.

Dumbstruck the folks who had lifted their hands looked at each other. The guy had asked us the question in Sanskrit. We had not just understood the question, but responded to it. This was a wearied mix of funny and creepy both rolled into one. We smiled in amusement.

Then there were some philosophical statements that were made, all in Sanskrit, with a little bit of English words inserted in every now and then, to give us the context and help us understand what he was talking about, but during most of the class, we felt like young kids learning how to walk, stumbling, falling, getting up, falling again. It was fun. Serious. Raw. Fun.

Notebooks. We were asked to not use them if possible, because chances were, you were going to lose your notebooks the moment you left the class. We were asked to just listen, sit back, enjoy and have fun.

In the one day boot camp, we were not just taught Sanskrit but that the secret behind any language is not to 'learn by translation'. It is to learn by LSRW which stood for Listen, Speak, Read and Write. You start by just listening to a language like a baby does. You do that for days. Then you slowly start understanding and speaking. The reading and writing are supposed to come in much later.

By the end of the day, two random students from the class got up and did a small situational play in Sanskrit. As we rolled over laughing at their mistakes, our minds were engaged in picking up on every single mistake each one of these guys made. Our minds, were learning. Unlike the French class, we were told over a dozen times in this class, that Sanskrit was easy and the general stereotype that it is really hard is just a myth.

Half way through the training a wearied realization dawned on me. I thought of my French classes we had stopped half way through and had never gone back to attend those. If our French teacher had used a teaching style that was similar to the one this guy was using, we would all be speaking fluent French by now.

The One Thing

If there is one thing I was told to pick as a difference between this Sanskrit teacher and the French teacher, it would be one little word that means the difference between your being a good teacher, your being a mediocre one or your being a lousy one.

Empathy.

No seriously. That is one quality a lot of my underpaid school teachers lacked as well. It's easy to put someone on the spot. Easy to ask him questions and feel frustrated when he is unable to answer questions. Teaching is not about any of that. Teaching is about connecting to other human beings, understanding their minds and giving them the best freaking environments where learning can be a fun and rewarding experience.

After all we are creatures who want to learn. The real question is, are you man enough to teach us? Do you feel strongly about your subject? Is your passion for your subject so strong that you can actually infect others with it? Can you simplify? Can you make it fun?

So, the next time you are planning on conducting a class or a small knowledge sharing session for your organization, here is a piece of advice: keep your frustrations at your home before you leave for the class and don't forget to load your bag with loads of patience. If your students feel bored, you are not entertaining enough. If you have to tell them to read up the subject at home, your passion for your subject is not infectious.

If they are not laughing and having fun, you are boring.Oh and yes, if you feel that your topic is very difficult and complicated, you might know your topic really well but you just might not be qualified enough to teach it yet.

Even if you forget everything else you read in this post, if you are ever going to teach people, whether it be professionally or for a small knowledge sharing session you are going to conduct in your organization, you cannot forget empathy. Now go, infect someone with your passion for a subject or a topic.

I dare you.

You could be a young and budding programmer fresh out of college or a veteran who has had a very long career. One fine morning as the birds flutter outside the office window and you stare at them, you realize a strange thing about the culture of your organization.

You realize that your organization is a safe, non-political environment where no-one is out there to screw you in particular.

You are safe. You are protected. You don't need to fight it.

And then you realize that all you need to get your job done are the few basic programming techniques you slogged hard to learn during your college days. You get a few pats on the back on a job well done, life moves on and you move on to the next assignment. Once again, the skills you picked in engineering school come handy. A project well done and on time. No one is complaining.

What you don't hear however, is that no one is clapping like they did last time either.

This is the start of the loop.

You are using the same skill-sets to product the same output for the same kinds of project month after month.

You are boring to the rest of us.

To you however, office seems like home. It's safe. It's warm. It's cozy. And look, you have made a few friends too!

For you, your friends are people you can take to conference rooms with you and chit chat about process and 'resources' and shit like that. You know, things that seem like work, but are not really work.

For you, friends are people who you are comfortable with. For you friends are people who you do not challenge you. For you, friends are people who you do not challenge either.

Put simply, your friends are in the same shitty loop of safety as you are.

Neither of you have ever brought yourself close to getting fired. Neither of you guys have tested your limits. You have looped your skill-sets, done just enough to get your work 'approved' and then have serious kick-ass chit-chat in meeting rooms.

Then one strange day it happens. You get an email from your customer telling you that your module has done no major feature releases for the last five months. You are not really working. You are just talking about work and whining your time away. Your customer is calling out on your bull-shit. Your customer just told you that the work you are doing lately is fu@#ked up.

Now you are just going to have to deal with it.

It feels like being punched on the stomach doesn't it? Your bit fat hundred pound ego shattered to the ground. The guilt of f@#cking around in meeting rooms for hours when you should have been doing some real work seems like a heavy burden on your back, doesn't it? What do you do? What do you do? They clapped at your work three years ago. They sent you special appreciation emails back then.

F@#CK!

It CANNOT be your fault.

Your first gut-based-knee-jerk reaction? Fire up the mail client. Hit the reply to all button and poop all over with a truck load of shitty jargon that you were busy learning in the last three years.

Resource Planning needs to be done properly... Blah.... Blah... Requirements need to be elaborated and frozen... Blah... Blah... The Quality Approval process needs to provide suggestions on what needs to be improved which they are not doing... Blah... Blah... Yeah.

You review that, pat yourself on the back and whisper to yourself, "Yeah. That aught to set things in perspective."

Thinking of hitting the send button?

Here is my humble advice: Don't.

There are multiple reasons why you need to stop. Now.

First of all, you have just been criticized. You need to give that some soak time.

Secondly, by hitting that send button you are taking your first step at becoming a fully qualified whiner. What ever amazing talents that were bestowed upon you by your engineering college, the ones you have been flaunting for years, even those might slowly start fading away if you walk down that path.

Thirdly, people are going to see your shit and laugh at you and here is the worst part, they are going to do that behind your back, because now they have seen how you defend negative feedback with aggression and lame excuses.

If you ask me, I'd start by telling you to just shut the F@#CK up and apologize. Then when you have done that, realize that words mean nothing. So when the next sprint begins get your ass out of that meeting room, logout of your yahoo messenger and focus on shipping. Then, go ahead and ship. Remember, goals win matches, fouls don't.

Are you still reading this?

Well, it probably means that you have made it through the entire blog post. The irony with a post like this one however, is that if you are reading this, it probably does not apply to you. The mere fact that you subscribe to a blog that talks about self improvement and reflection probably means that you are open to the idea of criticism. I agree, you are probably not the 'you' I talked about during the entire post.

But then, humor me on this one. What if (and I am just saying), for whatever reasons, what if you got distracted and could not produce anything in the last couple of weeks. What if your manager calls out on your shit and tells you that you have been producing horse shit in the last three weeks.

How would you react to that?

Will you try pampering your ego of being the alpha-geek who knows it all? Are you going to defend your guilt of that distraction by pooping all over in the email which you send out as a response?

Or are you going to be man enough to come out and say it, 'Yeah, I know. Sorry about that. Give me some time. I'll fix it'.

Once you have done that, are you man enough to actually go out there and fix it.

If you aren't, you are a whiner in the making.

If you are, we would love to work with you irrespective of the fact that you do go through a few random distractions in your life. We all do.

Our biggest problems are not your distractions. It is also not how you deal with them. It is what you do when we call out your shit.

Seriously. Stop feeding your ego and your guilt.

Now.

I dare you.

You walk a couple of miles into office. Brain Rules and Spark tell you that brisk walking or any exercise before work produces a supply of BDNF and Dopamine to your brain. It's healthy. But this is not a post on fitness. That one is here.

This is a post on 'Doneness'.

Pretty much like fitness, doneness is a state of mind.

Jack is at your desk as soon as you get into office.

A client seems to have reported a critical bug in the application. A bug that triggers a firefighting Endeavour consuming about fifty minutes of your time.

You check your email... ten minutes slip by.

Fred  is a little lost about the his purpose of life and needs mentoring (spelt: psychological pep-talk). You cringe. Another thirty minutes slip by and Fred is completely pepped-up now.

There is an interview you need to take. The candidate has arrived.

F@#CK!

Can't time move a little slower?

Someone on the transmission team needs your help. The dev working on it is stuck with some IIS configuration issues and is getting cryptic error messages. You show him how to change the Application Pool settings to allow Win-32 applications to run in IIS on a 64-bit machine. As you get up, you look outside the window. It's starting to get dark. It's evening.

F@#CK!

By now you have already moved to a panic state. The three items on your TODO list are staring at you straight in the eye. Your manager is calling you for another meeting. Improvise. Make a decision. Pick between the three items on the TODO list or the meeting. You are scared of the monkey taking a stupid decision which might come back to bite your team.  That monkey. Or maybe your team just needs some cover-fire. You decide to attend the meeting.

By the time you get out of the meeting your task list is still snarling back at you and you have a headache from the meeting.

F@#CK!

What happened to your true, fun loving self which used to get things done and ship? You take a pause by the office window to do some serious soul searching and reflect on today. The noise has dulled your brain out and there is a gentle silent voice whispering from deep down within.

"You did not get anything done today."

You feel like shit.

Michael Lopp describes this feeling rather articulately in one of his posts. He explains:

This sensation will appear at the end of the day when you ask, “What did I build today?” The answer will be a troubling, “Nothing”. The days of fixing ten bugs before noon are gone. You’re no longer going to spend the bus ride home working on code; you’re going to be thinking hard about how to say something important to someone who doesn’t want to hear it. There will be drama. And there be those precious seconds when there is no one in your office wanting… something.

It's an important realization. That and the fact that you actually did get a few things done. That interview you took, those three bugs you were able to close during the afternoon. That small class which you refactored while you were eating lunch. Those client emails you responded to while the meeting was going on. You just feel like shit because you are focusing on the three TODO items on your list staring back at you for the last three days.

You are planning, not coordinating.

Even more importantly, you are waiting for a big productive evening instead of celebrating small minutes or hours where you can squeeze time out and get stuff done. Next time you have fifteen minutes between meetings, see if you can look at the bug-list, pick up a small bug and close it. If you can, go ahead, pat yourself on your back. In fact, might I suggest that you celebrate the fact that you #gotdone on Twitter.

And then, when the TODO items on your task list snarl at you in anger, you have another list to throw back at it and not feel like shit.

Productivity is a state of mind, and much like exercising, even when it comes to work, you begin by understanding your basic limitations, working with contains and willing small battles instead of aiming for one large war.

Go ahead, be loud about what you got done today. Doneness is a good thing. It's healthy. It brings you happiness.

Celebrate your moments of doneness with the #gotdone hashtag.

I wish you good luck.

For those of you who might have read this blog post, you probably know my stand on the whole stupid you-follow-me-I-follow-you game that is played so frequently on Twitter.

If you remove that game out of the equation and then consider the amount of chatter and noise on twitter, the real question you start asking yourself is this - is twitter even worth spending any time on or is it just an elaborate version of Yahoo Chat or Yahoo Messenger, depending on if you want to meet interesting strangers or catch up with friends.

My recent activity on twitter however seems to have shot up drastically in the last few days. The rise in activity is a based on a simple realization about Twitter after 'not using it for months'.

If you have been using Twitter regularly, you probably do one or more of the following:

1. Talk about your product or service.
2. Catch up with friends.
3. Paste useful (or useless) links.
4. Collect followers and flex your mussel power.
5. Talk about a global event like the #worldcup for instance.

And depending on which one or more out of the above makes you happy, doing either is perfectly fine. After all, twitter was actually supposed to thrive on activities like these.

What you might be missing out on, however, is an opportunity to observe things around you. If you have been following me on twitter you might have noticed that this is what I have been doing a whole lot lately.

Here are some of my recent tweets that aught to give you an idea of what I mean along with a context of where they were done from:

Isn't it sad that #socialmedia guys are making so much noise about #socialmedia on #socialmedia sites? blatant self promotion.
(While searching the social media tag on twitter).

Amazed at what anger can do to you. Was about to file a complaint about a rude call center guy. Waited and decided against it. #happy.
(While having a bad time with an Indian call center).

Wonders how to give an interesting talk and constantly worry about someone feeling bad or disagreeing at the same time.
(While reading the GNU speaker guidelines).

A girl learning how to drive. wonder why people become so serious and worked up when learning anything new. smile. learning is fun.
(Walking on the road, as I watched a girl learn how to drive).

School uniforms are a disrespect to diversity. every human being is different and so is what he wears. can we please stop raising sheep now?
(In a bus in India where I saw a few students in uniforms get on and act like a flock of sheep being herded into the bus).

Word of advice: when you don't know what you are doing find people you can trust and who know what they are doing. set them free.
(While watching a new budding manager managing people).

Honking on Indian roads is a reflection of general Indian personality. loud. interesting and at times downright obnoxious. #toughlove.
(On Road in India).

Have you ever tried actively keeping a track of the days as they slowly pass by? The velocity at which time moves is rather scary.
(On a slightly depressed moment).

If there is one word you can block from your company's vocabulary what would that be? For mine it would be calling people "resources".
(As I heard the word 'resource' getting mentioned over a dozen times in a meeting at work).

The food joint where I am eating with brother and nephew has been around since 1939. the point: small businesses with a niche can work.
(While enjoying a snack at a small joint near home with brother and nephew).

The point, is that these are all events that pass us by about a dozen times a day. How frequently do you see a serious girl, looking all worked up behind the drivers wheel with an instructor equally worked up and worried? How often do you get turned off by the responses from an Indian call center? How often do you hear the term social media as if its the next best thing since slice bread? How often do you eat out at a small joint you love?

These are all perfectly 'normal' event. What twitter does is that it gives you an opportunity to turn these into 'abnormal' events by adding your perspectives and by adding a little bit of yourself to these events.  It then allows you to share your perspectives with the rest of the world and more importantly, archive them for your own future use.

What better way to end this post, than with a tweet that I first posted when I realized and started doing this:

Tweeting is about having a abnormal way of looking at perfectly normal things. Now give us meaningful content. I dare you.

See if you can make your different, weird or opinionated perspectives fit in that hundred and forty characters.

I wish you good luck.

Side Note: If you are still not there on Twitter, here is quick starter guide.

Hell has broken lose at Multiplitaxion Inc. The sky is falling. The shopping-cart of a production system seems to have developed a glitch in a live website and apparently, it seems like people cannot buy things from the website.

I know what to expect next.

Throng of emails start flowing in on the support system.

Then comes a few emails from the client, with a little bit of tough love, directed at all of us.

It looks like there is a minor configuration glitch in Jack's code which is causing this awkward moment for all of us.

I hear the soft whisper in my head. My first instinct, the hidden, sedated asshole within me, whispering in a gentle, seductive and powerful voice.

"Call up Jack! Ask the incompetent idiot to fix it ASAP. Tell him it's CRITICAL. Absolutely fu@#king critical."

And then the veteran who has been there, done that and knows that it not work in the long run takes over.

I smile inwardly and decide to wait, answering the emails to the best of my abilities and sitting down to fix my own share of bugs, reminding myself that I am just as incompetent and just as big an idiot as anyone else.

Jack has already received the email. Jack is a mature human being with brains to understand that when shopping carts go down, companies lose money. He is probably looking at the problem right now and trying his best to fix it as quickly as possible. If he does not respond in the next hour or so, I will causally check with him. I respond to the seductive voice in an equally commanding tone and shrug it aside.

A few minutes later, another email lands on my inbox. It's Jack. The issue is resolved. The cart is up and running again. Life is back to normal.

The next morning, Jack is at my cubical. He wants to apologize about the issue and all those emails everyone had to reply.

"Nah. Don't worry about it. Shit Happens." --- I respond with a smile.

That is it. End of discussion. We go grab a cup of hot chocolate, talk about latest phone that I have been drooling over and discuss my intent of buying it.

I am happy. My life as a 'manager', 'development lead' or whatever it is that you want to call me, is a happy one.

It was a zero-touch operation or me. I now have a self sustaining team that functions perfectly well without me and I would have never found that out if I would have intervened on that and many countless nights before that.

Yes, there have been a few accidents. A few bumps while the teams I worked with in the past were in the drivers seat and I was in the back-seat, looking out and admiring the view, but nothing bad enough to get us killed.

Here is the interesting part however.

Every time the sky starts falling you will have a temptation of taking the drivers seat. Ease out of it. Let your team drive.

Because if you let them drive, they might get into a couple of small accidents and maybe even a couple of big once, but then they will learn how to drive, really fast and really well.

And once that happens, you can just take the back seat and admire the view or just find bigger challenge for yourself.

You know, the "professional growth" crap they talk about in seminars. This is how it happens.

Try it.

It actually works.

I wish you good luck.

I just promised someone I'll do a talk in their conference. He wants a copy of the presentation I am going to deliver at the conference. I have two unfinished drafts of blog posts sitting in my drafts folder. There is a side project that I need to be working on.

I am out with my family, eating in an amazing Italian restaurant. There is some shopping that I need to do. The book that I started working on is on a stand still, unfinished, grabbing me by collar and asking me to give it the finishing touches it deserves.

Put simply, I am on a thread dead-lock as I desperately try to figure out which thread to take up and process next.

It is something fairly similar to your machine's processor choking with too many applications running and each ALT+TAB takes you seconds to switch.

The conference cannot wait, neither can the blog posts but it is time to choose between the book or the side project. A decision has to be made,  a thread needs to be ended and a door needs to be closed. At-least temporarily.

Dan Ariely in his absolutely amazing book, Predictably Irrational talks about the inherent fear that we as human beings have towards closing doors. He used experiments which included observing students while they played a computer game designed specially for the experiment to observe how human beings react to the idea of closing doors. He explains:

To find out, we changed the game. This time, any door left unvisited for 12 clicks would disappear forever. SAM, A RESIDENT of the hackers' hall, was our first participant in the "disappearing" condition. He chose the blue door to begin with; and after entering it, he clicked three times.

His earnings began building at the bottom of the screen, but this wasn't the only activity that caught his eye. With each additional click, the other doors diminished by one-twelfth, signifying that if not attended to, they would vanish. Eight more clicks and they would disappear forever. Sam wasn't about to let that happen. Swinging his cursor around, he clicked on the red door, brought it up to its full size, and clicked three times inside the red room. But now he noticed the green door—it was four clicks from disappearing.

Once again, he moved his cursor, this time restoring the green door to its full size. The green door appeared to be delivering the highest payout. So should he stay there? (Remember that each room had a range of payouts. So Sam could not be completely convinced that the green door was actually the best. The blue might have been better, or perhaps the red, or maybe neither.) With a frenzied look in his eye, Sam swung his cursor across the screen. He clicked the red door and watched the blue door continue to shrink.

After a few clicks in the red, he jumped over to the blue. But by now the green was beginning to get dangerously small—and so he was back there next. Before long, Sam was racing from one option to another, his body leaning tensely into the game. In my mind I pictured a typically harried parent, rushing kids from one activity to the next.

Is this an efficient way to live our lives—especially when another door or two is added every week?

I can't tell you the answer for certain in terms of your personal life, but in our experiments we saw clearly that running from pillar to post was not only stressful but uneconomical. In fact, in their frenzy to keep doors from shutting, our participants ended up making substantially less money (about 15 percent less) than the participants who didn't have to deal with closing doors.

The truth is that they could have made more money by picking a room—any room—and merely staying there for the whole experiment!  (Think about that in terms of your life or career.)

When Jiwoong and I tilted the experiments against keeping options open, the results were still the same. For instance, we made each click opening a door cost three cents, so that the cost was not just the loss of a click (an opportunity cost) but also a direct financial loss. There was no difference in response from our participants. They still had the same irrational excitement about keeping their options open.

As human beings in general and as programmers in particular we are hugely attached to the idea of keeping our options open, keeping multiple choices in our lives and getting involved with multiple projects. On one hand, we have programmers who cannot program and 501 developers. On the other we have folks who are working on so many different things and trying so hard to keep all of these efforts alive that none of them ultimately see the day of light.

For me, it was this secret project of mine, that would have to wait. I am closing a door for the time being, so that I can focus on another one and so that the book can reach a meaningful logical milestone.

If you are getting bogged down with too many side-projects to work on, too many speaking engagements, too many things to do and you find yourself handling multiple threads even on weekends, maybe its time to take a pause, evaluate and close a few doors. The least you can do is close them temporarily and then come back to them at a later time.

Prioritize.

Focus on what is really important to you, even if it means closing a few doors of your life so that you can focus on the ones that mean a lot more to you..

Go ahead, pick a few assignments or projects that can wait and either end them or put them on hold temporarily.

I wish you good luck.

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

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

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

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

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

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

Boredom.

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

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

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

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

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

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

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

It's more than just the iPad.

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

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

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

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

Go ahead, slow down.

Experience a little bit of boredom today.

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

I wish you good luck.

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

Or should I say, a drama king.

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

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

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

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

Drama.

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

More drama.

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

Insanely massive drama.

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

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

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

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

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

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

It's hard.

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

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

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

Seriously.

Start saying no to it.

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

I wish you good luck.

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

You are impressed.

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

You cringe.

A few days ago I posted a small tweet.

You thought you knew Jack.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I wish you good luck.

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

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

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

Approvals were quick.

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

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

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

I wish you good luck.

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

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

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

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

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

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

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

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

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

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

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

I wish you good luck.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To be honest, I love doing all of that.

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

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

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

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

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

People, here is presenting, my code-persona.

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

So What Happens To This Blog?

Nothing. It continues. Just as before.

I am not stopping to write on this blog.

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

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

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

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

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

More content will start getting added there soon.

Wish me good luck.

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

I cringe.

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

Fred as it turns out, has done neither.

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

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

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

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

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

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

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

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

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

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

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

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

I wish you good luck.

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

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

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

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

I call these folks, converted assholes.

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

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

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

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

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

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

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

I wish you good luck.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I wish you good luck.

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

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

Discuss.

We are seated at a local startup club where startups demonstrate their products to a bunch of fellow developers, designers, entrepreneurs or technologists. An young man is talking about his idea of building a community site with a difference. He wants to build a community site for runners and walkers around the world.

He doesn’t have a thing to show us.

No wireframes. No screens. No working systems. Absolutely nothing.

He seems to be blabbering non-stop about how his idea is different and how no website in the world has thought about it before him. It almost seems like he has just hit upon a totally different and new way to fly the skies.

During a quick bathroom break we start talking to this gentleman and I mildly and politely hint to him that maybe, just maybe, everything that he is trying to build on his community website can be easily done with a Facebook community site.

He seems grossly offended.

Somewhere, unknowingly I seemed to have shattered his dream and told him what he really does not want to hear.

Its not his fault though. Most ideas are a dime a dozen. To make things worst, when its your idea you tend to think that its the best thing since slice bread. You tend to protect your ideas like babies when your all your ideas need is dedication and concrete work, not protection.

Go on. Take the litmus test. Think of an idea. Then try to find websites that do exactly what you just though about. Chances are that you will stumble upon at-least a dozen sites that do exactly what you were just thinking about.

There is also a high possibility that when you stumble upon these websites, you will disregard them as useless and you will start sentences which begin with – "yes but this website is slightly different than what I was thinking about. It does not do 'Z' which is what is going to differentiate us from them.

Newsflash.

Your idea is already taken. Someone beat you to it and you have no unique selling points. You are just making this differentiation crap up because your brain has just switched to a denial mode where it is clearly refusing to accept that someone beat you to that idea, executed the entire idea flawlessly and is making money from the idea.

You, were late.

Deal with it.

Your product idea just does not have a unique selling point.

All that yes-but-we-are-different talk that you are mumbling is just bullshit to feed your own ego and pamper it.

You have about a dozen competitors out there and the only thing that is going to set you apart is how you add a little bit of yourself to the product and how you handle execution.

Now, take a pause. Reflect. Ask yourself if you can genuinely pull off an execution that is superior than any of the other products out there. Be careful, because even here, your brain is going to trick you into saying, 'Sure! Of course I can!' without giving it any real thought in the first place.

Take your own sweet time. Reflect. If the answer is no and if the idea is not keeping you awake at night, it's okay let go shamelessly. After all, you do not find truly remarkable ideas. Truly remarkable ideas find you. It just makes the defeat that much more easier to accept and it frees your mind to find something else that really matters to you.

Go ahead, start something that makes a small dent in the universe or just give up and wait for a new idea but don't build a mediocre crappy product because we have enough of them already.

I wish you good luck.

One of my first teams kicked some serious butt. We shouted at each other, we used the F-word rather generously and when that did not work, we raised our volumes to a level that would blow the office roof sky high.

Then when the fight was over and the best solution had won, we would go out and have lunch together with no hard feelings.

That was my understanding of strong opinions and disagreement.

These were two very useful tools to reach the best of solutions. During my times at Multiplitaxion Inc, I often tended to respect guys who had strong opinions weekly held and had  the conviction or the spine to disagree with me.

Disagreement was loud.

Disagreement was a good idea-validation-check.

Disagreement was good.

It was only during the later part of my career that I bumped into a different form of disagreement that confused me and left me totally dumbfounded.

Ladies and gentleman, if you haven't met 'Silent Disagreement' you are one lucky son of a gun.

If you have, you know exactly what I am talking about.

This is a form of disagreement where someone sits smack across the table to you in a meeting, nods his head in agreement to everything you have to say and then goes out and does just the opposite.

Consider an arbitrary example for instance. Assume that everyone in  your organization, starting from the lowest programmer fresh out of college, all the way up to the chief-executive-officer agree on having a free open internet access policy.

You call the group who is responsible for maintaining the restrictions on firewall in a meeting where you tell them to drop all restrictions from non-work related sites like Facebook or You-Tube. You are going to trust your employees work ethics more than a firewall, you tell them.

Everyone nods in agreement.

You wait for the firewall policies to change and Facebook to get unblocked. Nothing happens. Days later someone higher up in the management sends a flame mail, asking that all sites be unblocked immediately, and everything gets unblocked, only to get re-blocked a couple of days later.

You call another meeting to discuss what went wrong here. Did we disagree on something? Did we not collectively decide that we were going to have an open internet policy? Did we not agree on that? Didn't we waste an entire day discussing the pros and cons on having free internet and trusting your employees versus blocking non-work-related sites?

Strangely enough, even in this meeting, everyone agrees to the idea of an open internet policy.

Strangely enough, non-work related site still remain locked down.

It is then that you realize, that you are not dealing with rational, thinking, objective individuals who believe in strong opinions weakly held. You are up against folks who take every argument personally, folks who indulge in strong flavors of mitigated speech and folks who do not express their disagreement in words but instead choose to disagree, silently.

During my career as a software developer I have seen countless examples of silent disagreements. I have seen examples of folks who think that they should say 'no' to their managers but who lack the spine to say 'no' to their managers on their face, so they resort to silent disagreement. I have also seen folks who think that they are working for the 'best interest of the organization' and use silent disagreement to avoid all arguments or discussions.

Assuming that you can bring about change in your organization, if there is just one thing that you can change, I suggest you put an instant stop to silent disagreement within your organization. This is another one of those issues that you are way better of confronting rather than avoiding.

Go on, confront the folks who tend to disagree silently, and demand an open objective argument or total agreement through not just words, but action.

I wish you good luck.

I'm heading to office. The phone rings. Someone, somewhere wants a stupid signature on his release letter. I tell him I'll be there in about thirty minutes. My DVD company just shipped the next DVD on my queue to my office and I'll get it the next day. My manager is calling to catch up on how things are going. My phone is losing charge already and so am I.

I am juggling with an iPod, a phone, a book and the bus playing a stupid radio channel - when all I should be focusing on is enjoying the long roads that pass me by. Or I should be reading the amazing book I grabbed last evening. I am doing, twenty other things.

Then I walk into office, hoping to get to the bug I spent my entire last night thinking about. I woke up with my mind still chirping at the problem and I found the answer when I was in the shower. It feels like first day at work. Knowing that I have the answer and experiencing the pleasure of putting the fix in place.

That's when I open my mailbox.

A dozen other funny problems await me. Someone is not being able to make it office because of a headache. Someone has a broken laptop and is whining about it in a mail trail. The support guy responsible for fixing his laptop is yelling back and using the caps lock key rather generously both in his written emails and verbal communications. Yet another client is raising stupid, irrelevant red flags.

My miserable little dreams of focusing on one thing that is important and blurring everything else out seem to be getting shattered like a house of cards. That's when the headphones come out.

If you read this blog, you probably know my preference of silence over any form of music when I am consumed in work, but headphones serve another important purpose. Ted Dziuba explains this behavior of using headphones rather articulately in his post titled - Break my concentration and I break your kneecaps. He explains:

I own a good set of headphones that fully enclose my ears. I am not an audiophile, I just don't like to hear other people talk at me.  When I am staring at my Emacs windows with headphones on, it generally isn't a physical cue that I am looking for conversation.

In fact, when I am that deep into thinking out a problem and I get interrupted, I think about the anti-workplace-violence clause in the employee handbook, and how a poorly lit parking lot probably doesn't qualify as "company property".

Interrupting a thinking programmer is a sucker punch to productivity's kidney. Of course it's still important to keep open communication channels, especially in a small team. I don't mind answering questions and helping out, so long as it's not an immediate context switch for me, i.e. I'll help you if I don't have to speak.

On any given day, there are a dozen tasks that I ignore. There are probably dozens of emails that I ignore as well. The underlying assumption is simple. If it's truly  important, someone, somewhere will remind me or someone somewhere will talk about it. If no-one reminds me that it is important, it probably isn't important. I can go back to putting my headphones on and working on things that I believe will eventually matter in the long term.

Then there are things which are pseudo-important, the false urgency alarms, the trivia of broken laptops, egoistic arguments, meetings and the discussions on the status of how things are going. Being a programmer isn't just about programming and chances are that on any given day, you are going to be bombarded by things which seem important but at the end of the day, your ability to ignore them is going to be much more important than your ability to get them done.

Slow down. Take a pause every now and then. Think about, what matters the most to you and spend most of your time on things that matter the most, because most other things that seem really important, hardly matter. Most things that you do on any given day are just random distractions.

Go, reflect on what is really important to you and then spend most of your day, doing those things.

I wish you good luck.

During my days as a young and budding programmer, I was bubbling with confidence. Never in the wildest of dreams did I imagine that a software project or a task given to me could just not get done.

I mean, sure I might have to throw in a few extra public variables, not have enough time to give a shit about the quality of the code I was writing or throw in a couple of hundred band-aids on the codebase, but I would still get the job done.

Put simply, I knew if I worked fourteen hours a day I could stick it up together to deliver to a client. I also knew, if I acted smartly, I would not get my ass kicked or busted. To add to that, if I used enough jargon I could blame it all on requirements, use-cases or some abstract shitty artifact that was always responsible for the failure of the project.

Young engineers learn the shit that they see their seniors do and they learn it fast.

Then it happened. My first successful failure where we were building a piece of software that was sofa king (to be read really fast repeatedly) complex that the thought occurred to me a month before the delivery date - what if, we don't make it - the voice said deep down within as I tried desperately to write a function that would increase the power of the device my code was supposed to control.

This was a project where we were integrating with random devices around the world and some of them had serious issues with their hardware, which is what we were working around. This was not a typical - 'what if we don't make it in time' or 'what if we are a week late' question. Those, you can answer by pointing your finger at a random artifact. This was a case of 'what if we just cannot build this project'.

We did not have shit to show to the client.

What we had, did not work.

What if another one month passed and we were not able to crack the show-stopping problems we were facing?

What if we just did not get anything done?

The question was scary. The realization that I as a software programmer with just a couple of years of experience behind me, had limitations which were as real as gravity was scary. The realization that I could not overcome these limitations with trickery, big talk, smart ass ideas or stupid band-aids was even scarier. All the tricks that my so-called seniors had taught me were failing me. Blatantly.

The project ended without anyone getting killed. We threw tons of band-aids in there. Got a few things done. Then, I struggled for hours and days to set it right before we handed over the project to the client and moved on. Multiplitaxion Inc announced it a grand success. I called it the first (and hopefully the only) successful failure of my life.  

I don't want to live that part of my life again. It was terrible. It was scary. It felt like shit. What felt worst after the project however, was not the fact that I was overworked, stressed out, about to quit had it lasted sometime longer or any of that. What felt worst after the project was the feeling of being used - almost like a mindless human bomb who goes and blows himself up for a cause which is totally insane and downright stupid.

This was the part of the project, that helped me grow in ways I would have never otherwise grown in my entire life.

One of the most important things that the project taught me was the art of caring and putting in my one hundred percent into the work that I do, without giving a f@#ck about what my team, my managers or my clients classify as 'success'. After all, I had just been a part of a project that my team, my managers and even my clients classified as a huge success when the reality of it is that it felt like a one big colossal f@#k-ups of my professional-work-life.

Since then I have come across countless examples and incidents where a client somewhere wants me to believe that my tiniest of non-confirmations to their processes, their dates or their deadlines, equates to a humongous failure. The idea is simple - convince the programmer psychologically that shipping the software on a specific date with a specific list of features is so hugely critical that his entire career depends on it and then he will ship.

I have been through so many of these situations in my life, that I almost find them hilariously funny every time I encounter them now.

Every time I come across situations where I am being told how critical it is to ship on a given date or just how critical fixing a spelling mistake of a label is, I smile inwardly, argue outwardly and somewhere deep down inside, there is a calm, quite, silent voice telling me:

'You have been through this before Pops. You know what to do. Give it your best shot, be honest to yourself and then don't give a rat's ass about the so-called-success.'.

Years ago, after my first successful failure, I learnt that you are way more efficient if you leave your fears of failure behind and replace them with passion. If fear and pressure move you, that is all you will get your entire life.

On the other hand, if you are moved by your own passion to do amazing work, questions like - what if we do not ship on time or what if we fail - will just start sounding seriously stupid to you. You will eventually stop worrying about them and start giving your best shot irrespective of whether these questions are asked or not.

When the sky starts falling, don't panic. Prioritize. Think pragmatically. Give practical options to your clients. Do all you can to turn your project into a win-win situation for everyone connected with it. If you keep getting bull-shit in return, continue helping them, continue shipping, continue putting in your best but just stop giving a rat's ass about what anyone on the project says about the success of failure of your project.

It's time to wear a thicker skin.

I wish you good luck.

I'm sitting smack across the table as Jane, a very talented young and budding programmer, tells me her side of the story. For the last three months she has been a part of the product team and she has been fixing bugs which involve changing the captions of labels on screen.

I cringe.

There are more than one things in this discussion that worry me. The first is that her talents and her abilities are getting utterly wasted in the organization. Secondly, it also means that more sooner than later she would be sick of working and she would start looking for a change. All of this worries me as I listen to her, but what worries me the most is the thought that her team lead is an Alpha-Geek who is refusing to breed more Alpha-Geeks.

And he is violating the pact.

Yes, that pact.

He is solving the most complicated, challenging and some of the most interesting problems himself.

He is not, 'teaching the young'.

Every once in a while, I come across super-alpha-geeks, sometimes even good ones, who prefer to solve the hardest of the problems themselves, instead of letting others in their team solve it and helping them with the problems. Strike a conversation with them and most of them will offer you arguments on the lines of:

1. It's easier to do things myself than to explain and delegate things to someone else.
2. Most programmers in my team are not good enough.
3. I took it up myself because it was critical for the success of the project.

Hidden behind the layers of excuses, lie the bitter facts. The real reason why most alpha-geeks who like to control the most-critical items in the project and do these themselves, can be one or more of the following:

1. The Alpha-Geek has serious insecurity issues and feels threatened by people in his team.
2. The Alpha-Geek thinks of his team as a bunch of incompetent, inefficient idiots who are either not talented enough, fast enough or both.
3. The Alpha-Geek is a control freak and wants total control over the project.

The next time you see the scrum back-log and you start picking up the most complicated items, question yourself, if you are just acting like a selfish insecure jerk or are you helping other programmers transform themselves into alpha-geeks and become critical members in the team.

Give them the most complicated, difficult and challenging items, help them expand their zone of comfort slowly and help them turn into true alpha-geeks over time, because that is what true alpha-geeks do. They breed more alpha-geeks.

I wish you good luck.

At one of our clients office, who for the purposes of this post shall be called Multiplitaxion Inc we have what I call a decision-execution-crisis.

You know, those meetings where really smart people who have done really big things in life and have achieved really serious sounding designations on their business cards carefully position their asses on really soft chair and talk about really sensitive topics like the future of the organization, the future of the product, the official-name of the product, the official editions of the product and the features the free edition of the product would contain.

Did you notice the use of the word 'talk about' and the absence of the term 'decide' or 'act' in the above paragraph. The use of the word 'talk' was intentional, because while a lot of talking happens in these meetings there is often very little decision that ultimately gets taken and even lesser real work happens on those decisions.

It's not about what your manager says in these meetings that matters. It is how he acts after a couple of these meetings that matters the most. Does he get stuff done or does he act all tied and helpless.

Michael Lopp describes his practice rather articulately in his book Managing Humans. He explains:   

When the new VP showed up for his first day at the startup, he was wearing a Members Only jacket. Sky blue. I didn’t know they still made these throwbacks to the '80s. A jacket that lived under the tagline, “When you put it on, something happens.”

I’d given the VP a thumbs up during the button-up and tie phase of the interview, so I gave him the benefit of the doubt.

Three months in, we had a problem. Members Only was doing a phenomenal job of discussing and dissecting the problems facing engineering. We’d leave meetings fresh with new ideas and promises of improvements, but then nothing would happen. OK, so follow-up meeting. WOW! He gets it. I’m fired up again. Let’s roll. Umm, two more weeks and nothing is happening here.

Michael in the same book also describes the problem with most managers who conduct these meetings and love the idea of talking strategy, ultimately getting nothing done. He adds:

The act of delegation is a slippery slope for managers. Yes, you want to figure out how not to be a bottleneck in your organization and, yes, you want to figure out how to scale, but you also want to continue to get your hands dirty.

Members Only's problem was he believed his job was purely strategic. Think big thoughts; delegate the results of those thoughts to the minions. He was a pure delegator and he’d forgotten how to do real work.

Pure delegators are slowly becoming irrelevant to their organizations. The folks who work for pure delegators don’t rely on them for their work because they know they can’t depend on them for action.

This slowly pushes your manager out of the loop and, consequently, his information about what is going on in his organization becomes stale. Then, the CEO walks into your boss’s office and asks, “How’s it going?” The third time your boss gives the same generic answer, the CEO goes to you and asks the same question. When you respond with, “Well, we’re fucked,” the CEO has an entire other conversation with your manager.

Real work is visible action managers take to support their particular vision for their organization. The question you need to answer for your manager is simple: does he do what he says he’s going to do? Does he make something happen?

And its not just about strategic changes or the steering the organization or the product through its future path. I am talking simple decisions here.

How long does it take your organization to get you a whiteboard in a meeting room when you tell them that you guys desperately need one. How long does it take your organization to fix network patch chords in your meeting rooms. How long does it take for your organization to reduce your meeting count when you tell them you are sick of attending them and want to focus on work for sometime.

Measure your manager's and your organization's ability to take decisions and then act on those decisions. If they are able to take decisions and act on them, you will be just fine, even if those decisions aren't correct or even if they are failing and learning at each step.

On the other hand, if nothing ever gets decided and nothing ever gets done at your organization, maybe its time to get your act together, figure out why your organization cannot act and do something about it. Procrastinating with your organization will not get you anywhere in the long run.

As they say, You can Change Your Organization or Change Your Organization.

Either ways, I wish you good luck.

I find myself seated smack across the table with Fred looking at me like I just performed the gravest of offence in his professional life. I tell him the awesome news of his promotion and a handsome thirty-percent hike. He eyes me like a criminal.

Turns out, he was expecting more.

He tells me that he was aiming for a higher hike.

Ok. Breathe. I tell myself.

I thought this was good news. I thought his face would light up. I thought... I am confused by the time the discussion ends.

I feel shitty. Really shitty. Really, really shitty.

During my career of breaking appraisal results to folks and telling them how their year was I have worked with three kinds of programmers, or should I say, human beings.

The first is the kind of have very little expectations and if they get what they deserve you can see their faces light up. These guys are happy-human-beings. They know their net-worth, they know the perils of over-pricing themselves and they have no desire to take home more than what they really know they deserve.

The second kind is the group of folks who just don't give a shit. Ok, maybe that's not a very good way to describe this group. Maybe they do give a shit. Just a little bit. But these are folks who are motivated by the process of building stuff and for them an appraisal meeting by itself is an awkward moment.

They would rather you just print their letters and send them their revised salary letters by post so that they can ignore the letters like their telephone bills and find out their new figure when the amount lands up in their bank account. Maybe they would like to just glance at their appraisal letters and if they are not utterly insulting or disappointing they would just keep them aside and move on with their lives.

Put simply, For this kind of people, appraisal discussions are not a life changing moment.

This is the kind that usually draws the highest raises in the organization. Raises, power and promotions are funny things. They tend to usually go to he people who have very little or no craving for them.

Even though the first two kinds are insanely interesting to study this post is not about the first two kind. This is a post about Fred. The third kind. One which lives in the constant state of craving and discomfort. This breed will tend to bitch, whine and moan about their salaries, what the organization gives them, what they give to the organization and what the organization aught to give them.

If you are leading them they will remind you a dozen times a year that they are grossly underpaid and they will decide to stick with the organization anyhow.

This is the group that typically hops organization for a ten-percent hike every time they get a better opportunity. The group that powers the infinite loop of failure.

We start getting into an awkward dance here. Fred and I. Fred tells me he is underpaid, I show him industry wide pay scales of people with similar experience and expertise. He refuses to believe the research data. Fred, as it turns out, loves to nurture the idea that he is grossly underpaid and he seems to love continuing  to work for the organization in a mode of utter discontent.

If you are dealing with Fred, here is a word of advice that comes after coming across quite a few Freds in my career: you cannot make them happy. So don't even try. As an organization, get them a fair deal and everything that they deserve and move on.

You can attend a dozen management classes on how to keep your employees happy, but the sorry fact of life is that you are always going to hire a couple of people who you cannot please irrespective of what you do for them.

Do what you think is fair and then draw a line. Stop feeling bad. Stop getting confused and stop spending hours wondering how you can please Fred, because it is pointless. And assuming that even if you were able to please Fred, chances are you would get his resignation the day he gets a ten percent hike. You are way better off sticking to the age old saying, you cannot please everyone. Focus on the other two kinds instead and do all you can to keep them happy.

That way, you can at least have a team where most folks are happy and productive.

I wish you good luck.

We are here for you Twenty-Four-Seven.

Today, lets dive into the depths of time and bring from days that have rolled behind, a classic tale of support done the Indian-way. Before you read any further and start sending me flame mails about the generalization of the word 'Indian' here, trust me, I know exceptions do exist.

I also know that generalizing anything by a country is just about the biggest stereotype of the software development world that you should avoid at all cost, but humor me. I have a point to make and the point is not to ridicule or insult Indians in any way. I happen to be an Indian and I am actually fairly proud to be one. But then, having said that, India as a country and Indians as a group are often totally capable of doing seriously shitty things.

So, as I was saying, lets dive into the depths of time and bring back from the days that have rolled behind, a classic tale of support done the Indian way.

In one of my last work trips somewhere between New York and Chicago, after making us wait inside the plane for about an hour because they lost the stair-case that was supposed to get us down, making me miss my connecting flight and making me quite literally run for the next flight United Airlines manages to put a cherry on the cake of surprises by loosing my luggage.

After a few frustrating experiences with the ground staff who tell me that the bags would show up a day later at my hotel, I decide to make a move, get to the hotel and get on with my life. Three days later, however, I find myself trying to look up my luggage using the baggage tag on the United website which tells me that my luggage cannot be located.

Then, smack out of nowhere, I find myself doing something that I have a love hate relationship with --- I am calling the Support Line. Now, as I already said, I have a love hate relationship with support lines. Love because support lines often tend to be sofa king (to be read really fast, repeatedly) funny that they give me food for thought and posts like this one. Hate because they are so funny, that after a while they stop being funny.

As far as the United support line is concerned this is how it goes. The system routes me through series of automated questions. Then after routing me through a hugely long automated process which also confirms that my luggage 'cannot be located' it lets me talk to a customer care executive. Seven minutes of wait follows after which someone answers the call.

Voice On The Support Line: Good Evening Sir, This is United Airlines. My name is Fred (I could have used the real name, but then Fred sounds so much more fun in this situation), How can I assist you today?

The voice is Indian. Clearly. Plainly. Indian. And the fact that this gentle-man uses an American name to identify himself, tells me exactly what to expect next.

Me: My luggage seems to have gone missing at the O'Hare airport. The ground staff told me that they would ship it to my hotel in about the day and It's been three days since then. I am just calling to find out if you guys know when I would be getting my baggage shipped to my hotel because I am leaving this place and moving on to a new location in the next couple of days.

Fred: I am sorry for the inconvenience sir but we are here to help you Twenty-Four-Seven.

Long silence. Awkward moment.

Me: Do you need my baggage tag number?

Fred: Yes sir. Can you please provide your baggage tag number?

I give out the number. Another long pause follows. After which he tells me that he is going to put me on hold and I sit there listening to music for about three minutes. Then the voice cracks back.

Fred: I am sorry for making you wait Sir. I am also sorry for the inconvenience sir but the system is showing that your luggage cannot be located at this time.

Me: I know that. I saw that on the website and heard that on the automated system and both of them said I should talk to a customer care executive.

Fred: Sure sir. We will have updated information on your baggage soon. I apologize for the inconvenience but we are here to help you twenty-four-seven. You can call us anytime.

Me: How soon would you have updated information on my luggage?

By now I am having a seriously hard time hearing anything other than, Fred is really sorry for the inconvenience caused and that he is here to help me twenty-four-seven. But then, I don't want him to be there twenty-four-seven. All I want is my baggage back. I don't give a rat's ass if they work for three hours a day or twenty four.

We do this insane dance for long time where he assures me that he is really sorry about the inconvenience caused, that he is going to get me a hundred dollar discount on my next flight and that I can call the support center anytime. He then reminds me for, I don't know how many'th time, that they are there twenty-four-by-seven and that I can call them anytime.

Three days later the baggage arrives at my hotel and United conveniently just forgets the promise of the hundred dollar discount on my next flight. I receive no emails, as Fred had promised, no discount coupons. Nothing.

It's like the episode never happened.

We Cannot Help You Unless You Pay More.

Life moves on. I get back to work and this incident of Fred and his Indian support center being online twenty-four-by-seven for me is long forgotten. Till the time I see another example of support done in a slightly different way.

Recently, one of my posts hits the top five post related to programming on Reddit and I get a throng of people visiting this website. The new unique-visitor-count hits almost about fifty-one-users-a-minute, with old users continuing to read and click links on this blog.

This is when the website starts crumbling down under the load of heavy unexpected traffic. After about five hours of non-stop-traffic growing at an uncontrolled rate people start complaining about getting service unavailable errors. I decide to call the support line of my service provider.

Now, before I describe how the call goes, here is a little bit of history of how these guys transformed their support department. These are guys who were once notoriously famous for bad customer support and then one fine day, magic happened. They changed.

They were now, suddenly, providing support that started positively surprising me and the rest of their customers in all the right ways. No-one could really figure out what they had done but something had changed for better.

There were no solid announcements per-say but I suddenly started getting great responses in my support emails and my problems were getting resolved at the blink of an eye. I never had to call them so far, but with this issue it was better to call, than to email and wait for a response.

So, as I was saying, I decide to call up the customer support.

With literally two choices on the automated system, one that asks what I am calling for and other that asks me to press a number to talk to a customer support executive, in less than three minutes I am talking to a real human being,  who by the way, helps me locate the customer ID that he needs and then tells me, that I am facing service-unavailable issue on my website, without me having to describe the issue in detail to him.

Then he wants to know if this traffic was expected. He puts me on hold for less than a minute and comes back informing me that even though I am just using one percent of my bandwidth I have crossed my concurrent connection limit and that I would have to pay a little bit more to fix this issue. He then adds confidently that without upgrading the plan there is nothing he can do to fix the issue. Unless I chose to pay more, he cannot help me.

He is direct. Confident. Focused on my problem and is providing me the one single solution he has with a choice: take it or leave it.

I take it.

He initiates the payment right away and the service unavailable issue is sort-of-gone in less than about half hour.

While I should been utterly annoyed with my service provider and the fact that they never documented the number of concurrent connections my site was allowed to have anywhere, I actually end up liking the way the guy at the support handled the situation.

He is not nice to me, he is not sorry for the inconvenience cause, he makes me pay more.

But then, he understands my problem and fixes it while my dear Fred at United, who is there for me twenty-four-by-seven does not get shit done.

And The Point Of This Long Tirade Is...

That support is an art which requires people who know what they are doing. That hiring random Indian students, paying them their pocket money and giving them a bunch of carefully scripted cue-cards or a stupid set of Frequently Asked Questions does not equal good support.

Sometimes, we really do not give a shit if you are there twenty-four-by-seven.

All we give a shit about is our problem and how quickly you can help us fix it.

So the next time you think of publishing your support email, see if you can get the best of your folks in that mailing list and allow them to answer support emails if they want to. The next time you think of building a support department, see to it that you hire the guys who are just as good as your developers or the rest of your organization.

Support is not something you outsource and forget.

Because if you do, people will eventually just stop calling.

And then, they just might move on to companies who understand their problems and do not hire a bunch of random college students to tell you how sorry they are about the inconvenience caused.

Support, is serious business. Give it the time, money and attention it deserves.

I wish you good luck.

David Heinemeier Hansson in his talk at Startup School describes the typical product cycle and the day dream of making billions and getting bought over by venture capitalist that most young and budding entrepreneurs have using a simple slide:

During the presentation, David's point is focused on a single topic. One way to make money is to hope for a lot of magic in step two and expect that a venture capitalist or a Google will buy you out. David describes the other, more practical, sane and logical way using a simple slide:

If you have not clicked the link to the video yet, you should.

David explains the idea of pricing your product or charging for your online service using simple, direct and wise advice for young and budding entrepreneurs. He explains:  

The really cool thing about all of this is that you don't need to be a fu@#king genius to make it work. Its not rocket surgery. It really is a simple three step idea.

You have a great application. You ask money for it. If people like it, they will pay and you profit.

But here is a kicker. Just because you slap a price on something does not mean you will have a successful business

37Signals has their own offering of free products for the end consumer but the focus of this video, is on their paid versions and how they make money online. As someone who has observed a truck load of software products getting priced, if there is one thing that I have learnt about pricing it is that pricing is just like any other phase of building great software.

Like any other aspect of software development, when it comes to pricing your product, you will fail too. The earlier and more often you fail the better off you are, as long as you do not keep making the same mistakes all over again.