free html hit counter
Posted on: Saturday, February 27, 2010 by Rajiv Popat

Productivity Tip: Avoiding The Zone Of Nothingness In Your Work Life.

During the development of Crux I was in the flow or as many would say, I was in the zone. focused and getting things done.  I was productive.

Being in the flow is an amazing feeling. You are working with one sighted focus. Without worrying about other problems of your life. You are consumed with a problem and you are in a state of mind where answers are flowing through you without a lot of conscious effort. You are learning effortlessly, you are stumbling across answers, you are productive and you are getting things done fast.

But then, there is another flow or zone that is often not discussed or talked about. Here is what that zone looks like:

You have a late night status call hangover, you struggle to reach office during mid-afternoon only to find a truckload of emails in your inbox. You browse them, give a reply to a few of them.

Very soon your phone starts ringing. It is the calls again. A couple of development teams want your time.

You promised Jack you will sit down with him, review that application he has been working on and give him ideas. A couple of developers are fighting over a stupid issue and you need to take them in a room and talk.

Time is flying again. You are busy. You are doing things which 'seem' important. You are juggling tasks, you are talking, you are supposedly giving a direction to the team and you are managing human beings. It feels like you are in the zone again.

There is only one problem however - you are getting nothing done.

You, dear reader, are in the zone of nothingness.

In fact, the zone of nothingness is not just a manager thing. It impacts programmers as much as it impacts managers. What Joel Spolsky describes in his article on fire and motion is a classic example of someone being in the zone of nothingness. Joel explains:

Sometimes I just can't get anything done.

Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn't happen.

These bouts of unproductiveness usually last for a day or two. But there have been times in my career as a developer when I went for weeks at a time without being able to get anything done. As they say, I'm not in flow. I'm not in the zone. I'm not anywhere.

The scary thing about this zone of nothingness however, is that much like the flow of productivity, even here, time flies faster than you think it does. There have been times in my life where I have snapped out of something that looks like flow, only to realize that I have wasted weeks and have been able to get nothing done.  As of today, If there is one thing that scares the heck out of me and depresses me more than anything else, it is the zone of nothingness.

Having said that, every now and then, even today, I see countless developers get stuck in the zone of nothingness and then desperately hoping and relying on their organizations to get them out of it.

If you are a young and budding developers or a manager, relying on your organization to keep you out of the zone of nothingness, chances are, that more often than not, you will be disappointed. If you are serious about not letting those hours whine away only to leave you with a weird guilt and hangover later, might I suggest that every time you find yourself in the zone of nothingness start by making your life as difficult as you can. You can start by:

  1. Committing to speak at a local developer conference that might be getting organized in your area next week or consider announcing that you will be conducting a training at your office.
  2. Committing to an open source project or a personal project like writing a book or a specific number of blog-posts a week and announcing this commitment live publicly. 
  3. Committing to organizing a community event and publishing the event date live.

There are countless other ways to shake yourself out of the zone of nothingness but the key here is to build an environment around you where you cannot help but jerk yourself out of the zone of nothingness.  A public announcement or promise of getting something done where you ego is at stake often does wonders at shaking you out of the zone of nothingness.

Next time you find yourself doing nothing and weeks are flying by, go ahead and make a public commitment of getting something done. Go put yourself on the spot. Chances are that you might be able to shake yourself out of the zone of nothingness and experience the amazing productive flow again.

I wish you good luck.

posted on Saturday, February 27, 2010 9:00:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, February 26, 2010 by Rajiv Popat

Learning From Austin Powers: Your Product Does Not Need More Features.

Jack sits on the other side of the table with a serious face and heavy eyes as he talks about how he has been trying everything under the sun to get management to care about his project. He is raising legitimate complains about his project not getting any love, attention or energy from the organization.

I play around with his product.

Brilliant idea.

Interesting execution.

Within minutes, I notice that his product has all the ingredients of becoming a successful product and yet it has received very little attention outside the small team working on the product.

