free html hit counter
Posted on: Saturday, January 16, 2010 by Rajiv Popat

Programmer Tip: Have The Spine To Question Authority (And Your Manager).

Jack has been going around in circles. He is asking me about how I designed that logger in a project that I worked on two years ago. His team is working on a logger and he seems to need some advice. The programmer in me is alive, jumping at the whiteboard and drawing lines with wild vigor explaining the design that was used a couple of years ago and did wonders for us. After listening for sometime Jack breaks the news.

The design I am explaining on the whiteboard is pretty similar to what Jack already had in mind.

But then, there seems to be a problem.

His manager, is going a different route. An approach that Jack knows will not work. Things are bad. The team has already started working using the manager's approach. Jack, is not seeking the programmer in me for help, he is seeking the bullshit buster in me to chime in and talk to his manager. Jack is seeking my help to stop the entire team from moving in the wrong direction.

What started as a discussion around angular brackets of XML has turned into a discussion of confronting the issue and saying 'no' to things that you do not agree to.

My advice to Jack is simple. Instead of talking to his manager, I gently nudge Jack to have that conversation. I nudge Jack to tell his manager that his manager's decision is not correct.

The advice is supposed to have to good effects.

First thing it is supposed to do is help Jack develop a stronger spine and become an individual who is not just capable of having an opinion but standing by it too.

The other really important thing that the advice is supposed to do, is to help Jack's manager from, as Michael Lopp, in his book, Managing Humans, would say, 'Losing it'.  Michael  uses his book to explain:

Losing It.

Managers don’t lose it simply because the pixies showed up with the top hat, they lose it because those they work with forget to look at the back of the hat.

Front: I'm the boss.
Back: ... For now.

Management is a myth, just like the top hat. We, as employees, believe it’s there, so we treat these management types differently. We operate under the assumption that they are the ones who can make decisions.

When the team is stuck on a hard problem, we gather in our manager’s office, present our case, and then the manager nods and says, “Go that way!” More often than not, we’re so happy to be past the hard problem, we don’t even question whether it’s the right decision or not. “He’s got the top hat, so he must be right!”

No no no no. Also? No.

Managers lose it when they are no longer questioned in their decisions. When the team stops questioning authority, the manager slowly starts to believe that his decisions are always good, and while it feels great to be right all the time, it’s statistically impossible.

The most experienced managers in the world make horribly bad decisions all the time. The good ones have learned how to recover from their decisions with dignity, but more importantly, with
help from the team.

Saying no forces an idea to defend itself with facts. It forces a manager under the influence of his top hat to stop and think. Yes, I know that top hat can be intimidating, and yeah, he’s the guy who signs the checks, but each time you allow your manager to charge forward with unchecked blind enthusiasm, you only reinforce his perception that he’s never wrong. That’s a ticket straight to Crazy Town.

If you are a young and budding engineer reading this and if there is one advice I can give you today, it is that you develop a strong spine to constantly ask - why -  and question authority. Even if that means questioning decisions your manager might be taking.

If you believe your manager is taking a wrong decision, go take him for a cup of coffee and ask him to explain his rationale behind his decision.

If his explanations do not make sense, have the spine to say 'no'.

I wrap this post up, dear reader, with an answer to the question Jack asks me when I give him the advice of directly talking to his manager instead of routing it through me. 'What if he feels bad about me questioning him?' - Jack asks.

My answer to the question, dear reader, is a rather simple and direct response- 'That is his problem, not yours'.

What I want you to do dear reader, is look around you. Do you see something wrong? Something that you are doing just because someone higher up in the pecking order or your manager asked you to do it and doing it does not make any sense to you?

Maybe it is time to question authority - not just for your own sake but even for the sake of helping your manager from 'losing it'.

Now give up your mitigated speech and go have that direct discussion that you were so scared to have. Go and gently remind your manager that you think he is taking a wrong decision, and do not stop nudging him gently till either you are convinced he is right or till he changes his decision.

I wish you good luck.

posted on Saturday, January 16, 2010 10:27:15 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Friday, January 15, 2010 by Rajiv Popat

Programmer Tip: Start Re-Investing In Yourself Consistently.

