Archive

Archive for the ‘Uncategorized’ Category

Vignettes of My Interactions with Mary Jean Harrold

September 21, 2013 3 comments

It is with great sadness that I have learned about the untimely passing of Mary Jean Harrold last Thursday. Remaining true to herself—never disclosing the difficulties she always overcame so stoically—Mary Jean kept her illness private, with only a limited circle of people being even aware of her condition. Consequently, the news of her passing came to me as a complete shock. As a member of my Ph.D. committee and academic colleague, Mary Jean had a hugely positive influence on me as a researcher and person. To convey what a truly remarkable individual she was, I would like to offer the following series of vignettes of my interactions with Mary Jean.

My first encounter with Mary Jean occurred during my first semester in the Ph.D. program at Georgia Tech. She just joined the university and was moving her lab there. I came to grad school having been frustrated with the practices of industrial software development that I had witnessed at my job. However, I could not find an advisor who shared my research interests. After listening to her presentation to the first year graduate students, I was impressed not only with her enthusiasm for her research, but also with the unabashed pride she displayed for the accomplishments of her grad students. I knew right away that I wanted to join her research group.

Being supervised by Mary Jean was an amazing experience. She held two hour-long meetings a week with each of her advisees. With that kind of unprecedented support, I quickly got up to speed in my project, which was sponsored by Boeing and involved building a static analyzer for avionics code written in Ada. By the end of the semester, I acquired a deep appreciation for program analysis and testing. At the same time, I managed to realize that my research interests lied more in building systems than in analyzing them. However, due to the excellent guidance I received from Mary Jean, I delivered on all of the project’s goals, and later a research engineer was able to pick up where I left off, so that all the research goals set off by the sponsor were met. Based on my own experiences as a faculty, I can say that this was a remarkable win-win outcome: I actively learned about a new-for-me research area, and the industrial sponsor got their deliverable. Under any other advisor, the results of working on a project only for a semester would have to be completely written off. When I informed Mary Jean that I wanted to focus on distributed systems for my Ph.D. work, she was very supportive and we retained a cordial professional relationship for the rest of my studies and beyond.

For most of my Ph.D., I was working across the hall from Mary Jean’s lab. She felt that it was highly important to have dedicated space for a lab, so that graduate students could form a community fostering a sense of collaboration and camaraderie. It had not been a day when I would not stop by her lab to talk to her students, forming lasting friendships with several of them. Mary Jean’s office was close by and she’d often stop by the lab to talk to her students.

Once, collaborating with another student, I was trying to meet a tight deadline and ended up pulling an all-nighter. As a smoker, my collaborator needed to step outside for a cigarette about every other hour. I would come outside with him, so that we could continue our research discussion. I clearly remember seeing Mary Jean leave the building late in the evening around 10:30 or 11pm. Then, we saw her coming back to work around 5am. “I find you guys in the same place where I left you yesterday—have you been standing here all night?”–Mary Jean greeted us in the morning. For us, pulling in an all-nighter was an uncommon occurrence; as soon as we reached our goals, we went home and crashed for the rest of the day. For Mary Jean, leaving the office late at night and starting her work day at 5am was her regular work style, something that she did day in and day out.

When I applied for faculty positions, I naturally asked Mary Jean to serve as a reference for my applications and to write me a recommendation letter. I clearly remember how in early December, I sent out my faculty job applications and e-mailed all my recommendation letter writers where they should submit their recommendations. I left the office around midnight and headed home. When I woke up the next morning, I saw an e-mail from one of the universities, informing me that Mary Jean Harrold submitted a recommendation letter on my behalf at 6:15am. Later I asked Mary Jean how she could have written and submitted a recommendation letter so fast. She told me: “Look, this recommendation letter will be very important for your career and procrastination on my part can hurt you. As soon as I got to work at 5am, I saw your e-mail. So I just wrote the letter and sent it out.” This incident left a profound impression on me—this incredible display of professionalism and compassion. Influenced by this experience, I always give the recommendation letters I have to write the highest priority.

When I accepted a faculty position at Virginia Tech, Mary Jean invited me to celebrate this accomplishment with her research group. She was sincerely happy for my success, and treated me as if I were her own student. We went out to lunch to a fairly remote restaurant driving in two separate cars, with Mary Jean driving one of them. During the lunch, we argued about what was the shortest route to get back to the Georgia Tech campus. It was decided that on the way back we would compete on who would get back first. However, in the spirit of a true research experiment we committed to not breaking any traffic laws. Sitting in the car driven by Mary Jean was quite an experience, as she took this competition with the utmost seriousness and was really eager to win. To her disappointment, both cars got back to campus approximately at the same time.

