Great Essays

I browse the Internet a lot. I browse at office (when I should actually be working). I go home in the evening, have my dinner, and browse till late in the night. My browsing is not limited to a particular topic in any way. I browse on topics that interest me either at that point of time, or that have always interested me.

During such browsing periods, I sometimes come across articles that have me going, "Wow..!!" or, "Amazing...!! What a brilliant piece of writing!!" After my previous post, I was thinking on what to post next, when I realized I could have a post that linked to these essays - and also explain to readers why these essays were good enough to feature here.

As I listed the essays in my mind, I realized for an essay to be called a "great essay", I would have to set a bar. This is the bar I have set:

The article or essay must have
1) changed my thinking in some fundamental way (or),
2) must have opened up my mind to a different thought process, (or)
3) must have brought out what was in my mind all the while, but whose existence I had not 'realized', or was afraid to acknowledge.

With that bar set, I present before you these essays - essays that I term, "Great". A note here before we proceed: some of the essays are software development essays, so if you are not in that field or if you are not interested in software development, then you may not understand what makes those essays Great Essays.

Here we go!!


Usability for programmers (link)

Joel Spolsky's essay comes up first, simply because it was the first Great Essay that I read. This essay is software development related, but users of software may also relate to it; so I would actually recommend any software user to read it. Yes, at 9 pages, its a pretty long essay , but its worth reading. I say this essay is worth it even for non-software guys because the essay mainly deals with how to make an application easy to use. This means that the essay shows you examples of bad UI design that confuses users - something that non-software guys would readily empathize with. That is the reason why I recommend this essay to everybody who uses and creates software.

At the time I read this essay, I was working in a particular team in my previous company, and we used to share interesting links among ourselves. This team included the VP of the company I was working for. I was initially reluctant to share this link, as I knew my team-mates would shout me down for sending a 9-page essay, but after much dithering, I took the risk and sent it anyway. Next morning, when I checked my mail, I found a mail from the VP, that went like this:

"This is brilliant!! Must read for all!!!"

All day long, the VP looked at me and smiled with the realization that a bit had flipped over in his brain. I don't think he ever smiled at any of us like he did that day.

This essay was the one that introduced me to Joel Spolsky and I have learnt a lot from his essays ever since. From his website, I have got to know the Business on Software forum (where I got to know various aspects of business, as well as some different views of India and what people in other lands think of India) as well as StackOverflow.com (where I have come across some great questions, answers and links). It has been a great association with Joel so far.




Milgram experiment (link)
I generally read a lot of articles on Wikipedia. However, I am not sure how I stumbled upon this one. Guess it must have been while researching the various topics mentioned in Michael Crichton's novel, Sphere. In the novel, the main character performed experiments on the lines done by Asch and Milgram. Wanting to know who Asch and Milgram were and what was the significance of their experiments in the first place, I browsed Wikipedia and stumbled upon this one.

The article basically talks about an experiment conducted in 1961. We all know the horrors of the Holocaust during WW II. Yale University psychologist Stanley Milgram wanted to answer the question of whether people who commit such horrific, disturbing acts as those performed during the Holocaust were simply "following orders from above". Milgram devised this experiment to know whether ordinary people would commit acts against their conscience when prodded on to do so by a person in authority.

As I read through the article, I was nodding my head at every point, and when I finished reading it, I realized the impact of the experiment - I could very well be one of the 'teachers'!! Read the article to find out what I mean...!!

Staying on the topic of psychology experiments, do not miss the conformity experiments by Solomon Asch.



You and your research (link)

I have linked to the original article, but I actually read the article on Paul Graham's website.

This is actually a speech given by Richard Hamming at Bell Communications Research. Hamming was a mathematician involved in building telecommunications and computer systems. Hamming was brought in to Bell Labs so that he could program computers that would calculate the solutions to the equations that scientists working on the atomic bomb brought in.

Somehow Hamming hated this - he felt this was menial work, compared to the actual work of developing the bomb. He wanted to know why he was put in to do this work, when others were obviously working on the more exciting parts. He started to analyze what were the differences between him and the others; when someone achieved something great, he asked that person what made him do it, why, and wondered why others did not do the same. This led to some profound observations that are listed in this awesome essay.