I sit there and wonder why no one, other than the development team working on the product seems excited about the product? And then, it dawns on me. The project, dear reader, has lost it's Mojo.

Yes, that Mojo.

The team has been struggling for months now. They are being asked to build feature after feature when any technology savvy layman who might have laid his hand on the product would have told you that the product does not need new features. It needs, packaging, cleaning, simplifying, sophistication on the user interface front, a vibrant community, a free for use business model, adaption and an entire blooming eco-system around the product.

What the product manager aught to have done months ago is blown the whistle and asked the team to stop adding features the day they released their first sprint. They should have stopped the development of new features the moment they had enough features to constitute the soul of the product and they should have focused on adding things which would, in the words  in the words of Austin Powers, gives the product it's mojo.

Things that would make the product generate awe or put simply, things that would give the product it's appeal, get the casual website visitor to watch that product video and click the sign-up button. Things that would have got the management excited about the product and got the product the love it deserved.

Every year, I stumble upon countless engineers and startups spending hours, days and months building more features into their products by quietly working in their cubical, while they keep delaying the packaging, simplifying and garnishing of the product for what they call 'future sprints'.

If you are a young and budding startup working on a product or if you are a young and budding product manager pushing your team to build more and more amazing features into the product, here is my humble advice to you:

Work on the soul of the product and get the product an execution that goes justice to the initial vision or the idea of the product.

Once you have done that, stop your development and focus on the garnishing elements which will give the product it's mojo and differentiate it from the other half heartedly baked products out there. Those bigger fonts. classy design. Ajax driven screens and all the sophisticated packaging that you can get for the product.

Once that is done, ship and make just a little bit of noise about what you have shipped. Not a lot, but just enough for a few good mavens to find out what you were working on.

If you have a product with an interesting idea, a brilliant execution, a strong appeal and a few mavens are sold on your product, chances that your product will catch on. A feature here or a feature there does not matter. Now go focus on getting your product a mojo and then ship.

I wish you good luck.

posted on Friday, February 26, 2010 7:20:00 PM UTC by Rajiv Popat  #    Comments [1]
Posted on: Sunday, February 21, 2010 by Rajiv Popat

Avoiding The Typical Software Development World Stereotypes - Part 3.

During my early teens I found discotheques utterly confusing. If you found me at one, it was probably because friends dragged me in. Even if you were to find me in there chances were that you would find me seated in a table, scribbling a thought or two on a paper napkin and exchanging an idea admist the loud music.

For me discotheques were not fun. They were boring. Downright boring.

Then as I grew more social I cultivated a certain acceptance for discotheques and parties where people got drunk and sometimes created a ruckus. Put simply, I cultivated a persona that made me feel at home admits other drunk developers who were dancing like idiots to really loud music which made no sense. With age, my acceptance level for other people's definition of 'fun' increased.

As I entered my professional life, the number of these parties increased, the music got louder and drinks started flowing as I watched young and budding developers enjoy project parties and company picnics by getting soaked in alcohol, puke, throw up and sometimes even get into an occasional fight or two.

I still did not 'get it' but then I developed the maturity to accept it and have 'fun' watching developers getting drunk at parties and making a fool of themselves.

Even with all the growing up, the maturity and the acceptance of other people's way of having fun, there was a part of me that would often make me carry my laptop to some of these long-never-ending-parties and do a database design or write some code smack in the middle of some of these loud parties. For places where my laptop would not go, my windows mobile did the trick.

My laptop even accompanied me to most vacations.

Every once in a while however, I often stumble across a friend, a colleague or an acquaintance who sees me checking or responding to my emails in the middle of these parties or a vacation and gently advices me that I should not work so hard and in their very own words, I should 'enjoy' life a little more.

Seth Godin in one of his books describes one such vacation of his, where he is answering his email in the middle of the night and stumbles across a couple who feels 'sad' that Seth is checking his email in the middle of a vacation. Seth provides an interesting perspective about the topic in his book. He explains:

It was 4 a.m. and I can't sleep. So I'm sitting in the lobby of a hotel in Jamaica, checking my email.

