Stories of Engineering

Stories of Engineering:
The Narrative Perspectives
of New Engineers
Russell Korte
korte@illinois.edu
University of Illinois at Urbana-Champaign
2010 Forum on Philosophy, Engineering & Technology
Golden, CO
May 9-10, 2010

Think about:
What is the first thing that pops into your mind
when asked:
Who are you and what do you do?
10 May 2010 2fPET2010 (c) 2010 Russell Korte

Agenda
• Overview
• Narrative analysis
• Stories of engineering
• Conclusions

Overview
• Investigation of professional development within the
discourse of new engineers.
• Assuming that engineers’ professional and practical
understanding is bound up with their narratives of
practice.
• Thus, studying how engineers constructed their
stories provides insight into their professional
understanding.

Study
• Interviews of new grads, first job.
• Narratives transcribed into text.
• Content analyzed for what, how, and why.
– Focused on stories and accounts related to identity.
– Focused on stories and accounts related to work.
• Researcher’s stance: social constructionist

Agenda
• Overview
• Stories of engineering (examples)
• Conclusions

Ways of knowing
• Narrative process
– Links or relates particular events,
– Assigns significance to events
– Overlays a plot (organizing scheme)
– Focuses on local theories
Bruner, 2002; Polkinghorne, 1988

Plot formulation
• Abductive process of fitting an explanation
over the “facts.”
• Plots and subplots can weave together
complex events.
Polkinghorne (1988)

Narrative structures
• Emplotment of events, characters,
relationships, sequence, time, place, narrator,
audience.
• Range of narrative forms and structures.

Constructing a story
• Ah, let's see … I guess usually a lot of it is troubleshooting a problem, you know,
that's happened on the line or whatever and it requires some form of interaction
with either the mechanics and/or the process -- or the operators to get a feel from
them for what happened, what they were doing, maybe what buttons they
pressed or whatever the sequence was there and it's kind of -- that people side is
kind of the gathering of the information. And then from there it kind of becomes
a technical issue because typically you're there because they don't understand
what happens or can't figure it out, so at that point once you've gathered all the
information from your resources, then it becomes more of a technical issue. And
that's kind of, I guess, the transition there. But even after that point there's still,
you know, a point of relationship with the other engineers in the building and
sometimes you need to consult them in their experiences, so it really never truly
leaves the people side, I guess. Um, you know, and it's usually very heavily
involved on the people side. On the technical side, I found, is not as much. Like, I
don't find myself using a lot of stuff from school necessarily. It's usually very -- at
least at this point what I'm learning, I am supposed to rely on people to learn
things that I wasn't necessarily taught in school. So at this point I guess it's very
tough for me to say this is the specific technical side of me that I, you know, may
be working on myself. That doesn't happen very often. It's usually still working
with people.

De-constructing a story
1. troubleshooting a problem,
2. some form of interaction with
either the mechanics and/or the
process -- or the operators to get a
feel from them for what happened,
what they were doing, maybe what
buttons they pressed or whatever
the sequence was there and it's kind
of –
3. that people side is kind of the
gathering of the information.
4. And then from there it kind of
becomes a technical issue because
typically you're there because they
don't understand what happens or
can't figure it out,
5. And that's kind of, I guess, the
transition there.
1. The context
2. Events & actors (interactions)
1. Purpose of events, role of actors
2. Signifying an event, evaluating
actors
1. Establishing a transition point

De-constructing a story
6. But even after that point there's still,
you know, a point of relationship
with the other engineers in the
building and sometimes you need to
consult them in their experiences,
so it really never truly leaves the
people side, I guess.
7. On the technical side, I found, is not
as much. Like, I don't find myself
using a lot of stuff from school
necessarily. It's usually very -- at
least at this point what I'm learning,
8. I am supposed to rely on people to
learn things that I wasn't necessarily
taught in school.
9. So at this point I guess it's very
tough for me to say this is the
specific technical side
6. Partial reversal of the transition
7. Questioning the utility of dual
concepts
6. Significance of people in the
troubleshooting process
7. Formulating a new perspective

