Builders are guys who build stuff.

Software. Bridges. Cars. Roads --- Stuff.

For the early part of my engineering career this is the only kind I respected.

Then I met the other kind who are just as good at building and shipping. These individuals however, do not ship 'stuff'.

Storytellers, build, ship and spread --- stories.

Remarkable stories.

Stories built on strong honest foundations of truth.

'But Pops, you're talking about marketers' --- you say.

No I am not.

If you are working for a software development shop; look around.

Observe. 

Chances are that you will find them in all walks of software development. Some of the best story tellers I have seen have played absurd roles --- project managers, team leaders, catalysts and even evangelists. 

Honest, genuine, good story telling, done even at simple levels can make or break projects. 

Flashback time --- here is one example.

At Multiplitaxion Inc., two projects are over budget with similar variances from the initially budgeted timelines.

Fred is leading Project 'A' - a few of us in innocent fun; decide to name it Project Rocket Science.

Fred, after flexing all his management mussels, his state of art 'resource management' techniques and his proven 'processes' is not being able to keep the project from falling apart.

Weeks into the project the team has lost faith and has started shipping crap.

Months later the management looses faith and pulls the plug.

"Funding" --- we are told. We run out of funding. 

Project Rocket Science is officially dead.

Project 'B' on the other hand has similar issues of bad estimations.

The project however had more than one story tellers involved and connected with the project.

Project B's team does not embark on a project. They embark on a story which they have been told. A story built on truth with larger than life elements to it.

As the ramp up for the project is happening, every single member of Project 'B' is hand picked. They are told in clear teams that they are being picked because the project is special and that they are the best. They are told that they have been picked, to create meaning; to shape the future of an organization. To build a remarkable product that will change not just an organization but an entire industry.

It takes time, but the story is told remarkably; from one story teller to another; until it spreads through the corridors of the warfront where the development is done.  Everyone; including the story tellers themselves; believe the story.

When we slip deadlines we are told that we were making history; we could not ship crap. We're told not to lose patience. Not to panic.

Half way down the project we are convinced that there is no reason to panic.

Then as the project proceeds; something creepy happens --- the story slowly and steadily starts to turn into reality.

We start shipping stuff that was genuinely remarkable. Stuff that very slowly and steadily starts making it's slight dents in the overall industry.

Flashback over.

Ok, here's the million dollar question --- where did we go right with Project 'B'.

First thing where we went right was of-course the fact that we had amazing builders. To add to that, what we had was an amazing story. A cause. A meaning. A purpose. The project wasn't something we shipped to get our job done or to get our salaries. We connected to the project. We connected to the story around the project.

The outcome? 

No-one stopped the project.

We shipped a product which was not just profitable; but remarkable in it's own way.

True, we were as over budget just like Project Rocket Science; but if there is one thing that you can take from this story; it is this:

No-one; I repeat --- No-one cares about the budget.

Neither your team, nor your management, nor your client.

One way to look at your budget and deadlines, is to see these as commandments you absolutely must follow.

But, in the long run, that does not get you anywhere.

If that is your line of thought, you will continue to build mediocre products that can be otherwise defined as 'successful failures'.

Story tellers have a slightly different way to look at budgets and deadlines. They see them as mundane numbers; nothing but boring facts. Story tellers know that people who sign the paychecks and the clients; look at these boring numbers 'only' when they have nothing more interesting to look at.

In the case of Project 'B'; the 'story' was larger than the boring facts. It was much more interesting, exciting, evolving, fun filled and remarkable.

The outcome of the story, the product itself, was even more remarkable.

Obviously, no-one looked at the boring facts.

We shipped. We made a dent in the universe; in our very own small way.

We were successful.

Story tellers, as it turns know that a lot of their story telling depends on stuff the builders ship. This is why genuine story tellers show a lot of honest respect for builders. They use their art of story telling to get the crap out of the teams way. They use their art to glamorize projects; products and even team members who deserve to be glamorized. They use their stories as bullshit busters; and to change stuff; for the better.

