clog

It's like Batman would say,
It's not who I am underneath, but what I do that defines me

Joe (click the link to know more about Joe) would say it's not what i do at my desk, it's what I do while fetching my coffee that defines me.

I have seen Joe walking intently to fetch his coffee peering down at the cup or just to the restroom. It is no ordinary walk. To an untrained eye it may look like he is studying the coffee like a lot of people who read tea leaves. In reality his mind is busy doing calculations of unimaginable complexity. He probably is working out the price of his next multi-billion dollar acquisition

I have been told, however, that may be this isn't what Joe thinks during his walk. May be he is thinking about the expansion of the company. Like admiring the new chick he sees on his way to pantry. Or at times, he might be thinking about his next strategic move like whether he should go to pee on his way to pantry after all restroom won't be a really big detour. Well, he could do that but then where does he keep the cup? Oh, here comes Senior Joe, so that makes his decision easy. He decides to keep his line and say hello to him. OK, so its final, Joe decides to have the coffee and come back to pee, the coffee would add to the pressure making it a more fulfilling release.

Joe is great at keeping up appearances, in fact that's one of the few things he is good at. If not careful enough, he might create a first impression on you that you will live to regret.

Recently while I was attending a conference call I heard a name John Doe a couple of times. Same evening I was watching a movie where the name came up again. Coincidence? That's what I thought until a friend enlightened me the practice of referring unknown people (usually suspects) as John Doe or Jane Doe for reference.

