If you're into dice-driven board games chances are that you'll love MAD. If nothing else it's hilariously funny, confusing and completely insane all rolled into one. The objective of the game? You have to be the first one to lose all your MAD funny-money before someone else looses all of theirs. The funny feel of the game reflects right on it's cover which has funny pictures and a remark, "What, me worry?".

The board game comes with a printed document which is supposed to be your 'proof of purchase' with a warning inscribed very prominently:

DON'T PANIC: If you and your opponents find a board space or a Card card to be confusing, we wouldn't be the least bit surprised. But don't fight about it! Take a vote and play according to the majority rule. To most people, a majority is anything over 50%. However, because you're sufficiently intelligent and persistent to have read this far, you're clearly not most people. Therefore, determine in your own mind what constitutes a majority, take a vote and decide according to the majority rule.

The game is insanely funny; it is by far the funniest board games I've played till date. In-spite of the warning you will invariable see yourself get into really funny arguments with other players over interpretations of what the cards and board spaces mean.

The game has nothing to do with software development, but overall, the game is a very apt representation of the confusion and chaos that happens in game of software development.

1. The customer thinks he knows what he wants.
2. You think the customer knows what he wants.
3. You have meetings with customers in attempt to try and understand what he thinks he wants.
4. You think you know what the customer wants.
5. The customer thinks you know what he wants.
6. Neither you nor the customer knows what is it that he really wants and how you'll get there.
7. You convince the customer that you know exactly what he wants.

Then added opponents of software development start attacking from multiple directions and before you know it, something creepy and weird happens: Everyone Panics.

MAD, the board game begins with the same practical, pragmatic advice that Douglas Adams had picked for his famous book, The Hitchhiker's Guide to the Galaxy:

As far as software development is concerned panic contributes as much to the failure of the projects as much as any other factor.

Chad Myer Provides added insight into why every project usually goes into panic mode:

There is a point in every project - well, every project I've ever been a part of in one shape or another - where panic starts. I'm not quite sure what starts it every time, but the ones that I do know of have all been about money and 'burn rate' and I'm willing to bet that all of them (even the ones that were not made known to me) are about that. The point of Agile, in my opinion, is to allow visibility and more frequent opportunity for decision points for the stakeholder for just these types of moments.  The appropriate response, when this moment of panic is about to ensue is for everyone, especially the stakeholder, to put on their big boy pants and start making the hard decisions about what to cut. The inappropriate response - oh there are many, but they boil down to this - is to start mistrusting the developers and start assuming they're lazy SOBs who have been cleverly avoiding work throughout the whole project.  Looking back, nearly every single time the panic season started, this was the demeanor the stakeholders took.  Instantly the project went sour, all pace was destroyed, morale tanked, some people went into psycho 100hr/wk work mode to prove the stakeholders wrong, others proved them right by giving up and not doing anything. Ultimately, the project died a rather undignified and flaming death. Failure resulted (or perhaps success didn't happen to the degree to which it needed to happen), the team burned out and most left while the stakeholder was stuck with a failure product and all their critical brain trust gone or demoralized.

Ever been a part of a project where the panic button is pressed because the team is failing and someone realizes that it's failing because of lack of policing mechanisms? If you've been a part of any such projects in your life you're probably related to what Chad is saying here. If you, dear reader, have been through this experience, you probably know the feeling and can smell this panic button being pressed based on incidents that start happening. Office timings are made stringent, holidays and leaves are canceled, emails lose their touch of basic niceness, dead-lines for every single task are asked, micro management begins and everything starts failing apart.

I've seen quite a few Agile projects fail when the panic situation becomes public knowledge. After all, transparency is the biggest blessing and curse of Agile or simply an open culture in general. It brings the chaos and panic right on your face, forcing the weak hearted to either abandon it or press the panic button and replace the fundamental premise of trust on which Agile Projects are built are managed with policing measures and mechanisms.

I've often seen individuals accuse agile as being an excuse for being sloppy, but agile, by far, requires a huge deal of talent and discipline within, the development team and entire organization. In fact it requires more talent and discipline than any other process I've seen in my life. Chad in his post explains:

This is it, there's no turning back. Everyone on the team - stakeholder and producer alike - must trust each other to make the hard decisions and cut what they must to make the plan happen. You must resist the urge to bear down, roll up your sleeves and do everything wrong as fast as you can and ruin everything you've strived for. It's during the hard, trying times that discipline pays its debt. Soldiers don't go to boot camp to learn how to salute during peace time, they go there to learn how to be disciplined when the bullets are whizzing past your ears.

All of Agile is about forcing you to take the correct and sometimes hard decisions sooner than later. It won't give you a cozy feel of the 'green status report' when things are not fine. Software development is much harder than losing all your money in MAD. Before you start the software development game, the least you can do is remember the rules from MAD:

DON'T PANIC: If you and your opponents find a board space or a Card card to be confusing, we wouldn't be the least bit surprised. But don't fight about it! Take a vote and play according to the majority rule. To most people, a majority is anything over 50%. However, because you're sufficiently intelligent and persistent to have read this far, you're clearly not most people. Therefore, determine in your own mind what constitutes a majority, take a vote and decide according to the majority rule.

If you are a young and budding manager, developer or whatever-it-is-that-you-are, I leave you with one humble thought, that you can put on your not-to-do list. Take the hard decisions if you must, cut down on features if you must, motivate and train your team to work independently if you must; whatever you do; don't police and don't panic; because that is what spreads like wild fire and causes everything to fall apart.

During his early days as a mentor to some of the junior programmers at Multiplitaxion Inc; one of them, who we shall call Fred, had an issue with me and my management style. His issue was that I wasn't pushing him to meet deadlines.

Mr. Fred believed that my not pressuring him really hard, like most other traditional managers had pushed him in the past, was bad management on my part.

He patiently explained to me that, instead of me making him estimate the duration for his tasks and then letting him have enough time to complete them with a quality implementation, he would really appreciate it if I could estimate how long his tasks should take and then give him a dead-line so that he would start working harder as the deadline approached.

For most other thick-skinned programmers who were getting projects rolled out successfully at Multiplitaxion Inc, deadlines weren't working out all that well. They seemed to like the idea of estimating their own tasks and working in a pragmatic non-panic environment.

I had discovered, early on in my career that the mounting pressure to ship based on a given artificial deadline encourages developers to program by co-incidence. As a developer, I had learnt the lesson the hard way, and had told myself that I would not push teams I work with to program by coincidence just to meet a deadline; specially artificial ones.

As I grew in my professional and personal life I started realizing that not imposing any deadline on people and empowering them with trust, makes them much more productive. Then I met Mr. Fred who had issues with the whole no-deadlines-we-trust-you-to-get-things-done way to running projects. Here was a guy telling him me that he desperately needed deadlines and he needed to be pressured so that he would do his work as I stood there and looked at him, completely confused.

Deadline Driven Development or DDD as some call it lovingly, isn't new in the world of software development and this wasn't the first time I was seeing it in action. During my early days as an young and budding developer, I had seen deadline-driven-development in the world of project managers where it was rampantly popular.  Having said that however, this was the first time in my life when I was seeing a team member crave for it. This was indeed my first experience of seeing young and budding engineers infected with an otherwise managerial disease. 

Tom DeMarco and Timothy Lister describe a real life story, of how managers and senior executives, like keeping their teams under constant pressure of deadlines, in their book Peopleware: Productive Projects and Teams:

During the past year, I did some consulting for a project that was proceeding so smoothly that the project manager knew she would deliver the product on schedule. She was summoned in front of the management committee and asked for a progress report. She said she could guarantee that her product would be ready by the deadline of March 1, exactly on time according to the original estimate. The upper managers chewed over that piece of unexpected good news and then called her in again the next day. Since she was on time for March 1, they explained, the deadline had been moved up to January 15.

The story might seem extreme to a few of you dear reader, and even though moving the deadline ahead might seem a little dramatic for most management teams to do, consider this: how frequently has your management seen you ship comfortably on time and have thrown in a couple of extra features in the mix asking you to build the new features in the same timeframe. Maybe the deadline wasn't randomly moved ahead, but adding random features, just to keep the team on their toes, equates to the same thing.

Deadline driven development is an approach to software development where the management constantly and rampantly disrespects the iron triangle. At multiple organizations that I've seen or visited, I've personally heard of or participated in more than one project and utilization meetings where people being able to head home comfortably at 6:30 is cited as a bad example of resource utilization.

Most veterans understand and have mastered the art of balancing between aiming for perfection and shipping and these kick ass developers will ship as fast as they humanly can. At times they'll estimate stupidly, stumble like babies and miss deadlines. Then they'll get up, get better and ship successfully. Peopleware does a pretty good job at describing the paradox of success when it comes to deadlines:

How many times have you heard that some new technique is going to be used because it is the only chance to make the hard-and-fast deadline, and that if the deadline is missed, there will be hell to pay?  The  setup of the change has already made its  outcome more than a little  dubious. The  kid-like  willingness to throw ourselves into a potentially  embarrassing endeavor is defeated by the potential for ridicule. Paradoxically, change only has a chance of succeeding  if failure, at least a little bit of failure, is also okay.

Every time there is a business push to ship faster I see countless managers, just take the email, forward it to their teams and push them harder; under the optimistic belief that if the team really pushed harder they might be able to pull of a magic trick.

If you're a manager, your job is not just to build a gantt-chart and then run behind your team collecting the status in terms of percentage complete. Business is expected to rush software development teams into it's own death-bed through continuous increase in velocity but and some point you need to take the crap upon yourself, cushion your team from it and let them function un-interrupted without the pressure of continuous and mostly artificial dead-lines. If you need to sit through a thousand meetings to convince the business, please do; if you must get into heated argument with marketing guys and your bosses please do; but if you pass of a stupid artificial deadline to your team all you do is demonstrate the lack of your management skills.

If you're a budding manager and the next time they tell you that there'll be hell to pay if a deadline is missed, try to investigate a little more into exactly how the business gets impacted and what is the actual loss involved if you were to miss a deadline for a few days. Chances are, there'll be none and there is invariable a high possibility that the so-called magical deadline which appeared out of nowhere would be the brainchild of a prick trying to push the team a little harder by pushing random deadlines.

I've been a part of multiple projects and have worked with a huge numbers of developers. I have hardly ever seen programmers cheat their organizations and have a fun time watching movies and playing video games when they had a clear sense of what they were expected to do and what the organization expected out of them. Working under the assumptions that your employees are out there to rob you and then pushing constant deadlines at them so that they don't miss-utilize their office time is outright stupidity which does nothing other than encourage the infinite loop of failure within the organization and the software development world in general. 

Deadlines Driven Development is for a team of Dummies. For everyone else who is decently smart, there is communication, collaboration and successful implementations.

When acquaintances and distant relatives strike a conversation with me in parties and during these discussions want to know what it is that I do for a living, I tell them that I read, talk, listen and besides doing all of that, I write. The reply often results in a confused acquaintance or an even more confused distant family member looking at me like I am an alien with a third eye when in-fact I'm just passing Zen-line statements that you would usually hear from Yoda.

I am no-where close to being as insightful as Yoda but labeling myself as a programmer, project manager, technical architect or any fancy designation sounds like an incorrect introduction of my true self.

When I'm not reading, talking and listening to others in development teams, 'writing' describes what I do rather well:

1. I write code.
2. I write about code.
3. I write about my experiences with reading, talking and listening to others.

Of course, this blog reflects my love for reading, talking, listening to others and writing. Going ahead I'll be exploring my love for all of these activities using stories with lessons to learn both from projects that I've worked on and the ones I've witnessed or seen from the outside. These are stories from my past with a fictional sugar coating and no direct names of organizations, clients or individuals.

Most of these stories will be real with a fictional coating. Others will be completely fictional with real lessons. I will weave and knit words to confuse you just so that you don't find out what's real and what's not; but my intent isn't evil here. The intention is to share with you, dear reader, lessons learnt during my software development career in ways that are exciting and fun.

We will, for the sake of creative imagination use a few common characters and personas in all the stories that we publish on this blog from this point on. This post is about describing some of those personas and laying down the basic framework for the stories and posts to come.

Multiplitaxion Inc.

Multiplitaxion Inc, is a fictional company where things just don't seem to go right. The name, as usual, was suggested by my very smart nephew when he was first taught multiplication. The guy had mastered the idea of multiplication rather well and could multiply numbers decently well; but there was a 'little' bit of a problem. He was having a hard time pronouncing multiplication; so he came up with Multiplitaxion. The name was way too cool to be wasted. That's when Multiplitaxion Inc, was born.

The idea of Multiplitaxion Inc, was inspired by three different sources.

1. Lots of Organizations - During a point of time in my career I was hopping from one client office to other and visiting multiple so called big software development houses. I was realizing one thing; The bigger they were the bigger their stupidities were. There were a very few who were maintaining the magic touch of small but most of the bigger organizations were hugely big even when it came to their stupidities.
2. Office Space - This was a comedy that a colleague of mine introduced me to. The movie had a fictional organization called Initech; which was a pretty funny representation of the kind of stupidities that happen in a huge number of software development shops.
3. The Poster - I remember a conference room where project status was analyzed and decisions for future versions were taken; I remember a single conference which continued for a very long time where I was barely close to catching my zzzzz, hardly ever spoke and kept staring that this poster on the wall.

You would think that anyone with the common-sense and sense-of-humor to stick a poster of this sort in the conference room would be careful about the stupidities they would indulge in. However, I sat in the conference room, waiting for a very lengthy meeting to finish, where everyone involved tried to freeze the requirements for the next version followed by a finger pointing exercise of why the first version didn't meet all the requirements. I sat there and admired the idiocy that happens even when some reasonably smart people come together in large groups with conflicting interests. Multiplitaxion Inc, isn't real; and neither does it represent one single organization form my past; but the problem this fictional little organization faces are real. Very real.

Fred

To be honest Fred is not my brain child. He belongs to Venkat Subramaniam and Andy Hunt who conceived the idea of Fred in their book The Pragmatic Programmer where they described Fred using a simple example:

Suppose Fred is given a programming assignment. Fred types in some code, tries it, and it seems to work. Fred types in some more code, tries it, and it still seems to work. After several weeks of coding this way, the program suddenly stops working, and after hours of trying to fix it, he still doesn't know why. Fred may well spend a significant amount of time chasing this piece of code around without ever being able to fix it. No matter what he does, it just doesn't ever seem to work right. Fred doesn't know why the code is failing because he didn't know why it worked in the first place. It seemed to work, given the limited "testing" that Fred did, but that was just a coincidence. Buoyed by false confidence, Fred charged ahead into oblivion. Now, most intelligent people may know someone like Fred, but we know better. We don't rely on coincidences—do we?

I loved the idea of Fred and went ahead and said that there's a little bit of Fred in all of us. But then throughout my career I've also met perfect embodiments of Fred. This blog is not about criticizing Fred. Instead it's about analyzing what Mr. Fred does and learning from his stupid mistakes; but before we do that it's really important that we know Fred; which is why, dear reader, I present to you, Mr. Fred.

Fred, Meet the world. World, Meet Mr. Fred.

Jane and Jack

Jane and Jack are two programmers who are a pleasure to work with. They are not ‘perfect’ individuals; just highly reliable and consistent. Jane and Jack are people you can connect too. They are not very loud though. They enjoy talking to the compiler in the cozy corner of their office and are completely disinterested in office politics, moving on to management and leading others. If there is one thing they want to do, it is to ship remarkable code.

Pops

This one's not my brain child too. This is the brain child of Michael Lopp in his book Managing Humans where he referred to himself as Rands:

The icing on this semi-fictional cake is Rands. This is a name I began using in the mid-’90s for my virtual presence; when I began web-logging about management, the name stuck. Think of Rands as your semi-fictional guide walking you through the fake stories of fake people that have had incredible relevant (yet fake) experiences. Rands has a bit of attitude, but, then again, so do I.

I'm of Indian origin and I carry my Indian origin and accent rather well when I travel around a flat world. I'm definitely not an Indian call center employee with a thick Indian accent trying to assume an identity of 'Sam' or 'Harry' and making a fool of myself. My real name is Rajiv Popat and I have no complexes what-so-ever about that.

Pops however, is a rather funny identity which allows me to step out of myself to be just as critical of myself as I am of others including Fred. Then the idea of Pops is even more appealing when I go ahead and make random mistakes which, of course, I do all the time. I can blame it all on Pops. After all, it's not me making those stupid mistakes. It's Pops.

More Personas

Of course, Multiplitaxion Inc, Fred and Pops are a good starting point for story telling; but I do realize we'll need more characters as we move ahead. I'll be making changes to this post as I go ahead and introduce other characters in future.

Consider this page the Introduction to all of the characters that you'll meet in the stories about management and software development from Pops at ThousandtyOne.com.

Every time I want to go ahead and add a new character to the story I'll just go ahead and add him here. I know I'm not supposed to be going back and editing a post that has already been published, but it's not me who'll do that, remember? It's Pops. The guy just doesn't understand blogging rules all that well after-all.

One of my seniors told me something on the lines of - "Senior engineers are supposed to wear multiple hats and juggle multiple tasks at the same time"; the issue at hand was that I was not 'utilizing' the senior most members in my team to their fullest extent by not giving them multiple tasks to work on all at once. According to him, even though I had promoted these individuals I wasn't tapping into their full potential by pushing them to undertake multiple tasks at once.

This particular senior of mine believed that all senior members in all teams should multitask and if they couldn't, they weren't senior enough to be promoted to the position of senior programmers. He wanted, expected and demanded that anyone who was to be promoted as a senior programmer had to be a serious, mind-blowing, kick ass juggler when it came to handling multiple tasks as once before he was lifted to the position of a senior programmer or promoted.

During the early parts of my career I had been a ruthless multitasking guy myself. The obvious expectation from someone like me was that I would push multiple members in my team towards multitask as well, but then something creepy happened. All the multitasking that I was doing was starting to have it's toll on me.

There would be days at a stretch when I would stare at the monitor losing a track of what it is that I was doing and what I was supposed to be doing next. I had taken multitasking to the next level and was suffering through what can be, most aptly, defined as the ALT-Tab-Syndrome. That is when I started realizing how expensive a human context or task switch was.

In his article on human task switch Joel Spolsky explains how harmful human multitasking is by comparing it with multitasking on computers. He argues that both are expensive and the only thing they do is provide is a perception of speed, not actual increase in speed or productivity. He explains:

OK, back to the more interesting topic of managing humans, not CPUs. The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That's because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.

In his post, Joel basically pushes the idea that human multitasking in all it's form is not as productive as working on one-thing-at-a-time. In fact Joel feels it's harmful.  

G. Wade Johnson argues that what Joel is talking about can be described as preemptive programming. Wade on the other hand, introduces another form of multitasking where he talks about utilizing multitasking to utilize idle time:

An interrupt forces a task-switch. You incur all of the overhead of changing state, just like in the time-slice case. In fact interrupts are worse for humans than for computers. If you know you will be changing tasks after lunch, you can generally aim for a good place to stop. With an interrupt, you have no choice of when it occurs. On the other hand, I try to keep one major task and two or three minor tasks on my plate at all times. This way, when something causes me to block on the major task, (waiting on technical or business input, lack of some resource, a design problem that I just can't seem to beat right now) I can spend some time on the minor tasks. Every minor task I complete, is one more thing that actually gets finished. That way I don't spend the blocked time busy waiting (browsing the web, reading slashdot, etc <grin>).

As valid as Wade's point seems, I've been a first hand example of what happens when you try to utilize and squeeze out every second of your idle item. Human RAM's are relatively limited in size, writing a few functions, firing a build that is going to take a minute to fire, reading a blog-post in that one minute and coming back to the code when the build is complete with all the variable names, function names and class names you were working with fresh in your head doesn't sound real life as well.

Kathy Sierra believes that the perils of multitasking aren't just limited to lowering the quality of the tasks that you are multitasking. According to her multitasking may have perils which are much more profound. She explains:

Where I once believed that the myth of multitasking was about time (that doing four things simultaneously takes much longer than to do those same four things in sequence), scientists now know it's also about quality. And it gets worse... it's not just that the quality of those four things in parallel will suffer, it's that your ability to think and learn may suffer. Some researchers believe that all this constant, warp-speed, always-on multitasking is causing young people, especially, to become less able to follow any topic deeply.

Kathy has indeed done her research on the topic really well. Go ahead, browse through her post and you'll get everyone from The Time Magazine to Jordan Grafman, chief of the cognitive neuroscience section at the National Institute of Neurological Disorders and Stroke, telling you that multitasking and being involved in too many things at once is harmful.

While I see countless young and ambitious engineers wanting to take on more and more projects, bigger and better challenges, grow in life and go places all at once, Kathy's post does a good job at reminding them their physical and mental limitations:

Whenever I talk about the big myth of multitasking, people always come up to tell me how they themselves just "have the kind of brain that can do this." Riiiiiight. They don't. I don't. You don't. And maybe you'd realize it if you turn off your cell phone, disable IM, mute the little "ding" alarm that says you've got email, and just sit there for a few moments. The big problem for most young people, it seems, is that they don't know how to "just sit there." They get the shakes after just a few minutes without media stimulation.

What ever be the form of multitasking that you're doing; chances are that it is doing you or your work more harm than it is doing you or your work good; and that includes the kind of multitasking Wade explained in his post. As developers we tend to believe it's beneficial and we like to think we can handle it really well; but the truth of life is we can't. Kathy explains:

One of the most interesting things discussed in the Time article is that neuroscientists have established the specific area of the brain responsible for context switching. And unfortunately for some of us, it appears that this part of the brain performs less well as our brain ages. In a nutshell, the older we get, the less quickly and effectively we can multitask. But... most parents of teenagers already know that we have no frickin' idea how our kids manage to do what they do simultaneously. The key issue, though, is that while we now know they're better at it than we (the parents) are, they aren't half as good at it as they think they are. And chances are, you aren't as good at it as you think you are.

The next time you fire a build and you feel this yearning temptation to read a blog post or reply to an email, ask yourself if you can handle the task-switch and come back to the build elegantly and completely when it's complete? If not, maybe you're just better off sitting there, admiring the build getting fired and slowing down a bit as you think about the next few lines of code you are going to write. After all you'll hardly get anywhere with just random multitasked speed.

If you're leading a team, if there is one lesson you can take back from this post, Joel describes it rather articulately:

As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they're going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done. When emergencies come up, think about whether you can handle it yourself before you delegate it to a programmer who is deeply submersed in a project.

Are you still expecting your team members to multitask before you promote them? Are you only promoting your team members based on their multitasking abilities? Here's my advice to you: Don't use multitasking abilities as a measure for promotion.

Are you knitting your brows and telling yourself what a moron I am because you think that as you climb up the corporate ladder you have to multitask? Well, Multitasking is a real need in my job profile as well. I tend to give a very strong perception of multitasking when I work on multiple projects at once; but that's exactly what it is - a perception. Behind the curtains; I try my best not to multitask as long as possible.

A colleague recently told me that he was planning on picking up Ruby on Rails in the next three months while he also worked on something learning something else during those three months. My immediate response and suggestion to him had been that he should buy a Ruby On Rails book, stop learning the other thing that he was planning on learning and just focus on Ruby On Rails and finish it off in the next one and half month instead of three. Then he should consider moving to something else.

This is but, one simple example of avoiding the perils on multitasking. All situations in your life may not be as simple as this and I clearly don't have all the answers, but the biggest favor that you can do yourself is by starting to realize that human task switching is expensive and that multitasking in a real problem in our lives. Once you realize that, work consciously towards finding ways and means to avoid multitasking every time you can see an opportunity to avoid it.

Bottom line; whenever you have an option to avoid multitasking, avoid it.

The trick is to blind out everything else when you start with a task at hand and not look at anything other than the task as had till the task comes to a logical end where it's safe to switch to something else without having to keep too much about your first task in your head. Till you reach that point, don't open your outlook; close your browsers and if that stupid phone is ringing continuously switch it off too. Once you reach a logical end where you know it's ok to switch to another task, then by all means do; but random aimless multitasking in attempt to do too much in too little time gets you nowhere. Absolutely nowhere.

The Perils of multitasking are huge; both in software development and life in general. Multitasking is truly impacting and preventing us from being successful and happy; but you don't have to take my word for it; see Scott Berkun talk about attention and sex to help you decide for yourself.

During my school life, I quit my karate lessons within a couple of years or learning and practice. Today if I got into an award confrontation requiring self defense here's how I would defend myself: I would run, as fast as I could. I would run so freaking fast that I wouldn't even look behind. That's how much karate I remember.

On the serious side of life, my reasons for my early interest in martial arts, besides being physical, were also philosophical. Martial Arts, in all it's forms has ideas and concepts which can be borrowed and used for life and software development. This post is about one such concept and if you are a programmer, this post is also about asking a very important question: are you a code samurai?

Martial Art gurus believe that a perfect weapon is one which becomes a seamless extension of the warrior's body and brings him greater reach, humility and grace. On the same line of thought, a perfect warrior is one who can blend himself with the perfect weapon. In other words, in the world of martial arts it is believed that to become a great at a warrior you must pick the great weapon and then reach a stage where the warrior and the weapon become one.

I've often announced that software developers need to turn themselves into warriors and one man armies. If you look at it, your machine is your only weapon against the countless enemies of software development. Yet, I rarely find programmers who are one with their machines. A huge number of programmers on the other hand, are hunting and pecking for keys on their keyboards as they type and fumbling with the mouse as they hunt for points on the screen to click.

I've always said that hitting the window key and typing iexplore is fast. It's faster than reaching out for the mouse and clicking that Internet explorer icon but Jeff Atwood provides a much more compelling example:

Let's assume that we're typing some text into a document of some kind, and we wish to save the document we're working on. (I could argue that the user should never have to explicitly save anything, but humor me.) If it seems ridiculous that the mouse method: Take your right hand off the keyboard Place your right hand on the mouse Mouse over to the File menu Click File Click Save Place your right hand back on the keyboard Could be measurably faster than the keyboard method: Use your left hand to press Control+S I assure you that you are not alone. Please defer all your righteous indignation for just a moment.

David Allen in his book Getting Things Done: The Art of Stress-Free Productivity, describes his frustration with even the veteran professionals hunting and pecking for keys as they work:

If you're  in  a  large-volume  e-mail  environment,  you'll greatly improve your productivity by increasing your typing speed and  using  the  shortcut  keyboard  commands  for  your  operating system and your common e-mail  software. Too many  sophisticated professionals are seriously hamstrung because they still hunt and peck and try to use their mouse too much.

Steve Yegge feels passionately about touch typing so much so that he believes that those who don't touch type might be scarifying a big number of things:

Programmers who don't touch-type fit a profile. If you're a touch-typist, you know the profile I'm talking about. It's dirty. People don't talk about dirty secrets in polite company. Illtyperacy is the bastard incest child hiding in the industry's basement. I swear, people get really uncomfortable talking about it. We programmers act all enlightened on Reddit, but we can't face our own biggest socio-cultural dirty secret. Well, see, here's how it is: I'm gonna air out the laundry, whether you like the smell or not. What's the profile? The profile is this: non-touch-typists have to make sacrifices in order to sustain their productivity. It's just simple arithmetic. If you spend more time hammering out code, then in order to keep up, you need to spend less time doing something else. But when it comes to programming, there are only so many things you can sacrifice! You can cut down on your documentation. You can cut down on commenting your code. You can cut down on email conversations and participation in online discussions, preferring group discussions and hallway conversations. And... well, that's about it. So guess what non-touch-typists sacrifice? All of it, man. They sacrifice all of it. Touch typists can spot an illtyperate programmer from a mile away. They don't even have to be in the same room. For starters, non-typists are almost invisible. They don't leave a footprint in our online community. When you talk to them 1-on-1, sure, they seem smart. They usually are smart. But non-typists only ever contribute a sentence or two to any online design discussion, or style-guide thread, or outright flamewar, so their online presence is limited. Heck, it almost seems like they're standoffish, not interested in helping develop the engineering culture.

While everyone seems to give a great amount of importance to the keyboard as a powerful way to interface with your machine, Bruce Tognazzini has a different take on the topic:

We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts: Test subjects consistently report that keyboarding is faster than mousing. The stopwatch consistently proves mousing is faster than keyboarding. This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster. People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement. It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist. While the keyboard users in this case feels as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish. They have not had to set their task aside to think about or remember abstract symbols.

Maybe it's not just about the rather controversial the mouse vs. the keyboard argument; or the search of which one is the perfect way to interface with your machine. Maybe it's about using the combined use of the keyboard and the mouse in a way that makes you one with your machine. Irrespective of the input device you are more comfortable with, if you are not completely comfortable with your machine and not moving blazing fast, it shows.

In the world of music and martial arts, they would hardly let you get on the stage before you develop a sense of comfort with the instrument or the weapon. Touch typing and your at speed defines your comfort level at the keyboard and eventually with the machine; if nothing else, it provides a perception of being a power-user to both yourself and the external world.

Nolan Larsen, comments on how powerful perception is in the world of computing:

I came across an interesting example of perception vs. reality while designing a small text editor: When scrolling the text horizontally in a window we would refresh the text by redisplaying each line starting at the top. This resulted in a wave of text rippling down the screen, and many complaints that the screen refresh was too slow. The remedy was to scroll the bits already on screen and then redisplay each line from the top. The second implementation was actually slower than the first because we incurred the overhead of scrolling the bits before we even started to display the new text on the screen. However, the perception was that there was an immense increase in speed. We stuck with the second implementation because it increased the overall satisfaction of the user even though it actually decreased the throughput of the product.

I didn't learn typing formally in a typing class or at school. Computers and software development was love at fist sight for me. Out of my deep passion and love for computers and software development, I spent countless hours at the keyboard which may have brought up my typing speed to a decently high words per minute count without me even having to work consciously for it.

As a matter of fact I had hardly ever measured my typing speed until a few days ago, but my comfort level with the keyboard is high enough to let me touch typing blazing fast with my eyes literally blind folded. If nothing else, it makes me feel good about being able to connect to my laptop and turning it into an extension of myself.

I never thought about any of this cautiously before. I never realized consciously how important being fully comfortable with the input devices was till I happened to work with a gentleman who was fumbling in a confused state of mind between the keyboard and the mouse when we needed to push the prototype-build out really fast with some of the bosses waiting for the build to be pushed out eagerly. To be fair to him his lack of speed didn't delay the build push by more than a few minutes; but having said that, as I watched him hunting, pecking and fumbling, it definitely lowered my confidence and perception of whether he knew what he was doing. That's how important perception is.

Whether you do it for increased productivity or for perception and feel good factor, if you are hunting for keys on the keyboard and fumbling with the mouse you need to do something about it. You might be sending out the perception of being a newbie when you are really a veteran. If you are not one with the weapon do you really expect the world to consider you a good warrior? If you're not one with your computer when you code and work do you expect the world to consider you a good programmer or a code samurai?

Go ahead, blindfold yourself and try typing a couple of pages about your life or your favorite topic in any editor of your choice. If the idea doesn't freak you out and you can actually do that successfully, at a decently acceptable speed that's very close to what you would have achieved with your eyes open, chances are that you're on the track of becoming one with your machine. If not, the sooner you start taking your first steps at becoming really comfortable and fast with your machine, the higher your chances of having a productive life will be. Looking for your mouse? Pecking for they ALT+F4 keys? Or are you one with your machine? I leave you dear reader, with a reality check and wish you best of luck at getting faster and better anyway.

In one of my earlier posts I claimed that project management had a lot to do with understanding the human mind. In the same post I also went ahead and admitted that I'm no expert at it. Having admitted that, the amount of time and effort I have been dedicating and still dedicate to understanding the human mind and people issues is as much as the time and effort I dedicate to understanding code.

As a matter of fact, the time I spend to understand human beings in teams is sometimes even more than the time I spend trying to read and understand code. Studying programmers and how they function in a team fascinate me; as much as programming does. After all, I love everything about software development and team dynamics form a huge part of it.

I've seen countless college interns, fresher's and even regular employees being recruited by companies based on their 'analytical skills', 'mathematical skills', 'academic qualifications', 'educational background' and 'grades'.

I've also seen a huge number of those decisions turn out to be complete disasters. I've seen a few top notch graduates from top grade colleges who have toped three rounds of technical interview turn out to be complete pricks and in-compatible when it comes to working in a team. I've also seen programmers with humble starts out perform, get the team together and drive projects through the doors of success.  

Some of these experiences have made me to think that maybe, just maybe, organizations that evaluate candidates simply by using these black-and-white-approaches of judging them simply based on their 'academic background', analytical skills' or even 'technical skills', might be missing out big time on opportunities of recruiting a completely different breed of employees with qualities which are just as, and sometimes even more important for successful implementations, rather than just having 'technically-kick-ass programmers' on the projects.

'Catalysts' form a part of these different breed of employees. DeMarco and Lister, in their book, Peopleware: Productive Projects and Teams (Second Edition), describes Catalysts and their contribution towards making a project successful:

I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me  to request that I assess some of the people  in  the course (his project staff).  He was particularly curious about one woman. It was obvious he had his doubts about her: "I don't quite see what she adds to a project she's not a great developer or tester or much of anything." With a little investigation,  I turned up this intriguing fact: During her twelve years at the company,  the woman in question had never worked on a project that had been anything other than a huge success.  It wasn't obvious what she was adding, but projects always succeeded when she was around.  After watching her in class for a week and talking to some of her co-workers,  I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there.  She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out.  He just didn't recognize the role of catalyst as essential to a project.

I've worked with a couple of really awesome catalysts myself in my professional career. After having realized the importance of having catalysts in each team, I've also learnt that there is no one-step-formula for finding and hiring this breed.

These are candidates who will show up in your interview, will perform very averagely in them at the same time send you a very good vibe by connecting to you, their enthusiasm, passion for learning and connecting to other individuals resonating very strongly, leaving you completely confused on whether you should hire them for their potential and attitude or let them go because of their average scores in the technical rounds.

Just like hiring any awesome individual, in order to hire a good catalyst, you have to go with the facts, your experience, gut-feeling and then finally get lucky.

These are candidates who may not be able to solve those puzzles your organization wants you to ask them or answer all of those interview questions that good .NET developer aught to know but one of the biggest blunder managers and organizations can do is undermine their contributions.

I've personally witnessed countless occasions of failing projects starting to become successful over a period of time after a catalyst is introduced in the team. I've also seen successful projects starting to stumble when a catalyst leaves or is removed from those projects; and in all these cases the catalysts weren't contributing anything that can be described as majorly critical when it came to code or tasks in.

If you're building a team, leading a team, or working for a team, remember that the role of a catalyst in a team is as important as the role of the best programmer who is shipping the most complex and critical modules. Go ahead, look around you; or think of the people you work with. Is there a catalyst holding your team together? If yes, are you giving him due credit and appreciation for his contributions?

I've often been accused of being a pessimist. My pessimism comes back from the school days where I would announce, almost ceremoniously, how bad I had written my exam papers and how I might barely pass only to hit a 80+ or a A+ when the final results were announced.

My biggest strength at pessimism was that I was convincing at it. I could carry my pessimism tugged along with my depression using a very glum face; and I genuinely believed it too. If you were to put me on a lie detector and asked me how much I would score in that exam I probably would pass the lie detection test comfortably when I said I would just about scrap through or just about pass the exam. I would say that with a very serious and glum face.

Then I would go ahead and score a 80+ or an A+ when the results came out and you'd be wondering what just happened.

Acquaintances, teachers and most people who knew me considered pessimism to be one of my biggest weakness. They thought I was underestimating myself when all I was effectively doing with them was simple: I was lowering expectations.

When I entered the world of software development as a young an budding programmer and then a young and budding team lead, I realized that a little bit of optimism can make you your manager's pet and take you way ahead in your path to countless promotions and so-called-successful projects. I tried optimism and it sort of worked. I was successful but the success wasn't quite nearly as satisfying as I had expected.

I was frustrated; only to revert back to my true nature of a thick skinned pessimist who hopelessly under-promises, sells you the deal and then works his ass off to over deliver because he is freaking scared of failing in the end.

At work, I've been accused of being a pessimist by many. In past, I've been approached by Finance and Marketing people telling me that the organization had a long-pipeline of projects only to get my response that we should think about those projects only when the pipe line materializes and becomes real.

When it comes to recruitment and retention I'm continuously worried about my entire team quitting and on my feet to keep them happy; even when everything is perfectly fine. When it comes to projects I am constantly looking out for details which will cause the project to fail even when it's running comfortably well and three weeks ahead of time.

In an earlier post, I've already discussed my frustrations over being 90% done and have gone ahead and said that 90% done is as good as not done.

Pessimism is something that was always a deep rooted part of my character. However, I no longer consider it a weakens or something I need to work on changing.

If you're a programmer or connected to software development, Optimism and Wishful thinking are probably the two biggest vices you can be cursed with. Frederick P. Brooks in the classical legendary book, The Mythical Man-Month Essays on Software Engineering, explains:

All programmers are optimists. Perhaps this modern sorcery especially attracts  those who believe in happy endings and fairy god-mothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end  goal.  Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection process works, the result is indisputable: "This time it will surely run," or "I just found the last bug." So the first false assumption that underlies the scheduling of systems programming is that all will go well, i.e.,  that each task will hike only as long as it  "ought" to take.

Steve McConnell in his book Rapid Application Development - Taming Wild Software Schedules believes that optimism taken at the next level of wishful thinking may be at the root of more software problems than all other causes combined:

I am amazed at how many problems in  software development boil down to wishful thinking. How many times have you heard statements like these from different people: "None of the team members really believed  that they could complete the project according to the schedule they were given, but they thought that maybe if everyone worked hard, and nothing went wrong, and they got a few lucky breaks, they just might be able to pull it off." "Our team  hasn't  done very much work to coordinate the  interfaces among the different parts of the product, but we've all been in good communication about  other  things, and the  interfaces are  relatively simple, so it'll probably take only a day or two to shake out the bugs." "We know that we went with  the low-ball contractor on the database subsystem, and it was hard to see how they were going to  complete the work with the staffing levels they specified in their proposal. They didn't have as much experience as  some of the other contractors,  but maybe they can make up in energy what they lack in experience. They'll probably deliver on time." "We don't need to show the final round of changes to the prototype to the customer. I'm sure we know what they want by now." "The team is saying that it will take an extraordinary effort to meet the deadline, and they missed their first milestone by a few days, but I think they can bring this one in on time." Wishful thinking isn't just optimism. It's closing your eyes and hoping something works when you have no reasonable basis for thinking it will. Wishful thinking at the beginning of a project leads to big blowups at the end of a project. It undermines meaningful planning and may be at the root of more software problems than all other causes combined.

Even after people with reputations as high as Steve and Frederick describe optimism and wishful thinking as one of the biggest problems of our industry I continue to be surprised by just how wishful people still exist in our industry.

I've seen companies continue on projects where the entire teams knew months in advance that the project would fail without doubt. I've seen teams continuing work on the project without uttering a word even when they were completely aware of the ultimate destiny of the project.

The decision to continue silently was clearly taken under the hope that something magical will happen whisking the project away on the path of heroic success.

I've worked at multiple client places. During my work at some of the clients, I've witnessed business deals being struck, companies being acquired and projects been extended all under the curse of wishful thinking when every single individual directly involved with the deal, the companies or the projects that I talk about, would have told you hands down that there was no way things could have "worked out".

Yet, the teams decided to continue; closing their eyes to the hardcore realities of failure. What they were doing was ignoring the possibilities of disaster outright blatantly.

Optimism and Wishful thinking are by far the Biggest Curse of Software Development and to a large extent and if you're working on a project where nothing seems to be going right and yet you find yourself continuing without uttering a word you're probably cursed too with these vices. Your only glimmer of hope is a touch of pessimism and every once in a while a splash of a cold water on your face to wake you up and show you the reality.

Remember, optimism and wishful thinking are the biggest curses in our industry. The next time you tell yourself that things will 'work out' ask yourself if you've genuinely evaluated the situation or are you just turning a blind eye to the inevitable?

Every now and then I’ll have one or two young and budding colleagues walk up to me and ask me what they can do to become what they refer to as 'project managers' or 'team leads leading their own teams'.

Project Management or for that matter any form of management is about understanding people’s mind and I’m not sure what makes people believe I have all the answers when clearly I am as clueless as anyone else when it comes to understanding the human mind. It's not as simple taking a few lines of code and looking at them really closely to analyze or debug them.   

I suspect it’s either my very-serious-sounding-designation or depending on the definition of success, a lot of successful projects and a few not so successful ones that I’ve been a part of that makes people think that I might have a clue.

To be honest however, here’s the secret: I don’t have a freaking clue about how the human mind works. Yes, I spend countless hours reader about this stuff and putting some of the principals and theories into practice but the reality of life is that I have very few answers. 

I’ve attempted to answer how young and budding engineers can start leading their own teams by not being a leader but the ‘what-can-I-do-to-become-a-project-manager’ remains largely unanswered.

There are actually two answers to the question depending on how you phrase the question. If the question is ‘what-can-I-do-to-become-a-project-manager’ the answer is simple:

Join an organization where you can butter your way up the corporate ladder and turn yourself into a budding politician.

On the other hand if the question is ‘what-can-I-do-to-become-a-good-project-manager’ that's a completely different ball-game.

My personal experience is that anyone who asks the ‘what-can-I-do-to-become-a-project-manager’ question hardly ever asks the ‘what-can-I-do-to-become-a-good-project-manager’ question.

Yes, they manage to drive their way through their company politics and become leads and project managers but they never quite get good at it. During my career I've also noticed one common problem with this crowd of desperately-want-to-become-project-managers who want to rise above code and climb the golden ladder of 'management' and leadership.

The problem: They start doing too much to make their project successful as soon as they becomes what can be technically called a ‘manager’.

Give any of these guys a small project to manage and before you know it, they will start:

1. Making Gantt Chats and Project Plans.
2. Writing up a communication plan.
3. Following Up on Programmers to find out what the status is.
4. Sending Status Reports depicting progress in percentages.
5. Having a huge number of meetings every day.
6. Sucking up on their bosses.
7. Writing a lot of documents and making others write a lot of documents.
8. Going out of their way to slow down their team and make their life miserable by decreasing the general 'happiness factor' within the team.
9. Writing And Maintaining To-Do Lists for not just themselves but everyone else in the team.
10. Doing a whole lot of additional crap to pamper their own egos and justify their own existence.

If there’s anything I’ve personally learnt by being a part of a few successful failures and a lot of other successful projects it is that if there’s any list that you possibly need as a manager, it is not a To-Do List.

What you need is in-fact, is something that can be described as a “Not To-Do List”.

There you go; If you are a budding young manager, I just gave you a little trade secret. Seriously. You need a big fat list of things which you will 'not' do as a manager; If you are serious about this becoming-a-good-project-manager thing, start writing one; right now.

Here’s how you write a Not To-Do-List:

1. You take A Piece of Paper and something that you can write with like a pen or a pencil.
   (Or your could just open up a new blank Text File using Notepad)
2. You write down every single thing that you promise yourself you will try your best to “not do” as a manager.
3. You maintain the list religiously and stick to it as you move forward.

The best way to add items to this list is to look back on your days as a Junior engineer and try and recollect as many things you can about your managers back then that you hated. Other than that you can also watch every single thing you screw-up and every single screw-up that happens around you very closely.

Dissect each of these failures in your head and analyze them. Take every failed project and endeavor in your organization and analyze those, just like people listen to the black box after a plane crash. A wise man I worked with once told me that every failure is different. It has a story and that there’s usually something new to be learnt from each one of them. If you keep your eyes open you’ll realize that all projects failing can be broadly classified into two categories:

1. Incompetency of team members – which is why I’ve always said that it’s kick ass programmers who build projects; not Gantt charts.
2. A prick in the project team – if you investigate further, most investigations will reveal that this prick is often whom we glamorously proclaim and refer to as the Leader or The Project Manager.

This brings us to the soul of this post.

It's actually been a rather wordy post; and we're barely starting to touch the point I'm trying to make. If you've read so far, I saute you. If you haven't; all I’ve done with all these words is propose two simple ideas:

1. If you’re a manager you need a “not to-do list” which you list out things which you should not do as a manager.
2. Not Being a Prick is something that should top the list.

Not being a prick is so important; Michael Lopp uses the idea as an awesome starting point for his book Managing Humans. The book begins by describing how a single prick can destroy not just a project but an entire organization:

Flash back to the middle of the dot-com implosion. We, the merry crew of the failing startup, are drinking... a lot. There are various bars around corporate headquarters, and each has a distinct purpose. There’s the dive bar that’s great for post-layoff parties. The booze is cheap, and if you’re looking to blow off some I’m-really-not-worthless steam, you can pick a fight with the toothless sailor slung over the bar or the guy who just laid you off. Down the street is the English pub. The beer is better, they have a selection of whiskey, and they have edible food. This is where we get philosophical about the current organizational seizure we’re experiencing in our three-year slide toward irrelevancy. We’re there now. We’re drinking heavily because the company has just been sold to a no-name public company who will quickly dismantle the one for which we’ve bled. Everyone knew we’d be here at some point, but no one expected to be the last one standing. And no one expected the CEO to show up. This isn’t the CEO that built the company. He’s been gone for over a year. This is the guy the board of directors brought in to sell the startup. Sure, he tried to turn us around, but remember, we’re in the middle of a financial nuclear winter here. Money is no longer free. Those who got a glimpse of the CEO’s resume before he arrived knew the gig was up. His last four jobs ended in the company being finely sliced into nothingness. It’s called “maximizing shareholder value.” And here we are. Hammered on tequila, the last four from engineering, two guys from tech support... and the CEO. Even though we’re dizzy with booze, we’re fundamentally uncomfortable with the presence of our CEO because we consider him to be an unfeeling prick. And that’s it. That’s the title of my management book. Don’t Be a Prick.

Steve Yegge in his post on (Not) Managing Software Developers describes the one simple quality that differentiates a great manager from one that sucks:

However, I'll offer you one almost magical tip that can help you smooth over nearly any mistake, a tip that can get you through just about any bad situation. I'll tell you the tip right now, with no fanfare or ado. This hint is the most important one I'll offer you today. It's the secret ingredient to Great Manager Sauce. Unfortunately, it's not easy to learn. You either already understand it, down in your bones, or you have years of head-scratching ahead of you. The tip is just one word: Empathy. If you have true empathy for your engineers, they can forgive almost anything. Which is good, because you will make mistakes. We all do.

Recently an individual who is also a colleague and a close friend approached me informing me that he wanted to be a Manager because he was sick of coding and he thought it was time to grow professionally and stop being what he referred to as just-another-developer. He was thinking of moving over to project management and was thinking of becoming what he referred to as a project manager. My instant spontaneous reaction, in jest of course, had been that he'll never become a project manager. Even though it was a joke, It sounded like a really mean thing to say after I had said it; I wasn't politely articulate in explaining what I meant. Steve's post on the other hand, does a pretty good job at describing exactly what I meant:

If you want to manage badly enough, then you will manage, badly enough. Hence, before you jump in, stop and think about why you want it. Are you tired of engineering, or were you perhaps never very good at it? If so, technical management isn't much of an escape, because your engineers will know, and they won't respect you. Do you want to manage because you want authority? If so, it's a trap: you'll still be on a leash held by the folks above you. Or maybe you just want to be a little higher in the pecking order, so you can peck downhill? If so, then you're what we call, colloquially speaking, a "pecker". Think hard about why you want to be a manager.

If you haven’t clicked on the link to Steve’s post, click on it and read it word by word. I don’t care how long it is, do yourself a favor and read it. I'll post a link again so that you don't have to hurt your eyeballs looking for it - here you go - go ahead, click the link and read it. It's a great read. Honest.

Yes, after have worked your ass off to get promoted papering your ego feels like a natural thing to do now. In fact, chances are, that you may have already started or will soon start taking your first steps on the path of Prickdom but here’s my advice: Turn back; now; before it’s too late and the Prickdom gets embedded in your personality.

Resisting the temptation and disassociating yourself from it is what sets a veteran project manager apart from a want-to-be-never-going-to-be manager.

Of course, if you’re a manager, chances are that you’re making mistakes all the time. You’re probably making more mistakes than you can possibly think.  Really stupid ones. Your only glimmer of hope is that your team forgives your stupid mistakes and moves forward with you. Being a prick that they hate, doesn’t really help them in getting over every stupid mistake you have made in the past and moving ahead; with you. 

Going Forward, I’ll be posting more items for the Manager’s Not-To-Do List but Not Being a Prick is so important that it undoubtedly tops the list. In all probabilities it is also the most violated rule of project management.

Let's do a little exercise, shall we? List down all your bosses on a whiteboard or a piece of paper. Now stand back and take a long hard look and tell me; how many of them have acted like a prick during one or more occasions with you where if you had the power to fire them, the thought would have at-least cross your mind. Quite a few of them; right? Life sucks, doesn't it? But wait; there's hope.

Now look back at the names and realize how many of them have rarely done it and how many of them do it all the time.

The really good ones are the ones who realize they are being pricks, stop it, turn around and apologize. Very few, right? And chances are these are the ones you really respect. The kind you can hardly hear bad things about in a discussion with your co-workers and colleagues. For everyone else, you'll probably join in and take a kick out of the discussion.

The honest reality of life is that you'll find more managers with Prickdom infused in their personalities than you'll find managers who very rarely act like pricks. It goes without saying of-course that it would be really hard to find managers who never act like a prick.

That’s it my young-budding-baby-project-managers; that’s all I’ve got for you today. It’s been a rather wordy post but all I’m saying is that if you’re Managing Projects and working with (not managing) people, you need:

A Manager’s Not-To-Do List where Item one reads: Don’t Be a Prick.

If you still don’t get it, you’ll never be a manager; at-least not a good one; and not till the time you get a couple of tight symbolic slap on your face that makes you realize what we're talking about here. If you don't get it even when that happens, take the hint and stick to being a Know-Nothing Technical Director, an Arrogant Programmer, an Egoistic Business Analyst, a Bitchy QA Lead or whatever-it-is-you-are-good-at-being and spare us having to deal with another Pompous Manager who is basically a Prick.

On the other hand if you learn this lesson (even if you do it the hard way, by taking a few punches), try your best not to be a prick, and have first Not-To-do item in your manager's Not-To-Do list, implanted deep down in your head, your team will teach you everything else you ever need to know as you proceed, fail, stumble and make some really stupid mistakes while you lead them collectively through a highly successful projects or a highly successful organization. They'll stand by you through the thick and thin; as long as they know for sure that you're an not arrogant prick.

Start a Not-To-Do-List where the first item reads; Don't be a Prick. If this is one lesson you can learn like your life as a manager depends on it You’ll do good Mr. Manager; I wish you good luck.