Story tellers, besides respecting builders and hanging out with them connect to them; genuinely; and naturally. They stick their neck out for people who build stuff. This is because genuine story tellers know fully well that without remarkable products and remarkable stuff there can be no remarkable stories which are built on foundations of honesty.

Without amazing builders, the role of an amazing story teller does not exist.

Good story tellers know this fact and aren't ashamed to admit it. Openly.

Story telling is hard.

What is in-fact not hard, is wearing the badge of a pseudo-storyteller.

Now, that's easy.

To do this you go around building a lot of political relationships with people high up the pecking order in your organization. Then you play the nice guy with your team and when hell breaks lose or when you get pecked on by the peckers high up in the pecking order you peck on your team.

Here's another way to pseudo-storytelling.

Go to a client meeting --- when the client questions you about a feature you don't have and they are wondering if you can build it by the trade show which is going to happen next month; nod your head and say yes to everything; hoping your development team will build it by 'staying back a little late' or by 'pushing harder'.

Remarkable Story Telling as it turns out, is much harder than being a pseudo-story teller or a whiner.

Are you a manager --- Weave a remarkable story around your teams; get a few genuine builders promoted and a few whiners removed from the project. Weave a remarkable story to calm down a panic stricken client, director or vice-president.

Are you a Vice President --- Weave a story to add meaning to a product or an entire organization.

Marketer --- Get just a hundred mavens who are genuinely interested and will spread the word to sign up for an awesome service your builders have built.

Writer --- Try to get a thousand unique returning visitors per day on your blog.

Indulge and aim at either of these and you will learn first hand how hard story telling really is.

It's hard.

Really hard.

It is in fact as hard  building stuff; because when you weave a story, you are in fact, indulging in the act of 'building'; even if it is not 'stuff' that you are building.

If you are a pseudo-story-teller you are just another whiner.

If you are a genuine story teller; you are important. We need you.

Are you a story teller?

What are some examples of story tellers you have worked with dear reader?

How have storytellers improved your work-life, dear reader?

Discuss. 

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Of all the people I've worked with in my software development career; every single one of them; in terms of what they do; can be grouped into one or more of these three categories:

Irrespective of where you work, what you do, what your business card reads, what your designation is or what your role is --- you fall in one of these three categories: builders, story tellers, whiners.

After years of analyzing people; especially people who work in software development; that is the conclusion I have arrived at. 

Everyone is one of these three.

It is that simple.

You may have traits of one or more of the three but overall you are one of the three.  If you are going to read through this book, it is important that you understand these three personalities well; really well.

Learning from builders and story tellers is what this book is all about; so it makes sense to introduce you builders first.

Ready?

Read on.

Builders.

Builders build stuff. Amazing stuff. They ship.

They are the ones who might be making your life interesting with remarkable and innovative products or services and you may not even know it.

Christopher Baus learnt the importance of being a doer while making a career choice. He explains:

Software isn't about methodologies, languages, or even operating systems. It is about working applications. At Adobe I would have learned the art of building massive applications that generate millions of dollars in revenue. Sure, PostScript wasn't the sexiest application, and it was written in old school C, but it performed a significant and useful task that thousands (if not millions) of people relied on to do their job.  There could hardly be a better place to learn the skills of building commercial applications, no matter the tools that were employed at the time. I did learn an important lesson at ObjectSpace. A UML diagram can't push 500 pages per minute through a RIP. There are two types of people in this industry. Talkers and Doers. ObjectSpace was a company of talkers. Adobe is a company of doers. Adobe took in $430 million in revenue last quarter. ObjectSpace is long bankrupt.

That is exactly what builders do to organizations.

They build stuff; which invariably ends up building organizations.

They change crappy organizations into productive ones.

Silently. Innocently. Sometimes, even unknowingly.

If you've ever stumbled upon a team of genuine builders and you are a smart individual, there are a few things about builders you tend to learn rather quickly.

Most builders as it turns out, are quiet; very quiet --- at-least that's what most 'managers' will tell you. The notion of the introverted programmer who is so busy talking to the compiler that he loses touch with reality and stops talking to human beings is the stupidest stereotype painted by classical managers who for reasons more than one cannot seem to connect to builders.  You will of-course find builders to be incredibly quiet; but only till the time you connect to them.

