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.