Basically, the speech is about what one should do if one wants to do great research. By now if you are a person not associated with research in any way, you are probably thinking, "I am not associated with any research fields, so this essay is not for me". Actually, this isn't the case as Hamming himself says:

I will talk mainly about science because that is what I have studied. But so far as I know, and I've been told by others, much of what I say applies to many fields. Outstanding work is characterized very much the same way in most fields, but I will confine myself to science.

Yes, you might not understand few things in the essay if you are not part of the science & research fields or do not keep track of those fields, but I would still recommend this essay to you because its filled with great information and quotes on how to become great in your particular field - most of what Hamming talks about surely apply to your field and to you. Here's one example: most people believe you need luck to acheive greatness. There is also the belief that you need "lots of brains". Hamming takes the bull by the horns here:

...I find that the major objection is that people think great science is done by luck. It's all a matter of luck. Well, consider Einstein. Note how many different things he did that were good. Was it all luck? Wasn't it a little too repetitive? Consider Shannon. He didn't do just information theory. Several years before, he did some other good things and some which are still locked up in the security of cryptography. He did many good things.

You see again and again, that it is more than one thing from a good person. Once in a while a person does only one thing in his whole life, and we'll talk about that later, but a lot of times there is repetition. I claim that luck will not cover everything. And I will cite Pasteur who said, ``Luck favors the prepared mind.'' And I think that says it the way I believe it. There is indeed an element of luck, and no, there isn't. The prepared mind sooner or later finds something important and does it. So yes, it is luck. The particular thing you do is luck, but that you do something is not.

For example, when I came to Bell Labs, I shared an office for a while with Shannon. At the same time he was doing information theory, I was doing coding theory. It is suspicious that the two of us did it at the same place and at the same time - it was in the atmosphere. And you can say, "Yes, it was luck." On the other hand you can say, "But why of all the people in Bell Labs then were those the two who did it?" Yes, it is partly luck, and partly it is the prepared mind; but 'partly' is the other thing I'm going to talk about. So, although I'll come back several more times to luck, I want to dispose of this matter of luck as being the sole criterion whether you do great work or not. I claim you have some, but not total, control over it. And I will quote, finally, Newton on the matter. Newton said, "If others would think as hard as I did, then they would get similar results."

There it is - Luck favours the prepared mind and If others would think as hard as I did, then they would get similar results!! Who could have put it better than that? Yes, there is a certain amount of luck, but if you do your work diligently, always striving to improve yourself, your knowledge and the quality of your work, luck ceases to be a significant factor very soon.

There are other great quotes here. While on the topic of drive, Hamming says...

One day about three or four years after I joined, I discovered that John Tukey was slightly younger than I was. John was a genius and I clearly was not. Well I went storming into Bode's office and said, "How can anybody my age know as much as John Tukey does?" He leaned back in his chair, put his hands behind his head, grinned slightly, and said, "You would be surprised Hamming, how much you would know if you worked as hard as he did that many years." I simply slunk out of the office!

What Bode was saying was this: "Knowledge and productivity are like compound interest." Given two people of approximately the same ability and one person who works ten percent more than the other, the latter will more than twice outproduce the former. The more you know, the more you learn; the more you learn, the more you can do; the more you can do, the more the opportunity - it is very much like compound interest. I don't want to give you a rate, but it is a very high rate.

There are other great nuggets in this speech, which I shall leave it to you, the reader to enjoy. The gist of the essay is that you must ask yourself three questions to be great:

1) What are the important problems of your field?,
2) What important problems are you working on?, and
3) Why not?

Sadly, I sent this article to a friend of mine. This speech is a pretty long speech, and my friend immediately dismissed it, saying it was too long. In the process, she missed a great chance to improve her life by standing on Hamming's shoulders. Do not make that mistake - go on, read it!!



Good and bad procrastination (link)

I do procrastinate a lot and always felt guilty about it. All my life, I have been reprimanded by my parents for this. I thought I was the problem and tried a lot to change myself - I slightly did improve once I bought my cell phone and started storing my tasks in it. But the guilt remained, I guess. However, once I read the article's title, I was shocked - can there be any 'good' procrastination? But it turns out there is, as Paul Graham explains wonderfully.