If you've ever stumbled upon a team of genuine builders and have connected to them you probably know rather well that there are exactly two ways of connecting to builders.

The first one is so simple; it almost sounds stupid to write it down; and yet it is so important that I am going to indulge in the act of stupidity and write it down.

To connect to builders, you need to be a builder yourself.

That is correct. Builders, as it turns out, can smell stuff getting built from a ten mile radius. If the stuff that's getting built is genuinely remarkable they can sense it from a different planet or even a whole different universe. Your best chance of connecting to a team of builders in your organization, while you work with them, is to indulge yourself in the act of building and work with them; hand in hand.

Put simply, roll your sleeves and do some real work if you can.

The second way to connect to builders, is easier and harder that the first approach. Easier because you can walk into office tomorrow morning and do it; just like that. No special technical training required; no classes required; no special sixteen hours a day of slogging required. Harder because you won't do it. It is in fact so darn simple, I can spell it out in two small sentence for you; which is exactly what I'm going to do.

Ready?

Get out of their way.

Then when you have learnt how to do that get the bullshit out of their way and let them build stuff; even if it gets you fired. 

Doing both of these things is hard and they don't even teach you how to do these in management schools.

Actually, it is as hard as being a builder. It involves putting yourself in the line and taking all the crap that is redirected to them with one isolated focus - that the builders in your organization do not lose their focus. If you can genuinely and honestly do this, and can continue to exist in your organization, without actually getting fired; the builders will connect to you.

Once you connect to genuine builders in your organization though; either by the virtue of the fact that you are yourself a builder or by the virtue of the fact that you are a bullshit buster there are things you will learn about building stuff; about innovation; about how a builder's mind works and about how things get done.

Things most organizations and individuals do not care to know about. Things that are often not published by the articles that tend to talk about the labor and toiling of builders as a glamorous overnight success stories. Besides trying to study builders at work, this book will attempt to describe, as articulately as it can, some of these things, that I and others were able to learn by connecting to genuine builders and watching them in action.

Are you a builder?

Do you work with a team of builders?

What have you learnt by connecting to and working closely with a team of builders; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

"What are you up to these days?"

Throw this question to people you meet and observe.

I threw the casual question at an acquaintance working in a large IT department of an organization. From then on, he took over the conversation holding me hostage to his story as he described his recent tour to Australia; his recent promotion; how he now had seven people reporting to him and a truck load of crap which was supposed to make me look at him in awe as I heard him speak.

If you ask me honestly though, he was boring.

If I could have yawned without insulting him, I would.

The same question led to a very different answer from a passionate developer whose organization had just removed him from a project that he had started a year ago and had asked him to work on another project which, according to his organization, was much more critical.

He held me hostage too. He talked about how his management didn't understand software development, how is boss was an ass-hole and how nothing ever worked out as well as expected in his organization.

Frankly, he was equally boring.

If I could have yawned without insulting him, I would.

The same question asked to a distant relative also working at a software development shop; resulted in boring stories of his a vacation with his wife and his friends. He held me hostage as he gave me a boring account of how he and his wife did a lot of shipping during this vacation and how they managed to land up with the best prices.

Yawn.

That same day, around a thousands of individuals answered the same question on my RSS aggregator; without even being asked to answer it.

Some of them talked about a nugget of wisdom they picked up in their management life; some of them shared their neat code; some published a tool; some talked about an open source framework they were releasing; some talked about a neat idea which would make their build and deployment process better; a couple of them had read a book and were recommending it with a warning about specific parts which they found slightly boring.

A huge number of these discussions were remarkable. 

None of them bragged about their promotion; their position in the official pecking order of their mediocre organization; their salary and how they saved a few dollars during a boring vacation.

Even when they indulged in rants, they did it in an uncanny classy style brimming with passion, cause and described the lessons learnt along the way; rather elaborately. They took their rants, made them interesting, packaged them with humor and shipped them with an intent of passing on what was learnt from a rather ugly or painful experience.