A couple walks by, obviously on their way to bed, .... The woman looks over me and, in a harsh whisper a little quieter than a yell, says to her friend, "Isn't that sad? That guy comes here on vacation and he's stuck checking his email. He can't even enjoy his two weeks off."

I think the real question - the one they probably wouldn't want to answer - was, "Isn't it sad that we have a job where we spend 2 weeks avoiding the stuff we have to do 50 weeks a year?"

It took me a long time to figure out why I was so happy to be checking my email in the middle of the night.

It had to do with passion.

Other than sleeping, there was nothing I'd rather have been doing in that moment - because I'm lucky enough to have a job where I get to make change happen.

The words belong to Seth Godin, but if I had to own the above words and defend every single word above like it was said through my mouth, I would.

Seth is not alone in working during weekends and vacations however. Jeff Atwood at coding-horror has similar opinions and so does Donald Trump.

By quoting these individuals and by giving you a new perspective to look at this problem; I am, by no means, suggesting that you stop taking your vacations or do not go to parties. Neither am I nudging you to take your laptop with you everywhere you go.

All I am trying to do, dear reader, is stimulate your mind and leave you with the thought, that maybe, checking your email on your blackberry or widows mobile smack in the middle of a loud party, can be just as much (at times even much more) 'fun' as moving your hips and doing an insane dance with totally drunk individuals.

If you don't enjoy checking your emails and need long frequent vacations or a truck load of alcohol to forget about work that you have to do for the entire year, maybe you are not passionately connected to your work and should consider alternate options or professions which would keep you happy throughout the year.

After all, this work stuff is supposed to be fun through out the year; not random pseudo fun created by loud music and alcohol flowing like water.

So if you are a young and budding developer working with me, the next time you see me dancing for five minutes at a party and getting back to scanning through my email on a phone or starting a conversation on software development with an acquaintance or another colleague, please do realize that by indulging in the stupid dance for five minutes I am acknowledging my acceptance for your idea of 'fun'.

I am also hoping that you too accept my idea of 'fun' by letting me work and realizing that I 'enjoy' working on software development and writing about it as much as you enjoy getting drunk and moving your hands and legs to loud music.

Peace.

posted on Sunday, February 21, 2010 10:45:40 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, February 20, 2010 by Rajiv Popat

Soul Searching Question For Managers: Why Do You Want Manage Your Team?

I am in a conversation with a young and budding manager who has recently been promoted. He has inherited a young team of programmers and a couple of database administrators. He begins his discussion around what is wrong with his new team and how he plans on fixing things.

I cringe.

Besides not realizing the fact that the basic traits of human beings do not change, this budding manager has taken his first tiny step to becoming a micro-manager and a dictator both rolled into one.

The problem that is causing this otherwise wise and experienced programmer to not see the big picture as he takes his first step in leadership can be described in one word: Power.

A quest for power, disguised under multiple excuses (the whole I-want-to-help-people-grow being one of them) remains one of the primary reason which attracts people towards management. Steve Yegge describes this problem in his legendary post on Not Managing Programmers where he believes that most managers consciously choose the management route to purely fulfill their unrelenting quest for power. He explains:

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. I've worked with a hundred managers with a hundred different motivations, and all of the underlying reasons, including my own, seem suspicious to me now. Especially now that I work for a company that works, and well, with almost no managers or management overhead. Now that I've seen it working, I question the motivations of anyone who wants to manage.

I'm suspicious of all the mother-hen types: they want to nurture their teams, but tend to smother them. And I'm suspicious of the overly-organized types: they want to bring process to chaos, but process stifles invention, and it can be used to disguise incompetence for an entire career.

I'm suspicious of empire builders; too often they lower their hiring bar. I've heard or seen a hundred reasons for becoming a manager, and I now view all of them with suspicion, because each reason is a potential psychological problem waiting to manifest itself on a soon-to-be-unhappy engineering team.