Most people who write about procrastination write about how to cure it. But this is, strictly speaking, impossible. There are an infinite number of things you could be doing. No matter what you work on, you're not working on everything else. So the question is not how to avoid procrastination, but how to procrastinate well.

There are three variants of procrastination, depending on what you do instead of working on something: you could work on (a) nothing, (b) something less important, or (c) something more important.

That last type, I'd argue, is good procrastination.

Paul Graham says that procrastination isn't really bad - yes, you are putting off tasks, but as long as you are putting off unimportant tasks to work on more important ones, who cares? And that's the big difference here - when you procrastinate, there are two things happening: a) you are working on something, while b) the one you are supposed to work on lies unattended. What Paul Graham says is to ensure that the task you left unattended is less important than the task you are doing. When you procrastinate, ask yourself whether what you are doing now will give you much more benefits than the one you were supposed to do. If the answer is yes, then it is good procrastination - something you stand to benefit from, and hence don't have to feel guilty about.

Paul Graham also differentiates between errands and tasks. Any person has a never-ending stream of to-dos on his plate, but each one should learn to differentiate which of these to-dos are errands and which are tasks. (Here 'errands' are stuff that don't provide much benefits in the long term, while 'tasks' are stuff that provide benefits in the long term). Errands are small stuff, and hence its OK if we skip doing them. But how do we determine which is small stuff and which isn't? Here too Paul provides the answer...

What's "small stuff?" Roughly, work that has zero chance of being mentioned in your obituary. It's hard to say at the time what will turn out to be your best work (will it be your magnum opus on Sumerian temple architecture, or the detective thriller you wrote under a pseudonym?), but there's a whole class of tasks you can safely rule out: shaving, doing your laundry, cleaning the house, writing thank-you notes—anything that might be called an errand.

Good procrastination is avoiding errands to do real work.

Aha... tell me, which of the items in your to-do list right now would be mentioned in your obituary? Imagine your funeral - are people going to stand around and say, "He was such a good man - he used to shave regularly!!" No, they aren't - they are rather gonna list your achievements in life. For that, you should have done some real work - something they can say proudly at your funeral.

At this point, you are probably saying, "But not all errands can be ignored!! If I don't shave for two or three months, nobody around me is gonna like me!!" True, there are some errands that just cannot be ignored - these errands must be taken care of, but it may be ok to delay them by a day or two. Of course, there are other errands that can be safely skipped.

Note that there are other errands that simply cannot be skipped - for example, Paul describes an "absent-minded professor" who is so involved in solving a problem that he forgets to shave, eat or even look where he is going. Whenever, I think of such professors or scientists, who are so engaged in a problem, I also think of ignored wives. (I don't know why - hope I don't come across as sexist). In this case, an ideal scenario would be for the scientist to spend time with his wife, while still working dedicatedly at his research. Such kinds of errands require a balancing act, and one that comes with experience and understanding of the work you do and the persons you interact with. In my opinion, it would be better if we treated this as a task, rather than as an errand, since this does have ramifications in the long term.

Reading this article gave me a relief - it told me that there was nothing really wrong with me - procrastination wasn't really bad, as long as you learnt to use it to your advantage.




The Doomslayer (link)

I came upon this essay after reading Michael Crichton's novel, State of Fear. State of Fear basically says that in many cases, public concerns such as global warming are not really major concerns - rather they are fears generated by governments/institutions interested in keeping people under control and making them behave within certain limits. Thus, Crichton goes on to say, global warming could possibly be yet another fear and hence doesn't really deserve the attention that it currently gets.

This is disturbing - and I went on to the Internet to verify some facts stated in the novel and that's how I came across this article. This article deals with the same lesson that State of Fear tries to put forward - that certain issues are not really issues worthy of attention; they are rather, unfounded fears.

The article talks about how Julian Simon and Paul Ehrlich came to lay a bet between themselves. Julian Simon was a professor of business administration while Paul Ehrlich was an entemologist. In the 1970s, Ehrlich became popular by his work, The Population Bomb, that warned people that "famines of unbelievable proportions" would strike by 1975, "hundreds of millions of people" would starve to death in the 1970s and 80s, and that the world was "entering a genuine age of scarcity". The basis for these predictions was that the growth in the population is not matched by the growth in natural resources, which would evidently lead to an increase in prices, and making these resources inaccessible to most of the population.

Simon did not believe so, and very soon, the two laid a public bet - Simon asked Ehrlich to select any five raw materials, and select any date more than a year away. Simon believed that the prices on the future date would be less than the prices on the day of the bet, thus proving that raw materials would be more accessible and would not be affected by the burgeoning population.

Ehrlich took up the bet - he selected chromium, copper, nickel, tin and tungsten, and on paper bought $200 worth of each metal using the prices of Sep 10, 1980 as the index. The future date selected was Sep 10, 1990, a ten year period. During that period, the prices fell, with the result being that on Sep 10, 1990, Ehrlich sent Simon a cheque for the difference in price.

How could that be? As people use more and more resources, natural resources should
come down, right? After all, people can produce more of their kind, but natural resources cannot reproduce, so at one point, we should be hitting a limit, shouldn't we? In fact, the article asks this very same question...

After all, people are fruitful and they multiply but the stores of raw materials in the earth's crust certainly don't, so how can it be possible that, as the world's population doubles, the price of raw materials is cut in half?

And there is an explanation, as the article itself states...

It makes no sense. Yet it has happened. So there must be an explanation.

And there is: resources, for the most part, don't grow on trees. People produce them, they create them, whether it be food, factories, machines, new technologies, or stockpiles of mined, refined, and purified raw materials.

"Resources come out of people's minds more than out of the ground or air," says Simon. "Minds matter economically as much as or more than hands or mouths. Human beings create more than they use, on average. It had to be so, or we would be an extinct species."

The defect of the Malthusian models, superficially plausible but invariably wrong, is that they leave the human mind out of the equation. "These models simply do not comprehend key elements of people - the imaginative and creative."

On the Wikipedia article for this bet, a quote from Simon says that he concedes that increased usage of such resources does inevitably lead to increased prices - but they are only in the short term, since in the long term, people generally find out solutions to the problem.

More people, and increased income, cause resources to become more scarce in the short run. Heightened scarcity causes prices to rise. The higher prices present opportunity, and prompt inventors and entrepreneurs to search for solutions. Many fail in the search, at cost to themselves. But in a free society, solutions are eventually found. And in the long run the new developments leave us better off than if the problems had not arisen. That is, prices eventually become lower than before the increased scarcity occurred.

In case you are thinking that I have changed my views on global warming and other such concerns, no I haven't. But one thing that was new to me was the fact that I had never considered that problems such as the one put forward by Ehrlich were solvable - to me, once population began to increase, it was like it was the end of the road. I guess I am not the only one like this. It never crossed my brain that man's ingenuity would solve these problems.




IT Survivors - Staying alive in a software job (link)

In a particular company in which I worked, the project in which I was in rapidly turned from a sedate one into one where we were spending long hours at office. I used to come into office at 10am, only to leave at 2am or 3am the next day. The worst part was that the deadline for the project was initially stated as January, but later on extended onto February, then it became March, then May and so on... and during each of these months, we worked from 10am to 3am. I felt frustrated at the long hours, but the work was good, since this was my first experience in a software services co. as well as a big company, and I was being exposed to new methods and styles of working.

But family life suffered heavily, with my Mom one day picking up a newspaper article headlined, "Separate your work life from your home life", and pointing it at me, screamed, "This is for you!!" As such, I was hoping for a quick end to the project. One day, an opportunity to leave for another project presented itself, and I left to join the new project. But my mind didn't rest - it kept working on why there was a need for the horrid nature of my work hours during that period - and again, turned to the Internet for answers. I searched for answers as to why people put in long hours in software projects and I very soon started searching for why people manage software the way they did in my team, and one fine day, stumbled upon this article that aptly catches the reasons from a very high level.

First off, if you have read the breathless news reports that appeared when I was in school (and possibly still appear) about the IT field, you would have got the impression that nothing about the Indian IT industry can ever go wrong. In fact, if you tell anyone outside the IT industry that you work there, you can see that they are thinking: "Lucky guy! Wish I were in his shoes!!" (In fact, a medical professional who had come to our office for a presentation said, "You are IT guys. IT guys are intelligent people - you understand things fast..." (May not be his exact words, but they were to that effect). His assumption was that since we were IT guys, we would all have high IQs, we would grasp things immediately, and we were generally a cut above the members of the general population like him. This is the hype/respect around IT companies in India.)

To all you readers, if you have ever thought so, you will have to read this article. Note that all IT companies are like this - but if you have worked for sufficient time in the industry, then you know what Harshad Oak, the author, is talking about.

Because of the hype about IT companies, and also because of their contributions to India, many software developers generally do not talk about the conditions in such companies. Harshad hits the nail on the head when he says:

However I was avoiding writing this particular piece as it seems like an unpatriotic thing to do, to tell the world how bad the working conditions in software companies in India have become.

Yes, it does seem unpatriotic - just that I did not realize that patriotism has also leaked into this.

The reason why no one talks about is because the pay in such companies is generally higher than the pay anyone of the previous generation would have earned, when they retired. Hence the young guys assume that because they are being paid "unreasonably", there is nothing wrong in expecting unreasonable amount of work hours.

The software professional Indian is today making more money in a month than what his parents might have made in an year. Very often a 21 year old newbie software developer makes more money than his/her 55 year old father working in an old world business. Most of these youngsters are well aware of this gap and so work under an impression that they are being paid an unreasonable amount of money. They naturally equate unreasonable money with unreasonable amount of work.

Sadly, it does appear to be the way in which most software cos in India operate. This makes it hard to look around and switch cos - a reason why everybody seems to have accepted this as a way of life and started switching around for money. Software cos have also observed this, and seem to have started equating employee welfare with more salary. Harshad again hits here:

Top bosses of companies like Infosys, TCS, Wipro, etc. need to send the message loud and clear to their company and to other companies listening at national IT events that employee welfare is really their top concern and having good working culture and conditions is a priority. Employee welfare here does not mean giving the employee the salary he/she dreams of.

In A Field Guide to Developers, Joel Spolsky mentions that

If you start to hear complaints about salaries where you never heard them before, that’s usually a sign that people aren’t really loving their job. If potential new hires just won’t back down on their demands for outlandish salaries, you’re probably dealing with a case of people who are thinking, “Well, if it’s going to have to suck to go to work, at least I should be getting paid well.”

Sadly, in my belief, Indian IT companies have crossed that point long ago.



OK so...

Those were some essays that I felt deserved mention. You may or may not accept my list. In your opinion, there could be essays that are far better than the ones listed here - in such cases, do leave a link in the comments section and also a short explanation of why you consider these essays to be Great Essays. It would be nice if you could also list which of the above 3 criteria your essay satisfies to be called a Great Essay. Also, in case you do agree/do not agree with some points in my post, do comment!! In the meanwhile, I will leave you with links to three other essays that can also be considered Great Essays.

Why startups condense in America
Another essay from Paul Graham. He lists the reasons why Silicon Valley type environments are currently available only in the US and what it would take to replicate them elsewhere.

Why nerds are unpopular
An awesome essay that tries to answer the question of why geeky students are picked upon in school. Paul Graham goes into history to analyse the reasons why this occurs. Awesome!!

Toilets in Japan
Toilet - when you hear this word, you probably think, "What's there to speak about a toilet?" I thought the same too - I thought toilets were done; there was nothing that could be done to improve them, if anyone actually thought about improving them. Also, I had the belief that there could not be much technological advances in toilets - after all, its a toilet, what could there be in it? But this Wikipedia article opened my mind to the amazing toilets in Japan.

Sigh... why aren't such toilets available in India?

...but do products have domains?

This is with reference to my previous post, Do code generators have domains?

My IT career has spanned only 4 years, and I have worked for only 2 companies during this period, with the first being a software product company and the second a software services company. Since the work in the first company was developing a code-generator, I never heard the word 'domain' being uttered all through my time there. I heard it first only in the software services co.

Very naturally, I assumed 'domain' was a word that was used only in the software services industry. "Products can never have domains!!", my brain told me. "How could they? You saw it for yourself... company 1 never uttered that word!! Company 2 keeps saying it all the time!!"

Well, that was what I believed for a long time.. but my brain, being ever active ;-), seems to constantly verify whatever it believes against the real world. And very soon, it came up with exceptions!!


