Interaccess had been founded four or five years earlier by a young man named Tom, who had borrowed $60,000 from his father to get the business started. The company had around a hundred employees and primarily provided Internet access to small businesses. Unlike today, when a particular area might have only two or three major Internet service providers, the Internet was still a novelty back then, and many small companies offered Internet services. There were probably more than a dozen such companies in Chicago. Interaccess had about 20,000 customers at the time, making it a fairly successful company, somewhere in the middle-to-upper tier of the industry.
Competition was fierce, so companies had little choice but to attract customers by cutting prices. Even providing Internet service to a business with a few dozen employees cost only a few hundred dollars a month, making it difficult to turn a profit. The company had to save money wherever it could, and one way was to keep wages low.
Interaccess had grown by acquiring smaller companies. When I joined, the company was preparing to move from its haphazard, inconsistent systems, which had developed during its early years, to PeopleSoft. PeopleSoft required an Oracle database to run, so the company purchased Oracle software and hired a consulting group to carry out the system conversion. Once the project was completed and the consultants left, the company would need someone to operate and maintain the Oracle database. That was why it needed to hire an Oracle DBA.
At the time, an Oracle DBA with several years of experience could command a starting salary of at least $100,000 or more. Even someone with just one year of experience would not accept a job paying less than $70,000 or $80,000. On top of that, at a small company like Interaccess, the DBA had to be on call twenty four hours a day, seven days a week. Few people were willing to take such a job.
The company wanted to save money while still hiring someone with the necessary technical skills. After several months of searching without success, it finally changed its strategy and lowered its experience requirements. The company was planning to bring the Oracle system online in December, four months after August, and hoped that a new DBA could quickly acquire the necessary skills within that time.
Under this new approach, they hired me at an annual salary of $40,000 and agreed to sponsor my H-1B visa and green card. That was very important. Many companies would not even interview applicants once they learned that the applicants did not have permanent residency or other suitable work authorization.
Later, I asked Ari, the consultant who had interviewed me, why he had hired someone with absolutely no experience. He replied, “I had the feeling you were the kind of person who could learn things quickly, so I hired you.”
I had no idea how he had figured out that I was a fast learner. But Ari really was impressive. He was Jewish, not yet thirty, and already a senior consultant who worked with several companies at the same time.
Because Interaccess provided Internet services, its databases had to run twenty-four hours a day, seven days a week, 365 days a year. There was no downtime. Whenever something went wrong, it had to be fixed quickly. Being a DBA was an extremely stressful job.
If I had had any other choice back then, I certainly would not have accepted it. To make matters worse, my family was still living in Milwaukee, ninety miles away from Chicago, so I had to spend about four hours commuting every day. It was exhausting.
There were very few Chinese employees at the company—only three of us.
One was a young man around thirty who maintained PCs and lived in Chinatown. Although he was an American-born Chinese, or ABC, his outlook was remarkably old-fashioned. He found a girl from Chinatown and married her. Their wedding was an extremely traditional Chinese affair, complete with a bridal sedan chair, a convoy of dozens of decorated cars, the formal wedding ceremony, red envelopes, and the traditional post-wedding bedroom festivities. He even showed photographs to his coworkers. The American employees were bewildered: “Does getting married have to be so complicated?”
He replied, “Of course! Otherwise, people will look down on you.”
He had joined the company when it was first established and was considered one of its founding employees. He did not socialize much at work, and he certainly did not make much effort to talk to me. Unless there was a specific reason, he would never strike up a conversation. Even when something needed to be discussed, he would stick strictly to the matter at hand and leave as soon as it was settled.
The second was Li Peizhong, who worked in IT support and had been with the company for about a year. He was from Jiangsu Province and a few years younger than me. Like me, he had come to the United States to study. Because our backgrounds were similar, we got along very well. We were good friends then, and we have remained in touch to this day.
The third was H, who had come from Taiwan. He was about twenty-seven or twenty-eight, fair-skinned, and neatly groomed. He had graduated in computer science and worked for several years as a Unix system administrator. Three months before I joined the company, Interaccess had hired him at an annual salary of well over $100,000, making him one of the highest-paid employees. That alone showed how important his position was and how highly the company regarded him.
He was a little shy but polite and modest. Everyone was busy, so we did not have much time to chat. Still, after talking a few times, I had a good impression of him.
Because he earned so much and was single, he rented a studio apartment near the company. I heard that it cost him $1,500 or $1,600 a month, which shocked me. My entire family, by contrast, rented a two-bedroom apartment for just over $500 a month.
H was technically capable and ambitious. He wanted to make a real contribution to the company.
Interaccess had expanded by acquiring smaller companies. In those days, many small businesses had been launched in a hurry, and their computer systems were rudimentary and inconsistent. Every acquisition required another round of system integration. As more and more small companies joined Interaccess, its overall system became a hodgepodge, and operational problems became increasingly common.
Reorganizing the entire system would require taking it offline for an extended period. That was impossible for a company that had to provide services around the clock. So the company had no choice but to keep the system running despite its problems. Whenever something went wrong, people patched it up as best they could. As long as it kept working, that was good enough.
H was the company's only system administrator. He was eager to resolve the system's underlying problems, and that was one of the reasons the company had hired him.
He spent a long time thinking about how to untangle the complicated, disorganized system. Eventually, he seemed to develop a plan. But apart from occasional maintenance windows on weekends, the system could not be taken offline during the week. So he decided to use a weekend to try to overhaul it according to his plan.
It was a Saturday. He arrived at the office early in the morning and began making the changes he had planned. But instead of improving the system, his changes made it worse. Even more disastrously, he could not restore it to its previous state.
He spent all of Saturday trying to fix the system, then worked through Sunday as well, but still could not get it running properly. By Monday, the entire system was still down. He was frantic, like an ant on a hot griddle. By noon, he still had not managed to restore it.
Meanwhile, the customer service lines were being inundated with calls, and the crisis had reached the company's president, Tom.
The company urgently brought in consultants to help, but the problem appeared to be serious. By the afternoon, the system was still down.
In a fit of rage, Tom fired H on the spot and even called the police to escort him out of the building. Poor H was thrown out without even having a chance to say goodbye to his coworkers. I never saw him again.
I had been at the company for only two months when this happened, and it shook me deeply.
I had worked as an educated youth sent to the countryside during the Cultural Revolution, and I had nearly ten years of work experience in China before coming to the United States. I had enough real-world experience to understand the stakes. After joining Interaccess, I had already worried about the enormous responsibility of being a DBA: one mistake could bring the entire company to a standstill.
What happened to H made me even more frightened. If I made a serious mistake, I could easily end up in the same position he had.
After joining the company, I concentrated on learning. I devoured books about Oracle, hoping to master the necessary skills as quickly as possible.
One book was written by a veteran DBA with more than a decade of experience. The author stated that two-thirds of Oracle problems were caused by improper actions taken by DBAs themselves. He therefore recommended touching the database as little as possible.
When a problem required you to adjust the database, he advised, you needed to have a clear understanding of what you were trying to achieve. An ideal outcome was often impossible. Once you had achieved, or come close to achieving, the desired result, you should stop rather than keep trying to make things perfect. Otherwise, you might push one problem down only to have another pop up, potentially creating new problems—or even bigger ones.
The author wrote a sentence that I have never forgotten:
“Doing nothing is better than doing the wrong thing.”
It was the exact opposite of the saying Americans seemed to love: “Doing something is always better than doing nothing.”
What had happened to H seemed to confirm the veteran DBA's advice. H had good intentions, but he had been careless. Before making changes to the system, he should have sought authorization. If he had not received approval, he absolutely should not have proceeded.
Furthermore, he should have made only small adjustments rather than attempting a major overhaul. If he had left the system alone and simply kept it running, the company would have had little reason to blame him, even if the system continued to have occasional problems.
If a major overhaul was necessary, the company should have hired a professional consulting team to carry it out. H could not reasonably have been expected to shoulder that level of responsibility on his own.
After H's disaster, I came to understand that a DBA's primary responsibility was to keep the database running, not to make it run as perfectly as possible. Anything that threatened the database's stability should be avoided whenever possible.
Databases are extremely complex. A seemingly minor change can affect the entire system. People are much the same: many people have all sorts of shortcomings, yet they can still work and live their lives. If a system is imperfect or has some problems but can still do its job, you should not tamper with it unnecessarily. Often, the best choice is to leave it alone.
This kind of judgment—understanding the situation and knowing when not to act—is something schoolteachers do not teach you. Perhaps many of them do not know it themselves. Yet it is extremely important in a professional career.
Later, when I worked as a DBA, I generally followed this principle, although I did make one mistake.
On one occasion, I was trying to solve a problem. Following a recommendation in a book, I changed a database parameter and made a few other minor adjustments. Initially, everything seemed fine. But three hours later, the database began behaving abnormally. It was still running, but some functions no longer worked properly.
I called Oracle Support. Over the next several hours, several support engineers took turns looking into the problem, but none could identify its root cause.
The vice president in charge of IT kept coming over to ask how things were going. He even stood behind me for long periods, watching me talk on the phone. The pressure was immense.
Fortunately, the problem had not yet interrupted service to our customers. Otherwise, the consequences could have been disastrous.
When the workday ended, the vice president told me I could not go home until the problem was resolved. I stayed in the empty office without even eating dinner. I tried every possible solution, but nothing worked.
Then, sometime after nine that evening, I suddenly remembered the parameter I had changed that morning. Could it have caused the problem? I could not think of any convincing reason why it should have, but I decided to restore its original value anyway.
The moment I changed it back, the database returned to normal.
Computer systems often behave in mysterious ways that are difficult to explain.
I did not get home until midnight that night. The ordeal had frightened me so badly that I barely slept. The next morning, I could not get out of bed, so I called in sick. Even so, I kept my phone close at hand, ready to respond at any moment if another emergency arose.
After that experience, I believed even more strongly in the principle that doing nothing was better than doing the wrong thing. I stopped changing database parameters casually.
Most days, I spent my time reading rather than constantly typing away at the keyboard. And the database stopped giving us trouble.
Unfortunately, the good times did not last.
A new manager joined the company. He was a Yale graduate, about thirty years old, young and pleasant, and I will call him B. He had not studied computer science, although he had taught himself a little and understood some of the basics. Still, he was not quite equipped to manage a group of technical specialists like us.
After he arrived, he worked very hard. He noticed that other employees seemed to spend all day typing away, while my area was quiet, with hardly any keyboard noise. He could not help asking why I was not working and was just reading books.
I explained that I only needed to take action when necessary. When there was nothing that needed doing, I studied technical books. The more I understood, I told him, the fewer mistakes I would make.
He looked puzzled. “Don't you think you're doing far too little work?”
I explained that if the database was running properly, it was best not to touch it. I even showed him the passage in the book stating that two-thirds of Oracle problems were caused by DBAs taking inappropriate actions. Even then, he remained skeptical.
One day, during a meeting, he criticized me indirectly, saying that someone was not working hard and did nothing but read books. I felt I had been treated unfairly, but there was little I could do about it.
Later, when some technical issues involving the database came up, he made several inaccurate remarks that revealed his limited understanding. I had no choice but to point out where he was wrong. He was somewhat displeased and insisted that his interpretation was correct, but I refused to back down.
He obviously knew that I understood the subject better than he did, so he eventually dropped the argument. We did not end up having an outright confrontation, but the atmosphere was unpleasant.
In my first annual performance review, he listed both strengths and weaknesses. There were plenty of areas he said I needed to improve, and he even included my poor English.
Being the company's only DBA was extremely demanding. I had to carry a pager every day, and later a mobile phone, remaining on call at all times. I scarcely had a genuine day off.
But there was one advantage: no one except me was allowed to touch the database. Once I had tuned it into good shape, it stopped having problems.
As I gradually brought the database to a more stable state, it went a long time without any further incidents.
When B first joined the company, whenever a system problem arose, he would call me and ask whether the database was at fault. I would tell him that the database was fine. Each time, after checking, we found that the problem lay elsewhere in the system.
After a few such experiences, the company changed its procedure. When something went wrong, people would first ask the system administrator to investigate rather than coming to me.
Then, sometime in the winter of 2000, I was playing volleyball in Milwaukee on a weekend. I jumped up to block a shot, and another player who did not know how to play jumped sideways into me. As I landed, he stepped heavily on my ankle before I had regained my balance. I immediately found myself unable to stand.
That evening, my leg hurt as though it were cramping, and no matter how I positioned it, the pain was severe. The next day, I noticed that my ankle itself was not particularly swollen, but my entire lower leg was covered in bruises.
I went to the emergency room and had an X-ray, which showed no fracture. The doctor told me to go home and give it time to heal.
But when I got home, the pain was still unbearable, and I could not walk.
I called B and told him that I had injured my leg and could not come to the office. He reluctantly agreed to let me work from home.
A week passed, and I still could not walk. B began to doubt whether my injury was really that serious. Eventually, using an all-company meeting as the reason, he sent a car to pick me up. I had no choice but to go to the office on crutches.
Three months later, my leg was still very painful, and even after a year, I continued to experience a dull ache. During that time, I consulted three orthopedic doctors. They all told me there was nothing else wrong and that I simply needed to wait for it to heal.
But after such a long period of being unable to walk normally, my ankle had become stiff, almost wooden.
It was not until a year and a half after the injury that I saw a Chinese massage therapist in Chicago. After examining me, he confidently declared, “This is definitely a tear in the interosseous muscle. It was mistaken for a sprained ankle.”
I later looked up the condition online and found that my symptoms matched those of an interosseous muscle tear very closely.
Meanwhile, I continued working toward my Oracle certifications, taking an exam every four or five months and passing every one on the first attempt. Each time I passed, I reported the result to B. He always seemed a little surprised, but he duly submitted a request for a salary increase in accordance with company policy.
Whatever B thought, I continued to follow my own version of wu wei—the Taoist principle of non-forcing or non-interference. I rarely touched the database unless necessary. As long as it ran reliably, that was good enough.
One day, B came to me and asked me to retrieve a particular set of data from the database.
I had never done that particular task before, but it did not seem difficult. I invited him to sit beside me and began writing SQL queries.
After writing each line, I explained what it did before executing it. I then examined the results, modified the SQL command accordingly, explained the next change, and ran it again.
After about four or five rounds of adjustments, we obtained exactly the data we wanted. The whole process took less than five minutes.
He seemed satisfied. He took the results and left without saying anything.
I do not know whether he had deliberately come to test my abilities. But from that day onward, he never again asked me why I was not working, and he stopped arguing with me about technical issues.
His annual performance reviews of me became uniformly positive, full of praise and containing no criticisms at all—not even about my English.
I soon passed all the Oracle DBA certification exams, and the company's database continued to run without problems for a long time. My annual salary gradually increased from $40,000 to $70,000.
B even took the initiative to tell me that I no longer needed to come to the office every day. I could come in two or three times a week and work from home the rest of the time. Before long, I only needed to go in once a week, on Fridays, for the weekly meeting.
My job was to check the database's operating status a few times a day. In essence, I was doing almost nothing.
Most of my time was spent reading, browsing the Internet, or taking walks near my home. The company mobile phone barely rang a few times a month, usually about meetings or routine matters. Not once did I receive a call about a database failure.
It seemed almost too good to be true, so perhaps Heaven grew jealous of my good fortune.
In 2001, the company was acquired by another business, and layoffs began. By 2002, many employees had been let go. B was laid off in the summer, and I was laid off in October. Soon afterward, the company filed for bankruptcy protection, and a few months later it shut down for good.
But that is another story.
“Doing nothing is better than doing the wrong thing” is not a principle that applies universally. Nevertheless, there are times when it is exactly right.
Apart from jobs like database administration and system administration, the area where I have applied this principle most often is stock investing. I buy stocks in companies with long-term growth potential and then leave them alone. It makes life easier, and the results have been reasonably good.
The principle reminds me of the Taoist idea of wu wei, though it is not quite the same. Either way, it is a philosophy of life—a lesson you cannot learn in school.
Written in 2018.