Narrative construction
• A bounded set of events including an outcome (bounded by
the author of the narrative).
• A chronology ordering the events.
• A finite set of actors (individuals or collectives).
• A set of relationships between events.
• A set of actions that link/transform events from one state to
another.

Agenda
• Overview
• Stories of engineering (examples)
• Conclusions

Narrative themes
• Elaborating the social context.
• Finding one’s way in the organization.
• Assigning utility to knowledge.
• Formulating a professional identity.
• Straight-forward problem solving.

Elaborating the social context.
Well I needed to figure out how often they were repairing that stretch of the
road, and how often maintenance has to go back there and figure out to
put the material back and how often they had to go back and fill the holes.
The thing about this project that was very interesting was that it was
kinda controversial, because that stretch of the road is [interstate XX], and
this highway goes from Texas all the way to north of Minnesota, (I think
Duluth…), I’m not sure. . . Well anyway, we decided it was the only part of
the road where trucks are not allowed to go through. Trucks over 9,000
pounds are not allowed to go through because when they were designing
the road, the people, the neighbors around that area didn’t want to have
the sounding effect of the trucks going through it. So they actually sued
the [department] to avoid building that road. So then I had to figure out,
What is it? What were the limitations of it? Because I couldn’t find a
road that would produce, you know, sounds or levels of sound that the
neighbors will like. So I had to be really careful about it, ‘cause we don’t
want to get into a legal problem. So it was very interesting. 05-014n:26-
30

Well, one thing that was very interesting at the time, and I wasn’t really
expecting was there was a whole big thing about the ownership of...
There’s, how it works in our department, there’s development engineers
and analysis engineers. Analysis engineers is what I am, deal with all the
work simulating airflow on the computer. Development engineers work
with us, they’re the ones who actually are in the wind tunnel testing.
They’re the ones who actually work with the designers in the process, And
so the development engineers and the analysis engineers work together
and the development engineers like own the results. But they’re the ones
who go to those meetings, those weekly meetings about everything that’s
going on in the development process. We pretty much sit back at our
desks and work on the computers. And so for the front-end airflow
analysis, as software and computers have gotten better and our
techniques and things have improved, we’re pretty much now to the point
where there’s no need to actually test in the wind tunnel the front-end
airflow. They still do somewhat, but it’s becoming more and more the
case where the development engineers don’t actually touch that.
(continued)10 May 2010 17fPET2010 (c) 2010 Russell Korte

And so we kind of, we’re talking a couple analysis engineers and saying --
well why are the development engineers still in the loop with this? And
why couldn’t we be going to those meetings and talking with the designers
and be presenting our results directly instead of going through the
development designers? I thought it was really funny at the time because
it was like -- I know mutiny isn’t the word, but like all the analysis
engineers were like... It started with one guy had the idea and a couple
other analysis engineers said -- that makes a lot of sense, we should bring
that up at a meeting with our boss and the development engineers. And,
well, it was like soft, treading lightly. And so like all the analysis engineers
were talking. They were bringing -- the group of a couple people were
bringing it up with other analysis engineers one at a time and getting their
opinion on whether or not this was a good idea before bringing it up with
everybody else. And so I just thought it was interesting the way, like they
were talking to people one at a time, being sure not to spread the word
that we were talking about all this. Because we weren’t sure how the
development engineers would feel about it. 06-004:184

Finding one’s way in the organization.
And so I call him up and ask him what I think I need to know. And it turns
out, you know, I don’t really know what I’m talking about so, and so I feel
like the one main guy who I have been working with, he’s been very
helpful in straightening things out and I’d ask him a question and he’d be,
he’d kind of pause and -- well, okay, I’m a little confused. Is this what you
mean or what exactly are you referring to? And so...Where I think I’ve
gotten my questions all figured out and I know what I’m looking for, and
then when I call him, I find out that no, I don’t really know exactly what
I’m talking about and I don’t really know for sure what I’m looking for.
But he’s been very helpful and -- well, this is probably what you mean. Is
that what you mean? I’m like -- yeah, I think so.
I don’t like advertising that I’m new, because it’s just -- I’d rather just be a
coworker, you know, a regular guy. And so I don’t advertise that but I feel
like people have been helpful in figuring things out in getting me up to
speed quicker. 06-004:226