Products do have domains. The first example that strikes me when you talk to me about software products would be Microsoft Word. But that's not a very good example in this context, since almost every industry uses Word. I fail to think of one industry that doesn't use Word.

A good example would actually be something like the accounting package, Tally. Tally is a software product that is probably unheard of to people in the retail industry, while accountants using Tally are probably not much aware that there is a software called RayMedi RPOS in the retail industry.

This lack of awareness is because the tools target different domains. They are marketed only to people in the industry they target. Nobody's gonna market RayMedi RPOS to a company that provides accounting services. These products cater to the needs of specific industries (domains) and the people in those industries have probably never heard of those products that fall outside their industry.

Tally and RayMedi RPOS are examples of software products. They also target only certain domains. As such, they are examples of software products that do have domains.

Do code-generators have domains?

When I was doing my first job change, I was interviewed by the employees of a particular IT company. From their body language, I understood that the guys interviewing me were new to interviewing people. During the course of the interview, one of the guys asked me what I had done in my previous employment.

Now in my previous job (a software product company), I was involved in the support and development of a code-generator that generated web applications. Users would specify their requirements as pseudocode and our code-generator would generate the code in the language of the user's choice. We gave the users three choices in which he could generate the code: Java, Struts and .Net.

So I told the interviewer that I was involved in the development of a code-generator.

