System administrators have a stereotypical reputation for grumpiness and irritability. Some times this misanthropy is a cultivated pose, designed to deter casual or trivial requests that would take time away from more important activities like playing nethack and reading netnews. More often, however, sysadmins are disgruntled simply because they can’t seem to make any headway on the dozens of items clogging up their todo lists. If you’re an example of the latter case, you may find some help in Time Management for System Administrators, the new book from Thomas Limoncelli (who you may recognize as one of the co-authors of the classic The Practice of System and Network Administration).

This slim book (only 226pp) packs a large amount of helpful information about making better use of your time at work, so that you can make some headway on at least some of those tasks that have piled up around you, while still managing to have a life outside of work. One of Limoncelli’s main points is that sysadmins have to develop some way of effectively dealing with the constant stream of interruptions in their life if they’re going to accomplish anything. The other point is that they also need a good tracking system to make sure they don’t lose track of new, incoming requests in the process of dealing with existing ones. The book continually reinforces these two points, and presents several alternative, complementary ways to accomplish them.

The first three chapters deal with high-level, generic issues: principles of time management, managing interruptions, and developing checklists and routines to help deal with the chaos of day-to-day system administration. The middle third of the book details how to use “the cycle system”, Limoncelli’s task management plan for sysadmins. Basically, it’s a hybrid between Franklin-Covey A-B-C prioritization and day planning and David Allen GTD-style todo lists, with a few sysadmin-specific tweaks thrown in. The final chapters of the book address a grab-bag of issues: task prioritization, stress management, dealing with the flood of email that all admins seem to get, identifying and eliminating the time sinks in your environment, and documenting and automating your work-flow.

In general, I think this is a great book for sysadmins that are looking to begin addressing time management problems. People that have already done some investigation of time management techniques (like the aforementioned Franklin-Covey and GTD systems) may find less value here — but I still think the book will be interesting, especially the chapters detailing the workings of “the cycle system”. Personally, after reading this book, I don’t see any reason to move away from my modified GTD system, but I have gone back to using some daily checklists, which are helping me keep on top of my repeating tasks a lot better. I suspect that any working sysadmin will take away at least two or three productivity-enhancing tips from this book.

“Extreme” programming (XP) is a relatively new software development methodology which aims to allow small teams to produce higher quality software in less time, with less stress. The only thing that possibly exceeds the fervor of its adherents is the scorn heaped upon it by skeptics. _Extreme Programming Explained: Embrace Change_ is “the XP manifesto”, which lays out the basic tenets of the XP idea, discusses the philosophy behind the principles, and delves into actually implementing XP in a programming team. I found the book to be a quick read, and I’m sure if you’re about to start working with an XP team (in either a developer or a customer role), it would be a good place to start familiarizing yourself with the theory and practice of Extreme Programming.

The first third of the book lays out the principles and the theory behind Extreme Programming, and reflects on how the realities of current software development don’t match up with classic development methodology that well anymore (if they ever did). By the end of this section, if you’ve been involved with any sort of structured software development, you’ll be nodding your head in agreement and/or cringing from the painful memories of past failed projects.

The middle third of the book starts out with a high-level overview of the mechanics of the XP process, and then quickly gets into the nitty-gritty of carrying out the distinct steps: The Planning Game, small releases, pair programming, collective ownership, refactoring, testing, and all the rest. Even if you don’t go for full-bore XP practices, there should be something in this section that will make you re-think some of your practices.

The final third of the book deals with practical considerations of implementing the XP methodology for software development, including when you shouldn’t try to use XP. This section, with recountings of commonly encountered problems, and descriptions of the different roles often filled by XP programmers, will be the most valuable for someone trying to actually turn theory into practice.

Overall, I found the book to be a quick, interesting read, and it was fun to consider how some things at my workplace would happen differently if some XP practices were to be adopted.

“Bioinformatics” is the new sexy term for what used to be called simply “computational biology”. Simply put, it involves pretty much any application of computation techniques to biological problems. The reason for the new nomenclature and the greatly increased interest in the topic is, like much in modern biology, a more-or-less direct consequence of the many genome sequencing projects of the last decade.

The consensus in the field seems to be that it’s more productive (and certainly easier) to teach biologists how to program, rather than try to get programmers up to speed on the intracities of molecular biology. For similar reasons, Perl is a popular language to learn: it’s easy to get off the ground and be productive with it, without requiring a heavy computer science background. (This, of course, has downsides as well…)

Never one to miss out on a trend, I’m going to be teaching a course on Bioperl and advanced Perl programming, starting next fall, which means I’m doing a lot of reading in this topic area, trying to develop lectures and find good background reading material. One of the first books I grabbed was _Beginning Perl for Bioinformatics_, which has been sitting on my “to read” shelf since O’Reilly sent me a review copy in December of 2001. It’s a typical O’Reilly “animal” book (the cover bears three tadpoles), which does a decent job of introducing the basic features of the Perl language, and it should enable a dedicated student to get to the point where she can produce small useful programs. However, I’m not completely happy about the book’s organization, and I think the occasional “if you’re not a biologist, here’s some background” interjections could have been cut without hurting anything.

The initial chapters in the book cover “meta” information, such as theoretical limits to computation, installing (or finding) the Perl interpreter on your computer, picking a text editor, and locating on-line documentation. Some general programming theory stuff is covered as well — the code-run-debug cycle, top-down versus bottom-up design, the use of pseudocode. There’s also some biology background, but it’s very introductory level stuff — DNA has four bases, proteins are made of 20 amino acids, and so on.

In chapter four, the book begins to get into actual Perl, with some coverage of string manipulation. Examples deal with simulating the transcription of DNA into RNA. Chapters five and six continue to flesh out the language, covering loops, basic file I/O, and subroutines. Chapter seven introduces the rand() function, in the context of simulating mutations in DNA. Subsequent chapters introduce the hash data type (using a RNA->protein translation simulation), regular expressions (as a way to store the recognition patterns of restriction endonucleases), and parsing database flat files and BLAST program output.

I’m clearly out of the target audience of the book, as I already have a strong working knowledge of Perl. Perhaps that’s why I found the order that concepts were presented in to be a bit strange — for example, hashes, which are a fundamental data type, aren’t introduced until halfway through the book, and regular expressions (one of the key features of Perl) first appear even later. As I said above, I also found the biological background sections to be more distracting than anything, but I’ve also got a strong biology background, so perhaps I’m off base here too. That said, I think a person with a CS background would be better served with a copy of _Learning Perl_ and an introductory molecular biology text than with this particular book.

One of the things I did enjoy about the book were the frequent coding examples, all of which presented realistic computational biology sorts of problems and then demonstrated how to solve them. I’m sure that when I get around to writing lectures, I’ll be leafing through this book looking for problems I can use in class.

Overall, recommended for biologists without programming experience who would like to get started using Perl for simple programming. Not recommended for people with computer science backgrounds looking to get into bioinformatics.