The last time I saw Mary Jean in person was during a very difficult period in my life. I just went through my mid-tenure review, and the results were mixed. I had strong publications and teaching records, but my lack of success in obtaining federal research funding could seriously compromise my chances of getting tenure. I was seriously considering quitting my faculty job and going back to work in industry. Back in Atlanta for a meeting with an industrial collaborator, I asked Mary Jean for an appointment. I needed her advice. Mary Jean gladly agreed to meet with me. I felt very dispirited and confused, and I was very honest with her. “I wrote seven NSF proposals in a row, and all of them got rejected. I am not sure if I can make it.” What Mary Jean asked me next was striking in its wisdom: “It makes no difference whether you think you can make it or not. Is making it what you would like?” Would I have liked to succeed as an academic researcher? Of course! Going back to making a living by writing computer code would have felt like a huge defeat. This simple question helped me to completely refocus my thinking and ultimately persevere in my quest for academic success.

My last e-mail exchange with Mary Jean occurred when I was just promoted to the rank of Associate Professor with tenure. Upon receiving a congratulatory e-mail from Mary Jean, I replied by thanking her and also expressing frustration at how difficult my tenure track experience had been: “It was quite a rocky journey–I feel fortunate that things have worked out in the end.” Mary Jean was ever so gracious in her reply: “It may have been rocky at first but you figured it out!”

I wish I had a chance to thank Mary Jean in person for all the great influence she has had on me. She has made a lasting impact on her research community and on all the people who were fortunate to have had a chance to interact with her. I hope that these personal vignettes I have shared will help others understand what a remarkable individual she was and help preserve her memory.

Advertisements

Back to the USSR by Way of Twitter

March 24, 2013 4 comments

“A guy told a joke to his friend. Someone standing nearby overhead the joke. The joke-teller was fired from his job.” If someone asked me to describe the circumstances under which this scenario could have transpired, I would not have to think twice. You see, I was born in the Union of Soviet Socialist Republics (U.S.S.R.) and I have heard plenty of stories like that from my family. It usually went as follows. Someone told a political joke to his friend. A KGB informer was eavesdropping nearby. The informer alerted his KGB handlers, and the joke-teller’s state-owned employer was ordered to let him go. Most likely, this story happened after Stalin and before Gorbachev. If the story happened during Stalin, the joke-teller would be sent to a Siberian GULAG camp for a period of at least 5 years, probably along with the guy to whom he told the joke (for not ratting on the joke-teller to the KGB). If the scenario took place during Gorbachev, nothing would have probably happened, as by then the soviet repression apparatus had started to collapse.

The fact that a scenario with the same cause and effect transpired in the 21st century America is mind boggling and terrifying. Enter the Adria Richards Twittergate: “At a technology conference, a guy tells a dirty joke to his friend. A fellow attendee overhears the joke, gets offended, and in response, twits the picture of the joke-teller to her followers on Twitter. Scared of the potential of negative publicity, the joke-teller’s employer fires him.” Of course the nuances of these two scenarios are quite different: a political joke vs. a dirty joke, a KGB informer vs. a public person with a large Twitter following, the Soviet repression apparatus vs. the corporate PR machine. However, the cause and effect in both scenarios are terrifyingly identical: tell a joke to a friend => get fired from your job.

I am not going to comment on the appropriateness of telling dirty jokes where they can offend bystanders, on the propriety of twitting surreptitiously taken pictures, or on firing people based on hearsay; others have written about these issues in excess. What I would like to comment on is the terrifying similarity of the two Systems, with respect to sharing the same cause and effect for similar scenarios. It is amazing how a combination of modern social networking tools (i.e., Twitter) and the corporate PR machine has effectively replaced the role of the secret police in a totalitarian society. In fact, not every part of the scenarios was strictly worse in the USSR: the KGB would have certainly investigated the infraction; the joke-teller would be summoned to report to the local KGB headquarters, where he’d be able to tell his part of the story. “I was drunk as a fish and cannot remember anything” could have even served as an acceptable defense for first offense.

