free html hit counter
Posted on: Sunday, August 8, 2010 by Rajiv Popat

Getting Those Paycheck Programmers to Quit Your Organization - Part 1.

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.

posted on Sunday, August 8, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, August 7, 2010 by Rajiv Popat

Trying To Be "Practical" All The Time Equals A Mediocre Professional Life.

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.

posted on Saturday, August 7, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Friday, August 6, 2010 by Rajiv Popat

Learning The Art Of Genuinely Reading And Enjoying Books You Like.

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?

posted on Friday, August 6, 2010 6:00:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, August 1, 2010 by Rajiv Popat

When Trying To Make A Point With Your Emails Or Blog Post Short Is Better Than Long.

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.

posted on Sunday, August 1, 2010 10:14:01 PM UTC by Rajiv Popat  #    Comments [1]
Posted on: Saturday, July 31, 2010 by Rajiv Popat

The Noise And The Turmoil That Clutters Your Brain - Part 1.

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.

posted on Saturday, July 31, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, July 30, 2010 by Rajiv Popat

A Simple Question To Ask Before You Publish Something Live.

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.

posted on Friday, July 30, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, July 25, 2010 by Rajiv Popat

Work In Progress Version Of The Book On Builder At Work - Links To All The Chapters.

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.

posted on Sunday, July 25, 2010 10:12:14 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, July 24, 2010 by Rajiv Popat

Work In Progress Version Of The Book On Builder At Work - Part 3.

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.

posted on Saturday, July 24, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]