There were no boring monologues.

I did not know any of these individuals personally.

Honestly, I wasn't interviewing them. They were not answering my question.

They were building stuff; remarkable stuff; software, stories, experiences and communities. They were creating remarkable tools; building applications that would change the world; tweeting nuggets of wisdom; writing articles, doing blog posts and then when they are done; they were pushing whatever it is that they were building live.

They were building stuff; and shipping it. Without whining; without excuses; without cribbing, bitching or moaning. 

Some of them worked at prestigious names like Microsoft and Google; some were independent consultants; some were working in insignificant companies that you wouldn't be able to locate on the map if you tried to; some were leading teams; some were managers; some merely college students and a couple of them were even single moms; but none of that mattered.

What mattered was that they were building stuff in ways more than one.

What mattered even more; was that they were having fun.

They were having a party and anyone who cared to join in --- was invited.

These were not whiners; talkers or boring employees who do what they are told to do. 

These were relentless workers, story tellers, rule benders and people who make small and big dents in a really large universe of 'normal' human beings that is generally hostile towards the idea of things changing. They were what I like to refer to as --- builders; and they were at work.

Look around you; and if you are lucky; you might have a few of these amazing builders sitting around you.

Think of people you work with; and you might know a few of these guys yourself. 

This dear reader; is their book.

If you are one of them, dear reader, then this, is a book about you.

These are the gripping stories from the strangest corners of organizations where remarkable things get built by builders who indulge in the process of 'building' for two reasons in particular --- because they love building things --- and because they 'can' build things which are genuinely remarkable.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

In my earlier post, I talked about one reason why you should write an e-book. In the same post, I talked about how blogging is more like bathroom singing and writing a book is more like performing in a live concert.

For the past few days I've been stuck with this idea that will not let me rest in peace till I work my ass off on letting the it gain a form and an independent existence. I've written a couple of posts on the idea, but somehow like an ignored child, the idea seems to demand more of my attention; which I plan on giving it for the next couple of months; and I plan on doing this by writing a dedicated e-book based on the idea.

I love blogging.

I love everything about blogging; There is nothing more rewarding than seeing a meaningful idea that I really believe in, taking a shaping of its own and coming into existence. There is nothing more delightful than pushing the publish button on a post that is about something I genuinely believe in.

The only thing that tops that delight is your involvement, dear reader, through comments, when you go out and post some of these on other sites, when you blog about them, cite them or send emails to me about a post that was written with hours of thought and effort.

This blog, dear reader, is my third place and I am more 'me' here than I am myself in most places including places where I work.

Because the idea of undertaking the e-book has everything to do with fun; done in my free time; it therefore makes common sense to publish the e-book content out on my third place. The e-book therefore, dear reader, will be published out to you; as it takes shape and form.

Going forward I will be publishing posts that I write for the e-book under the category - My books. Because it is going to be mostly unorganized bathroom singing; the posts that will be published will be in no particular sequence. I am hoping that as we move forward the idea will come out in the open; make itself crystal clear and will resonate with you; dear reader.

As always, I would love feedback, criticism and participation from you dear reader. In the weeks to come I will publishing the book here, post by post as it starts taking shape. You reactions; I assume will be on the following lines:

1. Hate the posts.
2. Love the posts.
3. Want to suggest something else I should be covering.
4. Want to point out typos and stuff that should be edited out.
5. Want to contribute and help the discussion grow.
6. Have similar experiences.

The thing to do in all these cases is simple --- drop a comment; blog about it; drop me an email and express your opinions.

Remember, anything that is published here can still change in the book when it is finally published.

Put simply --- participate and contribute.

If blogging is like bathroom singing and writing an e-book is like singing in a live concert; I am going to get up on the stage of a live concert and do some bathroom singing.

This is your chance; dear reader; to boo a bathroom singer in a live concert.

You're not going to miss it; are you?

Looking forward to your participation and contributions.

Oh and before I forget --- wish me luck.

If you have ever been held hostage by an idea which will not set you free till you work on bringing it into a concrete form of existence, you probably know why the act of blogging is serious painful work and at the same time an addictive; highly rewarding and fun filled exercise.