Assigning utility to knowledge.
Because anyone you talk to pretty much, five percent of what you learn in
college, you really use in the real world unless you’re in a research
department. That’s when you’re still applying the theory and analysis.
But if you’re in other departments, you’re learning new things, new
processes, new programs, you know, using that. And I just feel college is
more the stepping stone of learning how to learn, learning where to find
what you need to learn, and learning how to deal with stress and what
you learned wasn’t so important, because now if you need to know
something, you have an idea of where to go, what to do, and you can
learn it then. That’s why I feel, I know a lot of people get kind of panicked
because they’re like -- I don’t know how to do this. I’ve got to know these
10,000 formulas out of this book because we’re going to need to know it
in the next class and you have to use it at work. And I’m like -- those like
triple integration, really deep problem, like you’re never going to see it at
work. 06-003n

Formulating a professional identity.
Just, I could feel…I don’t know. I don’t want to tell people what to do and
when to get it done. If I have the opportunity to be a project manager,
like if I have the opportunity right now, probably as a project manager I
have to submit deadlines. I say, Well this has to get done by this time or
this time. So I can get done things on my own time. But at that time, I
couldn’t do that; I was not a project manager. So if I am a project
manager right now - which I’m not, because my supervisor, she assigns
me projects or things. But in the future, if I am a project manager, then I
will plan and tell people, This is when I need to get it done. 05-014n: 242

Agenda
• Overview
• Stories of engineering
• Conclusions

Human experience
• The interactions between internal socio-cognitive
schema and sensory perceptions.
• How does one impose order on the flow of
experience and thus make sense of events and
actions in life?
• The composition and stance of the narrator not only
tells stories, but also constructs identities.
Polkinghorne (1988)

Narrative analysis
• How is the story put together?
• What cultural and personal elements are included?
• What cultural and personal elements are excluded?
• Why was it put together that way?
Riessman (1993)

Narrative resources
• We are never the sole authors of our narratives
(intertextuality)
– Early experiences
– Cognitive schema
– Socio-cultural structure (habitus)
• Becoming an engineer can be viewed through
narrative development (emplotment of experiences).

Selected References
• Abell, P. (2004). Narrative explanation: An alternative to variable-centered
explanation? Annual Review of Sociology, 30. 287-310.
• Bruner, J. (2002). Making stories: Law, literature, life. Cambridge, MA: Harvard
University Press.
• de Fina, A, Schiffrin, D., & Bamberg, M. (2006). Introduction. In A. de Fina, D.
Schiffrin, & M. Bamberg (Eds.), Discourse and identity. Cambridge: Cambridge
University Press.
• Franzosi, R. (1998). Narrative analysis: Or why (and how) sociologists should
be interested in narrative. Annual Review of Sociology, 24, 517-554.
• Ochs, E. & Capps, L. (1996). Narrating the self. Annual Review of Anthropology,
25, 19-43.
• Polkinghorne, D. E. (1988). Narrative knowing and the human sciences. New
York: State University of New York Press.
• Riessman, C. K. (1993). Narrative analysis. Qualitative Research Methods 30.
Newbury Park, CA: Sage.
• Watson, C. (2006). Narratives in practice and the construction of identity in
teaching. Teachers and Teaching: Theory and Practice, 12(5), 509-526.

Stories of Engineering

Recommandé

Recommandé

Contenu connexe

Similaire à Stories of Engineering

Similaire à Stories of Engineering (20)

Plus de Philosophy, Engineering & Technology

Plus de Philosophy, Engineering & Technology (18)

Dernier

Dernier (20)

Stories of Engineering

Notes de l'éditeur