We live in a democratic country. That is, even though the USA is a republic, I would like to believe that the system in place is more or less representative of the collective wishes of its electorate. As a society, do we want to live in a country where a person can lose his job because he has told a dirty joke to his friend? Back in the USSR, parents taught their children to never share unapproved political opinions with anyone outside of close family. It is not that political jokes were not plentiful, but they were shared in the company of close friends. Here is one: Brezhnev asks Carter: “Do you collect political jokes about yourself?” Carter: “Of course, I’ve got two notebooks! What about you?” Brezhnev: “Of course, I’ve got two prison camps!” We are not yet imprisoning people for telling offensive jokes, but it is all a matter of nuance. Once a society accepts a given cause and effect as acceptable, it is a slippery slope from there.

Categories: careers, Uncategorized

On Problem Complexity and Artificial Constraints

January 2, 2012 1 comment

Recently a colleague, a fellow CS professor, asked for my expert assistance in moving a sofa from the basement to one of the rooms of his house. The sofa was not heavy, but too bulky to be carried by one person. The whole procedure was expected to take no more than 15 minutes. We easily transported the sofa from the basement to the entrance of the destination room, and then we encountered an unexpected obstacle. The sofa was too wide to get through the room’s entrance.

We put the sofa down and quickly came up with a solution. The sofa is to be taken outside the house and be carried to the porch adjacent to the destination room; then the sofa is to be lifted to the porch’s railings, picked from the other side,  and be carried to the room. The room’s entrance from the porch was wider than the one from inside the house. The only problem was that lifting the sofa to the porch’s railings and then picking it up from the other side required two more people. I told my colleague that I’d be available for the rest of the day, and let him solve the personell problem of finding two additional persons to realize our solution.

In a couple of hours, my colleague informed me that he had found two additional people for the task, who could be at his house in an hour. I told him that I’d be there. I asked him who were the other two people he’s recruited. It turned out that my colleague had friends and collaborators in other departments, and these two served on the faculty of Industrial Engineering and Architecture, respectively. How many academics does it take to move a sofa?

When I arrived to the house, my colleague informed me that the professor of Industrial Engineering was going to be a couple of minutes late. The professor of Architecture arrived soon thereafter and immediately inquired about the nature of the moving job. Then the conversation proceeded as follows:

-Can I have a measuring tape, please?

-Yes, you can, but I have measured the entrance and it is narrower than the sofa.

-Can I have a measuring tape anyway?

-Here you go.

-Can I have a screwdriver, please?

Then, in no time, the Architecture professor removed the destination room’s door from its hinges.

-Can you give me a hand carrying this thing?

A couple of minutes later the sofa was in its intended destination and the door was back in its original place. I was completely dumbfounded. “But how did you know that the door could be removed and placed back so easily?” “Come on, give some credit; I know these things inside out. With these kinds of doors it is easy.” Then the professor of Architecture remarked something about the house’s lighting needing adjustment and bid farewell. The arriving professor of Industrial Engineering was informed that due to an unexpected optimization of our moving algorithm, the job was already completed by involving only two persons.

I could not stop thinking about this incident. We had a problem that required four persons to solve. Furthermore, these four persons were expected to carry a sofa around the house and raise it to the railings. And then the same problem was solved with only two people, who did not even have to perform that much work. Thus, the second solution was more than twice as efficient: it required half as many persons who had to perform less work. All of this is because an artificial constraint was removed—the door was temporarily removed from its hinges making the necessary space for the sofa.

I could not help but think how often we experience similar kinds of situations in software research. I’ve seen instances when researchers are working for years on fully-automated solutions to important problems. Fully-automated solutions are notoriously hard because they have to ensure absolute correctness and safety. However, if a human user can provide some input, the problem suddenly becomes manageable and can be solved in a reasonable amount of time. In other words, semi-automated solutions are as valuable but also tractable.

How often do we impose artificial constraints on the problems we want to solve? How often do we think that the proverbial door would be too difficult to temporarily remove from its hinges? Do we perhaps unnecessarily complexify the solutions we propose to improve our chances of getting funding or publications? Well, one thing for sure–helping your colleagues move furniture can give you new insights on your research!

Categories: Uncategorized

A Modest Feature Request

October 16, 2011 Leave a comment

The Au Bon Pain in our student center has recently started using an iPad application for customers to enter their sandwich orders. In the past, you would order a sandwich by filling out a paper form. You’d pencil in your name and sandwich selection and deposit the form to a tray, from where your order would be picked up and processed by the next available sandwich chef. The new system eliminates the paper forms completely, as the iPad transmits the orders electronically.

