Engineers as

Problem-Solving
Leaders:
Embracing the Humanities
KATHRYN W. JABLOKOW

I
n 1902, David Starr Jordan,
President of Stanford Uni-
versity, remarked: “There
are very many things be-
sides engineering [that] go
into the making of a real engineer”
[5]. Over a century later, in 2005,
Charles Vest, President of MIT, ad-
monished the attendees of the Na-
tional Academy of Engineering’s
“Engineer of 2020” National Edu-
cation Summit [15]:

“As you develop the concept

of a new curriculum and new
pedagogy, as you try to at-
tract and interest students
in nanoscale science, large
complex systems, product de-
velopment, sustainability, and
Todd Davidson/Stock Illustration RF/Getty Images

business realities, don’t be

tempted to crowd the humani-
ties, arts, and social sciences
out of the curriculum. The
integral role of these subjects
in U.S. engineering education
differentiates us from much
of the rest of the world. I be-
lieve the humanities, arts, and
social sciences are essential

Digital Object Identifier 10.1109/MTS.2007.911075

IEEE TECHNOLOGY AND SOCIETY MAGAZINE | winter 2007 1932-4529/07/$25.00©2007IEEE | 29

 to the creative, explorative,
open-minded environment
and spirit necessary to edu-
cate the engineer of 2020.”
Using problem solving as a backdrop
leads to insights about what it takes
to move beyond engineering
competence to engineering leadership.
Other distinguished engineering
scholars and practitioners have
made similar observations and rec-
ommendations in the interim. In
1995, for example, delegates from
12 nations at an international sym-
posium sponsored by the European
Society for Engineering Education
(SEFI) agreed that “the humani-
ties and social sciences are vital for
the full intellectual development of
an engineer” [4], and Florman [5]
noted several years later: “the vital
first step is to convince engineering
students that technical brilliance is
not enough”.
Clearly, at least one message
coming from those in the highest
and most respected positions in
our profession has not changed a
great deal in 100 years: engineers
must know more than engineer-
ing in ­order to be good engineers.
Equally clearly, a large number
of engineers must remain uncon-
vinced, or there would be little
need to repeat the message with
such urgency at those same high
levels of influence. What, then,
can be done to bridge this gap in
the appreciation of non-techni-
cal subjects? How might we do a
better job of convincing engineers
that non-technical knowledge and
skills are both relevant and useful?
How can we implement the com-
mon vision of Jordan, Vest, Flor-
man, and others more effectively?
In this article, I offer a new
perspective on this quandary that
may provide both a path to its
resolution and better understand-
30 | IEEE TECHNOLOGY AND SOCIETY MAGAZINE
ing of one of the core elements
of the engineering discipline
as well. Specifically, I will pro-
pose that framing the situation
in terms of problem solving – one
of the activities with which engi-
neers are most familiar (in a tech-
nical sense, at least) – provides a
view of non-technical subjects and
their practical value that may be
more appealing and compelling
to engineers. This framework sug-
gests and enables a new mode of
discourse, one that may be more
effective in reaching those who
remain as yet unconvinced; in es-
sence, the language of problem
solving is the language of engi-
neers, and I believe we can (and
should) use it more effectively. In
addition, using problem solving as
a backdrop leads to insights about
what it takes to move beyond engi-
neering competence to engineer-
ing leadership – a goal toward
which we must strive if we are to
remain competitive in the current
fast-paced global economy.
Communicate, Collaborate,
and Do the Right Thing
Let’s begin by considering a few
of the non-technical subjects most
often identified as relevant and
important for engineers. Among
the designers of engineering de-
gree programs and those pro-
grams’ accreditors, it is generally
agreed that in addition to some
well-defined standard of techni-
cal material, the “competent” en-
gineer needs knowledge and skill
in several key areas that have
their roots in the social sciences
and humanities [1], [15]. Some of
the most familiar of these are:
n Communication
n Collaboration
n Ethics and social responsibility
In the first case, engineers need
to be able to communicate to oth-
ers what they do, accurately and
persuasively (both orally and in
writing), and to understand what
others want them to do, where
these “others” are becoming in-
creasingly diverse in terms of both
discipline and culture as problems
expand to cover more different ar-
eas of specialization and the cor-
porate workplace spans the globe
[7]-[9], [18]. Second, due to the
increasing difficulty and complex-
ity of today’s problems and what
Florman refers to as the “changing
social order” [5], engineers must
learn to work effectively in teams
(i.e., to collaborate), making best
use of diverse human resources
(of knowledge, skill, and/or strat-
egy, for example) in order to solve
the problems with which they are
faced [9]. All of these conditions
also lead to increasing demands
for higher sensitivity on the part
of engineers to the social impact
of their actions [6], [14], [20]; en-
gineers must behave ethically and
responsibly within a broader social
context than ever before.
Unfortunately, in the view
of many engineers, even these
few key subjects are too widely
separated from engineering to
be relevant or useful, and sadly,
this opinion is held by students,
faculty, and practicing engineers
alike. Their ambivalence (which
sometimes borders on hostility) is
demonstrated in a number of ways.
Florman [5] reports, for example,
that many engineering students
choose engineering precisely be-
cause it is “viewed as having no
political or cultural component”;
in essence, they see engineer-
ing as a discipline that deals with
things, not people – and they find
the apparently greater predictabil-
ity of “things” more attractive. In
addition, engineers often perceive
that non-technical subjects “don’t
| WINTER 2007
count in the real world” despite
repeated claims from companies
that new hires must be “team
­players” who are able to commu-
nicate and collaborate effectively,
both within and across cultures.
For the most part, companies
continue to employ new gradu-
ates (and experienced engineers
as well) based primarily on their
technical abilities [5], paying lip
service to non-technical qualifica-
tions or attempting to introduce
them through training after the
hiring is done. Finally, engineer-
ing faculty members themselves
are frequently cynical about non-
technical subjects, viewing them
as a drain on already limited re-
sources of time and effort within a
crowded engineering curriculum.
Problem Solving:
A New Perspective
on an Old Quandary
Part of the challenge in convincing
engineers (in any sphere – academ-
ic or corporate – and at any rank)
that non-technical subjects are rel-
evant, important, and useful lies in
demonstrating concrete benefits in
exchange for their efforts in mas-
tering them. What, for example,
will they do better as engineers if
they become proficient in aspects
of the humanities or social sci-
ences? Will they design more and
better products? Will they build
systems more rapidly and efficient-
ly? Engineers are taught to identify
and use sound metrics to assess the
outcome of any new venture: what
kinds of metrics might we use to
support the value of non-technical
education for engineers? Here, I
suggest that moving the discussion
into the general domain of problem
solving may help us answer these
questions and more.
Based on the early work of
Rhodes [17] and the more recent
contributions of Kirton [9], prob-
lem solving can be modeled as the
interaction of four components
that incorporate both technical
and non-technical factors (see Fig.
IEEE TECHNOLOGY AND SOCIETY MAGAZINE
1). Within this model, a “problem”
is simply and broadly defined as
a gap between some current state
and a desired state. To solve a par-
ticular problem, one or more prob-
lem solvers (person) engage in a
problem-solving process (alone
or in collaboration) within a given
environment, resulting in an out-
come or product.
The language of problem solving is the
language of engineers.
Kirton [9] uses four funda-
mental variables – opportunity,
motive, level, and style – to de-
scribe the problem solver and his/
her interaction with the remain-
ing components of the model. In
particular, the environment is the
prime source of opportunity (i.e.,
problems); each problem solver
chooses which opportunities to
exploit (which problems to solve)
under the direction of motive and
then attempts to resolve them by
bringing to bear the levels and
styles required. A key contribution
of Kirton lies in his clear defini-
tions of and distinction between
level and style, which – despite
their independence – are often
confounded, with style being the
most frequently misunderstood.
Level refers to “by or with how
much” a person solves problems
(e.g., his/her capacity, knowledge,
skill), while style refers to one’s
preferred “way” (i.e., manner,
strategy, approach) of problem
solving. As Kirton [9] describes
Environment
Person
Fig. 1. A general model for problem solving.
| WINTER 2007 |
generally and as I have discussed
for scientists and engineers in
particular [7], a person’s problem-
solving style is directly related to
his/her preference for structure.
In the end, successful resolu-
tion of any problem depends on
the problem solver(s) identifying
and assembling all of the resourc-
es (levels, styles) required by that
particular problem and managing
those resources well. This notion
is best explained using Kirton’s
distinction between Problem A
(the original problem a team has
come together to solve) and Prob-
lem B (the automatically inherited
problem of managing differences
among team members): success-
ful teams spend more time and
energy on Problem A than on
Problem B [9]. All this means that
engineering leaders need to man-
age diversity well – both diversity
of problems and diversity of prob-
lem solvers. The latter are diverse
in level, style, and motive, but all
must remain focused on a common
aim within a common process.
Engineering leaders need to help
everyone in the team concentrate
on Problem A and resolve any
emerging Problem B’s as mutually
undesired distractions. This intro-
duction to Kirton’s work, though
very brief indeed, reveals the new
mode of discourse I hinted at ear-
lier – one that might be used to
Process Product
31
“translate” some of the non-tech-
nical challenges engineers face
when collaborating, using lan-
guage that sounds more familiar
and consistent with the technical
aspects of their work.
Using these concepts (and corre-
sponding language) as a backdrop,
the concrete benefits engineers might
Engineers often perceive that non-
technical subjects “don’t count in the
real world.”
rightfully seek in exchange for the
effort they spend studying (say) the
humanities or social sciences might
include, among others, some or all of
the following outcomes:
n Solving more problems (i.e.,
more Problem A’s)
n Solving more difficult and
complex problems
n Solving problems more
quickly and efficiently
n Learning how to manage
Problem B’s more effectively.
The associated metrics required
to assess progress in these areas
seem clear: the number of problems
solved, their degree of complexity,
the time required for solution, the
costs involved, the level of satisfac-
tion, and so on. If we can link the
study and mastery of non-technical
subjects to these goals (and others
like them), the value of those sub-
jects may become a bit clearer to a
professional community that gen-
erally prides itself on its problem-
solving function in society.
Returning to communication,
collaboration, and ethics/social
responsibility, we can see imme-
diately the role and importance
of communication as an under-
lying factor in all of the prob-
lem-solving goals listed above.
Misunderstanding (i.e., miscom-
munication) is a common cause
of project failure – particularly at
32 | IEEE TECHNOLOGY AND SOCIETY MAGAZINE
great distances. Returning to the
schema in Fig. 1: to avoid misun-
derstanding, the problem solver
(in this case, the engineer) must
be able to communicate well in
order to perceive all the relevant
opportunities within his/her envi-
ronment, assemble and help guide
his/her team (making best use of
its problem-solving diversity) in
order to exploit those opportu-
nities, manage all the processes
required, and introduce the prod-
uct back into the environment,
where it will be used and evalu-
ated by other problem solvers,
who – in turn – will try to com-
municate their assessments back
to the original problem solver(s).
If communication breaks down in
only one of these stages, problem-
solving performance will suffer.
Collaboration, as a second ex-
ample, lies at the very heart of
complex problem solving, as we
consider the vast range of lev-
els (knowledge, skills, types of
expertise) and styles (preferred
strategies, approaches) that may
be necessary in order to solve such
problems. No one problem solver
(engineer) can single-handedly
supply the vast breadth and depth
that is so often required. From this
perspective, collaboration shifts
from a “necessary evil” that must
be tolerated (a view all too often
held by engineering students and
experienced practitioners alike)
to a fundamental necessity, which
– while admittedly a challenge
to manage – is absolutely critical
to success. The different levels,
styles, motives, and perceptions
of opportunity provided by other
problem solvers (especially those
not like us) become added tools in
the problem-solving toolbox of the
engineer, along with differential
equations, computer simulations,
prototypes, and other more famil-
iar tools of the trade.
An example of a current,
complex engineering problem in
which communication and collab-
oration play particularly impor-
tant roles is distributed software
development. In such projects,
multiple teams of software de-
signers and programmers – often
located on different continents
and in different time zones (and
cultures) – must regularly com-
municate and coordinate diverse
and detailed requirements, con-
straints, resources, outcomes, and
feedback asynchronously while
maintaining the integrity of the
final product and maximizing ef-
ficiency. In this context, Sangwan
et al. [18] have suggested that a
problem-solving framework (such
as the one described above) can
be used to help project leaders
measure, monitor, and manage
the gaps in knowledge and skill
(i.e., level) and approach (i.e.,
style) that occur (seemingly with-
out fail) between members of the
same team, between teams, and
between individuals and/or teams
and the tasks they must complete.
The results, they propose, are
improvements in shared under-
standing (which is critical to the
resolution of any shared Problem
A) and valuable insights into the
convergent and divergent behav-
ior of collaborating development
teams [18].
Finally, knowledge of ethical
principles and experience with
socially responsible profession-
al practices can also be linked
to problem-solving goals. Such
knowledge and experience repre-
sent additional (level) resources
that can be used to support the res-
olution of many (if not all) com-
plex problem-solving scenarios;
we have only to look to the events
surrounding the Challenger Space
Shuttle disaster or the case of the
Citicorp Tower [6] to realize their
| WINTER 2007
importance. In her discussion of
the similarities between ethical
problem solving and engineer-
ing design, Whitbeck [20] notes:
“People confronted with ethical
problems must do more than sim-
ply make judgments; they must
figure out what to do.” In other
words, they must develop the
skills required to actually solve
problems with ethical dimensions,
not just analyze them in principle
(or in hindsight). According to
Lynch and Kline [14], “investigat-
ing the socio-technical aspects of
engineering practice” will help
engineers build those skills by en-
abling them to recognize ethical
problems in real-world settings,
thereby preparing them “to ad-
dress issues of public health, safe-
ty, and welfare before they require
heroic intervention.”
Harris et al. [6] agree, stating:
“A significant part of responsible
engineering practice is the exercise
of preventive ethics: the practice of
sound ethical decision making to
avoid more serious problems later.”
From Engineering
Competence to
Engineering Leadership
Using problem solving as an un-
derlying framework, we can see
now how non-technical subjects
might be linked to the successful
practice of engineering in ways
that are reasonable and potential-
ly more appealing to engineers
than those used elsewhere. The
model described above also pro-
vides a comprehensive framework
for the study of problem solving
itself within scientific and other
disciplines, a matter which I have
taken up in other works [7] and
to which I will return below. Even
more importantly, perhaps, by ex-
amining engineering through the
lens of problem solving, we can
obtain valuable insights into the
strategic development of our pro-
fession – in particular, insights
into how we might move from
engineering competence to en-
IEEE TECHNOLOGY AND SOCIETY MAGAZINE
gineering excellence and beyond
– to engineering leadership.
In confirming that all humans
are problem solvers with the po-
tential to assume leadership roles
within problem-solving situations,
Kirton [9] notes that problem-solv-
ing leaders in any discipline need
to have three things:
n enough domain knowledge to
be competent,
n knowledge and understand-
ing of problem solvers, and
n knowledge and understand-
ing of the problem-solving
process,
where “domain knowledge” refers
to content from the relevant disci-
pline – here, engineering. Within
engineering education, we seem
to have the delivery of our domain
knowledge fairly well in hand (al-
though there is always room for
improvement, of course). In add-
ing communication, collaboration,
and ethics to the pedagogical and
practical menu, we are begin-
ning to cover more of the territory
Kirton recommends for develop-
ing engineering leadership, but
we must take care not to separate
these subjects (and others like
them) from the underlying frame-
work we have built to support and
link them together.
In other words, we must add
knowledge about the general do-
main of problem solving to the
menu as well (which will bring in
psychology by default), broaden-
ing the scope of each engineer’s
non-technical expertise still fur-
ther. The greatest weakness in the
problem-solving education most
engineers receive today is simul-
taneously its greatest strength:
namely, its almost exclusive fo-
cus on the technical aspects of
problems and their technical so-
lutions. Even when students are
exposed to situations designed to
give them experience in collab-
orative problem solving, they are
rarely given a theoretical frame-
| WINTER 2007 |
work for problem solving that can
help them manage professional
collaborations in the future. As
Jonassen et al. [8] describe:
“Workplace problems are ill-
structured and complex be-
cause they possess conflicting
goals, multiple solution meth-
ods, non-engineering success
standards, non-engineering
con­straints, unanticipated pro­
blems, distributed knowledge,
collaborative activity systems,
the importance of experience,
and multiple forms of prob-
lem representation.”
A few “team project” experi-
ences in school will not provide
young engineers with the founda-
tion they need to handle these far
more difficult workplace prob-
lems. The problem-solving educa-
tion that engineers need – though
it may not be fully comprehensive
– must be rigorous and based upon
sound theory and proven applica-
tion (avoiding some of the pitfalls
of the trendy creativity literature –
e.g., that nothing works except the
wildest “innovation”). Beveridge, a
Cambridge scientist, provides a fa-
miliar and useful analogy [3]:
“It is not necessary to be a
mechanic in order to drive
a car, nor trained in cogni-
tive psychology (study of the
thinking process) or philoso-
phy in order to think or rea-
son. But there are times when
the car will not go and times
when the usual thought pro-
cesses do not solve a problem
and then it is useful to have
a working knowledge of the
machinery one is using. This
knowledge need not be pro-
found; it often helps to get
the car going again if one just
knows the general principles
of how the machine functions
and some techniques that are
useful in overcoming com-
mon difficulties.”
33
 Here, the “machinery” we are