Jack has been on my team for months. Besides being a kickass programmer fresh out of college, Jack is also a gadget freak. From the latest iPhone to the coolest iPod, Jack owns it all.

In a casual discussion on why Jack has not yet bought a domain name or a website yet where he can blog, he responds with a grin on his face, that he is, as he likes to say in situations like these, running seriously low on funds.

I cringe.

Of all the programmers I have worked with, when it comes to spending money, I have come across only two kinds - the kind that sees their career from a passionate entrepreneurial mindset and the kind that does not.

If you fall in the first category, before you grab a fancy-car or a sexy-motor-cycle, a decent part of your paycheck is automatically re-invested towards becoming a better programmer or a better individual. You probably invest in books, own multiple domains, buy tools which improve your productivity as a programmer, enroll for classes or sign up for seminars.

If you fall in the second category, you probably have a dozen excuses on why you do not need to buy your own domain or attend that programming class. If you fall in this category, you are probably also really good at convincing and telling yourself why you need that new car.

A good programmer is difficult to come across. A good programmer, spending time, effort and money to get better at the craft of building software is a rather rare phenomenon. This rare breed, that once walked planet earth and spent their pocket money to play with Altairs because they were passionate about programming these machines, is fast moving towards extinction.

Observe the young and budding programmers you work with and you might easily stumble upon way too programmers who shell out a truck load of money to buy the latest-slick-looking-phone out there, but are totally hesitant while enrolling for a programming class, buying a book on programming or getting their own domain.

Like it or not, programming, dear reader, is a profession which demands that you re-invest a part of what you earn in yourself. If you hesitate in doing so, you are no different than organizations that invest in their buildings much more than they invest in their employees.

Go ahead. This month, buy a few books, enroll in a class, upgrade your internet bandwidth, buy a domain name, try to do a small business venture or just buy a couple of refactoring tools like Resharper and Code-Rush.

Put simply, let this be a month where you begin setting aside some money that you will consciously spend on getting better at the craft of building software and becoming a better individual. Then do it consistently, month after month.

I wish you good luck.

posted on Friday, January 15, 2010 10:36:00 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Sunday, January 10, 2010 by Rajiv Popat

Innovation Tip: Keep Fooling Around Like A Child And Keep Looking For Bird Poop.

Every time I sit down in a meeting where ideas for the next generation of software products are thrown on the whiteboard, I cringe. Something seems fundamentally wrong about the image of a team of nerdy scientists, coming together in a dimly lit meeting room, to conceive and implement ideas which change the world.

Nassim Nicholas Taleb in his thought provoking book, The Black Swan challenges this whole idea and introduces the idea of serendipitous discoveries. He explains:

If you think that the inventions we see around us came from someone sitting in a cubicle and concocting them according to a timetable, think again: almost everything of the moment is the product of serendipity. The term serendipity was coined in a letter by the writer Hugh Walpole, who derived it from a fairy tale, "The Three Princes of Serendip."

These princes "were always making discoveries by accident or sagacity, of things which they were not in quest of."

In other words, you find something you are not looking for and it changes the world, while wondering after its discovery why it "took so long" to arrive at something so obvious. No journalist was present when  the wheel was invented, but I am ready to bet that people did not just embark on the project of inventing the wheel (that main engine of growth) and then complete it according to a timetable. Likewise with most inventions.

Take this dramatic example of a serendipitous discovery. Alexander Fleming was cleaning up his laboratory when he found that pénicillium mold had contaminated one of his old experiments. He thus happened upon the antibacterial properties of penicillin, the reason many of us are alive today (including, as I said (earlier), myself, for typhoid fever is often fatal when untreated).

True, Fleming was looking for "something," but the actual discovery was simply serendipitous. Furthermore, while in hindsight the discovery appears momentous, it took a very long time for health officials to realize the importance of what they had on their hands. Even Fleming lost faith in the idea before it was subsequently revived.

In 1965 two radio astronomists at Bell Labs in New Jersey who were mounting a large antenna were bothered by a background noise, a hiss, like the static that you hear when you have bad reception.

The noise could not be eradicated—even after they cleaned the bird excrement out of the dish, since they were convinced that bird poop was behind the noise. It took a while for them to figure out that what they were hearing was the trace of the birth of the universe, the cosmic background microwave radiation. This discovery revived the big bang theory, a languishing idea that was posited by earlier researchers.

