Posts that are engineering edu-ish
I burned and skidded hard last week regarding deaf accessibility — one thing after another, multiple events, multiple people, no safe “home” to relax in. It’s like running off the battlefield and coming home and taking off your armor only to have your family and friends come up and punch you in the face. At some point, you just don’t take off your armor, don’t let down your guard.
Every day, for over a week, I pulled myself away from burning out, accepting that just functioning — sleep, eat, pray, sleep, eat, pray — was sapping all my energy right now, and that it was ok to prioritize not-breaking-down over “getting real work done.”
I did not burn out. I’m proud of this. The storm’s not done, but it’s getting better.
I mustered up the courage and internal resources to reach out to friends. It’s a hard thing to reach out when the very thing you’re suffering from is a struggle to connect and communicate — you could just be setting yourself up for another blow, another frustration. And I’d like to say that it is wonderful having friends who study speech/hearing sciences and can translate your frustration into validated intelligibility, friends who study linguistics and have been the struggling-to-understand outsider in a room of native speakers of a different language — friends who make you homemade pasta and feed you tea and muffins and San Pellegrino and set up the chairs and lighting so you don’t need to strain to understand just that one conversation — because those few hours are enough to remind you that yes, this exists; yes, you belong within humanity; yes, this is what it’s like to live inside that sort of space and community, and this is how it can and should be. This is possible.
I also got some really, really good advice from other deaf academics for the first time (another side effect of reaching out was unexpectedly being introduced to a wonderful group of these people). I’ve summarized/synthesized their advice below, and placed my responses inline.
0) It sucks and we’ve been there too.
Thank you. This is so, so helpful to hear. My hearing colleagues almost never say this when I talk with them about accessibility, but I need to hear it before jumping into solutions-brainstorming. If I don’t, my subconscious keeps hearing “and it’s your fault and you should just try harder,” which makes me believe it and feel all sorts of guilty that I’m not, y’know, trying hard enough.
1) Consider only attending events where accessibility has been set up, and don’t feel guilty; there are tons of opportunities.
I may be able to do this for some (nonacademic) venues where I’m now invited to speak (instead of trying to persuade people to let me speak). None of them are accessible, but I can set accessibility as a condition of my attendance/speaking. The tricky part will be not having that “count against” other things I can negotiate (for instance, “we can pay for an ASL interpreter or your plane ticket, but not both”).
2) If you want to bring accessibility into a non-accessible venue because you’ll be attending it for decades, recognize it’ll take 3-5 years of work for them to “get” it. Build networks and allies and push your institution for flexible pools of funding for smaller events, especially during this transition time.
The two major academic conferences in my field (and the few outside it I may want to regularly attend) definitely don’t “get it,” so I think I’m in for a long-term project. I wonder how I can make this work visible and get credit for it.
3) Slow down. You’re carrying a workload that would crush any grad student, deaf or not.
I really didn’t want to hear this one, but you’re probably right. I think I need to know this isn’t a “lower your expectations because you’re deaf” thing, and that people would say the same things to a hearing student. My whole life has been full of people telling me I can’t do XYZ because I’m deaf (and being wrong), so I’m… hypersensitive to any statement about limitations, and need to stop myself from constantly trying to empirically disprove its truth value. Sometimes it’s true. It’s just hard for me to tell what’s true.
4) Delegate aggressively to the DRC (disability resource center) on campus; you and they need to calibrate that they’ll set up this stuff, not you.
This was a wake-up call. Thanks. Email sent and at least one conference’s worth of stuff delegated. I’ve never seen anyone “at my level” interact with interpreters, captioners, disability centers, etc. before, so I have no calibration for expectation for that interaction outside my own experience — and it is super-helpful knowing that I’m not “supposed” to do all this setup.
I will say I appear to be a weird first-case for a lot of things for my university, so they do legitimately need to ask me for a lot of details more often than not — but I need to recognize that as the exception rather than the rule (even if the exceptions are far more frequent than the rule right now).
5) Recognize the rhythms of the academic year for faculty — which are different than for students — and plan your workload accordingly.
The rhythm-differences between faculty and student life surprised me this year, so thanks for pointing that out. October’s definitely a crushing month for my discipline, and I’ll need to watch and plan for the rest. I’m glad I have a 3-year postdoc (starting next year) to do that in, which also gives me 3 years to get conference access set up before I do… whatever I do next.
This blog post started as an explanation of my personal research process for my Hacker School Book research team. We were talking about the various ways people take first-pass, rough notes on transcripts, and I offered mine as an example. Tiago Forin and I co-created this specific technique variant for our DTRS analysis, but we’re pretty sure we’re not the only ones who’ve reinvented this particular wheel.
The picture shows an interview transcript with a bunch of marker scribbles on it. Basically, it’s a way of marking codes (“themes”) in text so I can see big patterns and go back for finer-grained analysis and checking later. For instance, in an interview with furniture designers, I might want to mark all the times someone is talking about how important shapes are in furniture design. So every time I see that code occurring in the data, I write a short word for that code (“shape”) right on the data, and draw an arrow through all the text I want to encapsulate with it.
Important disclaimer: the document pictured (including the transcript) is entirely open-licensed, so the picture can be shared far and wide. However, to create this example, I picked random codesets (that don’t really apply to the data) and I randomly scribbled those codesets across the page with no particular rhyme or reason, so don’t try to actually read the text and figure out how in the world this sentence is an instance of “4th wall” or “model” or whatever — or even what those codes might mean — because these codes do not correspond in any way to the transcript!
When I have multiple codesets, I color-code the codesets. For instance, I might have a green codeset for “everything related to how the furniture design looks,” like “shape” or “form.” I might have a blue codeset for “acting techniques they use when presenting their work,” like “breaking the 4th wall” or “monologue” or “dramatic pauses.” I might have a red codeset for “pedagogical techniques” like “modeling behavior” or “coaching the audience through a process.” This lets me see where codes overlap/co-occur; for instance, does “coaching” often happen when people talk about “form”?
This also makes it super-easy to collaboratively first-pass code with someone, since we’ll just split up marker colors. I might take green and pay attention to shape/form as we’re going through the transcript, while you take the red and watch for pedagogical techniques. We can do this sort of coding simultaneously, discussing the transcript while we both scribble on it — or asynchronously, where I take the data to my desk and mark up all the shape/form codes in green, then hand it to you to do the pedagogy pass in red. We end up with a useful boundary artifact for discussion, which helps us do a more detailed analysis pass with better precision and sophistication. Eventually, we load the codes into a computer for even more analysis.
But that is all later — much later. This is my first quick-and-dirty step. It’s me, maybe a colleague or two, a bunch of colored markers, and a table strewn with printouts, reading quickly through these things and marking them. I can get through a 25-page transcript in less than 15 minutes if I’m only marking for a small codeset, and I’ve read the transcript before.
So if you’re in a research project that I work on, this is probably what’s happening to your transcript at some point! And if you’re working on a research project with me, you will probably be handed packages of children’s art supplies at some point. It is fun!
Last year, I wrote a post asking people to donate to the Ada Initiative and support women in open technology and culture. I said:
We change the world with millions of tiny patches… our world of open technology and culture is built one patch, one line, one edit at a time — and that’s precisely why it’s powerful. It brings billions of tiny, ordinary moments together to transform the world. If we teach it for our code, we can preach it for our giving. If you’d buy me a drink, or treat an open source newcomer to dinner, send that $3-$20 to the Ada Initiative tonight. –August 30, 2013
Why do we need to do this? Well, being a woman in open technology and culture is like riding a bike on a street made for cars, where rain and dirt get kicked into your face, and you are constantly, painfully aware that if you have any sort of collision with a car… the car will win. Yes, this is happening in our world, to our friends and to our colleagues; it’s happened to me personally more times than I care to remember. The farther you are from the straight white male difficulty setting, the rougher the terrain becomes.
And quite honestly, we’re busy. I’m busy. You’re busy. This isn’t our job — we have so many other things to do. I mean, we’re all:
- remixing music
- playing with code
- writing science fiction
- co-authoring open content articles
- redesigning user interfaces
- <insert your favorite open technology and culture activity here>
And guess what? There are so many people who want to join us. So many people who want to help us do all this work, but don’t, because they know that work — the good work — is likely to come with a lot of really, really awful stuff, like this sampling of incidents since last year (trigger warning: EVERYTHING).
The less time women spend dealing with that stuff, the more time they have to help us with our work. And the more people will want to help us with our work. I mean, would you want to accept a job description that included the item “must put up with demeaning harassment and sexual jokes at any time, with no warning, up to 40+ hours per week”?
Making our world a good environment for all sorts of people is, in fact, our job — or at least part of it. The folks at the Ada Initiative have made supporting women in open tech/culture their entire job — supporting it, supporting people who support it, and basically being the equivalent of code maintainers… except instead of code, the patches they’re watching and pushing and nudging are about diversity, inclusion, hospitality, and just plain ol’ recognition of the dignity of human beings.
They want to support you. With better conference environments, training workshops and materials, and really awesome stickers, among many other things. (Did you know that the Ada Initiative was one of the first woman-focused tech organizations to actually say the word “feminism”?)
So please, donate and support them, so they can support you — and me, and all of us — in supporting women in open tech/culture.
Now, my own contribution is a bit… sparse, financially. I’m a grad student earning less than $800 a month, and I’m waiting for my paycheck to come in so I can contribute just a few dollars — but every little bit helps. And there’s another way I can help out: I can bribe you, dear readers, to donate.
Remember that “active vs reflective” learning styles post I wrote in August? Well, there are 3 more: sensing/intuitive, visual/verbal, and global/sequential. I’ve got them all transcribed here and ready to go. And if we reach $1024 in donations to the Ada Initiative under the Learning Styles campaign within the next week, I will release them under a creative-commons license.
What’s more: the first 3 people who donate $128 or more to this campaign and email me their receipt will get a free 1-hour Skype call with me to discuss their personal programming learning styles, and will be featured as case studies on one of those three posts (I’ll link to your website and everything).
Donate to the “learning styles” campaign for The Ada Initiative now!
We’ve finally got enough interview data for the Hacker School Book Project that we can start seeing some patterns in the stories people tell. I’ve gotten fascinated by a cluster of ideas that relate to apprenticeship-style learning. This blog post describes some of my thoughts-in-progress on the topic.
Originally, I thought I’d be using the cognitive apprenticeship codebook (modeling, coaching, scaffolding, fading, articulation, and reflection) because it describes a lot of the techniques Hacker Schoolers use to teach each other. When the actual interview data came in, I rapidly realized that while I was seeing these techniques a lot in the Hacker School space, people didn’t talk about them in the interviews. So I’ve switched gears, and have these themes/codes instead.
Apprenticeship-related themes in Hacker School Book interviews (so far)
- accidental learning
- legitimate peripheral participation
- making thinking visible (cognitive apprenticeship)
- zone of proximal development
- talking like a programmer
- stage performance of programming
What do these words mean? Well, we can think of Hacker School as a place where people learn through (cognitive) apprenticeships. Instead of listening to lectures about programming, Hacker Schoolers learn by actually programming with other programmers. This ultimately helps them engage more deeply in the broader programming community of practice that stretches beyond the walls of Hacker School.
Several apprenticeship-related big ideas pop up in the stories Hacker Schoolers tell. First of all, Hacker Schoolers engage in lots of accidental learning of things they didn’t intend to pick up; a chance comment on a mailing list, a glance at someone’s screen, or a lunch conversation will spark a new idea. Second, they offer and take opportunities for legitimate peripheral participation, which refers to the creation of “entry points” where novices can usefully contribute to a real project.
Third, Hacker Schoolers make thinking visible to each other as a way of both teaching and learning; they present and demo, coach others through tasks while pair programming, work together to break down large tasks into simple ones, and so forth. They often do this as a way to help each other stay in their zone of proximal development, where they stretch their abilities by working together on things they can only do with assistance. In the course of this collaboration, they don’t just make their thoughts understandable to computers in the form of code; they also make their thoughts understandable to each other.
By making their thinking visible, Hacker Schoolers practice talking like a programmer, where using the right vocabulary words (“functional programming,” “z-buffer”), technologies (git, IRC/Zulip, bugtrackers), and conversational etiquette becomes just as important as writing the code itself. They get to experiment with their stage performance of programming and the choices they make about conveying aspects (humility, confidence, experience, etc) of their programming “persona” to others through their behavior.
Where do I want to go with these ideas?
This set of themes is very, very early and unformed — my thoughts are changing constantly as more people interview each other and more data comes in. That having been said, I feel like there’s something here — at least an indication that this is a useful way (among multiple useful ways!) to think and talk about about what’s going on at Hacker School.
One thing I’d love help/ideas on: I’d like to find a better way to phrase the “stage performance of programming” code, which draws from performance theory — the idea that we all perform roles (as if we were actors in a play) and portray ourselves as “characters” by doing certain things. For instance, part of my “performance” as a programmer might be always wearing t-shirts with a software company’s logo on them, so I’ll be seen as knowledgeable about and connected to nifty software startups. Or I might always talk really fast, with lots of long technical words, because I think it will make other people think I’m smart (…but it just makes it harder to understand what I’m saying).
In fact, a lot of the Hacker School social rules can be seen as ways to gently steer away from certain kinds of “performances” so that other (healthier, more hospitable) “performances” of programming can emerge. Things like “well-actuallys” and “feigned surprise” are negative because they’re putting on a show — doing something in order to get a certain reaction/status from someone else. So this idea of “performance” at Hacker School seems like a very important one.
However, I worry that the phrasing “programming performance” makes people think of “how good am I at writing code?” instead of “what behaviors do I adopt so other people see me in a certain way?” Can anyone think of a better way to word this?
Over the next few days, I’ll be introducing the new members of the Hacker School Book research team and the stuff they’re working on — or rather, they’ll be introducing themselves. We kick this off with a guest post from Gabrielle Ewall (the team is working on getting their own personal blogs up, so this should settle down in a week or so).
Hey friends! I’m Gabrielle. Right now I’m pursuing an undergraduate degree in Engineering with Neuroscience at Olin College. I am passionate about education questions such as: what motivates people to learn, how can lessons most effectively engage students, and what factors make an educational environment most accessible to learning disabled students. I am interested in computational modeling techniques like Machine Learning and Bayesian Inference.
The questions we’re trying to answer
We’ve heard that many Hacker Schoolers are interested in the learning styles framework, and we plan on investigating what learning styles mean at Hacker School. Specifically, we’re curious about the following:
What is the distribution of learning styles among Hacker Schoolers, and how does that compare to distribution among other groups (undergraduate engineers, etc)? Do certain combinations of learning styles gravitate towards Hacker School?
How does learning style affect feelings of personal success at Hacker School? Are certain experiences at Hacker School more rewarding for individuals with a particular learning style?
Is learning style related to how Hacker Schoolers feel about their undergraduate experiences? For example, might active learners think “college was boring but Hacker School is great,” whereas reflective learners might think “college was awesome, and Hacker School is also awesome?” If the learning environment of their undergraduate institution does not fit a Hacker Schooler’s personal learning style, can this contribute to imposter syndrome?
We hope that information about the learning styles distribution will help us understand Hacker School as a learning environment.
How we’re addressing these questions: Bayesian statistics
The first thing I am working on is comparing the distribution of learning styles in Hacker School to the distribution in other groups. Since there’s been a lot of research done on learning styles distributions, we already have some beliefs about what learning styles distributions might be most likely at Hacker School. Bayesian statistics (here’s an open-content textbook on that) is an awesome tool for these kinds of problems because it allows us to incorporate prior beliefs like this into our analysis. Additionally, Bayesian statistics allows us to preserve information about the uncertainty of our hypotheses, which is especially important given the sparsity of our data right now.
Where to get my code
The current code is living at https://github.com/gabriellee/HackerSchool, and utilizes Allen Downey’s thinkbayes2 and thinkplot modules (also included on my repository, so just grab the whole thing).
The code is very basic right now. I initially assume that the ratio of sensing to intuitive learners at Hacker School is equally likely to be any percentage from 0 to 100. The code updates the hypotheses of this ratio according to data from an imaginary group of Hacker Schoolers who happen to have a 50/50 ratio of sensing to intuitive learners, and outputs the probability that Hacker Schoolers have the same ratio of sensing to intuitive learners as a different hypothetical group with a 50/50 ratio. It also produces a graph of the probability of various sensing:intuitive ratios at Hacker School.
How to run my code
The code will be more exciting to run in a little while (and we will report back with a demo at that time), but if you’re really curious right now: to run it, you’ll need ipython notebook installed. If you already have python and are running Linux, you can type:
sudo pip install ipython[notebook]
into your command line and you’re good to go. Otherwise, grab Anaconda. When you’re all set, open and run learningstyles_dist2.ipynb to use the code.
Over the next few weeks, I plan to create implementations of this code for all of the learning style categories, use a more reasonable set of prior beliefs about the likelihood of each hypothesis, and start to input some real data! Stay tuned.
When I hang out with academic-offspring-of-academics like Alice or Caryn, I am struck by how much cultural capital gets passed from parents to children. I am the first person in my family to pursue a PhD, and every new benchmark in my academic career has slammed into me like a freight train of surprises: what is this “tenure” thing, and — wait, tenure is a big deal? What do you mean, I have to write in order to “do research”? And what’s this about “grants?” What are those, and why would you “write” them? Don’t universities just pay your salary?
I am a little jealous of my friends and colleagues who implicitly absorbed so many of these things from parents (and particularly mothers) who were and are academics. I often struggle to explain my work and my confusion to my family of middle-class, (mostly) fluent-English-speaking (mostly) college-educated professionals — I can’t even imagine what first-generation college students working outside their native language have to go through.
Perhaps my obliviousness is exaggerated by my deafness, since I don’t overhear (or join in on) those side conversations about academic culture that so many of my classmates seem to know. And maybe this frequent experience of getting hit by cultural freight trains is why I strain so hard to make my work accessible to others. I don’t want to be another contributor within the walled garden of the elite, because I know what it’s like to be locked out of that garden, blindly struggling to climb a fence into a world I want to join, even if I don’t really know what it looks like. (Yes, I still feel that way every day. I’ll probably still feel that way when I get tenure. Helen Keller got it right when she said being deaf cuts you off from people — it’s a statement that holds true even when those people are the family, friends, and colleagues you’re closest to.)
I also realize that, for what it’s worth, my kids will have a mother who is an academic writer/teacher and a hacker/engineer, and my meditations on that have grown to the point that they should be another blog post…
I’m blessed to have Alice Pawley on my PhD committee. Among many other things, Alice is an excellent writer and an excellent giver-of-feedback on writing. Since I’m still working to find my academic writing “voice,” I met with Alice this summer and asked for advice. This blog post consists of my synthesized recollections from that conversation. Three main topics stuck with me:
- What is good writing?
- What differentiates good journalistic writing from good scholarly writing?
- Where can I find examples of good scholarly writing, including writing in nontraditional formats and writing for lay audiences?
What is good writing?
According to Alice: good writing, academic or not, consists of:
- Coherent arguments in the form of structured and supported points…
- that are grounded in data…
- and have a so-what that tells the reader why they should care about what you’re saying.
What differentiates good journalistic writing from good scholarly writing?
Although it seems obvious now, this point was the one that surprised me the most: not all good nonfiction writing about science is scholarly writing. Scholarly writing — research — needs to introduce new knowledge to the world while still connecting to existing scientific literature. In contrast, journalistic writing is about ideas that matter and topics that people care (or ought to care) about. The two categories can overlap, but they don’t have to. Instead of being research, journalistic writing might be about research; it may present ideas that have already been introduced to the world.
I had been mixing up scholarly and journalistic writing, assuming that if it was about research, it was research. Nope, said Alice. By that standard, any book by Malcolm Gladwell qualified as scholarly writing. (I immediately grimaced, saw my logical hole, and retracted that statement.) By the updated criteria of “must introduce new knowledge,” many of my favorite “scholarly” writing books get recategorized from scholarly writing to “good journalism about science.” These include everything by Michael Pollan (of Omnivore’s Dilemna fame), Dan Coyle’s The Talent Code and Andrew Solomon’s Far From The Tree – easy concessions for me to make, because Pollan, Coyle and Solomon are journalists by trade. But even when the book is written by a researcher, it may not be research — for instance, Steven Levitt is an economics researcher, but his popular book Freakonomics is a journalistic synthesis of existing economics work.
These are tools for thinking, not perfect definitions. For instance, I find it difficult to categorize books in which researchers synthesize and re-present their own original research for a lay audience, such as Deci and Ryan’s Why We Do What We Do (still my go-to refresher on intrinsic motivation and self-determinism theory) and Wenger’s Cultivating Communities of Practice (a mercifully navigable business-audience rendition of his theoretically dense book Communities of Practice). A common pattern seems to be co-authorship between the original researcher, who presumably understands the ideas in the book better than anyone else, and a journalist, who presumably makes them understandable to everyone else.
Where can I find examples of good scholarly writing, including writing in nontraditional formats and writing for lay audiences?
Okay, I said. Then what would qualify as scholarly writing? We came up with a few examples: Belenky et. al.’s Women’s Ways of Knowing and Bateson’s Composing a Life were already on my list of favorites, as are practically all of Csikszentmihalyi’s books (the most famous being Flow.) Alice also recommended Bowker and Star’s Sorting Things Out, Cowan’s More Work for Mother, and Gieryn’s Cultural Boundaries of Science – along with Reading Places and Reading on the Middle Borders by her mother, Christine Pawley. On the “nontraditional format” front, Alice recommended reading academic bloggers and most things published by MIT Press, including their mediawork pamphlet series. (Laurel’s Utopian Entrepreneur is an example of a pamphlet in that series.)
I’m primarily interested in nontraditional formats because I want to reach a lay audience, but Alice pointed out that the “lay audience” step usually comes last in writing — Wenger couldn’t have written Cultivating Communities of Practice for a lay audience without having written Communities of Practice before that. Even books like Women’s Ways of Knowing and Flow and anything by Brene Brown draw on material that their authors originally wrote for an audience that shared their specialty. It helps to wrestle with ideas alongside people who understand our “shop talk,” just like it helps to have fellow programmers review your code even (or especially!) if your end product is an application for non-programmers.
That’s a long way of saying that my dissertation will probably not be (pleasurably) readable for a lay audience. I do want to edit it into something that will be fun for non-reseachers to read, but I need to write the research version first and graduate, then write the book for everybody else. And I think I am okay with that, although it has taken a while.
“You need a way to refer to your data and let us know where things are coming from,” said Robin.
I stared at the scribbly pages on the table between us and nodded. It was a mess. The great thing about letting your narrators read and refer to one another’s stories is that you end up with fantastically rich reactions. The problem is that you end up with stories that cross-reference each other, and it gets hard to disentangle who is quoting whose paraphrase of whose original thought. Was this Jon quoting Lynn? Lynn referring to Rob’s interpretation of Jon’s reaction to Lynn? My annotation on Lynn’s reference to Rob’s interpretation of… where were we, again? It was making my head spin, and I’d spent dozens of hours with these narrative transcripts.
“The data comes out over time,” said Robin. “And there are different voices, but the newer ones know and refer to the older ones,” I added. “Very specific pieces of the older ones, and they reinterpret it in light of what’s happening to them now.”
“So you need a citation format,” Robin said again, as I scribbled a long citation prototype on one corner of the transcript. (1 Jon Stolk, 2014, p. 4). That seemed so… clunky. I wanted to be able to create concordances, just like the…
What if, instead of 1 Corinthians 13:4-7, I had 2 Rob 4:18-22? Break my transcripts into “chapters” by topic, and “verses” within those chapters by thought-unit, and then used a familiar compact citation format within the text?
1I think that’s one of the interesting things about being in a place like this. 2 And I say Berea, because it’s quite unique. 3 Because most of the people who are here are not here because it’s a job. They’re not here because of the pay. They’re not here because of the glory associated with it. They’re not here because they love Berea, Kentucky. 4 They’re here because they like the school and they care about the students and they care about the mission. [2 Mark* 16**:1-4]
*Mahoney, a professor at Berea (yep, this content’s open-licensed)
**may not actually be chapter 16 in the final numbering, I need to go through and split everything properly
Instead of Matthew, Mark, Luke, and John, I have Gary, Mark, Lynn, and Jon… and Rob and Alan. I can now take my data and dump it into some sort of open-source Bible web software and make concordances, and study notes, and… all those other things that people do with Bibles that we already have a ton of software for. My data will actually be navigable. I can easily hyperlink to subsections of it from within my dissertation text.
My indexes and commentaries and concordances on the narrative text also turn into analysis, and all that analysis (not to mention the narrative text itself) — through all the open-source tools people have released to analyze the Bible. I can repurpose the work of hundreds of Christian software engineers to visualize and understand these 6 professors talking about engineering and technology curriculum design. BWAHAHAHA!
Of course, I’m going to need to resist the temptation to rewrite the transcripts into something like this:
A reading from the First Data according to Jon.
Thus saith the JON: My name is JON. I have been at Olin since 2001, and it is since 2001 that I have been at Olin. Lo, I have arrived a little bit before students arrived, in the summertime at the start of July. I, the JON, was at Olin early enough to hear lots of conversations from the founding faculty, the group of 8 here before me; 8 they were in number, and their number was 8. For I am the JON, and thus have I spoken, quoth the JON.
The word of the JON. (Thanks be to JON.)
Oh. Since I’m asking so many Hacker Schoolers for their engineering learning styles, it seemed only fair to post my own.
Text-accessible version: For each of the 4 axes, I am almost on the extreme edge one side. Specifically, I am very active (not reflective), very intuitive (not sensing), very visual (not verbal), and very global (not sequential).
It’s interesting to reflect on how these results may be skewed by other factors — for instance, am I a visual learner because I’m also profoundly deaf? Is there some alternate-universe hearing-Mel who soaks in audiobooks and lectures? I certainly love reading, and am a fluent writer and improvisational speaker, so it’s not that I’m unable to navigate verbal information… it’s just harder, although I don’t think I can dissect my hearing from any innate preference I might have with an undamaged cochlea.
It’s also interesting to see what axes I have and haven’t been able to stretch past my preference on. As noted above, my visual preference hasn’t kept me from being extremely fluent with the verbal end of the spectrum; the visual-verbal axis is one I feel I can shuttle freely across with little trouble (except when it relates to being deaf — once I can perceive the words, I’m fine).
The active/reflective spectrum is more of a stretch — impulse control and careful checking are a constant challenge for me (and ADHD doesn’t help), but it is often doable for short spurts with grueling, deliberate effort, partly because I have a clear idea of what “reflective” looks like and can therefore force myself to masquerade as such if needed. But it is absolutely a masquerade, and one that wears me down quickly.
I don’t think I know how to be anything other than intuitive. My brain makes connections no matter what I do. However, it makes connections so darn well that I also love a sensor’s concrete examples (possibly because they often use physical/visual artifacts) because it’s easy for my brain to generalize from case studies to high-level topics and theories. This means I can function in an environment designed for sensors, but I can’t masquerade as a sensor the way I can masquerade (poorly, and with great effort) as a reflective person.
It’s a similar thing with being global; I am definitely strongly global and cannot pretend to be sequential, but I’ve learned to function in a sequential world by reading ahead, devouring alternative resources, piecing together bits into my own big picture, asking question after question after question (as an active learner) until I have the bits and pieces that I need. This also reflects the way I recreate auditory data — I get bits and snatches, then piece them together into whole sentences and conversations (and it usually works, sort of). I piece together auditory data — and at a broader level, conceptual/intellectual information on topics I’m learning — the same way the normal human visual cortex stitches together a full-color, high-definition scene from the brief glimpses of our eyes’ tiny, lossy sensors as they saccade across the landscape…
But that’s another blog post for another day.
The best part of Visualization class so far is getting exposed to a wild gallery of examples (visual Hacker Schoolers, take note!) Some of my favorites:
I also learned a new phrase: external cognition (Scaife & Rogers, 1996) — it’s a concept I’ve used many times, but now I have a literature reference for it! External cognition refers to using stuff to offload your brain — for me, it’s spreading papers out on my desk, scribbling on a whiteboard, saving notes on a computer, and so forth… instead of memorizing, I learn how to look up things, or I configure my software to pop up notifications to remind me. Basically, I get a lot less “smart” without my tools.
I’ve decided my class project will be a visualization of narrative data (from my dissertation) — how to navigate between intertwined stories of the same event from multiple viewpoints. In addition to thematic similarities, we have examples of:
- Same event, same narrator, different tellings: Lynn sits down in the spring and tells me about the first day of UOCD (a class). Later in the summer, Lynn sits down again and tells me about the same first day of UOCD — how do the two versions of her telling differ?
- Same event, different narrators: Jon also told me about the first day of UOCD. How is his account similar/different from Lynn’s?
- Narrators mentioning each other: Lynn mentions Jon in her account of UOCD’s first day, and Jon mentions Lynn.
- Narrators responding to each other: Once Lynn reads what Jon said, she starts thinking about how she told the story. (Possible sub-question: what in our stories do we choose to focus on / react to? Is there a heatmap we can make?)
This is going to be fun to play with and untangle — I’m not sure what I want to visualize yet, but the above connections seem like a reasonable starting point.