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.

Geeks aren’t wired like the rest of the race. Even their awesomeness is different from the rest of the race. While you might love to party, your geek craves a deep intellectual meaningful conversation with just a couple of friends around small table in an open air food joint serving wholesome food.

No loud music. No distractions. No Dance. No risk of bumping into that socially awkward moment. That and a topic that is deeply intellectual and very intimate. That or just a ruthless battle of wits.

If socializing is what makes your geek more human, deep intellectual conversations with near and dear ones, are what make him who he is. If you really want to connect to your inner geek, find a friendly open air food joint with no distractions, invite a couple of close friends and trigger a deep intellectual conversation.

Watching hours melt away as you munch on wholesome food, enjoy the fresh air and enter into an inspirational or a deeply intellectual conversation with friends; pure geek awesomeness.

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.

There are hundreds of comments on the "why can't programmers program" post by Jeff Atwood where he talks about the fizz buzz problem being the stairway to heaven of programming and how most programmers cannot code it.

While that's useful information, the real question is what are you doing to help train a better breed of programmers for tomorrow?

Jeff's attempt is stack overflow. A place where programmers can help other programmers get better at their craft.

Others are contributing their bit by answering questions there, but what are you, the person who has developed applications for ten years, doing for the non programmer who is passionate and wants to take up programming as a career or a hobby?

While I was working on my entity framework videos, I decided to take a stab at talking about the very basics of programming using C#.

Here are the videos.

It has already turned into a mini series on getting started with programming using C#; a couple have been uploaded and more videos will be added soon.

It is not the kind of video you might enjoy yourself if you code for a living, but the kind that you give to your uncle, your HR manager or that QA person in your office who always wanted to learn a little bit of programming and a little bit of C#.

Like I said, the important question here isn't why can't programmers program. The important question is: what are we doing to help folks who can't but really want to?

Consider this my humble attempt at answering that question.

Happy learning.

Facebook and twitter were hailed as revolutionary because they brought instant publishing to every cell phone.

The game is simple, you stare at an empty text box which says "what's on your mind", you impulsively write something and your tiny world of relatives, colleagues, well wishers and acquaintances responds back... equally impulsively.

Science on the other hand believes that what makes writing so different from practically most other forms of communications i.e. talking, thinking aloud etc. is that when you are writing more of your prefrontal-cortex (the bit of your brain responsible for executive decisions) is involved than when you think or speak.

Put simply, the act of writing takes the impulsivity out of the problem and introduces objectivity, there by letting you dissect and analyze the problem from different aspects.

The mere act of pausing a bit and composing your thoughts in cohesive paragraphs, or forcing yourself to write continuously using a timer and then editing out the noise before you publish, let's your brain dwell on the problem, really focus on what's important and produce rich and meaningful content.

Instant publishing might have it's uses when you are reporting an incident as it unfolds in front of you, but the ability to "instant publish" depressing messages, Farmville requests, random one liners, links that most people can Google anyways or forwarded email jokes ultimately does more harm than good to your brain.

Before you hit that post button on twitter or Facebook, ask your self if that can turn into a structured, well polished article, blog post, white paper, package or any other art form born out of a coherent thought stream that might actually educate, add value, solve a real problem or inspire someone.

If the answer is yes, you are much better off, writing it, editing it, packaging it and shipping it as a blog post, article, white paper or packaging it as a solution. Even if it isn't instant.

If the answer is no, why were going to publish it anyway?

Just because you can publish anything instantly doesn't mean you should.

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.

Here's why:

1. Amazon now does offer paid technical support which actually lets you speak to real human beings in seconds.
2. EC2 instances (specially the micro instances) are the cheapest options that most small business and bloggers who want remote access to their servers, have.

As long as you're aware of the pain involved and the workarounds we're good. The other thing to remember of course is that you always have the switch in your hands to flip if the pain does get out of hand. Of course cloud based virtualization can hurt you, but knowing how it can hurt you, makes you all the more confident and pragmatic at using it.

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?

Richard Bach and Ernest Hemingway are examples of authors who have managed to build genuine art with really simple words and sentences.

It is easy to read Jonathan Livingston the seagull or Illusions, and go:

"Hey! That sounds like simple English! I could have written that!"

Similarly it is easy to see basecamp or stack exchange and go:

"Hey! That's a simple application. I could build that in a month!"

The reality however, is that the best of experience and mastery sits humbly camouflaged under layers of honest simplicity and no desire to prove anything to anyone.

Just art; devoid of all craving and desperation.

A simplistic answer to a problem, an honest desire to serve, a humble desire to practice a craft or build stuff for the pleasure of building stuff.

The very fact that you cannot see or appreciate that mastery makes you think that you can do that in a month.

Of course you can build a project management tool, a forum or write a short novel, but the day you start seeing silent mastery hidden in everything remarkable around you is the day you will start taking your first tiny steps towards that very same mastery.

It comes. In it's own sweet time. If you are a young individual full of enthusiasm (or are still basking in the glory of your MBA) and if this post doesn't make any sense to you, come back and give it another read in 10 years; it might.