Interviewer: OK, in which domain?
Me: Domain?... (A few minutes of confused, frantic thoughts) What do you mean by domain?
Interviewer: Surely you must have worked in some domain!!

Actually, I hadn't even heard the word 'domain' before!! What were these guys talking about?

Me: Sorry... I don't know!!

The interviewers moved on to the next question.

But that question has stayed in my mind ever since. The company in which I later joined was a software services company, and a few months later, it slowly became clear to me what the interviewers had meant.


What is a domain?
In India, there are mostly only software services companies. There are software product companies, (I am not going to deny that), but what you hear more talked about are the services companies. These companies provide IT solutions to various clients. The client can be from any industry - manufacturing, health care, travel, etc. etc. Hence to provide better services to the clients, any IT company generally divides itself up based on the industries it is servicing.

So in effect, you find the IT services companies grouping the clients they are servicing into these divisions. As an example, let us take a fictional IT company. It has 3 clients - two make cars, while the third is a hotel chain. Thus, this fictional IT company would group the first two into its manufacturing division, while the third would be grouped into its hospitality division.

It is this concept of a 'division' that is given the name 'domain' by the IT industry. But why should they do this? Simple... so that they can provide better services!! A guy who was worked for a significant amount of time in a particular domain begins to understand its intricacies. This means he can provide better value to the clients.