If you think on the lines of Taleb, every innovation in the field of computer science, ranging from the creation of MS-Dos to the building of twitter, does seem like a serendipitous discovery with only one a few things in common:

  1. Their builders were playing around with technology and were involved with projects which were nothing more than what can otherwise be described as 'fun projects' when, as a matter of chance, they bumped into something which was capable of taking a life of its own.
  2. They were not afraid to fail - as a matter of fact, they failed multiple times before the serendipitous innovation which set them apart from the other mere mortals that walk planet earth.
  3. When they bumped into a serendipitous discovery and saw what they had bumped into, they worked hard for years to turn it into a concrete implementation with a real existence. 

The next time you find yourself in a meeting where new ideas for changing the world of software development or redefining how people do business are being thrown on a whiteboard, remember this - the harder you try to desperately innovate ideas in a meeting room, the crappier your ideas will be.

Maybe you should just cancel the meeting and go for a walk. Maybe you should just get back to working on that side project and have fun like a child. Keep your eyes open and be on constant lookout for serendipitous discoveries that take a life of their own. Keep jabbing, keep opening your IDE, and always be on the lookout for bird-poop. When you find the idea worth chasing, work hard - consistently. Rest of it should just workout over time.

I wish you good luck.

posted on Sunday, January 10, 2010 11:31:27 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, January 9, 2010 by Rajiv Popat

Leadership Tip: Stick To Your Core Values And Pass Them On Across Teams.

You have hand-picked every single member in your team. Every single one of them is a fully competent one man army. When you ask them to do something, things get done.

Your organization is growing faster than you think. There is more work around than your team can possibly complete in years. You tell yourself that you need more people. More small teams like this one.

You scale up.

You hire more kickass programmers.

It is time. You ask your team members to step up, grow and lead their very own teams.

You continue working with your current team. Each of them now has their very own team which in turn is running a module or an entire project. All of these teams are highly effective and getting their job done.

You now have what they call - an organizational structure of self sustaining teams - in the management world.

Collectively, these teams are getting more done than you ever thought was possible.

You are living in a paradise.

Now unless you are seriously lucky, chances are, that you are going to snap out of your dream really fast.

It will happen when a young recruit you placed in one of these teams last year is going to walk up to you one fine morning and say in very clear words that his team culture is nowhere close to the culture you wanted to promote in your team. He might, for example, tell you that he is being micro-managed, bossed around or being pressured to work late three days a week.

It will hit you. Really hard. The realization that some of the core values that you worked really hard to push in your team may not be flowing through to rest of the organizational structure under it.

Jack is a very effective programmer. During his course of working with you, you developed strong respect for his talents and a strong friendship with him. You wanted to help him grow and hence the decision of letting him manage his own team. Now you have a young and budding engineer working under Jack telling you loud and clear that Jack, is not a very good manager or for that matter a very good leader.

Accepting that, dear reader, is going to be a painful reconciliation.

Confronting the issue and doing something about it is going to be even more painful. Your mind will trick you into telling yourself amazing stories in favor of Jack - Maybe his team members are bitching unnecessarily. Maybe he needs more time. His team is effective; maybe it is just the fact that his management style is different. His team is effective - he is getting things done - his team members will eventually get used to his working style.

Put simply, you can either confront the issue or tell yourself stories to avoid it.

What you are doing, dear reader is, making a choice. A choice between whether your organization will live by its core values that got it so far or it will grow big and lose its soul.

Go ahead, cut through to the bone. Confront the issue. Look at Jack in the eye and ask him to make a choice between passing on the core values, happiness and freedom that he receives from you, over to his team or stepping down and letting someone else lead.

That, dear reader, is your own chances at letting your organization retain the magical touch of being small as it grows and letting it retain its soul.

I wish you good luck.

posted on Saturday, January 9, 2010 10:06:27 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Friday, January 8, 2010 by Rajiv Popat

Avoiding The Typical Software Development World Stereotypes - Part 1.

Years ago, I find myself working for a huge Texas based client of ours. I have slowly and gradually become one of the star performers in a team of three. For reasons beyond my understanding, it is often being assumed that I am of French (or some other) origin.

