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.

Every now and then I stumble upon medium sized software development companies which play around with their product and their pricing. Observe these companies closely and you will realize a common trend running through all of these.

Most tend to start a product with a product idea and not a personal pain point that they want to solve to begin with. When you get subject matter specialists in the room and when you start spending hours gathering requirements, about a problem that you couldn't care less about, you tend to build mediocre products that, 'meet all requirements'.

The same subject matter specialist that billed you by the hour, also happened to bill your competition and what you have in your hand right now is a 'me too' product. Your product has screens which are very similar to the screens of your competition. Your product has features which are very similar to your competition. Your product also has pricing which is very similar to your competition.

You are what James Surowiecki describes in his article for the The New Yorker as, Soft in the Middle. He explains:

For Apple, which has enjoyed enormous success in recent years, “build it and they will pay” is business as usual. But it’s not a universal business truth. On the contrary, companies like Ikea, H. & M., and the makers of the Flip video camera are flourishing not by selling products or services that are “far better” than anyone else’s but by selling things that aren’t bad and cost a lot less.

These products are much better than the cheap stuff you used to buy at Woolworth, and they tend to be appealingly styled, but, unlike Apple, the companies aren’t trying to build the best mousetrap out there. Instead, they’re engaged in what Wired recently christened the “good-enough revolution.” For them, the key to success isn’t excellence. It’s well-priced adequacy.

These two strategies may look completely different, but they have one crucial thing in common: they don’t target the amorphous blob of consumers who make up the middle of the market. Paradoxically, ignoring these people has turned out to be a great way of getting lots of customers, because, in many businesses, high- and low-end producers are taking more and more of the market.

In fashion, both H. & M. and Hermès have prospered during the recession. In the auto industry, luxury-car sales, though initially hurt by the downturn, are reemerging as one of the most profitable segments of the market, even as small cars like the Ford Focus are luring consumers into showrooms.

And, in the computer business, the Taiwanese company Acer has become a dominant player by making cheap, reasonably good laptops—the reverse of Apple’s premium-price approach.

While the high and low ends are thriving, the middle of the market is in trouble. Previously, successful companies tended to gravitate toward what historians of retail have called the Big Middle, because that’s where most of the customers were. These days, the Big Middle is looking more like “the mushy middle” (in the formulation of the consultants Al and Laura Ries).

The companies there—Sony, Dell, General Motors, and the like—find themselves squeezed from both sides (just as, in a way, middle-class workers do in a time of growing income inequality). The products made by midrange companies are neither exceptional enough to justify premium prices nor cheap enough to win over value-conscious consumers.

The same article also talks about why it is so tempting and yet so painstakingly non-rewarding to stay in the comfortable middle path:

This doesn’t mean that companies are going to abandon the idea of being all things to all people. If you’re already in the middle of the market, it’s hard to shift focus—as G.M. has discovered. And the allure of a big market share is often hard to resist, even if it doesn’t translate into profits. According to one estimate, Nokia has nearly twenty times Apple’s market share, but the iPhone alone makes almost as much money as all Nokia’s phones combined.

The argument becomes much more dominant if you are launching your own product or service. You are not exactly a Sony or a Nokia and chances are the soft middle in your industry or domain is already taken by someone. Your only chance of surviving is that you make the best freaking products out there. Build awe and surprise by innovating the best product out there.

If you can't build a seriously kickass product that people would pay a premium price for, build something acceptable that works and disrupt your competition with the lowest of prices.

After all, safe is risky, remarkable is fun.

Go on, get out of that circle mediocrity when it comes to products and prices.

I wish you good luck.

How often have you witnessed two or more individuals disagree over something and battle it out over email?

Come on. You have seen the thirty-five email long mail thread where two big Grizzly Bears of your organization were fighting with each other over a technical disagreement. Haven't you? Huh?

If you've been in the business of building software long enough I bet you have been a part of at-least one or more of these email trails. At more than one point of time in my life,  I have been involved with quite a few of these and have specially devised twitter hash tags which can be used to rescue and bail me out of some of these 'yes but' discussions and arguments.

The deal is fairly simple. If it's a productive, objective discussion where the best solution is bound to win and it helps you learn something new, battle it out. Argue. Discuss. Learn. Strain yourself defending your strong opinions weakly held.

At the first indication of things turning personal, the sign of a meaningless flame war, the sign of bozoism or the sign of a 'yes but' discussion, back out. The battle is just not worth fighting.

Scott Hanselman's post on keystroke worthiness, which is inspired out of the original classic counting your keystrokes, by Jon Udell, is not a post which addresses this topic directly but provides some useful advice if you are just about to hit that reply to all button and respond to an email which is soon going to turn into a never ending yes-but discussion. The basic idea is simple. You have a finite number of keystrokes that you can use in your entire life. Scott explains:

Let break it down. I'm 36 and change. I'll live to be 80, let's say, and I can type 100 words a minute (but 50 of that is errors and the backspace key) so let's say 50WPM. If I type for 6 hours a day, 5 days a week, 50 weeks a year, for the next 44 years, that means there are 198M keystrokes left in my hands. Max. Period. And that's generous; it's likely 10% of that.

5.1CPW * 50WPM * 60m/hr * 6hr/s a day * 5 days/wk * 50 wks/year * 44yrs = 1,009,800,000 keystrokes left in your hands.

Let's assume the average length of an English word is 5, plus a space, so six. That's a ceiling of 168M more words I can type in my lifetime. Nothing I can do, short of dictation, or some new brain invention is going to create more keystrokes. I am I/O bound by my hands. The keystrokes they contain are finite. And this assuming my hands don't give out.

Drink that in. OK. So now, next time someone emails you ask yourself "is emailing this person back the best use of my remaining keystrokes?" That includes both 1:1 and 1:many emails. You could even add a little hubris to it and say: "Does this person deserve the gift of my keystrokes?"

If you are working with human beings, by now you probably already understand the fact of life: shit happens. While it is tempting to respond to every flame mail, every nasty comment and every heating discussion, remembering that your keystrokes are finite is your first step towards using them in places where they can have the biggest impact.

Go ahead, back out. Turn the heating mail trail into a objective research driven blog post.

Go on and Present your facts and findings and give the whole wide world the gift of your keystrokes. Chances are, that this is where your keystrokes will make a much wider impact on people who want to learn. Folks who want to participate and contribute.

Chances are that this is also how you will avoid useless stress, learn something new, move on and get stronger to fight much more meaningful battles that matter. After all, you have a limited number of keystrokes. Don't waste them on situations or mail trails which are not worthy of the gift of your keystrokes. Use your keystrokes wisely. 

I wish you good luck.