So when a guy from another IT company interviews for your IT company, it is logical to ask him which domain he worked for. This is so that in case there is a vacancy in that particular domain, you can place him there. This would ensure that he continues his growth career-wise, while also ensuring that you reap the benefits of his knowledge!!


Unhappily...
Code generators don't fit the bill!! The main purpose of a code generator is to generate code. Given an input, it generates the output for it, and that's it. Hence, they can be used in any industry!! Nobody can mandate that a code-generator must be used only in the automotive industry, for example. It just cannot be done!!

And that is the reason why the interviewer shouldn't have asked me that question. Plainly said, it is foolish.

Repeat to yourself: Code generators do not belong to any particular domain!!!

Two new stuff...

...came by mail!!!



The first is the Ubuntu Desktop Live CD. I ordered this since I wanted to tinker with Linux and maybe, just maybe, learn more about working on it. Till now, I have tinkered with the Live CD only, but have plans of installing it on my computer alongside Windows. However, since my family members also use this computer, I guess they might not like the idea of a window asking them to select which OS to use when they start up the computer. Also, I am not sure whether my existing Internet connection will work with Ubuntu installed.

Put simply, all this means that I have not yet decided anything!!

The next one is the book, "My Job Went To India (And All I Got Was This Lousy Book!)" by Chad Fowler. I had heard of this book and wanted to know what was inside it. Of course, the book is targeted at Americans, but I bought it on the notion that there could be some tips that might be helpful to me too!! Will read the book and let you know!!