During the first week, it was an Au Bon Pain manager who would take orders on the iPad. She has explained that it was a way to “squelch all the bugs” before the customers start using the application. After ordering my favorite Mediterranean Wrap, I inquired “Wouldn’t be nice to know what the approximate wait time is?” “What a great idea! Let me write this down.” Well, as a researcher, I come up with new ideas for a living. I also well-realize that not all of my ideas are worth implementing. I also teach courses in software design and engineering on a regular basis, and it immediately occurred to me that this feature request can make a useful teachable moment.

So, as I was waiting for my sandwich to be prepared, I started thinking about what it would take for the developers of this sandwich ordering application to fulfill my feature request, adding the functionality that would display the expected wait time upon completing an order. It immediately occurred to me that implementing this feature may not be trivial. First of all, to make any wait predictions, the system must timestamp when the sandwiches are ordered and done. Even if this functionality is already there, the client part of the application (running on the iPad) may not have the information about the length of the sandwich queue at the server. The client part is likely to simply accept orders and send them the server, which maintains the queue. So if the client is to be able to display any wait information on the iPad, the server interface would have to be extended to provide this information.

One can think that calculating the average wait time is easy. Just calculate N*T, where N is the length of the sandwich order line and T is the average time to prepare a sandwich. However, this formula is unlikely to produce an accurate estimate. Several sandwich chefs usually work in parallel, with different levels of productivity that depends on various factors such as their natural ability and experience. Also, not all sandwiches are created equal–some of them may take longer to prepare than the others. From time to time, sandwich chefs may need to interrupt their work to bring over various sandwich ingredients from somewhere in the back storage. The system probably does not keep track of how many sandwich chefs are present and what their individual productivity is. Adding all this information to the system is likely to significantly complicate its implementation.

To predict the wait time more or less accurately would require using queuing theory, which may require encoding some statistical formulas. Overall, adding this deceptively simple-sounding feature is likely to require substantial changes to the system’s design and implementation. Also, testing the new feature once it is deployed would also take additional resources.

Now the big question is whether all this extra effort would be worth it? Would Au Bon Pain sell more sandwiches if their customers are given an accurate estimate of the time it’d take to make a sandwich? To answer this question would require thinking through representative use cases. Let us walk through a use case that I encounter quite often. Say I have a class to teach in 30 mins. I feel hungry and having a sandwich sounds like a great idea. I also know that it takes me about 10 minutes to get from the Au Bon Pain store to the classroom. If the system informs me that it will take anything longer than 10 minutes to prepare my sandwich, I would definitely cancel my order, lest I be late for class. This use case shows that this feature may in fact cause Au Bon Pain to lose potential customers!

Looking back, it no longer looks like my suggestion to add  the expected wait time feature to the new iPad sandwich ordering system is such a good one. It is not trivial to implement properly, and it may not help the store’s bottom line. A better alternative may be to add a simpler feature that shows the length of the sandwich order line. I often wonder whether all these students hanging around the store are just socializing with their friends or are waiting for their sandwich to be made. Implementing this feature is quite straightforward, and optimistic, short-on-time customers may still choose to wait for their sandwich when given the number of pending orders rather than the expected wait time.

Categories: Uncategorized

On the Prudence of Pessimism

October 9, 2011 Leave a comment

I am in beautiful Detroit, MI, sitting at the gate in the airport, having missed my flight by about 10 minutes. The next flight is in 5 hours. Nevertheless, I feel fortunate. No, I don’t need to have my head examined. I am fortunate indeed to have a confirmed seat on the next flight, which is not just full but oversold. My fellow travelers who missed the same connection were not so fortunate–they may have to spend the night here or fly to a “nearby” airport a 5-6 hours drive away from their final destination.

How did I luck out like that? I am a pessimist by nature, and always prepare for the worst possible outcome. When I was waiting to board my first flight this morning, a cheerful announcement notified me that the flight would be slightly delayed. “We have a minor maintenance issue, but should be out of here in 30 minutes. Please ask the agent to rebook your connecting flight only if your layover is less than 30 minutes.” Well, my layover was longer than one hour and thirty minutes, but nevertheless I immediately proceeded to rebook my connecting flight. “But sir, you should be able to make your flight comfortably–we are expected to be only 30 minutes late.” “Lady, just please rebook me for a later flight just in case. If I make my original flight, I just won’t use that ticket.” Lo and behold, the 30 minutes delay turned into an hour and forty minutes delay. If the next flight were delayed by as little as 10 minutes, I would have probably made it. Now I have a pleasant 5 hour wait in the airport, but as it turned out, I am the fortunate holder of the last seat on the next and last flight of the day.

