Comments (1)

By Krishna, March 30, 2009

An important part of management and mentoring is the need to provide accurate feedback to employees about their work. The motivation is to reinforce positive actions and behaviors and reduce or end mistakes. It is easy to give praise to employees when they are doing something good, but the flip side has many risks.

The main problem with giving negative feedback is that it can easily come across as personal criticism. The employee thinks that you have found something wrong with them. This can bruise their feelings and make them antagonistic towards you. This is not true of everyone. Some people are more receptive of negative feedback, others are more sensitive. You cannot be too careful with how you communicate.

One strategy used by many managers is the “sandwich” technique. Here the manager first praises the individual, then slips in an item of criticism and then ends the conversation on a good note by praising the individual again. In practice, mastering this technique can be tricky. If the criticism is too strong, the praise portions of the speech can ring hollow. Plus, employees quickly master the peculiarities of managers and, if this technique is used too often, they will ignore the praise placeholders.

A different technique would be to avoid framing the mistake as a problem, but instead suggest a change as a different/better way of doing things. This is an internal acceptance that the employee did what he did because of ignorance or inexperience, and the mistake was, in fact, an honest effort that failed. So instead of berating the individual, acknowledge their efforts and explain what must be done in future. Look forward.

Another issue with negative feedback is that instead of trying to rectify the problem you identified, the employee tries to avoid the situation that caused the problem. For example, if a code review discovers problems in a programmer’s code, he may try to reduce the frequency of code reviews to buy more time to fix the code instead of writing good code in the first place.

One could solve this issue by describing the solution in addition to explaining the problem. But there is a danger that the employee may be too overwhelmed with negative feedback and be under pressure. In such a situation, it is better to slow down, and give the employee time and resources to get back on track. Different employees are different and you have to make the right judgment whether a particular employee will improve if they are given more rope.

In many cases, if the employee is capable, it is better to avoid full-length discussions and let them handle the situation themselves. This is an important aspect of delegation too because if you run around trying to solve people’s problems for them, they will never improve. Treat employees like adults and they will respond accordingly.

Comments (0)

By Krishna, March 30, 2009

Daniel Larison writes: (it is in a different context, but relevant nevertheless)

ideology will not reliably predict consequences of events, but it will condition the mind to force every event into the mold provided by the ideology. If a person approaches the world with an ideological frame of mind, whatever events dominate the historical memory of his fellow ideologues are perceived as constantly recurring again and again as part of a progressive narrative of successive triumphs, each one more important than the last. […]

This is one reason why so many ideologues express great confidence that History will judge their endeavors to have been worthwhile and why they always avoid accountability for the consequences of their own policies and actions: their grasp of historical contingency is poor, and their knowledge of history is usually limited to a narrow range of approved opinions about major events.

This reminded me about how fervent the arguments the programming community are about everything from development methodologies to choice of language and tools. If a project succeeds, it is because of the choice made by the ideologue. If a project fails, it is in spite of the choice. There must always be some other reason such as incorrect execution. The ideologue never admits that failure is a result of the choices he made.

Some of this could be attributed to mercenary intentions. After all, the CMMi and Agile project management space is filled with consultants, book writers and trainers all looking to profit. But there are true believers who simply cannot conceive that there could be a different way. Facts and events do not dictate their beliefs, instead the former is twisted to avoid changing the latter.

This is, of course, a common and human phenomenon. The world wouldn’t be in the greatest financial crisis since the Great Depression if many of the bankers and investors had stopped to examine their assumptions. But just like them, anyone who keeps imposing their version of reality on events will encounter problems and wonder what in the world went wrong.

Comments (0)

By Krishna, March 24, 2009

In my post on BizSpark, I suggested that while $1 in hard cash can be considered equivalent to $1 in programmer effort, practically they are quite different. There are a few different situations around this, so let me try to explain them here. For the sake of this discussion, let me use some round numbers, such as a programmer costs $100 an hour, ignoring differences in geography, skills, and a programmer works 2000 hours a year, ignoring holidays.

So let’s say that you are such a programmer. You are at home deciding whether to cook or order a pizza. One way to think about this is: You make $100 an hour and it would take 30 minutes to cook a dinner, but no time is wasted ordering a pizza. Compare the $50 for the 30 minutes versus the $20 pizza and you have your answer: Order the pizza every time. Obviously, this doesn’t work that way, because you will spend the next 30 minutes watching TV and instead of earning 50 bucks, you are simply out 20 dollars.