Having said that, for me, writing blog posts is pretty much like free form dancing or bathroom singing.

You don't have to worry about every single idea resonating with your readers. If one doesn't work, they will show up; again; the next day for a completely new idea; a completely new perspective; this time, they may agree to agree and absolutely love your post.   

Writing your own book however, is different.

For a book to succeed; or for you to even attempt to write a book; you need to be hit by a a single insanely strong idea and then work your ass off at it. You need to put the idea on a test of its limit as you probe deeper with a coherent yet remarkable stream of thought.

If your idea is flawed; or not remarkable; you are basically screwed; big time.

You end up making a fool of yourself; after days of writing, editing; re-editing; proof-checking and toiling.

Put simply, if writing a blog is like bathroom singing; writing a book is performing for a live concert.

True it has its glamour associated with it; but along with the glamour; it involves a lot of work; risk of making a complete fool out of yourself and above all, some serious commitment.

Google the topic of writing your own e-book and you'll get a gazillion articles; describing the glamour associated with writing your own e-book and how you can be an overnight success and an instant millionaire by writing your own e-books. Only a minuscule number of these articles talk about the hours of hard work the usually go into this sort of an initiative before anything you write is read by more than an audience of one called you.

Amongst the hundreds of boring self article which are not even worthy of being linked of plugged from this post;  I happened to bounce on one that resonated with me or moved me positively. It was a post by Seth Godin and his advice on writing your own e-book.

It's technically easy and when it works, your idea will spread far and wide. Even better, the act of writing your idea in a cogent, organized way will make the idea better. You can write an e-book about your travel destination, your consulting philosophy or an amazing job you'd like to fill. Seven years ago, I wrote a book called Unleashing the Idea-virus. It's about how ideas spread. In the book, I go on and on about how free ideas spread faster than expensive ones. That's why radio is so important in making music sell. Anyway, I brought it to my publisher and said, "I'd like you to publish this, but I want to give it away on the net." They passed. They used to think I was crazy, but now they were sure of it. So I decided to just give it away.

Writing; is much like singing or exercising your mussels. The harder you work at it, the better you become. That dear reader, is the only true reason why, if you write for your blog and if you have an idea which you believe is worth sharing, you should try your hand at writing a book. You should do it because it gives you an opportunity to do more writing; which is what you love doing.

That, dear reader, is why you need to write a book.

Not because of the five figure income or that celebrity status the millions of readers who go gaga over your book are going to bring you.

You should write a book because you have an idea that will not let you rest in peace till you work on bringing it into existence and the idea or story demands more than just an isolated blog post in order to conveyed articulately.

Writing an e-book is easy. Writing a good one is hard. It's like climbing a mountain. You should try writing an e-book because it lets you see if you 'can' climb the mountain; and once you know you can; you should do more of it.

Why?

Because you can.    

It is really that simple dear reader; it's that simple.

No, you are not going to have a million users drooling over your book.  No you are not going to be a best selling author with a five figure income.

Wake up time. I hate to break the news to you but, that overnight success you might be looking for through your book doesn't exist.

To be honest, you'll be lucky if you don't end up making a fool of yourself with zero downloads.

If you've never done it before chances are high that you'll get sick or tired of it and quit in the middle.

Remember, there are only two reasons why you should write your own e-books; because you really want to; and because you can.

Now; do you want to write your own e-book?

If you said yes, you probably know what it is that you are getting into.

If you said yes, chances are high that I am going to enjoy your reading your book after it is done.

If you said yes, you should write an e-book.

I wish you good luck.

If you've ever been involved in a sales chase for a million dollar project you probably know that folks who market consulting services and software products will go quite far to sell their products or  services to you and close the deal. The whole act of lying about quality of people working for the organization, timelines and above all features that the product being sold has, is an age old Adam's apple folks in the business of marketing software have been tempted to bite for years.  

After all software marketers are experts and their interests revolve around selling you their services. If you have a problem and they have a hammer; they are notoriously famous for making your problems seem like a nail.

