Hell Freezes Over As I Update My Resume

I’ve enjoyed my time off, but it’s time to get back out there–after I get back on the 12th from a birthday trip to San Francisco of course. A certain whip-cracking recruiter made me update my resume (pdf) in the middle of the night. The result isn’t pretty, but it stopped the beatings. I hate writing resumes, and I keep thinking I need to solve the underlying mechanical problems with some kind of technology and document management know-how.

The first problem is targeting. I’m not exactly a young pup anymore and my updated, pared down resume is still seven pages. When doing the hiring, I hate long resumes. Anything over three pages starts with a strike against it. Putting a resume on Jennie Craig by targeting (industry, technology, project type, etc.) helps the reader concentrate on relevant facts, something the whip-cracker emphasizes with supersonic booms. Thing is, it’s hard to know when some seemingly unrelated item will interest or inspire a reader. While I agree with the whip-cracker about targeted resumes, I think it’s important to provide a way for the curious to find out more on their own.

The second problem is repurposing. Some people like pretty resumes printed on fancy paper. Some companies require submitting your whole life in a single plain-text box on a website. Some unscrupulous sorts will take an electronic resume, doctor it up, and misrepresent themselves as your agent. Some resume formats play better to certain industries or nationalities. Even if you’ve narrowed down your content to just what the audience wants to see, how you present it is at least as important.

A perl monger friend makes an interesting case for making code look pretty (visually well-organized), and it applies to resumes as well. He says that the visual parts of our brain have had much more time to evolve than the parts responsible for language, reading, and symbolic processing. A well-formatted piece of code can convey plenty of meaning just by how it looks without all the overhead of reading words and constructing that pretty picture in your head. My favorite personal examples of this are “make versus ant” and “DTD versus XML Schema”:

XML Schema is vastly superior to DTDs for expressing complex document structure; data typing and constraints alone are worth their weight in golden angle brackets. For java development, the same is arguably true for ant over make. The thing is, XML Schema and ant files are barely human readable: The hierarchical structure doesn’t convey any useful context–there’s no grammar/narrative like you’d see in a make file or DTD. You have to read the tags and figure out their “part of speech” (operator, expression, value, etc.) which entails a much higher cognitive load. All that increased capability comes at a price in human readability. Compare this ant build file from an Apache Tutorial:

<project>
	<target name="clean">
		<delete dir="build"/>
	</target>
	<target name="compile">
		<mkdir dir="build/classes"/>
		<javac srcdir="src" destdir="build/classes"/>
	</target>
	<target name="jar">
		<mkdir dir="build/jar"/>
		<jar destfile="build/jar/HelloWorld.jar" basedir="build/classes">
			<manifest>
				<attribute name="Main-Class" value="oata.HelloWorld"/>
			</manifest>
		</jar>
	</target>
	<target name="run">
	<java jar="build/jar/HelloWorld.jar" fork="true"/>
	</target>
</project>

To this hackish, slapdash makefile I just created in vi(m):

BUILDDIR=./build
CLASSPATH=./build

compile: ${BUILDDIR} HelloWorld.java
	javac -d "${BUILDDIR}" HelloWorld.java

${BUILDDIR}:
	mkdir build

run:
	java -C "${CLASSPATH}" HelloWorld

jar:
	cd ${BUILDDIR}; jar cvf HelloWorld.jar *

clean:
	rm -rf ${BUILDDIR}

Even though we’re on ant’s home turf, the makefile is easier to understand at a glance if you know a little about make grammar. They don’t do exactly the same thing, but I hacked this up in five minutes. There are lots of hidden benefits with ant understanding java intimately; the downside of that is most developers can remain ignorant to what’s really going on. The makefile is easier to understand and faster to write while the ant file is much more powerful but is best created in an IDE that groks ant.

I only use XML Schema and ant when I have tools that take those unreadable piles of markup and translate them into something more visually organized and pleasing. For quick-and-dirty projects that I need to roll by hand from the shell prompt, make and DTD are faster to write and easier to debug. Several hundred million years of evolution behind recognizing shapes and colors trumps at few hundred thousand (at best) of linguistics and abstract thinking. Project complexity plays a part here too–simpler tools and languages for simpler problems. If I need constraints in my xml for instance, then it has to be XML Schema.

So I’ve been thinking for a few years now that my resume’s grown to a level of complexity where a single resume, even a small set of targeted resumes, just doesn’t work anymore. I can envisage a web application over a database (relational or xml would do fine) that breaks down and tags all the content of my resume in a way that allows easy targeting and repurposing. It’s not all that different from what we did for international drug submissions in RDMS, just with much smaller documents going in and coming out.

Anybody seen or worked on something like this? Part of me thinks there’s a business opportunity here, and the other part thinks it’s obvious enough that somebody’s already done it. I just don’t update my resume enough to make this a personal project, especially with repeat clients. They already know what I can do and just dump the resume into my compliance record without a glance; that didn’t inspire me to agonize or self-flagellate over my resume four years ago.

Really, how many resumes actually get studied beginning-to-end? I keep wondering if we need to move back to a cover-letter-like summary that points to a URL instead of clogging the hiring channels with more paper and bytes. In any event, I’d want any published resume to point back to a site that breaks down the whole database by company, project, technology, location. I just need to find somebody willing to pay me to write a system to manage my resume!