In this situation, your effort is not directly translatable into money simply because your effort is not valued at the same rate all the time. If you could convert every hour of your time into directly producing revenue, then such a determination could be made. For example, you may be working from home and be able to bill every hour you work without any overtime constraints. In such cases, you could choose to work instead of doing some other chore, earning more than you would be spending.

But generally, people have two different values for their effort: one while they are doing their company work ($100/hr in our example) and another at all other times ($0/hr). Spending more time to accomplish something when there is a faster solution (that costs money) available may be preferred in the first circumstance, but not so in the second situation. This is one reason why many startups choose inexpensive solutions like LAMP. Their effort brings close to $0 an hour. Any tool they purchase could speed up their work, but it is money that has to be spent upfront.

This is not necessarily right or wrong. I am just describing what happens. That is the way that almost all startups operate: with a tight budget. Some survive and go on to bigger things. Others are under-capitalized and do not make the necessary investments to go to the next level. Peter Drucker has described this growth problem with startups: they often stick to the same operational model that worked well during their earliest years. The founders do not understand when they have to change their management and financial structure to become a bigger player. Quite often, the founders have to be forced out for the company to make the necessary investments and structural changes.

Employers make several different mistakes when calculating the value of a programmer’s time. One is that they take the expense of salaried programmers for granted and pay very little attention to maximizing their productivity. Almost all companies treat permanent employees and consultants differently because the cost of the latter is treated as a “special” expense and has to be accounted for more diligently. Employees are often given a pass on actions or inaction that would get a consultant fired on the spot.

Of course, some employers go the other extreme, trying to suck every ounce of work from the employee, making them work long hours and being on call. Practically, this is useless. Employees give their body, not their spirit. A programmer may spend 12 hours in the office, but actually perform only 6 hours of work and introduce bugs that take another 6 hours to fix. I won’t deny that there can be some short-term gains, but it all evens out in the long run with no gain in output and a greater risk of damage to products and human relations.

The shorthand of using programmer cost per hour can be misleading. Of the 2000 hours that a programmer spends, he will be most productive in some of the hours and very unproductive at other times. For example, a programmer who is an evening-person may start his day by clearing out his desk, sending official emails and participating in meetings, i.e., not producing any code. But after 2 pm, he gets into a flow and starts writing the code for his tasks.

In the above case, the programmer’s evening hours are worth a lot more than his morning hours. If the employer causes the programmer to be disrupted by phone calls and meetings during the evenings, he has changed the value of the programmer’s hours from a high value to close to zero. This may not be evident immediately because the programmer seems to be doing the same tasks as he was doing in the mornings.

Comments (0)

By Krishna, March 23, 2009

My friend and project management writer, Mike Ramm, from Bulgaria, was kind enough to answer a few questions about his work and his ideas on project management.