The point that Steve Yegge makes in the rather long winded post is simple: why you want to become a manager or leader will ultimately define how good a manager you become. More often than not if quest for power is the primary reason that motivates you to become a manager or a leader, chances are that the same reason will start messing up your mind as soon as you get take your first couple of promotions.

I have spent years watching young and budding managers get very excited about their promotion, desperately trying to take control and trying to fix everything that they believe is a wrong in their team. Some of them claiming that they are putting their teams under pressure and trying to bring out the best in them while others claiming that they are working for the best interest of the organization. In most cases however, all they are doing, is satisfying their quest for power.

Put simply, I have seen the quest for insanely insignificant perception of power, corrupt and confuse some of the brightest of the minds that I have worked with.

Today, I leave you, dear reader, a thought worth harping on from Steve's post:

The catch-22 of software management is that the ones who want it most are usually the worst at it. Some people, for worse or for worst, want to be managers because it gives them power over their peers. There's nothing good that can come of this arrangement: you should never give power to someone who craves it, for reasons that I hope are obvious.

If you are a young and budding manager who has just inherited a team and has started out by noticing everything that is wrong with your team or building plans on fixing everything in the next couple of weeks by throwing your new team in an instance pressure environment, I want you to take a long hard pause, do some soul searching and answer the million dollar question:

Why do you want to manage your team, dear reader? Is it really because you want to help, or do you really want to quench your unrelenting thirst for power?

How you answer this question will ultimately decide how you do as a manager. Before you start fixing everything that is wrong in your team, spend some time doing some serious soul searching and find your answer honest answer to this question. If your answer to this question is that you do not want to manage your team at all, chances are, that you will be rather good manager.

I wish you good luck.

posted on Saturday, February 20, 2010 9:05:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, February 19, 2010 by Rajiv Popat

Leadership Tip: Avoiding Generic Whining Within Your Organization.

Early Monday morning you see Fred approaching your cubical with a usual highly depressed Marvin like look on his face.

You can read his body language and why he is approaching your cubical.

You cringe.

You secretly wish there was something that would make him go away.

Within moments you find yourself listening to sentences which begin with words like we-do-not-have or we-need-to. Every single one of those sentences seems like gibberish to you.

We do not have documentation for all the development scenarios. We need more use-cases. We need a detail design document. We do not have a detailed process. Fred continues and if you spend enough time with Fred you actually start getting convinced about how pathetic both you and your organization are. Fred is depressed and much like Marvin he tends to spread his depression through constant whining, bitching and moaning.

Then it dawns unto you. The realization that Fred is not a bad guy after all. He means no harm. He has just realized that he is not very competent and is having a problem reconciling himself with that fact.  When this happens, it is usually easier to criticize an organization or a 'process' because, well at-lease you are not criticizing a particular human being capable of defending himself.

This, dear reader, is precisely what Fred is doing by criticizing the process or the organization. 

Put simply, Fred, has freaked out. Like a cornered cat, Fred is not looking for a convenient excuse full of complicated jargon where he can burry his incompetence.

Allow him to do that or get away with it and you are setting your precedents loud and clear.

Go ahead, take a deep breadth. Look Fred in the eye and ask him to discuss specific problems connected to the process or people and how to fix them rather than making wide generic statements on a truck load of universal problems. Put simply, ask  Fred to stop whining and start delivering.

I wish you good luck.

posted on Friday, February 19, 2010 8:47:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, February 14, 2010 by Rajiv Popat

Entrepreneurship Tip: You Do Not Find A Genuine Idea. It Finds You.

In any given year, I get proposals for working on at-least one and sometimes even more than one business idea someone has cooked up. You are sitting with a casual business acquaintance, a sort of a weak tie who introduces you to someone who has been trying to launch a startup. It begins with chit-chat. What I like to call meaningful small talk.

He shares his idea, you tell him why it will not work, he tells you how much he has thought about it, you tell him how he has not thought shit (of course you do this politely). The next thing that happens is you find yourself scribbling things on paper napkins in a restaurant and then you are called for another cup of coffee on the weekend that follows to brainstorm further.

