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.

Every blog post you do "must have" a picture.

Every build you push "must have" release notes.

Every site you publish "must have" a FAQ.

Every organization out there "must have" a written mission statement.

Most "must have's" are reasons for going with everyone else and doing what everyone else is doing.

A way of seeking acceptance by compliance and avoiding blame.

"We are doing everything we must do! You can't blame us!"

But then, in more cases than one, not having those must haves is often a "must have" for building remarkable products, cultures, organizations and lives.

Let go.

Good luck!

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.

What are you dissatisfied with?

You can be dissatisfied with "things" you have:

1. Your salary.
2. The size of your present home.
3. The brand of your clothes.
   (The other brand is so much more better!).
4. The resolution of your television.
   (The one with full HD is so much better!).
5. The configuration of your laptop.

Or you can be dissatisfied with "experiences" at large:

1. The kind of movies that are being made now a days.
2. The kind of books being written.
3. The kind of customer service your cell phone company gives you when you call.
4. The kind of management that is being done these days.
5. The kind of products and the kind of user interfaces being launched these days.
6. The kind of cultures companies promote.
7. The kind of ways with which people make new friends online.
8. The kind of video games being launched.
9. The kind of fun people have.
10. The kind of clothes being made now a days and the lack of innovation in clothing industry.

When you are dissatisfied with things you have your knee jerk reaction is to crave other things. Things which are a little better than the things you already have. Life is about more and better things.

When you are dissatisfied with experiences at large and are willing to match that with effort and competence of creating new experiences not just for yourself but for the rest of the world, life is about magical and rewarding moments where you put your best into transforming experiences you don't like into something reamarkable.

Of course neither is easy. Neither is bad or wrong. But the irony here is that people who are usually dissatisfied with experiences at large often bring the best of the experiences and even the best of the things to the rest of human race.

What are you dissatisfied with?