Managing your time when you’re not very good at it

A friend considering a return to school recently asked me how I manage my time while being (in no particular order) a graduate student, a full-time employee, a husband, a father, a contributor to various projects, etc. As you may have surmised from the frequency with which I update this blog, the answer is “poorly”. But since I’ve been meaning to write about this subject for a while, I decided now is as good a time as any to commit my answer to more words.

I really do maintain that I’m not good at time management, although I’ve done well enough to survive into my third year of graduate school. Maybe the smartest thing I did was to slowly ramp up: I had a semester of school finished before my daughter was born, which was very helpful in allowing me to adjust to both separately. I’ve also borrowed heavily from some of Tom Limoncelli’s sage advice, although I’m not nearly as good about following it as I’d like to be.

To manage the high-level view of things, I have turned to TaskJuggler, a free software project management tool. I use this to manage application development, paper submission, and miscellaneous projects at work. For school, I mostly use it to track the classes I’m taking and progress (such that it is) on my thesis. For larger projects (e.g. research papers) within a course, I’ll include those as sub-tasks, decomposed as necessary.

For smaller tasks, and the miscellaneous to-do items of life, I use a text-based to-do list manager called TuDu. True to Limoncelli’s “The Cycle” methodology, I try to have every task scheduled for a day, even if that day slips. Tasks with no scheduled day often languish forever. The other advantage to scheduling tasks, especially things like homework and other school-related tasks, is that I can make sure I don’t try to do too much in one night. It can be easy to forget how much you have to do until it is too late to do some of it earlier.

Perhaps the most important thing I’ve learned about managing my time is that sometimes, things will hit the floor. That’s okay, so long as it’s well-planned. Sometimes you have to decide where effort is best spent. As an example, at the end of last semester, I was facing the last week of classes with two research papers, a group project, and a homework assignment due. I decided to sell out the homework assignment in favor of the research paper for that class, figuring that the paper was worth more to my grade than the homework. I did get a pretty bad score in the class, but my overall grade was still an A.

It helps to set aside time to concentrate on what’s important. Between the time I get home and the time my daughter goes to bed, I spend time with her and my wife. The only time I’ll skip that is if I have something else scheduled that evening, or if I’m hopelessly underwater on my to-do list. When class is cancelled or dismisses extra early, I use that time to work on any outstanding schoolwork I may have. I’ve commited to git repositories while on the bus. And when life settles down a bit, I’m going to take a nice, long breath.

Deploying Fedora 18 documentation: learning git the hard way

If you haven’t heard, the Fedora team released Fedora 18 today. It’s the culmination of many months of effort, and some very frustrating schedule delays. I’m sure everyone was relieve to push it out the door, even as some contributors worked to make sure the mirrors were stable and update translations. I remembered that I had forgotten to push the Fedora 18 versions of the Live Images Guide and the Burning ISOs Guide, so I quickly did that. Then I noticed that several of the documents that were on the site earlier weren’t anymore. Crap.

Here’s how the Fedora Documentation site works: contributors write guides in DocBook XML, build them with a tool called publican, and then check the built documents into a git repository. Once an hour, the web server clones the git repo to update the content on the site. Looking through the commits, it seemed like a few hours prior, someone had published a document without updating their local copy of the web repo first, which blew away previously-published Fedora 18 docs.

The fix seemed simple enough: I’d just revert to a few commits prior and then we could re-publish the most recent updates. So I git a `git reset –hard` and then tried to push. It was suggested that a –force might help, so I did. That’s when I learned that this basically sends the local git repo to the remote as if the remote were empty (someone who understands git better would undoubtedly correct this explanation), which makes sense. For many repos, this probably isn’t too big a deal. For the Docs web repo, which contains many images, PDFs, epubs, etc. and is roughly 8 GB on disk, this can be a slow process. On a residential cable internet connection which throttles uploads to about 250 KiB/s after the first minute, it’s a very slow process.

I sent a note to the docs mailing list letting people know I was cleaning up the repo and that they shouldn’t push any docs to the web. After an hour or so, the push finally finished. It was…a failure? Someone hadn’t seen my email and pushed a new guide shortly after I had started the push-of-doom. Fortunately I discovered the git revert command in the meantime. revert, instead of pretending like the past never happened, makes diffs to back out the commit(s). After reverting four commits and pushing, we were back to where we were when life was happy. It was simple to re-publish the docs after that, and a reminder was sent to the group to ensure the repo is up-to-date before pushing.

The final result is that some documents were unavailable for a few hours. The good news is that I learned a little bit more about git today. The better news is that this should serve as additional motivation to move to Publican 3, which will allow us to publish guides via RPMs instead of an unwieldy git repo.

A wrinkle with writing your resume in Markdown

For Sysadvent 2011, Phil Hollenback wrote an excellent post called “Write Your Resume in Markdown Already!” Ever since I read it, I’ve been using a Markdown file as the source for my resume, which gets rendered to HTML and PDF as necessary. Recently, someone using Windows tried to open the PDF of my resume in Acrobat Reader. When she did, she got errors about missing fonts. “How odd,” I thought. In the course of several job applications over the past year-plus, I hadn’t heard of any problems. (It’s possible that nobody reviewing my resume used a Windows machine to do it.)

I fired up my Windows XP virtual machine that I keep around for playing Sim City 2000 and installed Adobe Reader. I was able to reproduce the problem, which is always comforting. It didn’t shed any light on the matter, though. I actively avoid doing anything “cute” so that my resume (and other documents) can easily be read by anyone on any platform. After examining the workflow, I figured that the problem had to be in the LaTeX template used to generate the PDF.

One of the features of the template is the conditional use of packages and font settings. Since the pandoc package in Fedora 17 (version 1.9.4.2) no longer includes the markdown2pdf command in previous versions, the –xetex argument that Phil passed isn’t necessary. Removing the control structure resulted in a PDF that looked qualitatively the same, but would open on Windows. Phil’s instructions are still good overall, but they need some tweaks for newer versions of Pandoc.

Here’s a diff, for those of you who are interested:
7,9d6
< $if(xetex)$
< \usepackage{ifxetex}
< \ifxetex
15d11
< \else
18,22d13
< \fi
< $else$
< \usepackage[mathletters]{ucs}
< \usepackage[utf8x]{inputenc}
< $endif$