I've used Google Calendar to make a list of what I plan on attending at LISA. In past years I would spend the breaks trying to decide what to do next. This year I've precompiled my decisions so I can spend the break socializing. You can view my decisions here.
My general plan:
What's your plan?
(I'll give you all some time to read the articles... done yet?)
I want to agree and disagree with something Mark wrote (and a big "P.S." at the end about something he said about my time management book).
Undergraduate courses in CS and CEng are not there to teach industrial tools, but basic principles
I agree... but please don't go too far. The use of industrial tools, when used, should be as a demonstration of the principles being taught, not to gain some kind of certification that they know how to use the tool. Eliminating such tools would be going too far. We all know there are students that are "visual learners", "audio learners" and "kinesthetic" learners. Using the tools in a real environment is where the kinesthetic learners will benefit.
When I took my undergraduate class on software engineering methodology I felt it was useless because I couldn't see the point of most of what I was being taught. Most of my programming had been done solo or on a small team. I could not take seriously the problems that were being "fixed" by the software methodologies discussed in our lectures. "Code size estimation? Bah! Impossible, so why even try!" What would have solved this problem? To put me in an environment where we had a large enough team that things started to break down and we needed GIT, Bugzilla, and Tinderbox.
However, that was 1987-1991. Back then basic tools like source code control, bug tracking, and automated testing were uncommon. Today's students get more exposure to those things via exposure to Open Source projects than I got in my entire college career.
What about the students that aren't exposed to how open source projects work? They get no exposure. They don't get taught these principles. My guess is that these students are the majority of college students today. The superstars get exposure but not everyone is a superstar. In fact, by definition most students are not.
Obviously first-semester students should focus on getting comfortable with smaller issues like text editors, files, and getting their first programs to work at al. However, after someone gets some exposure, they should hand their homework in via passing a GIT or Subversion URL to the instructor. Peers should test each other's code and submit bug reports, and be graded by whether they include reproducible test cases or not. Unit-tests and system-tests, in a simple automated test framework ("Makefiles" are sufficient) should be part of the assignment.
P.S. And since you mentioned TM4SA...
At least when Limoncelli wrote Time Management for Systems Administrators he was putting forward a set of skills that had proven to work for him in the field, and he was trying to pass on lessons learnt the hard way.
I made a conscious decision to write what worked for me and people near me rather than write a book about the theory of time management and productivity. Before writing the book I did some research and found that people do not tolerate more than a certain amount of theory in self-help books. A little bit is motivational, too much is a turn-off. On the other hand, research finds that geeks tend to be motivated by knowing how the internals of something work. That's an argument for including more theory. I had to strike a balance.
I don't recommend Time Management for System Administrators (TM4SA) as a textbook. It is a self-help book. People will only benefit from a self-help book if they feel they have a problem. The 80% of your class that doesn't feel they have a problem would hate the professor for making them read it. Oddly enough I had terrible time management skills when I was in college. My low GPA is proof! If only I had TM4SA then! (Go figure out that time paradox!)
On the other hand, I do promote The Practice of System and Network Administration as a text book. It was written with colleges classes in mind (senior undergraduate and masters programs). As proof, each chapter ends with questions, something one generally finds in text books. The questions are designed to help the student review the material with a few "soul searching" questions mixed in here and there. The latter are potentially good term-paper ideas.
A message to the US readers of this blog.
This year's Usenix LISA conference conflicts with election day. I want to encourage everyone attending to vote absentee, unless of course, you can be home to vote on Tuesday.
There are no federal contests this year. Thus, the conflict does not affect most people. Of course, there are many local contests, and voting in those is very important. However, two states elect governors "out of cycle" with the rest of the nation. Both New Jersey and Virginia's governor races are neck-and-neck. Your vote is very important.
Both states permit registered votes to vote "absentee" (i.e. by mail) if you will be out of state that day. Actually, they permit you to vote absentee for just about any reason. Here are the forms you need:
Applications must be sent by postal mail. Deadlines are soon. Act today!
Some New York Trains are 1-minute late by design according to an article in today's New York Times.
It turns out that a 5:20 train leaves at 5:21. This gives people a good feeling when late because they "just caught" their train.
Since I take such a train every day, I'm not sure if I believe this. By my AT&T cell phone, the trains seem to leave right on time. My theory is that they leave 59 seconds late. It is still technically 5:20 (in the above example).
What really annoys me is that the train doors close "on time" (whatever that is) but then the train sits there on the track waiting for permission to move. Once I just missed a train and stood there pounding loudly on the glass door, yelling and screaming (and then yelling, screaming and cussing) as the train stood there for 5 minutes. The conductor heard me but wouldn't open the door to let me in.
Maybe it was the cussing.
How this relates to system administration: Under-promise and over-deliver. If you tell a user "this will take an hour" and then it takes 2 hours, they will hate you. If you tell them "this will take 3 hours" then fix it in 2 hours, they'll think you are a genius. Either way you spend 2 hours on the task. Therefore, always increase your estimates. TPOSANA has a few tips related to this kind of thing, especially where giving support to unsupported products is concerned.
This is a tutorial that I've never taught before. You can see it first at LISA 2009 in November.
In case you missed it, Matthew Sacks interviewed me about my other LISA tutorial. That tutorial also has a lot of new material.
This is a guest-blog entry by a coworker Tanya Reilly.
Something I realised this week:
Opening my (personal or work) email inbox makes me stressed. If the network is slow, and it takes a couple of seconds for my mail to be displayed, that's a couple of seconds where I feel under real pressure. Email, rather than being the source of joy one would assume, brings obligation: this mail needs reply, this question needs to be answered, this bank statement needs to be read, this lovely long catch-up email from a friend needs a thoughtful response. No matter how pleasant an email is, it usually means something new that needs to be done. Worst of all are the mails that are still in my inbox that I've already read. Was I supposed to do something about them? Does someone think I'm a jerk for not replying? Was there something I was supposed to do with my bank account? Have I forgotten to pay for something on eBay? All of this to think about inside a couple of seconds. It's so pointless.
Usenix interviewed me about my Time Management tutorial at the upcoming LISA 2009 conference. It isn't too late to sign up for this class!