By Derek Smith
I have spent the past few months focused on two projects: applying for graduate fellowships and wrapping up loose ends at my job as a software developer. I’d like to share some of the details of my system for simplifying the application process and describe how it was influenced by my (relatively short) career in software.
Every graduate school or fellowship application requests letters of reference. It doesn’t take much of a system to keep track of the five or so people best suited to helping you satisfy this portion of the application. However, the National Physical Science Consortium (NPSC) graduate fellowship may require a background investigation, which begins with your completion of the SF-86. This form is extremely detailed. If you are applying to this fellowship or would ever entertain a job requiring a clearance, it is worth a few minutes to browse the form.
I store contacts in a simple text file. For each person I include name, email address, title, office phone numbers. For some people, I record personal variations of these fields. If you’re actually undergoing a background investigation, it’s good form to give a heads up to the people you list on the SF-86. For each job, identify a supervisor and close colleague. For each school, keep track of professors who you have asked for letters of reference as well as students who knew you. Don’t forget to include external contacts. For instance, I worked closely with external contractors as a software developer.
This document also contains URLs which list public contact information for any persons listed. You never know when you’ll need a blurb or biographical statement. When in doubt about the future relevance of the URL, simply save a copy of the web page to your local machine.
After you fill out a couple of applications or browse the SF-86, you’ll get a feel for the type of contact information you should be recording. Note that the SF-86 asks for 7-10 years of residency data. Record addresses, dates and person who knew you for all places you lived, even if only for a short time. See the form for further instructions.
It is important that you record this information in a timely manner, as it’s very easy to lose track. I graduated college prior to the Facebook boom, but have found it very handy for staying up to date with military buddies. LinkedIn and other social networking sites can help manage contacts, but only to the extent that everybody uses them. Also what happens if somebody deletes their page? You will probably still want/need a your own local solution. For reasons I’ll describe later, make sure that whatever system you use allows you to store your address book in a text-based format.
I keep a master resume, or “resume journal,” in LaTeX format. For each job, I record titles, dates of employment, dates of promotion, salary and other compensation, supervisor names (but not contact info), location, reason for leaving and bullet points. I update the bullet points on a quarterly basis (or when I remember) by reviewing monthly reports, my daily journal and email. For each school, you need the basic name, dates, GPA and degree, but you may also need things like GPA in Major. This is a pain to calculate, usually it’s not even very well defined, so do it once and stick with the value. Additional things to include: scholarship names/dates/amounts, awards, positions in clubs, publications, talks, conferences and professional associations.
My resume and resume journal are a single document, where excess notes are suppressed as LaTeX comments. You could have two separate documents. When it comes time to apply to a job/school/fellowship you will need to tailor your resume. If you find yourself writing entirely new bullets and adding new information, incorporate it back into your resume journal. For instance, the NPSC has a duties section for each job. I have never seen this elsewhere, but saved it for future use. It may also come in handy to keep an output folder with particular saved instances of your final resume.
Again, record early and record often. I did not follow this advice as an undergraduate. I’m now attempting to dig up specifics of scholarships/awards from nine years ago.
Essays follow largely the same process as my resume. I have three or four generic essays: personal, previous research, proposed research, and diversity. If you’ve applied to graduate school or a fellowship, you?ll know that each asks for a variation on these essays. When working on a particular application, I create a text document which puts all the writing prompts into a single place. This is handy for future reference, as you probably won’t remember the specific question asked. Some applications allow you to export the final version as a single PDF document. I save this output in the same place as old resumes. Disk space is cheap!
Software Development Analogy
The mechanics of software development find an analogy in writing application packages. One must coordinate a series of changes from one or more persons to a set of structured text files under a fixed schedule. Thankfully, many a creative developer has turned their skills inward, resulting in powerful tools and concepts for managing the writing process.
The first idea is that of normalization. An application is structured into libraries so that common subroutines may be shared without duplication of effort. The relational model in database design provides benefits such as reduced duplication and increased integrity of data. What ever system you use to simplify the mundane details of the application process, make sure you’re not duplicating yourself. For example, you should only update contact information in one place.
If you’re not familiar with the concept of a version control system (VCS), head off to Wikipedia right now. I’ll wait. I use TortoiseHg on Ubuntu to track changes to my address book, resume, and application essays. The Tortoise family of tools provides Mercurial integration into GUI file managers like Nautilus and Windows Explorer. A VCS is not limited to software source code, but works equally well for storing any text-based file format. It’s helpful for a single person and essential for sharing changes among multiple authors. A VCS can be as simple as a file on your local machine, or a database-backed solution on a internet accessible server. Much like as a software developer, your job as a graduate student is to write. Any non-trivial writing project can benefit from even the most basic features of a VCS.
Finally, version control is not backup! Using a VCS, your repository may become corrupt. Whether or not your use a VCS (you should), you need to have a backup plan. Some tools and online services incorporate both tools into a single interface. The space of options here is huge, choose a tool which simplifies the process as much as possible. Also, the restore capability of any backup procedure should be period exercised.
Graduate school involves a lot of writing: to get in, to get funded and to get out! A lot of this writing is mundane and repetitive, but it can be simplified if you embrace the concepts of normalization and version control. A solid backup plan may save you countless hours when disaster strikes. Take advantage of the tools available to the modern writer such as Latex, version control and automated, remote backups.