Get your own Free Home PageWednesday, June 20, 2001 9:23:42 PM Are you going to write programs for a living? Do you think that programmers pound out code day and night? Actually they spend most of their time reading code that already exists, until they understand it, and reading on-line manual pages. They experiment with little side programs a lot, determining correct behavior for little routines like functions, system calls, testing and branching, before they put code into the programs they're writing for a project. Typically, I will have three windows open when I code. The first window will have an editor running, in which I'm writing the code that is going into the project. The second window will have an on-line manual page in it, describing the function I am considering for use in the project code. The third window has a shell, and in it I compile, run, and debug the project code, and make up little test programs to learn what the manual pages are supposedly telling me. In today's environments I'll also have a web browser up, referring to web documentation of whatever package I might be using or writing to. I could spend thousands of dollars to get an integrated development environment (IDE) like Forte, but usually the core functionality of the IDE is what you would find in the windows I'm already using. There are lots of nice extra features in an IDE, of course, and once you've spent a little time programming you might really appreciate them. On my real desk I'll have a book or two on the programming language, at least one of which will have working examples, and one that actually defines the language. For instance, if I'm writing in Perl I'll have Teach Yourself Perl in 24 Hours, Programming Perl, and the Perl Cookbook, all open, highlighted, bookmarked, and dog-eared. When I worked at Join Systems, the V.P. of Engineering asked me to modify some code. The idea was to get a program to change the way it logged data. There were many files in this program, and it took me about three days of reading and interpreting the files to realize that all the logging was done in a set of functions contained in one file. My work collapsed from changing all the references to logging functions in all the files, to changing the functions in only one file! It took me about a day to change the functions, and then another three days to test the new code and correct all the typos and minor errors. When I worked at Microsoft bCentral one of my responsibilities was to write configuration files for cfengine, a cutting-edge network management program. It took me about a month of reading the web materials on the product to understand how the configuration files worked, about a week to write and demonstrate the files, and then another month to install them. Debugging the files after they had been installed probably would have taken another two months.
Saturday, June 16, 2001 10:20:03 PM How to start a new project Projects, projects ... it seems like my whole life is projects. One thing I have learned is that I don't get the whole picture of a project sitting at my desk replaying what others have told me they want. It has to coalesce sometime, and that usually happens while my mind is relaxed. Often when I am thinking (some call it daydreaming) about the way things fit together it helps to browse the UNIX System Administration Handbook, by Nemeth, Snyder, Seebass, and Hein. Their advice seems to help me gain a lot of perspective. Another thing I have learned is that most projects don't meet their original timelines, no matter how well managed they are. Even if I hold up my end of the deal someone else may change the requirements at what I perceive as late in the game. When I think about designing or troubleshooting a system I walk end to end with a pencil on paper and try to see how everything fits together. Sometimes I find holes in other persons' plans when I ask "How does data get from here to there?" somewhere in the middle of a diagram. "Beginning, middle, end" describes a system to me. Every time I find a "middle" I break it down to "beginning, middle, end," until there are no middles left. Another thing I have noticed, both on the job and in the laboratory, is the greater my frustration in the middle of a project, the greater my satisfaction when the project is completed.
Saturday, 09 June, 2001 12:57:22 AM Some people I have worked with have kept their jobs a secret. When I came on site to help them, their attitude was that I could learn what I wanted and do as I pleased, as long as I didn't try to figure out what they were doing. I got the feeling that they were threatened by their imagination that I would somehow take away their jobs. Well, there's enough work for everybody, and I don't expect that to change within the next decade. Actually, people do their jobs better when they share information. The load can be distributed, and more brains are applied to the problem of the moment. When I started my career at Sun Microsystems I was placed in a converted conference room that was full of technical support engineers. I didn't really understand UNIX, and every time I got a question that I didn't know how to research, I would walk around the room asking everyone there. I was laughed at for being a DOS weenie, but as I asked I would also learn. At first I was asking close to 100% of the questions of the other engineers, but in a few weeks I was up to 50% or so. In four months I was as up-to-speed as anyone in the technical support center, and by the time I left I was teaching classes. After I left the company and came back, I found that my colleagues had taken my notes and turned them into the foundation of a symptom/resolution database! Without the help and cooperation of those engineers who were thoughtful enough to share their knowledge with me I would have been lost. Their expertise would not have been captured, and their influence would not have been lasting. Because they were willing to share what they knew, everybody benefitted.
Wednesday, June 06, 2001 06:28:18 PM There are only three things you need to do to fix any computer problem. It doesn't matter what the computer is or what the operating system is, these three steps are the universal solution method: 1. logout 2. reboot 3. reinstall Think about it. Users' environments get out of whack, and you need to change things. Environment variables, login shells, terminal settings, all can change in mysterious ways and need correction. Window displays need to be reset sometimes. Unless you know the entire operating system, and often even when you do, it's easiest to just logout and login again to make the changes take effect. If you stay logged in 24 hours a day, to keep your environment sane it's a good idea to logout once a week on general principles. If something goes wrong that is outside one user's environment, especially with daemon processes or services, or when you need to reconfigure the services, often the most effective way to get the services initialized properly is to reboot the system. The most drastic thing that can happen to an operating system is mysterious destruction of system software. The second most drastic is the destruction of application software. In either case, the only recourse in many cases is to reinstall the application software or the damaged components of the system software. Now, it is true that there are many reconfiguration issues that need to be addressed in the course of system administration: adding users, changing network addresses, modifying services, etc. But to the system administrator these are not problems, they're part of the business of system management. Problems are the issues that require extensive troubleshooting, and that end up in a diagnosis of missing or damaged software or hardware. More formal procedures can be defined and documented. But if all you remember are the above three principles, you can always get a system back to an as-shipped state, which is known. Of course, these steps should be taken in the order given, that is from least drastic to most. Often strange little quirks that have appeared in my sessions, on many different operating systems, have been straightened out by a simple logout. I used to talk with users that had the strangest problems, and when I asked them to logout they would put up a screen lock. Some of them had never really logged out the entire time they had worked for their company! Step 1 would get them going again, and I would teach them the difference between using the lockscreen and logging out. This general method does not have to apply to a UNIX system. This week my parents mentioned at a barbeque that their laptop had lost its video; all they had was a blank screen. After determining that the problem was not with the contrast and brightness controls, my brother asked them about the history of the computer. It turned out that at home they would just close up the case and let the power monitor take care of preserving the session state; there had been no logout or reboot for as long as they could remember. The video had blanked out when the battery ran dry. My brother powered up the system, then forced it to shutdown. On the reboot the video driver came back normally. Microsoft users may recognize this scenario; step 2 is famously popular with them. At San Francisco State University, in the early days of local area networking, the School of Business chose 3Com servers. The first generation servers were Altos microcomputers running Xenix, an operating system of which we had no understanding. We made regular backups of the home directories, which was enough to preserve students' data. Once or twice per semester the networking software would go awry, and we had no idea what was going wrong. We would reboot the server, and if that didn't work, we'd reinstall it from scratch and restore the home directories. Had any of us understood Xenix at the time, we could have taken a more gentle approach. But the big hammer was quite effective. To this day I have no idea what was going wrong, and I also have no need to know. Step 3 was simple enough and good enough to handle the situation.
Tuesday, June 05, 2001 2:33:09 PM At one point last week I made a major faux pas. I forgot my audience. At times my lectures drift from a presentation of technology to opinionated forays into irrelevant topics such as economics. I thought it was a simple statement of fact that the existence of a recession was a matter of debate, and I expressed the opinion that a real recession would not materialize. A significant number of my students were retraining in part because of the rounds of layoffs in the high-tech industry last winter and spring, and I was greeted with a chorus of objection. I believe someone once said, "a correction is when the economist knows someone who has been laid off; a recession is when the economist has been laid off." So, I gave my apologies to those personally involved. This incident led me to examine whether I was flaunting wealth. Here the students were, in what their past experience told them was a high-risk situation. Many of them had taken out loans to take the course, and the fact that they were enrolled meant that they weren't in a situation where they could foresee how to pay back the loan soon. Programming was a new discipline for some of them, and they weren't sure of the market recovery or of the general business dependence on computing. So when I mentioned that my colleagues vacation in foreign countries, or that I can choose my contracts, was I flaunting prosperity before them? Ultimately, my answer was no. The fact that Chuck Buntjer could email me a note that said "I've been laid off, I'm going to see Morocco" was a direct result of his being a high-tech contractor and making the money to go. These students needed to see that their path was a successful one, that the dependence on computing and those who sustain it moved through economic booms and busts alike, and that they, too, would have the opportunity to vacation freely, choose their career paths, and have confidence in cash flow. If I wanted to give an example, what better one to give than my own experience? My life, and the lives of other real techno-weenies, could be held before them as a beacon of courage, and, as long as it was presented with compassion, it could be used to show them that they, too, would be prosperous. That could help them make it through the intensive course of study they had chosen.
Saturday, June 02, 2001 12:28:44 AM Look for more log entries when I begin teaching my next class on June 16, 2001.
Return to David's Home Page
Your comments are welcomed by David R. Dull,
ddull@netcom.com.
(C) Copyright 2001, by David R. Dull.
All Rights Reserved.
Get your own Free Home Page