Koen's idea about engineering as a way of thinking seems to generalize engineering so much that it essentially can be found and applied everywhere in our everyday lives. It causes me to dig into the essentially difference between an engineering way of thinking and other ways, for example, scientific way of thinking.
What makes an engineering way of thinking different from a scientific one? I think features like innovativeness and feasibility mark the engineering way of thinking. An engineer tries to create some type of new things or modify things based on their existent formats. On the other hand, features like curiosity and imaginativeness symbolize the scientific way of thinking. A scientist strives to discover embedded rules or principles. To me, "to create" and "to discover" make Engineering and Science different from each other.
Showing posts with label Koen. Show all posts
Showing posts with label Koen. Show all posts
Wednesday, October 7, 2009
Saturday, October 3, 2009
What is engineering? What is not engineering?
I agree with Noah that engineering should be defined more uniquely. When I need to strictly define the scope of X, I expect the definition to be so clear and unambiguous that everything in the world should either inside or outside X. No exception. So far, I don't think I can define engineering in this way.
"Is drawing engineering?" As raised by Sensen in class, I was also confused by such a question. But according to Koen's argument, engineering method is the strategy for causing the best change in a poorly understood situation within the available resources. Light changes. Fixed-size canvas. Artists try their best. The model may not pose the same all the time. Drawing shows all characteristics of engineering: change, resource, best and uncertainty. From my perspective, however, these four criteria serve as evidences rather than determinants to judge whether Y belongs to engineering. Koen may agree with me because he described these four words as characteristics of an engineering problem. Having Taken Bucciarelli's argument about social components of engineering, I am still not able to define engineering precisely. Do we really have such a definition?
Another question confusing me is that in Jonassen's paper, I lost connections between 12 themes and 6 implications for engineering educators. How can those 12 be matched to the 6 improvements?
"Is drawing engineering?" As raised by Sensen in class, I was also confused by such a question. But according to Koen's argument, engineering method is the strategy for causing the best change in a poorly understood situation within the available resources. Light changes. Fixed-size canvas. Artists try their best. The model may not pose the same all the time. Drawing shows all characteristics of engineering: change, resource, best and uncertainty. From my perspective, however, these four criteria serve as evidences rather than determinants to judge whether Y belongs to engineering. Koen may agree with me because he described these four words as characteristics of an engineering problem. Having Taken Bucciarelli's argument about social components of engineering, I am still not able to define engineering precisely. Do we really have such a definition?
Another question confusing me is that in Jonassen's paper, I lost connections between 12 themes and 6 implications for engineering educators. How can those 12 be matched to the 6 improvements?
Jonassen, Koen, and Bucciarelli
[This post belong to last week's reading: Jonassen et al., Koen, and Bucciarelli)
Jonassen, Strobel, and Lee
Ill-structured problems are those found in engineering workplace, as contrasted with the well-defined problems that engineering students find in classrooms. Seven main categories were defined from the qualitative analysis of the interviews with active engineers. Each category describes common problems, recommendations, or typical daily experiences engineers encounter in the workplace.
It's the first time I stumble into the concept of "ill-structured problems", so it is implied that classroom problems are "healthy-structured problems". As I would say, classroom problems are "organically-grown, gluten-free, and low-fat" with minor "bugs", compared to workplace problems.
If future engineers need to develop good team relationship skills, then, we should encourage them to take more practical psychology-type of seminars and workshops; in addition to encouraging them to be less isolated and more involved in team-work. One thing I used to hear of my classmates (including myself) was: "I prefer to work alone. Team work is so complex". Engineering schools should actively keep addressing that students' difficulty, to make the transition to workplace the smoothest possible.
The three articles stated that engineering problems are also composed of traditional "non-engineering factors"; such as empathy, motivation, good relationships, effective communication, collaboration, compassion, value of diversity, etc. (I added other items to the list). I remember that in the Software Engineering classes, professors barely taught about the "non-engineering issues". They focused in the traditional issues of complying to government agencies, laws and policies, privacy issues, how to organize the project based in a software development life-cycle model, keeping track of the budget, project phases, etc... As if engineers had only a "binary machine" in their minds, without a human component.
[...I'll cut here...]
///////////////////////////////////////////////////////
Jonassen, Strobel, and Lee
Ill-structured problems are those found in engineering workplace, as contrasted with the well-defined problems that engineering students find in classrooms. Seven main categories were defined from the qualitative analysis of the interviews with active engineers. Each category describes common problems, recommendations, or typical daily experiences engineers encounter in the workplace.
It's the first time I stumble into the concept of "ill-structured problems", so it is implied that classroom problems are "healthy-structured problems". As I would say, classroom problems are "organically-grown, gluten-free, and low-fat" with minor "bugs", compared to workplace problems.
If future engineers need to develop good team relationship skills, then, we should encourage them to take more practical psychology-type of seminars and workshops; in addition to encouraging them to be less isolated and more involved in team-work. One thing I used to hear of my classmates (including myself) was: "I prefer to work alone. Team work is so complex". Engineering schools should actively keep addressing that students' difficulty, to make the transition to workplace the smoothest possible.
The three articles stated that engineering problems are also composed of traditional "non-engineering factors"; such as empathy, motivation, good relationships, effective communication, collaboration, compassion, value of diversity, etc. (I added other items to the list). I remember that in the Software Engineering classes, professors barely taught about the "non-engineering issues". They focused in the traditional issues of complying to government agencies, laws and policies, privacy issues, how to organize the project based in a software development life-cycle model, keeping track of the budget, project phases, etc... As if engineers had only a "binary machine" in their minds, without a human component.
[...I'll cut here...]
//--//--//--//--//--//--//--//--//
Koen
I agree with Koen in his statement that "engineers cause change" (p.11) and that it's "not just any change, but the best change (...)" (p.10). However there are some things I would like to bring to surface here. I found somewhat disgusting the author's example of "the prince who wants the divorce of his daughter" as part of the examples of what is "correctly called an engineer because (...). Each wants to change, to modify, or to convert the world represented by one state into a world represented by a different one" (p. 10). Is this "engineer" taking in count the freedom and decision of the other human being? Just because you are changing from state A to state B, and you are taking in count the "best change within the available resources" (p. 10), that doesn't make you an engineer. You must have an ethical and benevolent component for humanity (or the other fellow being).
If we choose a real example instead of the prince example, Adolf Hitler wanted to change a whole society for what he thought it was the "best", following a certain race-hate theory; but we ought not consider that to be an "engineering act", because to be an engineer is not to be a creator of instability, malady, unfavorable causes to humanity (or to another individual).
[.. I'll cut here because if I keep going, I'll end-up writing more than what it's needed for this post...]
The other concept discussed by Koen was the idea of "the best", that is currently linked with the idea of what is optimum, within the engineering-mathematical level. In engineering, the optimum level is defined by calculus and mathematical formulas; however, for example, a computer with less optimization, defined in one society, may be defined as "optimum" in a society without the resources to acquire the "most advanced" technology (here I am sticking this to my context of Computer Eng.).
Bucciarelli
Of Bucciarelli's article, I wish to bring his emphasis in the importance to know the distinction between engineering and science. Both terms are used interchangeably. Scientists, as the author stated, work within a small, ordered, and well-defined context. The variables that an engineering problem have, come from different areas, away from the traditional perimeters of the technical-mathematics realm.
I did also like his explanation of failure as a "social construct" (p. 25). For an event to be labeled as a 'failure', the "beliefs, judgments, and claims of persons concerned with the event (...)" (p.25) construct it as such.
I agree with Koen in his statement that "engineers cause change" (p.11) and that it's "not just any change, but the best change (...)" (p.10). However there are some things I would like to bring to surface here. I found somewhat disgusting the author's example of "the prince who wants the divorce of his daughter" as part of the examples of what is "correctly called an engineer because (...). Each wants to change, to modify, or to convert the world represented by one state into a world represented by a different one" (p. 10). Is this "engineer" taking in count the freedom and decision of the other human being? Just because you are changing from state A to state B, and you are taking in count the "best change within the available resources" (p. 10), that doesn't make you an engineer. You must have an ethical and benevolent component for humanity (or the other fellow being).
If we choose a real example instead of the prince example, Adolf Hitler wanted to change a whole society for what he thought it was the "best", following a certain race-hate theory; but we ought not consider that to be an "engineering act", because to be an engineer is not to be a creator of instability, malady, unfavorable causes to humanity (or to another individual).
[.. I'll cut here because if I keep going, I'll end-up writing more than what it's needed for this post...]
The other concept discussed by Koen was the idea of "the best", that is currently linked with the idea of what is optimum, within the engineering-mathematical level. In engineering, the optimum level is defined by calculus and mathematical formulas; however, for example, a computer with less optimization, defined in one society, may be defined as "optimum" in a society without the resources to acquire the "most advanced" technology (here I am sticking this to my context of Computer Eng.).
//--//--//--//--//--//--//--//--//
Bucciarelli
Of Bucciarelli's article, I wish to bring his emphasis in the importance to know the distinction between engineering and science. Both terms are used interchangeably. Scientists, as the author stated, work within a small, ordered, and well-defined context. The variables that an engineering problem have, come from different areas, away from the traditional perimeters of the technical-mathematics realm.
I did also like his explanation of failure as a "social construct" (p. 25). For an event to be labeled as a 'failure', the "beliefs, judgments, and claims of persons concerned with the event (...)" (p.25) construct it as such.
Subscribe to:
Posts (Atom)
Posts