A couple of whiteboard discussion later, people expect you to jump in and get on-board. I don't mean get on-board in an intellectual-exercise-for-the-brain way. I mean get on-board in a get-paid-and-start-working-on-the-project-during-the-weekend way. But what the young and budding entrepreneur does not understand, is that you are not in a committed relationship with the idea. You are just flirting with the idea. I do it all the time.

I like flirting with ideas, stimulating my brain with them. But then, I have serious commitment issues as far as ideas are concerned. So I leave the idea alone and after about a couple of months of no touch, no connection, my relationship with the idea comes to a painful halt. 

That, dear reader, is my typical idea love story.

At any given day my brain is looking at three or more different ideas, flirting with a couple of them for more than a day and then moving on.

These are not the ideas that will make you fall in love with them. These are not the ideas that will keep you up all night. These are not the ideas that will, for lack of a better word, f@#k up your brain and make you slog for hours at the machine. These are not the ideas that will make you give up whatever little personal life you have left on weekends. The ideas that can do all of these are exactly the kind of ideas and projects I love working on.

The problem with genuine ideas that have the potential of making you do all of this, is that no matter how hard you try or for how long you brainstorm on a whiteboard with your weak-ties, you cannot find them.

To put things more specifically, when the time is right, these ideas, find you.

It is a subtle sublime inspiration or incident that brings this idea into your life. You see something drastically wrong with the way the world works and you see how the idea can help you fix it. The idea keeps you up all night. You spend a couple of hours thinking about it. Then you bring up your IDE and code just a couple of screens. A prototype, that would sit there on your machine for weeks as you get busy with your work life.

The difference between this idea and the one you are flirting with, is that you just find yourself opening the IDE and adding just a little bit of code on this project every time you get some free time.

This is not causal flirting. You cannot seem to move on. You keep coming back to the IDE and you keep adding just a couple of functions each day.

Before you know it, you get hooked. Committed. Stuck.

You, dear reader, are in love with the idea.

You have found the idea or to put things slightly more specifically, the idea has found you.

You have no intentions of making money out of the idea, no intentions looking for venture capitalists and turning it into a Google. In fact, chances are that you will not make any money out of the idea and that you are not on your way to becoming a Google either, but you have what we call, a project worth slogging on. A way to make a small dent in the large universe. Something that is fun to work on and a blank canvas where you can draw in bold colors.

If you are a 'practical' entrepreneur who talks about 'business model', 'revenue plans' and 'venture funding' you probably have no freaking idea of what I am talking about here. On the other hand however, if you ever fallen in love with an idea in your life you know exactly what I am talking about here.

What happened to that idea? Are you still slogging away at it during late nights and weekends?

If not, might I use today as an excuse to suggest that you dig from your hard disk, one such idea that had found you, fire up the IDE and just start adding a couple of functions to the project, again. We don't want you to change the universe, just make a dent or two on it. We don't want you to break up with your loved ideas. We want you to bring them to life. Show us what you can build through committed consistency and dedication.

I wish you good luck.

posted on Sunday, February 14, 2010 11:24:54 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Saturday, February 13, 2010 by Rajiv Popat

Leadership Tip: Encouraging Your Teams To Raise Red Flags.

I've always held the opinion that happy programmers are a true reflection of how well your project is going, how much adaption it will get and eventually how much money it will make. After all, it is the happiest programmers within your organization that often, show you the money.

If your programmers do not believe in what they are building and want to quit a project, your only chance of survival or getting that project close to any form of success is letting the unhappy individuals move to projects where they might be happier and getting people who might be more connected to the project, into the project.

If none of the programmers in your organization want to associate themselves with a project, it is high time you rethink what you are building. Maybe even consider closing down the project all together. Chances are, that a team working half heartedly on a project is just going to produce strong or mild variants of f@#k-you code and your project is not going to go anywhere anyways.

