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.

Your favorite platform which is also your bread, butter and your passion has just come out with a beta release. You are tied up with an important project. There is a part of you that wants to play with the beta bits during the weekend.

Having said that however, the  idea of catching up with friends and heading out to the new movie looks appealing.

In a casual conversation with yourself, you talk the voice that is softly whispering, asking you to take a look at the new beta pieces aside. "Monday. I'll look at it Monday morning." - you casually brush your inner voice aside.

Life moves on.

On a bright afternoon a post in your RSS reader tells you that the beta pieces have now gone to production and a released version is finally out. But then, you are currently tied up with some important work pertaining to your project so you promise yourself you will take a look at it tomorrow.

Weeks pass by and you have still not had a chance to try out the beta pieces, see the framework evolve or even try out the production pieces.

Now when you sit down to play around with an evolved version of the framework chances are that you are going to feel overwhelmed. You are going to feel like whining about to too many technologies getting released too quickly. You have taken your first step towards doing funny things like filing a petition for keeping the unmanaged version of visual basic six alive.

If there is anything years of software development and weeks of exercising has taught me, it is that both exercising and software development are fairly similar in more than one aspects.

If there is one thing anyone who is in fitness will tell you, it is that mobility is hugely important. The most difficult thing with exercising is to get a person started. To get him moving. Most fitness plan for example started with simple games squash, activities like dancing or activities like running and once the momentum sets in, rest of it becomes fairly easy. You actually start liking it.

Software development in general and picking up new technologies and languages in particular to a large extent is similar. The most difficult task is usually to get someone to download a new version of visual studio and try out that new release of WCF data services. The rest of it is fairly easy and once you have started you actually start liking the process.

Books like spark will also tell you that there are striking similarities between how your mussels and neurons work. You make your mussels stronger by using them, tearing them down through your exercise and then giving them time to heal. Every time you do this, your mussels emerge stronger. Your mind, as strange as it might seem, follows a similar path to develop strength, power and endurance.

Every now and then I see folks whining about Microsoft having more than one programming language. The whole VB.NET and C# wars are fairly common too. The thing with languages however, is that after you have worked in three or four of them, picking up a new language and coding in it doesn't remain all that difficult.

The more you work your brain with languages, the quicker it picks them up.

It is perfectly okay to not know every new technology in your platform. It is perfectly fine to stick to one language, but then, the more languages you play around with, the easier it becomes for you to pick up newer languages. After all, flow and the pleasure of learning is much more fun than whining about how rapidly technologies are changing.

Go ahead. Break the mobility barrier. Download a new language or a beta release of something you have been meaning to try out for months and actually spend some time with it today.

I wish you good luck.