It is somewhere bang in the middle of the project that a SOS request for help comes in from a connected project team that is working out of the same campus. When Fred walks up to a couple of other guys and me, seeking help with fixing and refactoring code he is rather articulate about how the code got this convoluted in the first place. He explains - 'They got some Indians to write this. Those Indian guys f@#cked it up. What else could you expect?'

I smile inwardly.

After spending some time, we have white boarded a solution and I find Fred thanking us for all our help in fixing the code. Without further adieu I decide to disclose my true identity using a friendly joke cracked with a simple as-a-matter-of-fact smile: 'So, the code that was fu@#ked up by a stupid Indian was fixed by another stupid Indian'. 

I stand there smiling while Fred experiences a long awkward silence as the news of my being an Indian slowly sinks into his head.

Fred apologies. Suddenly he acts like I have caught him scoring a foul.

I crack a joke about me knowing exactly how it feels to work with Indians. That lightens the situation instantly.

Then we talk about whether and movies. Soon life returns back to normal.

Years later I find myself writing about the incident and adding my very own fictional elements to it.

If you have been in the business of building software long enough and have worked in more than a couple of countries, chances are, that you might have pre-conceived notions and stereotypes about people from different countries.

Chimamanda Adichie describes the issues with this kind stereotyping in her TED talk on the danger of a single story. She explains:

Years later I thought about this when I left Nigeria to go a university, in the United States.

I was nineteen. My American roommate was shocked by me. She asked where I had learnt to speak English so well and was confused when I said that Nigeria happens to have English as its official language.

She asked if she could listen to what she called my 'tribal music' and was consequently very disappointed when I produced my tape of Mariah Carrey.

She assumed that I did not know how to use to a stove. What struck me was this - she had felt sorry for me even before she saw me; had a default position towards me as an African, was a kind of patronizing, well-meaning pity.

My roommate had a single story of Africa - A Single story of catastrophe. In this story there was no possibility of Africans being similar to her in any way. No possibility of feelings more complex than pity. No possibility of a connection as human equals.

The single story creates stereotypes and the problem with stereotypes is not that they are untrue but that they are incomplete. They make one story become the only story.

In my career, I have worked with people from Pakistan, Germany, England, Sri-Lanka and the US. If there is one thing I have learnt about people from different countries around the world, it is that smart people exist in every nook-and-corner of the world.

My approach towards classifying human beings is pretty similar thought approach Nassim Nicholas Taleb takes in his book The Black Swan. In his famous book, the black swan, Nassim describes his thought process on this topic. He explains:

This nationality business helps you make a great story and satisfies your hunger for ascription of causes.

It seems to be the dump site where all explanations go until one can ferret out a more obvious one (such as, say, some evolutionary argument that "makes sense").

Indeed, people tend to fool themselves with their self-narrative of "national identity," which, in a breakthrough paper in Science by sixty-five authors, was shown to be a total fiction.

("National traits" might be great for movies, they might help a lot with war, but they are Platonic notions that carry no empirical validity—yet, for example, both the English and the non-English erroneously believe in an English "national temperament.")

Empirically, sex, social class, and profession seem to be better predictors of someone's behavior than nationality (a male from Sweden resembles a male from Togo more than a female from Sweden; a philosopher from Peru resembles a philosopher from Scotland more than a janitor from Peru; and so on).

This post, dear reader, is not so much about an isolated incident of my life, or stereotypes connected with my being an Indian. This post, dear reader, is my humble attempt at gently nudging you, dear reader, to avoid all stereotypes in your life, as far as you can.

Software developers are not very good at communication.

Geeks are usually not into fitness or fashion.

All Indians are cheap bodies who write shitty code and suck at communication.

As programmers, we are surrounded by hundreds of these stereotypes and what I intend to do with this series of posts, is to blow up some of these stereotypes, expose exceptions, and bring to your notice, the fact that multiple sides of the story can exist.

Now, what I want you to do, dear reader, is to go out there, every once in a while, pick up any of of these stereotypes, challenge it and find out the truth for yourself. For it is only by challenging some of these stereotypes that you will find truly remarkable people, stories and results.

I wish you good luck.