Having said that, citing 'Programmer Happiness' as a measure of how successful a project or an organization will be, often causes people to knit their brows and look at you like you just dropped a dead rat on the table.

People in general and organizations in particular that I have talked to, often tend to ask for slightly more objective measures and signs they can use to see if everything is fine at an organizational or a project level.

It is in the interest of a young and budding startups or relatively newer organizations that I present to you, dear reader, my very own personal guidelines on when you should be nudging your team members to raise a red flag, stop working like programmed robots and bring the issue up, even if it involves indulging in what I call a skip.

At an Organizational Or Team Level It Is Time To Raise RED flag If:

  1. Your daily meetings or daily project calls are consistently crossing thirty minutes and your team is getting addicted to meetings.
  2. Your team is consistently staying late without being particularly excited, happy or passionately connected to the project.
  3. Your team is consistently doing regular grunt work, like pushing a build or fixing bugs, even on weekends.
  4. Your team is not taking any happy hours.
  5. Your team is being constantly asked to build features which are not really needed.
  6. Your team or you are confused about where your role stops and where the role of your manager begins.
  7. Your team is facing constant intimidation from a client or a manager.
  8. Your team is allocated tasks with concrete timelines without having any involvement or say in those timelines.

At a Development Level It Is Time To Raise A RED flag if:

  1. Your team has parts of the project or the database which are not being checked into the source control system.
  2. Your team crosses more than a month and a half without shipping any new sprint or any new features.
  3. Your team works on and ships more than three sprints without any real feedback from a real beta user.
  4. Your team consistently writes functions that do not fit a screen. 
  5. Your list of 'Active Critical Bugs' consistently shows a scroll bar and does not fit in a screen.
  6. Your project requires a developer to carry out more than ten manual steps to get the source control system, set it up and fire a build.
  7. Your team tends to have an alpha-geek who often decides all critical design decisions with very little scope for discussion or argument.

The list of course is very basic and will grow over time. In fact, this is where I expect you, dear reader, to throw in some comments.  If you, are a manager running multiple projects or an entrepreneur running an organization which RED flags would you want your team members to bring to your notice as soon as they happen? If you are a developer which RED flags would you like to raise as soon as they happen?

Go ahead, drop in your comments. Discuss.

posted on Saturday, February 13, 2010 11:09:05 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, February 12, 2010 by Rajiv Popat

Programmer Tip: Thinking About What Works For 'You' Or 'Your' Team.

In a blog-post on your your code being a one way time machine, David Robbins identifies a special enemy from the past that can do you more harm than anyone else: yourself.

David explains:

What type of duress are you under?  The unfortunate among us have been sentenced to slavery by our evil nemesis from the past.  We all have this enemy, and at one time or another have succumbed to the enemy‚Äôs evil plot.  The enemy from the past is 'you'.

A huge part of your life as a software development is all about making decisions. How much code do you really need, how much time are you spending on thinking about your functions, do you need to start extracting till you drop or for now are you just going to ship a shitty version with bugs and get better over time. Every decision that you take will define your relationship with the you-from-future.

To be honest, most of these decisions are simple pragmatic decisions based on common sense and yet year after year I see developers building software and projects which are nothing less than Frankensteins. I see young and budding developers letting their desire to flex their engineering mussels guide the platforms or technologies they pick and not even bothering to fix broken windows as the speed along their career highway.

You primary responsibility as a developer is not to build a highly scalable enterprise application or to work on that really complex software development project. Your only true moral responsibility as a developer is to be reasonably good to the you from future and not sentence him through a painful infinite loop of failure

The more time and effort you invest in being honestly nice to the-you-from-future, the more at peace you will be with your greatest enemy from the past when the future arrives. Now go spend time and conscious effort in being nice to the you from tomorrow. Try keeping that patterns and practices book or that coolest data access framework on the block aside for one moment and take a few pragmatic decisions that will work for 'you'.

The you-from-future might actually thank you for it.

I wish you good luck.

posted on Friday, February 12, 2010 7:21:00 PM UTC by Rajiv Popat  #    Comments [1]