This realization makes the wait sweeter. It also makes me ponder about the value of pessimism. Not getting back home today would have been disastrous for me. I not only have to teach tomorrow early afternoon, but a senior colleague is scheduled to come by my class to conduct a peer teaching evaluation, crucial for my tenure application. Yes, I will be very tired when I get home, but nothing that a good night sleep would not cure. Well, I would have to break my promise to grade that assignment by tomorrow; Sorry, folks!–I hope you understand.

Is preparing for the worst possible outcome always prudent? Harvard economist, John Kenneth Galbraith, claims that “We all agree that pessimism is a mark of superior intellect.” I don’t know about superior intellect, but this strategy has worked for me well in different settings. For example, whenever I submit a manuscript for review, I immediately start making back up plans for the case if the paper gets rejected. I don’t just make abstract plans, but I usually ask a student co-author to reformat the paper for the next submission target. I don’t just want to be prepared for the possibility of rejection psychologically, I want to know what kind of editing I would have to do to resubmit the paper. If the next publication venue has a smaller page limit, I want to know exactly how many pages we should be prepared to cut. If the opposite is the case, I want to plan what new material we can include to strengthen the paper.  What if your paper is accepted for publication right away? Well, I’d be pleasantly surprised. But what about all the work you have done to shorten or lengthen the paper? This work will never go to waste. Whenever reporting on a research project, I have always found myself needing to write about it in different forms: short, long, and everything in between. These shortened or lengthened manuscripts will serve as building blocks for future publications on the same topic.

Well, it looks like I am going to be able to squeeze in some grading after all. Nothing shortens a wait so productively as grading assignments. Thanks to cloud-base course management systems and 3G tethering, nowadays one can be productive almost everywhere.

My 9/11 Story

September 11, 2011 1 comment

I started my Ph.D. studies in August 1999, and my first year did not go well at all. When I started my Ph.D., I was a competent software developer with 4 solid years of industrial experience and several publications in professional software development periodicals. I just had completed an M.S. from NYU and had plenty of exciting career opportunities in industry.

My first year in grad school was very disappointing.  I tried working for two different research groups but did not like the problems I was working on at all. Despite admiring my research supervisors, I could not see myself working in their research areas long enough to earn my Ph.D.

So at the end of my first year, I left the Ph.D. program and spent the summer of 2000 working for a startup in NJ. I joined the project as the DotCom boom was starting to dissipate. I worked as part of a great technical team that created a state-of-the-art technical solution for an idea that, alas, had no solid business basis behind it. By the end of the summer, the investors stopped funding the company, and all the developers were laid off. Nevertheless, I immensely enjoyed the experience working with top notch technical professionals creating innovative technical solutions.

Even though by the end of summer 2000, I did not have a job anymore, I was not sure whether I wanted to go back to my Ph.D. studies. Administratively, it was easy—because I was only gone for the summer, I could come back in the fall and continue my studies. In addition, right before I left for the summer, I had started talking to a new professor, who’d just joined the department, about working on one of his projects that involved building programming language tools for distributed computing. I was quite intrigued with that project and felt compelled to give it a try. Nevertheless, it was not clear at all whether that project held enough promise to become my dissertation topic.

So my options were either to go back to school and continue my Ph.D. or look for an industry job in the NYC area. To explore my industry options, I e-mailed several acquaintances of mine who held software development jobs and asked them if they knew of any openings that could fit my profile. Within days, a couple of them replied.

One reply looked particularly compelling. Dan, a former co-worker, just became a technical team lead in a large financial company. He cut through the chase right away: “I have worked with you; I have seen your code; I have read your programming articles; you can pass our interview with flying colors; I know because I’ve been interviewing people almost daily. As far as the compensation goes, this is a financial company, and they compensate competent and productive people well. Trust me your salary will make you glad that you have this job. Think it through carefully, and let me know when you are available for an interview.” Even though Dan did not identify his company by name, I trusted him that I had the technical background and expertise to pass their technical interview. A couple of days later, I left NYC  to continue my Ph.D. studies without ever getting back to Dan, which was rather inconsiderate of me.

About a year later, Dan e-mailed me asking if it’d be alright if we talked on the phone. It was early September 2001, and I had just spent an exhausting summer prototyping an ambitious research project. During the entire summer, I worked 12-14 hour days, coding non-stop, but at that point still had no publishable results. I asked Dan to call me in the evening at home.