posted on Friday, January 8, 2010 9:10:59 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Sunday, January 3, 2010 by Rajiv Popat

Programmer Tip: Do Not Waste Your Professional Trump Card On Funny Things.

Jack is at my desk; talking about how he deserves an additional seven percent salary hike over and above what his next month's appraisal promises him. He even has an offer letter from a different company to show me what his 'market value' is. It truly is just seven percent more than what Multiplitaxion Inc would have promised him in the next appraisal.

Jack really 'needs' that seven percent and he needs the seven percent now. He even has an offer letter to prove to me that he means business.

I file a request for a 'match' and escalate the request to what is often referred to as 'upper management'.

I am happy because I know the request might get accepted.

At the same time however; I feel deeply sorry for Jack deep down inside; because Jack just used his trump card for a measly seven percent salary hike.

For the first couple of years that you spend in an organization; you are basically warming up and developing deeper roots within the organization. You are understanding the culture chart of the organization; understanding what it will take to bring about changes. It is after these couple of years; that you wake up one fine morning and find out that people are listening to what you have to say.

This is when you start loving your organization and your organization starts loving you back.

Attached with this love is also the fear element of this relationship coming to an end. Your organization has a fear of losing you; and you dear; reader have a fear of losing your organization. 

This is when; you start realizing that people in your team and at times even folks in other teams are listening to you or looking up to you for help or advice. This is when you start making small changes to the organization.

Word of advice if you are going through this phase of your life: Slow down. Be careful.

This is by far the riskiest time of your career. This is when you learn that you as a young; budding and a rather valuable engineer have a trump card you can use.

Your resignation.

You know that it will send ripples down the organizational pond. This is when you will be tempted to do crazy things - like negotiate a seven percent hike on your salary based on offers from another organization.

Now here is another word of advice if you have been reading along and have been thinking of using your trump card: Don't.

The use of the trump card passes valuable information over to your organization. This is the kind of stuff folks people who run companies for instance; are on the look out for:

What drives you.

Your using the trump card for a simple salary percentage hike says out loud that the number on your paycheck drives you. I don't know about you; but if I was running a startup; I would be a little uncomfortable putting up with someone who is solely driven by the numbers on his paycheck so much so that he can quit for a seven percent salary hike.

What would it take to retain you.

You know the whole thing about love relationships that make them so desirable; it is the mystery of it. It involves working hard to getting to know the other person; spending time with the other person and learning what the other person really wants or does not want.

Now; all of this also applies to retention of employee. Your quitting for a small percentage of salary hike; yells out loud that retaining you in the organization is as easy as retaining a piece of furniture that can be bought from a local furniture store.

What are the changes that you can bring about.

Most organizations and entrepreneurs tend to look for leadership in people they want to promote and retain in the long term. Most entrepreneurs also realize that they need this leadership to spread their shared vision and to correct them if they start making mistakes or walking in the wrong direction.

If all that worries you every appraisal cycle is a seven percent salary hike for yourself; I personally; would not see you as someone who can be what I call a 'partner in crime'. An excellent employee; maybe; but not someone who can share a vision and work for the organization like it truly belongs to him.

With years spent in the organization; you get a truck load of responsibilities and a trump card that you; at all time; should try your best; not to use.

Remember; the lesser you use the trump card; the better off you will be.

And now; a final word of advice: forget that the trump card exist; and get back to work. If you continue using your trump card; chances are that things will never work out and you might never really exactly get what you wanted; but if you stop using it; forget that it exists; and focus on working towards growth; chances are that things might work out in the long run.

I wish you good luck.

posted on Sunday, January 3, 2010 10:11:01 PM UTC by Rajiv Popat  #    Comments [1]
Posted on: Saturday, January 2, 2010 by Rajiv Popat

Entrepreneurship Tip: Do Not Start 'Good News Wildfires' Using Your Wishful Thinking.

At Multiplitaxion Inc; people are optimistic about everything that they do. Jack; a programmer sitting across in his is silently and quietly celebrating the fact that the organization has signed up a new project. My problem; dear reader; is my knowing that we do not have a sign off from a client yet.

How did he learn about the new client; I ask him hesitantly.

His manager told him; I am told.

I cringe; then I decide to keep my gob shut.