talking about is the human brain
– the most powerful and versatile
The engineering leader must
understand and be able to manage
technological change.
“engine” we have at our disposal.
Engineers who aspire to leadership
need to know at least the “general
principles” of how the brain solves
problems (i.e., the problem-solv-
ing process) – both alone and in
collaboration – in order to opti-
mize their own performance and
to facilitate the performance of
the teams of which they are a part.
The problem solver is the leader’s
prime resource, and a leader must
be well-prepared to manage the
problem-solving diversity avail-
able within his/her team in order
to make best use of it in solving
problems successfully.
The engineering leader must
know how to manage problem-
solving diversity for another rea-
son as well: s/he must understand
and be able to manage technologi-
cal change. We, as engineers, ex-
pect the users of our products to
understand enough about them to
use them safely and wisely (or so
we hope). In return, it is our re-
sponsibility as engineers to con-
sider how our creations influence
society, and we can only do so if
we understand how technologies
and societies change and how in-
dividuals respond to both [2], [19].
Engineering is based on the devel-
opment and validation of models
and theories, as well as the devel-
opment and testing of new tech-
nologies. Understanding how those
models, theories, and technolo-
gies develop is critical; how else
(returning to Fig. 1) can we im-
prove the processes and products
of engineering? It is not only the
solution of any particular problem
34 | IEEE TECHNOLOGY AND SOCIETY MAGAZINE
with which we are concerned, but
with the process of problem solv-
ing in general: how it is done, and
how it is done most effectively.
Above all, in this complex world
of large, profound problems, we
must understand how other, differ-
ent problem solvers operate, their
value in being different, and how
to manage them, differences and
all. This knowledge (and apprecia-
tion for difference) enables us to
be good followers and able lead-
ers – as Kirton points out: leaders
need to master the management
of diversity in order to master the
management of change [9].
The questions we must ask in
order to gain this kind of under-
standing are fundamentally philo-
sophical [2], [13]: What kinds of
patterns do we find in the develop-
ment of new theories, models, or
technologies? How do we know
when a new theory or technology
is needed, and how much (and in
what ways) should it differ from
what already exists? How do we
compare and choose between dif-
ferent theories, models, or technol-
ogies? These are the kinds of ques-
tions that can help us characterize
technological change; to under-
stand and facilitate such change,
engineering leaders must have a
solid, working knowledge of both
the history and the philosophy of
science and engineering as well.
Both of these subjects deal with
how science (or scientific change)
“works”: history provides an es-
sentially inductive view through
its vast collection of examples (we
learn from the past failures and
successes of ourselves and others),
while philosophy provides the the-
oretical framework in which those
examples can be placed. For ex-
cellent examples of contributions
made by engineers and scientists
to the history and/or ­philosophy of
science and engineering, one need
only look to Petroski [16], Flor-
man [4], [5], Lienhard [11], [12],
Lipton [13], and, of course, Kuhn
[10], among others.
Implications for the
Future: Toward a More
Esteemed Profession
While it may be more expensive in
terms of time and effort, the broad-
er view of what an engineer needs
to know is surely safer (by includ-
ing more, it is more conservative)
and more sensible to the well-edu-
cated person; today, it is also, in
fact, critical. As we have noted,
while engineers may not need to
know everything about other dis-
ciplines (indeed, this would not be
possible in a lifetime), the com-
plexity and difficulty of the tech-
nological problems we now face
mandate greater diversity in the
knowledge and skills with which
we must be familiar in order to
succeed; we must know more, and
about different things [7].
In considering the general man-
agement of such a vast array of di-
versity, Kirton offers some sound
advice [9]:
“As with our own bodies
(including, critically, our
brains), all diversity within
a group is potentially useful
to its members except that
which is manifestly hostile.
If the diversity is neutral,
then its presence should be
seen as yielding more reward
than cost. To worry about
diversity that is neutral or to
spurn one that has a net ad-
vantage are the prime ways
of mismanaging diversity.
Tolerance of neutral diversi-
ty is a long-term strategy of
survival; acceptance of the
cost of managing diversity is
a price of survival.”
| WINTER 2007
 In an engineering context, the
