I had to laugh this morning at Scott McLemee’s piece in Inside Higher Ed proclaiming the difference – or rather, what he’d define as such as there appears to be no truly common consensus – between a geek and a nerd:
As a nerd, my bias is towards paper-and-ink books, and while I do indeed use information technology, asking a coherent question about how any of it works is evidently beyond me. A geek, by contrast, knows source code….has strong opinions about source code….can talk to other geeks about source code, and at some length. (One imagines them doing so via high-pitched clicking noises.) My wife understands network protocols. I think that Network Protocols would be a pretty good name for a retro-‘90s dance band.
While the content of the article is not really about the difference between geeks and nerds, I find this distinction somewhat.. interesting all the same. I would claim, by Scott’s definition, to be neither properly a nerd nor a geek, but rather some combination of the two* – while the printed word holds value and mystique, I’m not so wed to dead-tree format that I don’t understand code, but I’m also not adept enough with code to speak in high-pitched clicking noises. Taking this a step further, I would say this appears to be yet another divide in which practitioners of institutional research sit the fence.
(More beyond the jump.. things got a little long!)
Generally, fence-sitting is viewed somewhat negatively – a state of indecision; however, I see fence-sitting as a state of mediation – the ability to see both (or many) sides of a given line of demarcation and to communicate over the line so that both sides get what they need. By existing at the borders, one learns to speak the language of both sides and as such is able to interpret between the two and facilitate efficiencies.
While visiting another institution earlier this year, I found myself in a conversation with members of that institution’s IT department in which I was first able to articulate the idea of institutional researchers as fence-sitters. In the IT world (apparently, or what I have been able to glean from the fence), people are one of two types – IT people (programmers, developers, server admins, database admins, etc.) or Users. In a strict IT environment, the two don’t mix – if you’re a User, you don’t get to muck around in the database writing SQL code that may or may not be optimized and which may or may not bring a server to a grinding halt because you forgot a key limit or join; instead, you tell a programmer or DBA what you want and they create code to go fetch it for you.
The programmer or DBA doesn’t particularly care *why* you want it, or what you intend to do with it, just about protecting the integrity of the database while they retrieve it for you. Unfortunately, the user doesn’t always know what they want in specific enough terms to ask for it properly the first time. A really good example of this is how you count students – do you count “heads” (headcount)** or full-time-equivalent students (FTEs)***? Depending on the issue or question you’re trying to answer, one or the other may be more appropriate. For instance, if you’re trying to determine how many parking spaces may be used during a summer session, odds are good that you’d want to be counting heads. However, if you’re trying to determine how much tuition revenue the institution will bring in during that same session, FTEs may be a better measure. It’s uncommon, however, for the average User asking the question to know – or to remember to specify – which metric they want and it’s equally uncommon for the programmer or DBA to know – or to remember to ask – which metric might be appropriate.
This is where institutional research comes in; we’re interpreters that help both sides get what they need, and as such we need to speak enough of the language of both sides to be able to pass the right bits of information back and forth. It’s our job to ask Users what they want the information they’re seeking *for* – how they want to use it, what question or issue their trying to answer – so that we can help them ask for it (or ask for it for them) in language that makes it clear to the programmer or DBA exactly what is needed (in the aforementioned headcount vs. FTE example, you may need to ask for student headcount vs. enrolled credits). In a strict IT environment, however, that’s the extent of what institutional researchers are often allowed to do – help Users figure out how to ask for information.
Most institutions have a more relaxed – by choice or necessity – IT environment and institutional researchers can go one step further to write code to retrieve data needed by Users directly (thus sitting the fence between IT and Users even more explicitly). Depending on the programming skills of the IR function and the resources available at the institution, this could be anything from hard-coding SQL queries to using a click-and-drag query building tool to filling out a web-based query template. The advantages to this scenario are, among others, increased response time to the User – there’s one less relay involved in the request – and likely greater utility of the delivered data as most institutional researchers, having done the preliminary work of investigating for what purpose the data is needed, will take the few minutes to provide documentation – even if just in the form of changing system-defined variable names or labels to something more meaningful to the User – before sending the data back. Understanding this added utility can help create a niche, even in strict IT environments, for IR “on the fence” and contribute to the efficiency of the institution.
There are numerous and varied other areas in which IR sits the fence, but the interpretor of data is probably the largest, and takes on forms other than that described above (e.g., provision of raw data vs. data and policy analysis). In order to function well in institutional research, therefore, it helps for an office**** to have the ability to see the bigger picture of institutional effectiveness – both at a macro level and a micro level.
From the macro level, it helps to understand the issues facing higher education as an industry, as well as those issues that are of current import on a given campus in order to frame data and analysis with appropriate context. For instance, in the state in which I work, increasing the number of baccalaureate degree holders has recently been a topic of great focus, and knowing that allows me to provide information and analysis to decision-makers on our campus that will help them demonstrate how we are contributing to that goal as well as create models and provide information that will allow us to identify ways we could be contributing more. By knowing the broader set of issues, I am better able to anticipate the needs of key decision-makers on campus and get them appropriate information in a timely manner.
At the micro level, simply by virtue of the fact that institutional research tends to be far reaching within an institution – in the sense that we touch data produced or maintained by nearly every office on campus – the capacity to bridge gaps and recognize instances where two units or areas may be working on the same issue and could help each other or avoid duplicating efforts contributes to the general efficiency of an institution. In my experience, there are truly very few offices within an institution of higher education that, by definition, understand enough of what’s happening in each area of campus to serve in this role. Not to imply that institutional research knows the details of every area on campus – quite the opposite! IR knows *enough* across each area to make appropriate connections, but rarely possesses the depth of knowledge held in each area. By sitting the various fences, however, and peeking into the yards of each area to see what’s happening, we can facilitate efficiencies others may be unable to see. By knowing *enough*, we create an economy of scope by having the ability to see how the big pieces at least all fit together and serving the role of interpreter between areas – not just between IT and Users, but also between faculty and administrators, or even between functions such as Records and IRB. Additionally, as data monkeys, IR personnel inevitably learn the ins and outs of any given data base structure well enough to link data across areas more quickly and accurately than even two experts from the given areas (which is another form of interpretation, but one of data instead of language).
I’m sure there are other occupations that could also been seen as fence-sitters by various definitions (e.g., lawyers in their role as interpreters of the law to day-to-day applications and clients), and the idea intrigues me. It’s even possible that to some extent, all jobs could be framed as such, and it’s simply a question of identifying upon which fences one sits. *shrug*
* In another random, somewhat odd juxtaposition of nerds and geeks, I found this post from Savage Minds (which I stumbled upon through the link from Scott’s piece) today (though it was written a few weeks ago) oddly appropriate given that I am both a craftsperson and a gamer.
** The number of actual individual people that comprise a student body, regardless of how many courses they’re taking.
*** In every college or university there is an expectation that a full-time student is expected to enroll in a certain specific number of course credits, usually in the area of 12-15; an institution’s FTE is the total number of credits for which all students are enrolled, divided by the number of credits a full-time student is expected to take. It truly bears no real relationship to headcount, but it is often useful to compare the two: if an institution’s headcount enrollment and FTE enrollment are nearly equal, most of the students at that institution can be assumed to be attending full-time; however, if an institution’s headcount is considerably larger than their FTE, it can be assumed that a fair number of the students are enrolled less than full time.
**** Unless the office is just one person (which is not uncommon), it’s unnecessary for each member of an office to have these characteristics so long as the office when viewed as a whole does.