1. Could you please give an introduction to yourself and your online work for our readers?

   I started my career twenty years ago as a software developer and my heart still belongs there. I am a consultant, a management coach and a lecturer in different areas: software development, project management, career development and public speaking. I have several websites and blogs (mostly in Bulgarian) where I share my thoughts and ideas with my readers trying to make them adherents, customers, partners or friends. I have two blogs in English – PM Stories (http://pmstories.com/) which is devoted to project management and software engineering, and Stop and Think! (http://mikeramm.com/) which is devoted to business, entrepreneurship, internet marketing and blogging and it is a little bit more personal.

2. How is the software industry in Bulgaria in particular and Eastern Europe, in general?Well, although we’ve been living for 20 years in the post-communist era, we still have many economical challenges in all industries and the software industry is not an exception. The software companies in Bulgaria can be divided in several categories:
   • The major international players – IBM, Microsoft, HP, Oracle, Siemens – all they have their representatives here and they sell their products as well as undertake the biggest projects in the public administration. They bring management know-how and good organizational practices but they work for big money and this lays the ground for more corruption among the administration.
   • Outsourcing companies – sometimes they are Bulgarian companies, sometimes – divisions of foreign companies. They do mostly coding – most of the other activities are done by the Western companies who order the product. This makes our software industry more coding-oriented. Very few companies have business analysis, testers or project managers and these roles are considered not important. Coding is religion. Unfortunately, these companies face very tough competition among Asian companies which offer significantly smaller rates and it is becoming more and more difficult to win outsourcing contracts for simple coding.
   • Product-development companies oriented to the local market. These companies produce mostly financial or accounting software that fulfills the requirements of the Bulgarian legislation. Their problem is that the local market is very small and they cannot make big money developing software only for Bulgarian customers. Therefore they cannot attract the best developers and their technical level is lower than the others. Another threat comes form the harmonization of the European legislation and I suppose that in very short time all the European software companies will become potential competitors to those Bulgarian companies.

   I have no direct observations on the situation in the other Eastern European countries but I suppose it is not much different.

3. What is “PM Stories”?Reading my answer to the previous question one may assume that I have a very bad opinion of the software industry in Bulgaria . Well, it is not like that. We have very talented developers and the Bulgarian software companies are technically savvy but we lack good management and organizational practices and thus the Bulgarian companies are not very efficient. Our productivity is relatively small and this makes our products more expensive, which makes it much harder to compete with the foreign companies.

   So, PM Stories (http://pmstories.com) is my answer to this problem. I wanted to build a place where to share my experience and knowledge about software project management and to help software teams in Bulgaria establish a better management in order to improve their efficiency. This is the reason why I write there mostly in Bulgarian. The English version of the blog is intended to share some ideas with the international community of project managers to see if I am still on the right path.

4. What are the most important items that project managers should learn about?In two words – taking responsibility and sharing responsibility.

   Taking responsibility means that you have to know your abilities and your team’s strengths and weaknesses; to actively undertake tasks that you can do and to firmly say “No” to suicidal projects. There are companies where the project manager is just a funnel – the top managers make all the decisions and the PM’s job is just to inform the team. What I urge them to do is to ask for their part of the decision-making, which comes with the respective part of the responsibility.

   Sharing responsibility means to respect your team and to rely on them; to delegate them tasks which they can accomplish; to build trust and self-confidence as a team; to lead and motivate them. There are many cases when the PMs command their subordinates like an army squad and they are not a team anymore but just a group of people who have common tasks but not a common goal. I believe this is unproductive and inefficient. Even if you succeed to achieve some results, they are temporary and unstable.

5. What personal qualities are most important for project managers?In order to be respected and trusted manager by your team and your managers, you have to be a true leader. It means that you have to be open and honest, to be able to communicate with different kinds of people, to be a good negotiator and motivator, to understand the business matter, and (maybe) to have a little charm.
6. Do you see any difference in dealing with people from different nationalities and cultures?Yes. Since the project manager is primarily a communicator, it is very important to be aware of the cultural background of the people they deal with. When you criticize or joke, sometimes your critics or jokes can be considered as insults. It is imperative to know where the border that you shouldn’t cross is.
7. What prompted you to come up with the idea for the title “Stop and Think!”?In my country we have a proverb: “There is no time to think – you have to work!” and I know a lot of people who live like that – jumping into the craziest projects without even give a single thought about the possible negative outcomes of that undertaking. They grab an idea and say: “This is great! Let’s do it and we’ll get a lot of money!” I know that some of the greatest inventions of the world came this way but I believe that there must be some balance and some critical thinking before taking a new challenge.

   There are also people who ruin their lives living this way. They say “I hate my life but I have to go to work next morning again to earn my living” They destroy their relationships and live a miserable life. So, my advice is:

   Stop doing stupid things and think about yourself! Take a break! Look at yourself and ask yourself the question: “Who am I and what are the most important things in my life?” And throw away everything that is not important and that distracts you from the things and the people you love.

   This is what “Stop and Think!” means.

Comments (0)

By Krishna, March 18, 2009

In the last few months, I had the misfortune of attending speeches where the talker took a fascinating subject about a real-life crisis and then went about brutally twisting the facts to fit into a project management paradigm. Without naming names, let me say it went something like “How to Manage Your Project by Learning Lessons from Accident X That Killed Y and Seriously Injured Z”.

Apparently, this seems to be a trend. Why, we even have “Deep Survival”, a book about surviving in high-pressure situations, being recommended by the Personal MBA people. Of course, non-fiction book writers have always had an inclination towards researching success and failure stories and trying to derive deeper meaning from them, where none exists. The enterprising author is the one who writes two books before the presidential election, each one expecting a different result, and releasing the correct one on the day after the election results are announced.

There are two big problems with retroactively fitting these real-life situations with project management frameworks and methodologies. First is, as Wikipedia says about “Blue Ocean Strategy”, such ideas are descriptive, not prescriptive. When the events actually happened, they happened to follow a particular pattern. They didn’t design and follow the pattern to achieve success or encounter failure.

For example, none of the companies mentioned in “Blue Ocean Strategy” actually followed the strategy recommended by the authors. They made their choices according to their existing decision making process. At a later time, someone (the authors) noticed a particular pattern and suggested that following the same steps may produce the same results. Which isn’t the same thing. Plus, there is always the question of whether there are other patterns that the “strategists” missed.

The second problem is that these real-life crisis situations have few similarities with software projects. Nobody’s life is at risk when a project fails. Worst case, some people get fired and, if it is a good economy, they find jobs quickly enough. Compared to tragic accidents, the events in a project take place at a snail’s pace. There are many, many opportunities in a project to reverse the decisions that are leading in the wrong direction, but many different factors (ego, fear of change, ignorance, etc.) prevent it from happening.

Projects do have their crises. But even those projects do not start as crises. They reach there by various decisions made during the project – wrong decisions made with deliberateness and under calm conditions. For example, there might be an error in estimating the resources required, or a mistake in choosing a particular technology or design choice, or an oversight of a critical stakeholder.

By focusing on managing crises, the project manager ignores his upfront responsibilities that could prevent those crises happening in the first place. It also glorifies fire-fighting heroics, which can act as a powerful addiction for some people who continue to operate in crisis mode and keep everyone on edge. That is not a good long-term management solution.

Comments (0)

By Krishna, March 17, 2009

The Creative Commons license has different attributes, one of which is “Non-Commercial”. It simply states “You may not use this work for commercial purposes.” The literal reading makes it very clear you cannot profit directly from the work, such as selling it as part of an image library. But what if you are using it on a website that makes money from advertising? What if you use an image for your company’s website, where it serves as marketing and promotional material, indirectly resulting in revenues? Is that use commercial enough to invalidate the use of such Creative Commons content?

Philip Lenssen explored this question last year and got an inconclusive answer:

I’ve asked the Wikipedia mailing list a while ago, and recently received another confirmation from Creative Commons’ Lawrence Lessig: yes, the CC organization believes this being OK is the best reading of the license. […] But it’s also a matter of how you display ads, Lawrence disclaims, saying that there could be certain advertising schemes that take it too far.

(It should be noted though that the Creative Commons organization does not determine whether a judge would agree with their interpretation, in case someone would get sued over using NC content on an ad-supported site.

As Philip notes, many blogs and even Google would be in trouble if you could not use CC images on ad-supported sites. Still it does seem like something to be more safe about now than sorry later.

Another problem I saw recently is that some people on Flickr repost photos (taken by others or professionals) under a Creative Commons license. They actually put a copyright notice stating they got it from AP or somebody, but the picture is under their account with a CC license. I suppose this happens according to their account settings, but it can be very misleading.

It is possible for people to change the copyright for their images from a CC license to a more restrictive CC license or basic copyright. It can be a pain to prove that you had used the image under the correct license. Image Stamper is one service that may be helpful in that. It records the license when you used it so that you can use that as evidence if you ever require it.

None of this should really matter for small-scale bloggers and non-commercial websites, because it is not profitable to sue them. But we have seen what the RIAA did in the music industry. And there is always a non-zero possibility of somebody creating problems.

Comments (1)

By Krishna, March 16, 2009

Microsoft has a program for startups called “BizSpark” that offers Microsoft development and production licenses with the following terms: (via StackOverflow blog)

• No fees to join
• Access to as many production Microsoft product licenses as you need, for free, for three years
• MSDN Professional full access subscription to download the software

At the end of three years

1. you have to pay $100
2. you have to license the software you’re actually using

The startup must

• Be in the business of software development
• Be privately held
• Have been in business for less than 3 years
• Have less than US $1 million in annual revenue.

While this is a forward-looking step, I don’t think BizSpark goes far enough. People are fond of arguing about the relative strengths of a particular technology, but in the case of adoption, entry costs play a disproportionate role. While $300 seems very inexpensive, it is not when compared to close to $0 for a LAMP stack which gives you mySQL/postgreSQL, PHP, Perl and Python.

Now, I know all the arguments for justifying spending the $300 for a Microsoft development stack. For example, you can argue that using .NET will increase productivity that will generate savings many times greater than the expenses. The software cost is only a fraction of development costs, especially if the startup is very successful.

Practically, though, these rationales only make sense for startups that are true business concerns. For every application produced by an “official” startup, there are hundreds of small applications created by programmers working alone or in small groups (1-3). These applications may be hobby projects created without much hope of striking it big, but some do. These programmers like to keep their costs minimal because they don’t think they will benefit. Because LAMP is easily available at low cost, that is the default choice for many such developers.

(While $1 in hard cash may be the same conceptually as $1 in programmer effort, they are not the same in practice if you don’t have the $1 or you are not willing to spend it. In real life, some people, to save a dollar, are willing to spend several times the equivalent human effort, because the human effort cannot be employed to earn the same dollar. Coupon cutting is one such example. This is actually more complicated than I make it out to be, probably will discuss this in a future post.)

The second problem is the cost after the three year period. Some startups will be enormously successful and for them, this doesn’t matter. But what if the application is bringing in revenues just keeping pace with salaries of the programmers? That would be a big hit. Now, three years is a reasonable time for a company to succeed, but things can go wrong like, for example, the economy may take a turn for the worse and affect the business, as it is doing now. With a LAMP model, the costs remain same, and there is no sudden jump of expenses at the end of the third year. A better model in this situation would be a revenue or profit sharing arrangement.

I may be ignorant about the details about how this works and would love to be educated otherwise. But if I am correct in my understanding, BizSpark is good, but not good enough. Microsoft is losing a lot of programmers who are building small applications and, while I have enormous respect for the .NET platform, better technology is not going to attract them. You need an even lower barrier to entry. Make it as cheap as LAMP for entry and then have a business arrangement that minimizes financial risk for the startup.

Comments (0)

By Krishna, March 15, 2009

I was fascinated with Jurgen Appelo’s post proposing a new “Complex Manifesto” because it was able to explain with clarity why we have to think deeper when we read software experts talk about various principles and practices. I requested him to answer a few questions on the topic and he was very kind to agree and respond. Here are the questions and answers:

1. If you were to sum up the “Complex Manifesto” in one sentence, what would you say?
   It is important to understand why there is no silver bullet: the world is complex.
2. What were the recent causes that prompted you to create a “Complex Manifesto”?
   I saw too many claims about the “absolute necessity” to do refactoring, unit testing, and several other good practices. While it is true that these practices are often quite good, there are no absolutes in this world, other than death and taxes.
3. Why does the programming world need a “Complex Manifesto”?
   It doesn’t. But it also didn’t need an Agile Manifesto, nor a Manifesto for Software Craftmanship, or whatever. However, these things can help to give people a frame of reference for the things they do. They are a bit like vision statements, in that they paint a global picture of how things should be. We can glance and point at them occasionally, and then we get back to work.
4. What would you say to critics who may interpret the “Complex Manifesto” as “It Depends” statement? Or do you agree with that assessment?
   Yes, I agree. It depends. There is no silver bullet. Everything is relative. However, my Complex Manifesto does more. It explains why this is the case.
5. How much knowledge and/or experience would a developer need to be able to understand “when to use what”?
   I cannot answer that question. A one year old child already understands when to use its feet and when to use its hands. While at my age I still don’t know when to use Twitter and when to use Facebook. So again… it depends on the problem.
6. Do you envision the “Complex Manifesto” as changing the arguments from “what methodology is best” to “what scenarios is a particular methodology better in”?
   No, I don’t think any methodology is best. For every software project there are several optimal sets of best practices. Whether or not such an optimal set closely resembles any particular methodology is probably pure chance. The real value of methodologies is that they are good vehicles for teaching practices, and for practices to be carried over from one project to another. The practice “collective code ownership” gets copied around more than “private code ownership” because the former is part of XP while the latter is part of FDD, and XP is far more popular than FDD. That is the value of methodologies: they copy practices around.
7. Finally, religious arguments among programmers in the right spirit are fun to read. If the “Complex Manifesto” is widely accepted, wouldn’t it make the community a little, ahem, boring?
   Not at all. Religious arguments in absolutes are useless when they don’t consider the context. But when people do consider a context, we can still enjoy fanatical arguments. I know several of these going around in our projects…

References:

• Agile Manifesto
• Manifesto for Software Craftsmanship
• XP
• FDD
• Collective Code Ownership vs. Private/Individual Code Ownership

Comments (0)

By Krishna, March 14, 2009

Sometimes, people can be too clever by half. When it comes to knowledge of understanding other people, everybody thinks they are an expert. They think they can understand the motivations of others based on one or two interactions when, in fact, they are drawing upon stereotypes and are making wrongful assumptions. People who are quick to form impressions of others set themselves up for failure, especially those who are disposed to mistrust of others.

A jaundiced and cynical view of the world pushes away people who want to help. It attracts people who want to feed the venom of hatred and bitterness. It keeps problems festering and avoids dealing with issues before they become serious. It prevents one from taking advantage of opportunities. And above all, it destroys something human in us, the ability to empathize with others.

I am reminded of “Good Will Hunting” where the Matt Damon character, Will, makes an infuriating remark about Sean Maguire (played by Robin Williams), a therapist trying to help him, after seeing a picture of Sean’s. As reply, in one of the most moving movie speeches ever, Robin Williams explains why Will is wrong to base his judgment on one single observation of his life.

Sean: So if I asked you about art, you’d probably give me the skinny on every art book ever written. Michelangelo, you know a lot about him. Life’s work, political aspirations, him and the pope, sexual orientations, the whole works, right? But I’ll bet you can’t tell me what it smells like in the Sistine Chapel. You’ve never actually stood there and looked up at that beautiful ceiling; seen that.

If I ask you about women, you’d probably give me a syllabus about your personal favorites. You may have even been laid a few times. But you can’t tell me what it feels like to wake up next to a woman and feel truly happy.

You’re a tough kid. And I’d ask you about war, you’d probably throw Shakespeare at me, right, “once more unto the breach dear friends.” But you’ve never been near one. You’ve never held your best friend’s head in your lap, watch him gasp his last breath looking to you for help.

I’d ask you about love, you’d probably quote me a sonnet. But you’ve never looked at a woman and been totally vulnerable. Known someone that could level you with her eyes, feeling like God put an angel on earth just for you. Who could rescue you from the depths of hell. And you wouldn’t know what it’s like to be her angel, to have that love for her, be there forever, through anything, through cancer. And you wouldn’t know about sleeping sitting up in the hospital room for two months, holding her hand, because the doctors could see in your eyes, that the terms “visiting hours” don’t apply to you.

You don’t know about real loss, ’cause it only occurs when you’ve loved something more than you love yourself. And I doubt you’ve ever dared to love anybody that much. And look at you… I don’t see an intelligent, confident man… I see a cocky, scared shitless kid. But you’re a genius Will. No one denies that. No one could possibly understand the depths of you. But you presume to know everything about me because you saw a painting of mine, and you ripped my […] life apart.

You’re an orphan right? [Will nods] You think I know the first thing about how hard your life has been, how you feel, who you are, because I read Oliver Twist? Does that encapsulate you? Personally… I don’t give a shit about all that, because you know what, I can’t learn anything from you, I can’t read in some […] book. Unless you want to talk about you, who you are. Then I’m fascinated. I’m in. But you don’t want to do that do you sport? You’re terrified of what you might say. Your move, chief.

I wonder how many times we have labeled, condemned or written off someone because of one incident, one misunderstanding, one assumption. That is one thing which has to change if we are to make our relationships (business and personal) work.

Comments (3)

By Krishna, March 12, 2009

I will be posting more on Randy Pausch’s “The Last Lecture” in a different post, but before that, I wanted to talk about the context in which his lecture takes place. Taken by itself, the speech is very inspiring and has many thought-provoking ideas. (You can skip the book which is too much process, too little content.) But the fact that Randy Pausch was dying (at the time, he had only a few months left) made the lecture more meaningful and attracted heavy media coverage.

The powerful philosophical idea here is that our life is limited and we should spend it chasing our dreams than waste it in pursuit of material comforts. Somebody about to die has many, many regrets. Seldom do those regrets revolve around not having made enough money. They are usually about broken relationships, shattered ambitions and the squandered time.

The problem I see is that unfortunately, we don’t know how limited our life is. We could die the next minute or live till 100. And this uncertainty means that we cannot make easy choices. If we truly knew that we had 2 weeks to live and no way to escape, we would act entirely different. We would quit our jobs, stop caring about household tasks, call every friend and relative, and visit the most important people and places we want to see. But if we knew we would definitely live to celebrate our 100th birthday, maybe we would worry more about our retirement and health, work longer and spend less.

The same thing applies to our family and friends. If we knew that someone would no longer be with us next year, we would pay them much more attention and love than we do. If we knew that they will always be around, maybe not so much. That happens to be our default thinking, because we hate even the idea of something happening to our dear ones, and so take them for granted.

Life is uncertain and unknowable. At the same time we accord respect to the dying and treat their struggles as heroic, we should also remember that those who are living and have found a way to reconcile their needs with their dreams are also worthy of our respect and gratitude. They are all around us, disguised as parents/children, employees/employers, volunteers, school teachers and so on. They don’t know what the future holds, but they have found a way to contribute.