social sciences, arts, and humani-
ties (among other non-technical
disciplines) are at worst neutral
diversity; in actual fact, they offer
a net advantage more often than
not. Engineers must remember
that when the value of these sub-
jects is not immediately apparent
for a particular problem, it does
not mean they are not useful at
all; as we have discussed, without
them, we will lose problem-solv-
ing power in the face of complex
challenges. If we spurn them, it is
at our own risk.
Becoming versed in non-tech-
nical subjects promises other re-
wards as well. As Florman [5]
reports, many engineers feel that
their profession is not properly es-
teemed and that engineers are not
viewed as leaders in U.S. society,
even when they achieve social
prominence (consider President
Jimmy Carter during his term in
office). Clearly, we need to im-
prove the prestige of the engineer-
ing profession through – as Ben-
Haim remarks [2] – the “subtle
and intellectually sophisticated
interplay between science, tech-
nology, and man’s understanding
of nature and of himself.” Florman
[5] claims (and I agree) that we, as
engineers, can enhance our posi-
tion in society (i.e., achieve esteem
and higher social status as a pro-
fession) by developing and present-
ing ourselves and the profession
as willing and able to “reach out”
IEEE TECHNOLOGY AND SOCIETY MAGAZINE
to the rest of society (on society’s
terms); society, in exchange, will
be more likely to reach out to us
in return. To propel this vision of
prominence and prestige into the
future, we must convince engineer-
ing students, faculty, and practitio-
ners that non-technical subjects do
have value, they do “count” in the
grand scheme of things, they are
useful and relevant, and they will
make them better citizens through
greater effectiveness and power in
general. The key to delivering this
message more directly and more
persuasively may lie in showing
them how non-technical knowl-
edge will make them better prob-
lem solvers as well.
Author Information
The author is with the Pennsylva-
nia State University, Great Valley
School of Graduate Professional
Studies, 30 E. Swedesford Road,
Malvern, PA 19355 U.S.A. Email:
KWL3@psu.edu.
References
[1] ABET 2005-2006 Accreditation Policy
and Procedure Manual. Baltimore, MD:
ABET, Inc., 2004; www.abet.org.
[2] Y. Ben-Haim, “Why the best engineers
should study humanities,” Int. J. Mechani-
cal Engineering Education, vol. 28, pp.
195–200, 2000.
[3] W.I.B. Beveridge, Seeds of Discovery.
London, U.K.: Norton , 1980.
[4] S.C. Florman, “The whole engineer,” Tech-
nology Rev., vol. 99, no. 3, p. 67, 1996.
[5] S.C. Florman, “Non-technical studies for
engineers: The challenge of relevance,” Euro.
J. Engineering Education, vol. 22, no. 3, pp.
249–258, 1997.
| WINTER 2007 |
[6] C.E. Harris, M.S. Pritchard, and M.J.
Rabins, Engineering Ethics: Concepts &
Cases, 3rd ed.. Belmont, CA: Thomson Wad-
sworth, 2005.
[7] K.W. Jablokow, “The catalytic na-
ture of science: Implications for scien-
tific problem solving in the 21st century,”
Technology in Society, vol. 27, no. 4, pp.
531–549, 2005.
[8] D. Jonassen, J. Strobel, and C.B. Lee, “Ev-
eryday problem solving in engineering: Les-
sons for engineering educators,” J. Engineer-
ing Education, pp. 139–151, Apr. 2006.
[9] M.J. Kirton, Adaption-Innovation in the
Context of Diversity and Change. London,
U.K.: Routledge, 2003.
[10] T.S. Kuhn, The Structure of Scientific
Revolutions. Chicago, IL: Univ. of Chicago
Press, 1962.
[11] J.H. Lienhard, The Engines of Our In-
genuity: An Engineer Looks at Technology
and Culture. New York, NY: Oxford Univ.
Press, 2000.
[12] J.H. Lienhard, How Invention Begins.
New York, NY: Oxford Univ. Press, 2006.
[13] P. Lipton, “The Medawar Lecture 2004:
The truth about science,” Philosophical Trans.
Royal Society B, vol. 360, pp. 1259–1269,
2005.
[14] W.T. Lynch and R. Kline, “Engineering
practice and engineering ethics,” Science,
Technology, & Human Values, vol. 25, pp.
195–225, 2000.
[15] National Academy of Engineering, Edu-
cating the Engineer of 2020. Washington, DC:
National Academies Press, 2005.
[16] H. Petroski, “Technology and the hu-
manities,” American Scientist, vol. 93, pp.
304–307, Jul.-Aug. 2005.
[17] M. Rhodes, “An analysis of creativity,”
Phi Delta Kappan, vol. 42, pp. 305–310,
1961.
[18] R. Sangwan, K. Jablokow, M. Bass, and
D. Paulish, “Asynchronous collaboration:
Achieving shared understanding beyond the
first 100 meters,” in Proc. 2006 ASEE Ann.
Conf. & Expo., Chicago, IL, 2006.
[19] C.P. Snow, The Two Cultures and the
Scientific Revolution. Cambridge, U.K.: Cam-
bridge Univ. Press, 1959.
[20] C. Whitbeck, Ethics in Engineering
Practice and Research. Cambridge, U.K.:
Cambridge Univ. Press, 1998.
35