I have been meaning to create a character for my blog especially the ones where I rant. My pet peeve all my life has been shitty Managers. It is always easy to deal with shitty developers since they can do limited damage. I was looking for a name for the guy (hope females won't be looking to be treated equally here) and I came up with Joe, an average manager just like an average Joe and then the first paragraph happened.

Combining the two of them, without any further ado, please welcome Joe Don, our average manager who by definition would be crappy. All things you dream of not becoming while you are growing up.

* This sounds like a real name though I don't know anyone by this name. I don't intend to mean any disrespect if a person with this name exists. If you are the one, and chance upon this blog and have objection, feel free to drop me a line and I can make amends.

Process is one of those holy grails or holy cows that are sacrosanct in software development not open to questioning. A question posed is enough to label a person heretic, rebel, bad influence or any such thing.

There are three fundamental parts to the execution of a project. The classic trio of people, process and tools/technology. Any failure can be attributed to one of them and fixed appropriately ensuring it doesn't repeat itself.

The most common response to a broken process, causing issues downstream, is an additional process introduced to check it. Seldom have I seen people looking at the real cause before applying the fix on the process part. Isn't that the part project managers love most.

The right way out would be to first analyze why the process was broken, adding a process to avoid breakage of another is a self serving cycle with no gain for anyone but the process itself.

The people part in this triangle can offset the other two, but not vice-versa. Hence, it is extremely important to identify people failures and then treat them as such. A process cannot offset for a person not doing his job right.

In most of the cases, adding processes to offset for incompetent people(team) ends up in a bureaucratic team. And an over-process environment _slows_ everything down giving an impression of number of mistakes going down. Processes become tools for assigning blames in case of failures rather than being tools to stop them.

If you ever face issues in this trio, fix the people issues first and rest will fall in place in time.

Some smart people want to seize every moment and every opportunity to show that they have a point, no matter how banal it is. They feel cheated if they are not the first one to correct someone on a very obvious mistake made. Like saying we will check this tomorrow on a Friday will get smart asses all worked up (assuming its not a working weekend). Hope you got the drift. Making a point is extremely important for them, even if almost everyone except imbeciles could have made it. The race is about being the first one to point it out. Also, in the process making a point becomes more important than making it count. That explains why meeting are considered an utter waste of time, because all the smart-asses end up making points in order to get heard not really focusing on making those points count.

So, the summary of this argument is that, if at the back of our minds, we can keep the objectives clear and focus on them, rather than focusing on getting yourself brownies, which are useless for the objective, all of us at the end should be better off. This is in line with the aphorism, that if people stop caring about who gets the credit, they will do much better as a team. And if you are working with good people, in the end they should be able to give everyone his/her deserved due. However, I am not entirely sure if this is a practical thing to do. It sounds quite Utopian thing to do and may work only if there is a cooperative (as in cooperative game theory) environment.

Things can turn ugly in places where things are really cut-throat and the benign ones might just end up getting all the flak at the end without getting any credit for good things they did. In a non-benign environment there is no single objective, there are objectives and invariably most of them are in conflict with each other, so this may not really work out. However, if the smartass is in a leadership capability, then to reach to a smarter level, (s)he needs to ensure the smart-asses in his(er) team (that includes him/her also) are free from this kind of competition and thinking.

In the end, someone has to think of the forest over trees, and that is the kind of fella I would like to be and work with.

(To know what is MSPM - Read the opening post here)

Here is the first of the list of things that I think smart people don't do well until they get smarter.

Most of the not-so-smart people are unstructured in their approach towards things, but not all unstructured people can be classified as not-so-smart. For, I know quite a few smart but haphazard people.

The smart ones tend to have a structure to everything they do, but sometimes they go overboard.

A particular example that comes to my mind is a module lead with whom I worked once. He was one of the better folks I have worked with so far in my career. However, his documents would only have numbered points and he wanted me to do the same. On one frustrated night at 2 AM, I made a comment, that if I remove the filter that controls the level of "table of contents", every single thing in this document will be in it. Is that how you intend it to be?

I am not taking it out against him here to prove I was right and he was wrong. But I felt he suffered from over-structure.

A lot of times I am accused of the same, it makes me feel happy and sad at the same time. Happy because I can classify myself as smart in my own post but then that rules me out for consideration as 'smarter'.

Most of the times, people are aware and tend to improve if their feedback loops are strong. So, the critical part that takes them from smart to smarter is being open to foreign opinion and internalize it's valid parts.

Never argue with a fool or he will drag you down to his level and beat you at it

I have seen 'leaders' whose only competence is to stick around in office infinitely. And if that is the case, the project is bound get screwed thereby generating the need for long (unproductive) hours. Once that happens, the environment is set for the losers to shine.

That's what losers do, they re-define winning as being losers, so its a win/win game for them and a lose/lose for non-losers.

* I have always avoided using word loser in my conversations/writings. I am using it here because it's just so casually powerful that it conveys how strongly I feel about this subject.

Camels are traitorous; they walk thousands of paces and never seem to tire. Then suddenly, they kneel and die. But horses tire bit by bit. You always know how much you can ask them, and when it is that they are about to die. -Paulo Coleho (The Alchemist)

I think I see horses and camels at my office all the time. There are silent killers who will drop dead one day and be gone. And then there are others who will keep showing dissent at regular intervals to keep you abreast of their low morale. Be careful to identify your camels and horses and handle them accordingly.

Its been around 10 months since I went to Delhi. The idea was to go to IITF. Well some trip it was, a pleasant surprise. Roads to and in Delhi are fantastic. There are all the right signs at all the right places (well almost). Things are in order as they should be everywhere. Well, that wasn't all that impressed me. The Metro, newest addition to Delhi is truly world class.

Thanks to Metro and a series of flyovers, almost all of Delhi now travels in air. Trade fair was fine, not that I was expecting a lot.

All in all, Delhi rocks!

Classifying colleagues has been one of my favorite activities. I can safely say the same for almost everyone around me. Here is an old one.

This time, my parameters are facts and logic. To elaborate, there will be people who can be trusted for their facts and those who can be trusted for their logic. Adding a layer of abstraction, you have people who can be trusted for their Information (fact). And there are people who can be trusted for their judgment (logic).

Using the quadrant theory, I have 4 categories:
I+J+: Industry movers(can fit anywhere, but will rise sooner than you think)
I-J+: Great Leaders (with good I+J- or I+J+ around)
I+J-: Great Workers (with any of the above around)
I-J-: :(

Where do you fit in?

http://www.inc.com/magazine/20071101/how-hard-could-it-be-five-easy-ways-to-fail.html?partner=fogcreek

"In grand scheme of things, small things matter because they are indicative of situations in which big things are being done" (said who? me, of course)

I will explain this with two examples that are close to my heart:

Code Quality: Listing down two very common issues that you will come across:
- Absence of documentation in code (Code comments or javadocs/interface definitions)
- Improper variable names

Apparently they have no impact on the code itself, but more often than not it describes the situation in which the code was written. There are multiple possibilities. Code written by a careless programmer with no constraints or written by a good programmer with time constraints and so on. And none of these are favorable.

Broken support System in an organization/project: Its easy to ignore small hiccups (just like punctuations) in support services, since they don't have much to do with the revenue collection directly. If you find yourself struggling to keep up your regular services at an acceptable level, there is a bigger problem to handle than just fixing those day to day issues. Its not about that one thing remaining incomplete, its about fostering an attitude; "its ok to have things incomplete". If overlooked, these things become a norm and end up destroying the culture.

The idea here is, to use small things as god sent warnings about bigger problems. They are the just the symptoms indicative of the actual (bigger) problem.

During my work I have often experienced that on tough projects, if things start going wrong, they very soon fall into a self propagating spiral. The spiral makes its causes stronger causing it to become more steep as it progresses.

Here is the scenario that is almost a norm in non performing teams or in teams with new members.

The work doesn't get done - The manager gets mad - Forces people to overwork - People get exhausted - they are not left with time and energy to learn - kills any chances of improving their skills to make them more efficient.

In the end the team spends the maximum possible time on their work but the amount that gets done is generally disproportionate to the effort and then the whole phase of apathy comes in when nobody cares about anything anymore. You just have people blaming each other for the situation (more commonly management v/s leads v/s developers).

So that was the problem part and I feel the whole responsibility for this should be taken by the management because they generally have greater power to change the situation. The biggest precondition for that to happen will be acknowledging the problem. Few points which I think would work and should be considered:
- One who has the power to change are the only ones who can be held responsible
- If a team is not performing, it is not team's fault. They are just in a wrong place
- Either improve them or remove them.
- Removal should happen only if there is no chance of growing people. If there are worthy candidates invest time to nurture them
- If the management cannot improve anything though they acknowledge the issue, they should step down/out
- If the management cannot improve anything and don't acknowledge the issue, they should be removed. There has to be someone who should be able to see the problem. If not, then the problem is probably not real

I am pretty sure the list is far from complete and it was never meant to be.