Seth Godin in his book titled All Marketers Are Liars describes how all marketers are supposed to indulge in the act of story telling:

Marketers are a special kind of liar. Marketers lie to consumers because consumers demand it. Marketers tell stories, and consumers believe them. Some marketers do it well. Others are pretty bad at it. Sometimes the stories help people get more done enjoy life more and even live longer. Other times, when the story isn't authentic, it can have significant side effects and consumers pay the price. The reason all successful marketers tell stories is that consumers insist on it. Consumers are used to telling stories to each other, and it's just natural to buy stuff from someone who tells us a story. People can't handle the truth.

Seth in his book describes how marketers make consumers and even veteran wine tasters believe that the same wine actually tastes better when tasted in a better glass. The book has other examples including that of a real estate marketer who takes customers around the neighborhood and talks about the various other houses including the lives of people living in those houses.

Seth describes how the individual selling the house is not selling the property he is supposed to sell. He is selling a story.

The book is all about successful story telling.

Story telling that can genuinely create win-win situations both for the marketers and the consumers.

Then there are times when the story telling isn't authentic. The foundations, framework and the very core of the story is built around a lie. That is when Seth warns that the consumer ends up paying the price.

With software however; there is one more group of individuals who end up paying the price of lousy story telling built on utter lies ----- the development team.

My first successful failure was a classic example of the marketing team promising too much with little or no respect for the iron triangle under the influence of wishful thinking and the we-have-a-great-team-that-can-do-it story.

Apart from a few folks, like 37signals, Google and a handful of others who have a great story to tell; almost all other software marketers; especially the ones selling consultancy services; are down right lousy story tellers who don't have anything new to say. Most stories revolve around the same old rather lame ideas:

1. We can meet your deadlines.
2. We can build something really cheap (by outsourcing most of the project).
3. We can deliver quality.

Of course if you pay us more we can do all three and vaporize the iron triangle into thin air; just for you.

If software marketing, for you or your organization, is just about one of these three lame old stories or their combination, your marketing efforts; just like your product website and descriptions; might be downright impotent.  

Pawel Brodzinski describes his rather honest and candid approach to software marketing:

I often try to bring this kind of approach to the table. Too often. You shouldn’t be surprised if you’re a customer and I ask you: “We plan to develop this product for you, does it makes any sense for you or is that just a brain dead idea?” I may also state: “This function would make both your and our lives easier, although I don’t believe they’d allow me to do it for free. Would you find some budget for the feature? I promise the price will be good.” On the side note, if you ever worked with me as a salesperson I know, you already hate me. I guess I must live with that. This approach may weaken negotiating position of my party. Sometimes it is considered as pretty harsh by customers since you occasionally don’t wrap up the truth with nice marketing blah-blah (“No, we won’t build and deploy complex telecommunication solution in a month”). That isn’t playing by the rules and from time to time people find it hard to deal with it at the beginning. However the thing I found out is that when a relation with the customer is already built they start to appreciate this attitude. Having an honest source of information on the other side is quite a valuable thing. Even when the guy is sometimes too honest and too straightforward.

Marketers are supposed to be story tellers. If you are in the business of selling; you need learn the art of story telling and weave stories that are completely new, remarkable and built of a strong foundation of facts; not the same old lousy stories woven around disrespect of the iron triangle. Software marketing guys have been telling these same old stories for years and honestly we're all a little sick and tired of these.

Even if you not a master story teller and can't tell a win-win story which is completely new; you still have a trump-card up your sleeve --- move over to plain old honesty; because honesty in the world of software marketing; as it turns out; is sofa king --- [to be read loudly and very fast] --- extinct that the mere act of being honest will make you a remarkable purple cow and help you not just close your deals or win customers; but have long lasting business relationships.

I wish you good luck.

Sometimes what you want to be is best defined by what you do not want to be.

Success-Factors CEO Lars Dalgaard has a passion for developing a company where employees are nice to each other. This point of course, is described much more articulately by his passionate hatred of ass-holes than it is by his love of niceness in the workplace.

The folks at 37Signals define this as picking a fight. They explain:

