Get your own Free Home PageThursday, May 31, 2001 12:22:09 AM How to buy a book I tell this to all my students, so I guess I'll tell you, too. First of all, I don't recommend buying extra books if you're taking a class. The time to buy a book is when you are on the job, you have a question that needs answered, and you believe a book will help. If you're in school, buy the books they tell you to, and then go for more after the class, when the above situation appears. I have had varying results buying books over the internet, so I don't recommend it unless you already know which book you want. For example, you can buy The Unix System Administration Handbook, by Evi Nemeth et al, from anyone. I'd go to Fatbrain or to Amazon to buy the latest edition (3rd ed. at the moment), all other factors being equal. If I don't know the book, the ratings and reviews on the web pages are other persons' opinions which may not apply to me. The way I go about buying a book is to start with a question in mind. For example, I might want to know how to make a file archive of an Informix database without the intervention of database administrators, who would never give me the answer and who would take forever to get around to my request. As a system administrator, I find this an interesting and requested task. I would go to a real bookstore. Not a general bookstore, a good technical one. I've listed below some good technical bookstores I have found. At one of these bookstores I would go to the section dealing with Informix, and I would browse the books. Open them up, look at the tables of contents and the indexes, maybe see what was on the included CDs. I would try to answer my question. Many books, some of which have very good ratings from other people, would not speak my language. Let's think about this. If I bought one of these books at a 10% or a 30% discount, and it did not answer my question, I would still be looking for a book! So when I find a book I can read that includes the information I want to know, I buy that and forget about the price. There's no workaround. When I was the Information Systems Manager at Birr Wilson, the most popular spreadsheet was Lotus 1-2-3. It didn't have an auditing capability, and I noticed the finance and accounting people were putting original data where calculations were supposed to be. Since we were going for second-round financing the CFO and I decided to find out where the fudges were. I went to Stacey's and found a book called Macros, Menus, and Miracles for Lotus 1-2-3. I found a macro that did the auditing function I wanted to do, and I studied it. Then I went back to the office and tried to write my own. About half way through I was stumped, so I paid another visit to Stacey's. On my third visit I realized my foolishness and bought the book. I used about three macros, maybe five, but they more than paid for the book. If I had bought over the web constantly, without going to technical bookstores, I would have been cheating myself out of new experiences. For example, I would not have discovered that Sams is publishing an excellent series of books called "Teach Yourself ... in 24 Hours." Many of them have tools and example code on CDs included in the books. Good technical bookstores I have found: Stacey's Bookstore 581 Market Street San Francisco, CA 94105 (415) 421-4687 Stanford Bookstore 135 University Avenue (at High Street) Palo Alto, CA (650) 614-0280 Computer Literacy R.I.P., sold to Barnes & Noble
Mon 05-28-2001 9:45:40.17p The expert is the person who carries the tool kit. On TV in the early 1960s Paladin carried a business card that said "Have gun, will travel." Consequently, he was hired (on a contract basis) to clean up the West. I carry in my briefcase a flashlight and a screwdriver. They're not the proudest of my possessions, but over the years I have found it more convenient to carry them than to look for them at odd times and places. I went on an interview at Visa International in December, 1998. It was a formality; Dave Macfarlane had worked with me before. During the interview the power went out. It was a power outage that covered the entire northwest grid, but all we knew at the time was that we had 30 minutes to shut down the departmental servers before the "uninterruptible power supplies" ran out of juice. We went into a server room, and all was pitch black. I went back to the office and pulled my flashlight, and then I lit the keyboards as Dave shut down the systems. After that round of emergency work, the technical lead with us asked me when I could start. It's oversimplification, but I like to tell people I won the contract by carrying the flashlight!
Fri 05-25-2001 10:45:09.72p The best way to learn something is to teach it to someone else. In 1991 I had a year and a half of UNIX behind me when Cindy Wilkie asked me to teach new customer support engineers about the common problems and solutions that were encountered in my specialty. At the time my specialties were the core operating system, system administration, and network configuration. I organized a series of classes, and began presenting them as "brown bag specials" during the lunch hour. The phenomenal reception of these classes became the basis in my confidence in on-the-job training, and enhanced my reputation inside the company tremendously. It also made the role of customer support in these areas very clear to me. Consequently, I was able to provide outstanding customer service at a number of companies through 1998. Also in 1991 I presented a course in TCP/IP, NFS, and NIS to a group of employees at Hewlett-Packard. Although the competition among the members of this audience sent me reeling, I learned these protocols to a degree I never had before. I brought that experience to the forefront at Pyramid and SGI in 1995-1997, establishing a reputation as a communications specialist. In 1996 I ran an in-house training seminar on the SVR4 kernel at SGI. Before I left that company I was a participant in a regular weekly class designed to train customer support engineers. The "brown bag" days were over; we had a time slot on the regular business calendar. When I asked San Francisco State University in 1999 how I could help their UNIX/C/C++ Certificate Program, they asked me to teach. With my prior in-house training experience, this was the perfect way to step into the teaching world. As I continued to consult with major corporations, I cultivated my teaching skills at night. Because I had taught shell programming, I was completely confident when I was asked to work with a new programming language at Microsoft. Microsoft asked me to teach, as well. I ran a Monday afternoon class, again on the business calendar, in system administration, Perl, and CGI programming. This gave me new perspectives on the Korn shell, C, and C++ classes I was teaching at S.F. State. I have recently been called an "information technology Jedi knight," and consultants who have worked with me before are asking to take my classes. I know more about operating systems and programming languages than I possibly could have mastered without the imperative that I know them well enough to present them to someone else. The questions and observations the students have given me brought insights I might never have discovered on my own, and I have also discovered that hidden in my career has been the development of a genuine teacher.
Wed 05-23-2001 10:26:33.64p The expert is the person who is declared an expert. "Fake it till you make it" can be an effective way of life. Before you start thinking ill of self-proclaimed experts or consultants, let's take a look at how this works. When a person declares himself an expert, others around him immediately bring their puzzles in the declared area of expertise to him. As he sees the range of problems and does the research to solve them, he becomes the expert. I went to Rational as a Sun workstation expert, and that was all I expected to work on. Soon after I started, however, my supervisor declared that I would be the single point of contact for all problems that had the word "computer" in them. This was for a business unit of a computer software company! Before the contract ended I had become familiar with all the major vendors' UNIX systems. At that point the mystique associated with AIX and HP-UX were gone, and the idea of a universal operating system named UNIX was well entrenched. At SGI the managers declared a need for internal web sites, and asked me whether I had any prior experience in the area. What had been a hobby of maintaining my personal web pages suddenly became a differentiating expertise. I set up a web server and became the webmaster for two internal sites. For several months I maintained an internal regional support site, and I also maintained a cultural ethnic diversity site. There have been times when I interviewed for positions and disqualified myself by saying I did not have enough experience to be comfortable with the job description or the skill set. This certainly was legitimate, and I take pride in dealing honestly with my clients. There have been times when I interviewed for positions and felt that the job description or the skill set was well within my capability to learn and master. This was also legitimate, and as I explained what related experience I could draw upon, I always let my clients make their own decisions whether to ask me to proceed. Usually if they decided to let me grow into the positions I succeeded.
Tue 05-22-2001 10:57:11.72p Here's a comment on comments. Even though you may only be planning to satisfy an immediate need, the chance that your code will outlive your job is very high. One thing that bothered me on some jobs was my inability to determine where a program came from, what it did, and how old it was. There was a file, sitting in a directory somewhere, doing I didn't know what. Was the date on the file the date it was put on the system? Had it been touched or modified? Did it do what it was supposed to do? A look inside would reveal very little:
I mean really, what was that supposed to do? Who should I contact to find out more? Were there copyright restrictions? Had it been tested for bugs and security holes? Was it performing some mission-critical job, like calculating some billing information? Here is a program whose comments I like:
This program is signed and dated. I know how old it is, and I know who to go to for more information. The comments even tell me what the program is intended to do, and how! Is it copyrighted? Read the comments! Comments help you understand what another programmer intended to accomplish, so you can understand whether the program is running correctly. Comments can help you understand what you are trying to accomplish -- if you aren't clear about your goal, describe it in comments first. The comments can then be used as your program specification. If the program is distributed as source code, you can even include instructions to the installer in the comments. I have seen entire man pages in comments; Perl comments written in POD actually become the man pages. Comments can even be used for a little inside joke. I have seen a manifesto in freeware source code. I have even seen poetry in SunOS source code! So comment early, and comment often.Mon 05-21-2001 8:06:12.96a In 1984 I attended Dean Gary Williams' seminar at the University of San Francisco on business ethics. One question has stuck with me through the years: "What would be the price of oil if all future generations could bid on it?" Most of us thought that oil would become priceless, because as it became more scarce, its users would bid up the price. This question has become relevant again as the power companies in California have implemented their rolling blackout plans, and the so-called "scarcity" of electricity has made national news. There is no scarcity. The real problem appears to be that the companies that are trying to maintain their monopoly in producing power, and the public who are trying to diversify the production of power, are at odds. Alternate energy sources were proposed and tested thirty years ago, yet they were not agressively developed because electricity was too cheap to fund the development. That's the story, anyway. In the 19th Century we had automobiles that burned wood to create steam. They pre-dated the internal combustion engine, and it is because of their technology that we even use the words "internal combustion." Few people today would bid on a wood-burning steam-driven automobile. We can't use it. Similarly, I believe that at some point in the future, oil will no longer be valuable because, as it becomes more rare, the technology to use it will cease to exist.
Sat 05-19-2001 10:06:14.90p A strange thing happened this week that made me stop and think. At school the students fired an instructor. It's interesting, in a time when a large number of them recently have been laid off, that they would do such a thing. But quality and customer satisfaction are the name of the game. In the 13th Century the University of Cambridge was established by and run by students. In the 20th Century, when a college education almost became the minimum requirement for entry into the white-collar job force, the colleges and universities became the territory of bureaucrats. But my school has a commercial goal; it's an extension, not part of the main campus. We have a professional, non-academic curriculum. And because we know the students are our customers, the administration responded to their voiced desires quickly and with positive action. It reminds me of the principles of Tom Peters, applied to a novel industry. Yes, education is an industry, and a booming one at that. Hmm ... I wonder why?
Fri 05-18-2001 8:52:49.38p How does one go about setting a price for one's labor? In How to Be a Successful Computer Consultant, Alan Simon recommended a method that began with the amount the consultant would make working as a full-time permanent employee, and then factoring in risk, downtime, overhead, and so forth. I believe marketing people call this cost-plus pricing. It seems to assume that the consultant would know what his or her time was worth. Simon proposed this method in 1985. How does one know what one's time is worth? Salary surveys abound, but most of them were made at least a year ago, and the market is a moving target. That same year, in Become a Top Consultant, Ron Tepper gave a number of different pricing techniques. His advice was a little stronger than the technique I have followed in the past. I used a technique I call sail trimming. When I was learning to sail I found out that the wind was always shifting slightly. Even though you had your sail set perfectly one moment, in five minutes it might be out of whack and you might not be getting the full thrust from the wind in your sail. So what you had to do to get the most out of your sails was trim them constantly. You may have had a little pennant, and if you did, you watched the pennant. Whether or not you had a pennant, you also watched the way the wind was moving in the sail for any sign that the sail was not being filled. When the sail was filled, you slowly pulled it in until you saw these signs, and then you let it out slightly. That was sail trimming. I did the same thing for my own time valuation. The market was constantly shifting, and it went up and down. If I stayed too rigid in my rates I could be out of contract for a long time, and not billing is a very fast and efficient way to lose money. On the other hand, if I billed too little, then I would be grabbed up immediately by the first customer who talked with me, because he recognized a bargain when he saw one. Then my time was locked up with him, and I was billing less than market rate for a long time. This was not a way to lose money, but it didn't make all the money I might have, had I billed a slightly higher rate. So when I was on the market I stated a rate that was slightly higher than my previous one, say by five dollars an hour, and saw whether there was a customer who would like my services at that rate. If there wasn't, I knew because I was on the market for a month or so without getting any offers. So then I would lower my rate about five dollars, and start over. Eventually my rate would match the market rate, and I would get a contract. Sometimes the process sped up a little when I encountered a customer who was savvy enough to make a counter offer that was acceptable to me. I called this sail trimming, but I think marketers call it perceived-value pricing. If you're wondering whether this technique kept me out of contract too long, you should know that I have never been out of contract for more than ten weeks. I have seen some other contractors out of contract for six months or more.
Thu 05-17-2001 10:39:20.18p Most system administrators agree the most important system admin task is making tape backups. However, many of them forget that it's the restore that's the objective, not the backup itself. One site I walked into had plenty of backups, and a nice script that sent email to the system admin group each morning with a "backup successful" report. When I sampled a tape I found out it was blank. Further investigation revealed there had not been a successful backup for four months! After I straightened out that problem I made an arrangement with an engineering manager to play a little game with me. He would send me email once a week asking me to restore a file that he picked at random. That gave me a chance to spot-check the tapes for quality control. Lots of little things came out of this game, most of which improved the backup strategy over time. I think I got this idea from the UNIX System Administrator's Handbook, by Evi Nemeth et al. I've seen several companies struggle over massive backup software that seems to take over the entire network, and then takes forever for new people to learn and understand. On the other hand, some of the most successful backup strategies are made with software that comes free with the operating system. The ufsdump utility is my favorite. It's a tape backup utility that comes with most UNIX systems, and it's usually free. At a medical instrument company a CFO contracted me to make sure a reliable backup strategy was in place. He asked me to do whatever it took to get the tapes rolling. A software engineer who worked at the site had been evaluating commercial backup software, but the backups weren't being made yet. After I started making periodic backups, the engineer noted that all I had done was set up a ufsdump as an automatic system-initiated task. Yes, I agreed, and that was all they needed!
Wed 05-16-2001 8:34:16.81a When you shift from a non-technical background to a technical job, give yourself credit for the experience you already have. Some of my most valuable skills (in practice, if not in managers' minds) are the ones I have acquired in other career paths. I walked into a shop one morning and found a note on my desk asking me to find a backup tape for a demo workstation that was headed for a trade fair in a couple of days. This workstation was unique, and had suffered a disk crash the day before. I walked into the room where they kept the backup tapes, and found piles of tapes all over the floor. The three shelf units on the south wall stood empty, but there were little piles of tapes everywhere, with walk space in between. Obviously, someone had already tried to find the critical tape. I decided this was an excellent opportunity to sort and organize the tapes! I began putting them on the shelves, grouped by backup server, ordered by backup date. When I was finished sorting the tapes I had the one I was looking for in my hand. Mind you, I didn't stop sorting when I reached the target tape -- it only took another 30 minutes to finish the job. At that point I could pretty much reach out and pick any backup anyone would ask for. Then I went to the demo workstation and restored the project files. That afternoon I talked with the manager in charge of the demo project, and I asked him how he valued the data. "Let's see," he said. "I've paid three programmers for two months to get this demo for the trade fair, so that would be about $60,000." That was just the development cost; imagine what the loss in sales would have been without the demo! What skill came into play here? The ability to sort and organize the tapes, something I picked up from my clerical background! It had nothing to do with my technical skills or my knowledge of UNIX!
Tue 05-15-2001 9:01:20.73a Here are a few notes for Mike Steiner, because we discussed some of these topics at lunch yesterday. Publishing is in the news these days. First up: the inspiration for this journal was "Can Digital Media Match the Longevity of Plain Old Print?" by Neil McAllister, a journalist for SF Gate. In it he mentions the various digital media that have evolved in the last 20 years, and points out that most of them are inaccessible today. I am reminded that archaeologists are reading papers left behind by the Romans at forts along Hadrian's wall. Will they be able to accomplish the same with, say, QIC-150 tapes two millenia from now? Second item: an MIT alum discusses "Computer Source Code as a Form of Expression." In this article Omri Schwarz proposes that source code deserves free speech protection, and presents a convincing illustration of the evolution of high-level programming languages as natural languages. Third: We have Richard Stallman of GNU fame on "Copyright and Globalization," explaining the need for change in copyright law and where he thinks it should go, considering modern changes in reproduction technology. In addition to a lesson in the history of copyright, we also get a healthy rant against free trade. [ 1/1/2003: The web server carrying Stallman's article at MIT has been decommissioned. Stallman's article has been moved or lost, proving McAllister's point all too clearly. --ddull ] Last, but not least: Readers of the San Diego Union-Tribune sent an article to Slashdot in which it is noted that the law can carry a copyright. If you've ever sat on a jury you'll be interested in this one! Then again, I find that my favorite copy of The Constitution of the United States bears a slew of copyrights by Harper & Row. So ... copyright law evolves case by case, has some general principles which can be enforced or violated by the courts, and is little understood by the common man (that being me). What constitutes "fair use" is extremely contentious today. Never mind that the First Amendment, without which the States would not have established the Union in the first place, prohibits "abridging of the freedom of speech," without any qualification or excuse. Ah, well, the nation is yet young. We have yet for the tired populace to give up trying to run itself, and to establish the triumvirate, from which a triumvir can declare himself emperor and ... no, wait, that was Rome. We still have the two-term limit for the executive branch -- Franklin Roosevelt did not turn out to be Augustus Caesar -- and a lot of growing to do in the future.
Mon 05-14-2001 12:11:33.32a The expert is the person who bothers to read the manual. When I first interviewed for my first major contract, I didn't know UNIX much at all. I had played a bit with a BSD 4.2 emulator running under Primos at San Francisco State University, and had looked at the SVR3 operating system running on an AT&T personal computer made by Olivetti, but I wasn't confident enough to do anything in system administration. Here I was being interviewed for a technical support job, where I was expected to tell customers what to do. I went down to the UC Berkeley library, where I had staff privileges, and browsed the stacks. I found the Kochan and Wood classic, UNIX System Administration, checked it out, and read it cover to cover. At the interview I didn't do very well, but I recognized a few situations and recited what I had learned from the book. A few weeks later I got a call back. I checked out the book again, and read it cover to cover again. This time the questions from the first interview made some of the chapters stand out. At the second interview I felt I had done a passable job, but the second-level interviewers were also interested in whether I knew C programming. The recruiter told me I was gaining favor and that I should prepare for a third interview. I went to Cody's Books, just off campus, and bought my own copy of UNIX System Administration, as well as The C Programming Language by Kernighan and Ritchie. In the third interview when I was asked whether I could program in C, I was able to say that I had read Kernighan and Ritchie and that I could read the code. The client decided to give me a six-week trial contract. I stayed there for 19 months.
Sun 05-13-2001 7:22:18.51p One of the most common mistakes I have done is buy into my customers' trips. As a customer support engineer it was easy to do. I was required to listen not only to the customers' descriptions of their problems, but also to their theories and everything they had tried so far, in order to move on to the troubleshooting process. Usually valuable clues appeared in their narratives, but often their narratives would be so complete and well-thought-out that listening to them would make me forget the fundamentals. It usually turned out the biggest problems were like magicians' tricks. They existed because everyone was looking in the wrong direction. What would be something fundamental and would emerge in the early stages of a trained, orderly investigation, would be overlooked because of questions and obsessions posed by the customers. I remember a half-hour discussion I had with someone about a printer problem. I asked him somewhere through his narrative whether the printer was actually on line, that is, receiving data to print. He assured me it was, and we proceeded with an exhaustive software configuration troubleshooting procedure. After thoroughly checking all possible settings in the printing software, I asked him to print out a simple text with a procedure that bypassed the printing software completely. Then I asked him if the print came out. The printer was in a room down the hall, and the customer was away from the phone for about five minutes. When he returned, he said to close the case, because he had discovered the printer was not on line! The idea not to buy into the customer's trip can be more subtle and harder to enforce when you are at a customer site for the specific purpose of helping him or her through a problem. Most of my contracts have lasted for months, several for more than a year, and it has not been easy to keep in mind my purpose for being there. Customers can try insane metrics, set impossible deadlines and milestones, and generally make themselves miserable in an attempt to improve their lot. When I have internalized these attempts, I have often found that I have become miserable with them. Over time, and through many little examples, I have found it is much better to remain calm, and to rejoice in my independence. The quality of service rises and falls according to human factors, not metrics. The jobs get done in the same amount of time whether I push and raise my anxiety level constantly or relax and let things happen in their own time. My job, for me, is to remain calm and to do whatever I do the best I can. All else follows naturally. The most admirable trait I have heard on the street about Dawn Lepore, the Chief Technology Officer of Charles Schwab, is that she remains calm at all times. I can choose whether to worry about things I can control. If I choose not to worry, I look better to my customers, and they perceive that I am more valuable to them.
Sat 05-12-2001 9:17:57.74a This log is dedicated to Leia Stinnett, to whom I promised to publish my book before the end of the year. On the web, everyone's a publisher. Hi, Leia!
Sat 05-12-2001 9:07:12.59a Tom Peters, in In Search of Excellence, studied business from a high level. Robert Townsend, in Up the Organization, expounded on his own executive prowess and everyday front-line business practices. People like these seem few and far between, but they are just like you! Chances are you don't know you're millionaire, paid in stock instead of cash, and you are interested in seeing your next check so you can make your payments on your car and your apartment. If you're in the computer field the car and the apartment may be pretty nice, and if you're not, then you might be thinking of moving into it so they can be. I'd like to share with you the thoughts of a rank-and-file soldier in the computer industry. I'm a guy you might find in cube 11-201 somewhere on the east side of the building, "toiling away" at the keyboard. Sure, the sweat may not be from hard labor, but if you look closely, the sweat is definitely there. Just as the mighty steam engines of the Industrial Age had their oilers, the mighty computing engines of the Information Age have their programmers and system administrators. These men and women, the unsung mechanics that assemble, maintain and repair the systems on which business depends, are nearly invisible. But they are vital, just like the countless unnamed oilers that crossed the country in the 19th century, keeping the trains running one piston at a time. These people whom we call "geeks" are ordinary men and women in ordinary circumstances. If you aren't one, you can be assured that the oilers of the information age are really just like you.
Fri 05-11-2001 8:43:24.30a The average tenure of a computer professional in a Silicon Valley company is two years. Some people resent their companies, thinking that there is something wrong because of the high turnover rate. That's a little narrow, though, because the change in corporate culture has gone both ways. Managers may not think of their employees as anything but the positions they were originally hired for. If you came into the company as a mail clerk, you're a mail clerk. Forget about being CEO and Chairman of the Board, they already have one. If you want to move up in the world, your bet is better at another company. Rewrite your resume so that it shows you've done the job already, even though the job title wasn't the same, and convince someone you haven't seen before that you are the right person for the job. Because you can do it, and you have done it. Along the way, you'll convince yourself, change your lifestyle, and get a raise. If you stay at the company where they thought you were the mail clerk, your pay may rise just enough to keep up with inflation. I do know of CEOs who started in the company mail room. I believe the CEO of Visa USA claimed this path. However, it is a rare phenomenon. You can go that route if you want to, but the numbers are in your favor if you look at your job changes as your opportunities.
Thu 05-10-2001 9:23:08.46a It's amusing to see in Business Week comments about the possibility of a recession and how this is the worst economic period since 1991. Well, let me tell you about my 1991. In late 1990 life was a little nervous at Sun Microsystems. Front-line management turned over a couple of times, and several experiments were made in getting more work out of the technical support engineers. One involved a statistical process method that stumped the generalists with its obscurity and amazed the engineers with its irrelevance. A book had just been published, The Electronic Sweatshop, and although most of us didn't read it, we liked the title. Sun managers were apologetic, but basically relayed the news that the budget was tight, and eventually they took us from three-month contracts to two-week extensions. I saw the light and, with 19 months of UNIX experience under my belt, I started looking for new opportunities. Several weeks of interviewing netted me a six-month contract at Xilinx. They saw me as a demigod because I had lived at the fountain of Sun Microsystems' knowledge. During my time at Xilinx I learned quite a bit about heterogeneous environments, which helped me separate what I knew of SunOS with what was UNIX in general. It also familiarized me with MS/DOS, the Macintosh, and 10Base-T wiring, so I was actually better off than if I had stayed in customer support at Sun. Xilinx approved overtime, and I was working 65-hour weeks for a while. It was outstanding money! In June I moved to Rational. They had been looking for a permanent system administrator for five months and couldn't find one. I came on a temp-to-perm agreement, which was a situation where we made friends and helped each other out, reserving the decision to hire until we got to know each other better. Rational was a private company at that time, was developing new software tools, and didn't have the frantic production pressure I had seen at Sun and Xilinx. In this environment I made friends with the IBM RS/6000, and was able to move from San Francisco to Sunnyvale without serious job pressure to distract me. We installed an early version of X/Runner from Mercury Interactive, which gave me some experience troubleshooting application software and communicating with the developers in Israel. It was fun staying late at night so we could talk with people on the other side of the world. In October I returned to Sun. Contractors who would have received the boot the same time I did were still there. One asked me what I was doing there, and I told him I had just signed a contract. He told me that all the contractors were being flushed at that time, and he was very surprised to see me! The permanent employees were complaining about the tiny raises they had been awarded, which seemed to barely cover inflation, and the contractors felt happy to have preserved their rates. I, on the other hand, had moved through two other companies, had gained valuable outside experience, and had raised my rate 15%. I didn't know it at the time, but this was the beginning of an 18-month relationship with Sun. It would be nine years before I got the news that I had lived through a recession.
Thu 05-10-2001 8:21:14.06a A blog is a "web log." Sometimes I wonder why I missed something this significant. They've been around for years. I just learned about them from the 5/8 column by Neil McAllister on SF Gate. So here's mine!
Return to David's Home Page
Get your own Free Home Page