As someone who leads teams of programmers there is something you need to know about both good-news and bad-news. They spread; within the corridors of the organization. They spread in an uncontrolled manner; pretty much like an organizational wild fire that is rather painful to stop once it starts spreading.

To add to that; most managers that I have seen around the globe seem to have another problem. It is a problem with transmission of messages. Messages often change drastically when they move from managers to programmers.

A classic example for instance is: we 'might' sign off a really huge project next week becomes we 'will' sign off a really huge project next week.

What this means is that getting Jack in a room and telling him about a new deal that Multiplitaxion Inc 'might' sign off; will often mean that you end up telling him about a new deal Multiplitaxion Inc 'will' sign off.

When you do that as a manager what you are doing is adding a lethal dose of optimism and starting a wildfire. If you are one lucky son of a gun; the sign off will happen next week and the wildfire of happiness you started will do no harm.

If however; you are like most of us mere mortals; in most cases Murphy's Law will kick in; which simply put; means that if something can go wrong; it will. It is then; that you might find yourself indulging in a painful firefighting exercise.

Spread wildfires of happiness with optimism a couple of times and you have lost all confidence that people who work with you had in you.

As individuals who lead a team and as human beings in general; we crave to become the bearer of good news.

Obviously you love spreading Happy wildfires; but before you do; think.

Are you adding unnecessary elements of optimism to these happy wildfires? Are you creating happy wildfires which you might have to bring to painful a painful halt in future? Are your happy wildfire based on genuine confirmed good-news or are there elements of your personal wishful thinking?

If your good news has elements of personal optimism and wishful thinking attached to it; you be better off waiting a while before you light the wildfire. Hold off lighting the fire till you have a confirmation of good news and till you know deep down inside that there are no elements of personal optimism and wishful thinking involved in lighting the wildfire of happiness.

I wish you good luck.

posted on Saturday, January 2, 2010 9:06:56 PM UTC by Rajiv Popat  #    Comments [3]
Posted on: Friday, January 1, 2010 by Rajiv Popat

Entrepreneurship Tip: Shipping Mediocre Products Is Not An Option.

Optimism. It is that thing that will sneak up from behind and will take your project down. No; Seriously. It is the thing that makes you believe that they care about what you are building. It is also what will make you believe that your idea or product rocks. That it will 'change the way people do business'.

Newsflash: No one cares about your product.

Second Newsflash: Your idea probably is not as good as you think you it is.

Third Newsflash: Your product will probably launch and perish like a slightly different low budget Hollywood movie that never made it to the big screens.

I have seen over a dozen software products take a nose-dive Microsoft Bob style - every single one with a single unifying theme tying the failure.

The director; vice-president; or someone high up in the pecking order; usually misses out on asking a simple question - What if you build it; flawlessly and the audience of millions you expected decides that it just does not want to show up; or what if the audience of one that you expect to pay for the product decides that the product idea itself is just not good enough to pay anything for?

If you are knitting your brow and wondering why I sound pessimistic and why that might happen to your product website or your product even when you pour your heart and long hours implementing an idea that you considered to be seriously kick-ass innovation of the year; allow me dear reader; to present my thought process to you with simple mathematical figures:

In one of the citations I read a couple of years ago; the average number of users for any given site on planet earth was quoted as two users. The numbers since then have increased substantially but the overall equation remains just as bad.

Number of websites on planet earth: 156,000,000

Number of people internet users: 1670000000

This dear reader; leaves you with around eleven users on your product website; system or blog. Build a website or a product that is 'decently good' or mediocre and an average traffic of eleven users is all you should expect.

For anything more than eleven you might have to move away from the realms of mediocrity and build something that is genuinely remarkable or helps people; not something that you 'think' is remarkable and definitely not just something that you 'think' will help people.

Go slow. Take small steps. Wrap up projects that are not going anywhere. Continue things that are working and push them harder.

Building mediocre products is just not an option; because mediocre products result in mediocre traffic and mediocre traffic of eleven users; on the software development world of today is so-not-exciting.

Now go build something that gets more than returning eleven users.

I wish you good luck.

posted on Friday, January 1, 2010 11:40:12 AM UTC by Rajiv Popat  #    Comments [0]