Sometimes the best way to know what your app should be is to know what it shouldn't be. Figure out your app's enemy and you'll shine a light on where you need to go. When we decided to create project management software, we knew Microsoft Project was the gorilla in the room. Instead of fearing the gorilla, we used it as a motivator. We decided Basecamp would be something completely different, the anti-Project.

They explain why picking a fight helps:

One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.

Jeff Atwood refers to this process of picking up a fight as having an arch enemy.

Overall, advice from Jeff and the folks at 37signals is just as relevant to career building and life as it is for product development.

As a part of my day time job, I interview countless young and budding developers around the world. Honestly, even today, after years this excersise, I continue to be amazed by the level of indifference most candidates demonstrate during their interview. They will move from .NET to PHP and Scrum to CMM Level 5 implementations, with no personal preferences what-so-ever, only if you were to hand them the job they seem to need so desperately.

In a world where most programmers can't program, and only a minuscule number of them are capable of forming their own opinion on anything; asking them to feel so passionately about a way of building software, a technology or any idea for that matter; that they start considering it their arch enemy or friend might be too much to ask for them.

On the other hand, if you are reading this blog; chances are high that you do not fall in this category of programmers. Chances are also high that you take your work passionately and consider it more than just a way of earning your lively-hood; and that dear reader, implies that you need to find your arch enemy.

During the early days of my career, I lived the life of a conventional good programmer climbing the ladders of promotion year after year with a passion for programming and a will to learn whatever it takes to get those promotions. Life was both comfortable and highly boring; till the time my first successful failure defined my arch enemy for me. Honestly this project did the job of defining my enemy much more clearly than I would have hoped.

Since then I've passionately hated all forms of stupidity that happens in the name of organized process and corporate culture.

My name is Pops, I write shitty code with bugs and my arch enemies include stupidity, lame conventional management ideas and incompetence camouflaged under jargons, the pretense of so-called 'serious software development' and 'process'.

It is of-course a hugely big enemy to pick; as it turns out, there is more stupidity in the world of software development then there is common sense. Take a quick look; chances are high that you'll find it all around you.

Picking up fights with this mammoth arch enemy has allowed me to bring about small changes in my universe. It has taught me more about being a better software developer, a better manager and above all a better human being. Much better than what I would have ever learned to be had it not involved working passionately at learning how to beat this arch enemy.

As far as the fight is concerned; it is far from over yet.

Have you picked your arch enemy yet dear reader?

Which fights are you fighting? 

If you have no enemies and no wars to fight, you might be missing out on a whole of lot exciting challenges, passionate struggle of thoughts and above all an ability to be 'remarkable'.  

Whether you are building a product, building a career or building a life; having an arch enemy is much more important than most people think. 

Pick a colossal arch enemy and then work passionately to wipe out it's existence from the surface of this planet.

I wish you good luck.

As a project manager, team lead or someone who works with a team what is your biggest nightmare?

When a couple of your smartest developers agree to disagree on something stupid and none of them is willing to give up or let go.

In the interest of keeping this post short, allow me to use my artistic skills to represent the scenario.

At my early days at Multiplitaxion Inc, I saw countless young and budding managers avoid these situations and issues like a plague.

Their excuse --- "I think I will let them sort this out mutually".

The reality --- "Are you mad? I am not sticking my neck into this mess; specially for the salary I get".

A major part of your job as a manager is to differentiate healthy arguments from never ending deadlocks.

You are supposed to spot deadlocks from a ten feet radius and make sure people do not stall and thrash their brains over never ending deadlocks.

You may not have the right answer. No one in your team might have the right answer; but anything close to the right answer is better than nothing.

Situations like these are precisely the kind that will require you to put your foot down and take a stand. This is exactly the kind of thing which requires your involvement, judgment, decision making capabilities, straight forward feedbacks, a strong spine and conviction.

Go ahead, make a call; take a stand. 

Then take responsibility for any failures if you encounter hiccups when your team moves forward based on your judgment.

Show us what you're made up of Mr. Manager.

I dare you.

On a side note, as far as that picture above is concerned -- we're just going to go with five for the time being.