You need to think like the user

In software development, it is necessary to think of all the actions that the user would perform with your software. This is so that you can fix any bugs or inadvertent situations that might arise before it goes over to the user.

Software professionals refer to this as 'thinking-like-the-user'. Like Joel Spolsky says in this article, you need to create imaginary users in your brain and think of them exercising your software. This usually reveals scenarios that you might otherwise have never thought of. Personally, I have always striven to think like the user in all situations, whether I am writing a full-fledged application or just changing a block of code.

For the past few months, we have been maintaining some code written many years back. Recently, I found one 'bug' that illustrates what happens when you fail to think like the user. I have not taken screenshots of the application, but the screenshots you see below are similar.

We have a screen where the user can search for groups.


Now the Find Groups button lists all groups if the user does not enter anything in the text box. However, if he does enter something, then clicking the button lists all groups starting with that text.

Usually, I would just press the Enter button and move ahead. On this particular day, I used the mouse to click on the button.

And I got this...



I analyzed the code to see what the developer had done. Here it was:

<script>
function validateIt() {
//If the value entered is of zero length, then show an alert message.
}
</script>

Then a few lines down....

<html:form action="some.do">
<html:submit value = "Find Group" onclick="javascript:validateIt();"/>
</html:form>

So basically the developer had written a script to validate the text entered by the user in the field. This would fire when the user clicked the button. But the control which fires this event is a submit button, which can be activated by pressing the Enter key. However doing so does not fire this script - for that to happen, you would have to write an onsubmit event handler.

So now you have a case where clicking on a button to submit the form is considered erroneous, while pressing the Enter key to do the same thing isn't.

This thankfully was an internal application - people probably didn't care that much about quality. The application has more of these annoyances, but the users probably grind their teeth and worked away, since they needed this application for their daily work and also because they had no other choice.

What would have happened if this was part of a product? And in a market where you have competitors?

In a conference call...

In my previous company, we were developing an application for a Japanese client. One day, we were supposed to call up our coordinator at onsite. My team leader asked me to go ahead and place the call while he would join me a few minutes later.

I placed the call, and after a few rings, someone began speaking in Japanese.

I was stumped, since I was expecting our coordinator to pick up the call. But then I realized it could be a common number, and that the person speaking right now was probably a receptionist. I waited for him to finish, after which I thought of asking him to transfer the call.

But he didn’t. He continued speaking.

After a few minutes of this, I said, slowly in English, “Hello. Can I please speak to <coordinator name>?”

No response. Receptionist keeps speaking.

I try again, but this time, just repeat the name of the coordinator, in case he did not get what I was speaking.

Still the same.

Finally, I call up my team leader and tell him that someone is just speaking on and on in Japanese.

He said, “Keep the receiver down. Its voice mail”.

Why you should have good language skills...