Dan called me around 10pm and we chatted for a while. He asked me whether I was happy with my decision to continue my Ph.D. studies. I was not sure at all. The hours were long, the work was exhausting, and I had no social or personal life. Furthermore, it was not clear at all whether my research project would pan out and engender enough quality publications for a decent Ph.D. dissertation.

I shared my doubts and frustrations with Dan, who as it turned out, called me to seek my opinion on some technical issue. I distinctly remember him asking me whether I regretted declining his offer to interview to join his team the year earlier. And I remember replying that at that point I was really frustrated with my life and was not sure whether I’d persevere with my Ph.D. studies. To which Dan replied that unfortunately at the moment there were no more openings on his team, but that he’d keep me in mind for future openings. His last words were: “Remember no matter what you decide, we are still friends. When you visit NYC next time, make sure to visit me in my office. You should see the view from my office window.” Then he apologized for having to cut our conversation short—he had to be back in the office next morning at 9am sharp for an important meeting.

This conversation took place in the evening of September 10, 2001, and Dan had less than 12 hours to live. Daniel Ilkanayev worked for Cantor Fitzgerald in World Trade Center, Tower 1, on the 104th floor. All the employees of the company who reported to work on that fateful day perished. Since Dan never mentioned his company by name, it took me weeks after 9/11 to connect the dots. For some time, I hesitated whether I should contact his family, but since I had never met his family in person, I decided against that.

Dan was a highly talented IT professional and a great guy overall. That’s how he will always stay in my memory. The more I live, the more I realize that life has no coincidences. Why did he have to call me in the evening of September 10? That was our first (and alas last) conversation in more than a year. Why that particular night?

This tragic episode had a profound impact on my life. I persevered in my Ph.D. studies having overcome tremendous difficulties against all odds.  However, no matter how I’d feel during my Ph.D. studies, I no longer had any doubts that completing my Ph.D. was my destiny. And this was enormously helpful. I did finish my Ph.D., producing a strong dissertation backed up by several quality publications. My research record enabled me to get a tenure-track position in a research university despite the very tight academic market at the time. This year, I am up for my tenure review, which I hope will lead to a positive outcome making me a tenured professor.

Now I am even more convinced that you cannot escape your destiny. If you are pursuing a hard-to-attain goal, it can be quite hard to keep your doubts away, particularly if you have other, perhaps easier to pursue, options. My decision to decline an attractive job offer to pursue the tenuous goal of completing my doctorate did not seem logical at the time. In fact, taken in isolation, it does not seem logical now.

On this 10 year anniversary of 9/11, my heart goes to Dan’s family–his memory will never be forgotten. But now I can say in all certainty that my irrational decision to persevere with my Ph.D. studies was the right one, and I feel fortunate that I made that decision.

Categories: careers, Uncategorized

Proving That Time is Not Money

August 20, 2011 Leave a comment

I have long realized that Benjamin Franklin must have been wrong when he stated that time is money. After all, money is a replaceable resource while time is not. However, I could not find convincing life examples that would demonstrate this point.

And then I realized that I have known personally or read about plenty of people who have lost financial fortunes but were able not only to restore but often to increase them. However, I have never met or known of a single successful person who has wasted massive amounts of time.

Recently, I have learned a fascinating story about a very successful individual whose prior business adventure collapsed after his business partner stole 1 Million US Dollars from their joint investment. Nevertheless, that individual was not bitter about his former business partner. Instead, he thought of his ex-partner as having taught him an important life lesson about how to be a better judge of character and place his trust in people more wisely. In other words, losing a large amount of money turned out to be an invaluable learning experience for him that enabled him to make much more money in his next business venture.

At the same time, I see how wasting time brings about bitterness. My definition of wasted time is paying a large opportunity cost, and in return not only failing to gain any tangible assets, but also failing to learn anything in the process. For example, spending a large amount of time and effort on writing a funding proposal incurs a significant opportunity cost. This time could have been better spent working on research or on developing teaching materials. If the proposal is not funded, it is frustrating; however, the time and efforts expended on it are not wasted if the reviews help you improve your proposal writing skills, thus learning valuable lessons. Therefore, to minimize waste in research proposal writing, one should not write an unsolicited proposal to an agency that does not provide reviews to the proposers.

Time and money are different ontological entities. It is important to allocate one’s pursuits wisely. Because time cannot be replaced, each of our pursuits must at least serve as a valuable learning experience.

Categories: Uncategorized