There was this guy in my team (thankfully, he's left for another team). Together, we were supposed to finish two use cases. Our team was running on an artificially induced crunch mode.

One day, I felt that we had typed some code without the corresponding Javadoc. Since I was stuck with some work, and since he was free, I asked him to type the Javadoc before any other work came by. He refused, saying he was not very good in English and spelling errors would occur. I told him that he could not go on throughout life giving this as an excuse, and that if he knew he was poor in English, he had better improve. As a first step, I suggested he type the documentation in MS Word, which would point out his mistakes. He could use that as a learning experience.

He agreed, and some half-hour later, told me he was done.

I went over to his workstation, and as expected, his text was riddled with red squiggly underlines. I asked him to correct those first.

He said, "Ya I know I have to correct them, but how do I do so?"

I thought this guy probably does not have much experience with Word, and told him to place the mouse pointer over the word and right-click. He did so, and the menu popped-up.

He said, "Hey! I know how to open this menu... but how do I know which item to select in the menu?"

I was shocked, to say the least...

Hmm...

I have been doing a lot of late nights recently. This has taken a toll on me so much so that when I exited the lift today, I heard it say, "The time is now 12pm. Have a night stay." It was a while before I realized that it actually said, "Have a nice day."

Does onsite travel mean only the US?

I am a software developer working in India. (OK, you got that from my blog's heading, but I just thought I'd repeat it). I am now working for my second company. While in the first company, I went on an on-site visit to Delhi, where our client was. I stayed there for a month, helping the client out as he faced problems with our product. It was a kind-of great experience for me, as I got to know for the first time the thought processes people had and problems they faced as they used our product.

Well, a year and a half later, I was job-hunting, and went to various interviews. Now, on-site experience is considered very valuable in the Indian software industry, and I was pretty sure that people would respect me for the experience I gained. In one particular interview, I mentioned that I had gone on-site. The interviewer asked, "Where?" and I said, "Delhi".

He said, "That's not on-site." I said, "Yeah, but that's where our client is..."

The interviewer nodded, but I could see he didn't believe it. He didn't believe in the experience I had gained there. He didn't consider Delhi as on-site.

I joined the very same company whose interviewer asked me that question. With other work, this incident was pushed to the back of my mind. Some days back, it re-surfaced. After lunch, I and a few of my friends working in the same company were walking towards our building, when for some reason, I mentioned the incident. One of my friends immediately hotly defended the interviewer; surely Delhi could never be considered on-site!!

I got angry; I took it kind-of personally - well, he was after all, saying that my on-site experience at Delhi was not to be considered. I got puffed up and ready to argue, but my friend said he had to pick up cash at the ATM and walked away.

Later, when I was at home and in a calm mood, I thought this over, finally. I realized
that for some reason, my company (I am not sure about other companies in India, but I think they are also the same) seems to consider only US travel as on-site. I feel this is ridiculous.

Why should I feel so? Let me put forth my reasons. Let's start by answering this question:

Why is on-site experience valued?

Let me provide the answer too: On-site experience is valued because for the first time, you are face-to-face with the customer. While at offshore, you can easily say that this-bug-cannot-be-fixed/I-cannot-come-on-Saturday-to-fix-that-bug and such stuff. But you cannot say that in front of the customer, because if you do, the customer then stares at you in anger. And I tell you - that stare pierces your heart, that stare gives you guilt feelings, that stare gives you cold sweats - your company, rather YOU have just lost a customer. The customer has just taken one step down the road to never recommending you and your company to others.

Lost. That very word makes you sweat. That very word, that very stare, ensures that even after you go home, you keep thinking about it. The customer's face, after you finished speaking, is what comes into your head, and you cannot shake it away, for some reason, which you don't know.

That, in my opinion, is why on-site experience is so valued. You face the customer. Not everybody can do that. And when you return, after having successfully moved your application to production, and after having been given a personal send-off by your all-smiling customer, you return to two things - 1) the knowledge and the satisfaction that you have just retained a customer, and 2) the applause of all your colleagues. Soon, you find that everybody in your company listens to you all the more. Its not that they weren't listening before; its just that they listen to you all the more.

It is for this lesson that on-site experience is so valued. Now the question is, where can you get this experience? Only in the US? I say, no!! Customers are spread throughout the world, and wherever your customer is, you can gain this experience. He may be in Delhi or in San Francisco, but whatever it is, on-site is valued for customer relationships, not for US travel.

And that's why I expect people to respect me and my experience when I say I travelled on-site and solved my customer's problems!! It might be Delhi, but when my application didn’t work the way the customer wanted it, he raised his voice, and said, “What application is this, yaar?” And that’s it – it sends me into a flurry. I immediately note it down, and when I return, include the feature into the application.

On-site is valued for customer relationships, not for US travel.

What are your views on this? Am I wrong here? Is there something I don't seem to understand? I would love to hear any opposing views, so feel free to comment on this post or mail me regarding this.