AcaWiki - User contributions [en]

The Socially Responsible Engineer: Assessing Student Attitudes of Roles and Responsibilities

2011-09-20T00:47:53Z

Mchua:

{{Summary
|title=The Socially Responsible Engineer: Assessing Student Attitudes of Roles and Responsibilities
|authors=Sandra A. Lathem, Maureen D. Neumann, Nancy Hayden
|url=http://jee.org/2011/July/03
|tags=engineering education, institutionalism, institutional change, social responsibility, curriculum reform, systems approach
|summary=This paper describes a four-year mixed method study on the changes in student technical knowledge and their perceptions of engineers' social responsibility resulting from curriculum reform at a state university's Civil and Environmental Engineering department.

The curricular changes included:

* developing systems courses on the intersections of transportation, the environment, and economics that replaced earlier, discipline-siloed versions of those classes
* the addition of service learning into required classes
* incorporating information technology and inquiry-based learning into required classes

The study found that while self-reported technical knowledge and perceptions on social responsibility remained constant (or even increased for females), student attitudes were negative regarding the curriculum change for the first two years, with concerns like "will this change our pass rate on the FE exam" raised (answer: it didn't). This suggests that student attitudes to curricular change may be negative regardless of the actual impact and value of that change.

It introduces and validates a Student Attitude Survey (included in an appendix) designed to measure student attitudes (no surprise here) on the roles and responsibilities of civil and environmental engineers.
|journal=Journal of Engineering Education
|pub_date=2011/07
|subject=Engineering
}}

The Socially Responsible Engineer: Assessing Student Attitudes of Roles and Responsibilities

2011-09-20T00:47:29Z

Mchua: Created page with "{{Summary |title=The Socially Responsible Engineer: Assessing Student Attitudes of Roles and Responsibilities |authors=Sandra A. Lathem, Maureen D. Neumann, Nancy Hayden |url=htt..."

{{Summary
|title=The Socially Responsible Engineer: Assessing Student Attitudes of Roles and Responsibilities
|authors=Sandra A. Lathem, Maureen D. Neumann, Nancy Hayden
|url=http://jee.org/2011/July/03
|tags=engineering education, institutionalism, institutional change, social responsibility, curriculum reform, systemes approach
|summary=This paper describes a four-year mixed method study on the changes in student technical knowledge and their perceptions of engineers' social responsibility resulting from curriculum reform at a state university's Civil and Environmental Engineering department.

The curricular changes included:

* developing systems courses on the intersections of transportation, the environment, and economics that replaced earlier, discipline-siloed versions of those classes
* the addition of service learning into required classes
* incorporating information technology and inquiry-based learning into required classes

The study found that while self-reported technical knowledge and perceptions on social responsibility remained constant (or even increased for females), student attitudes were negative regarding the curriculum change for the first two years, with concerns like "will this change our pass rate on the FE exam" raised (answer: it didn't). This suggests that student attitudes to curricular change may be negative regardless of the actual impact and value of that change.

It introduces and validates a Student Attitude Survey (included in an appendix) designed to measure student attitudes (no surprise here) on the roles and responsibilities of civil and environmental engineers.
|journal=Journal of Engineering Education
|pub_date=2011/07
|subject=Engineering
}}

Journals for Certification, Conferences for Rapid Dissemination

2011-09-19T02:58:37Z

Mchua:

{{Summary
|title=Journals for Certification, Conferences for Rapid Dissemination
|authors=Joseph Y. Halpern, David C. Parkes
|url=http://cacm.acm.org/magazines/2011/8/114942-journals-for-certification-conferences-for-rapid-dissemination/fulltext
|tags=cs, journals, academia, scholarly publishing
|summary=An opinion piece in the ACM Communications by two CS professors describing the current situation in CS publishing: unlike other academic disciplines that emphasize publishing in peer-reviewed journals, CS as a discipline emphasizes publication at conferences.

They theorize this is due to a number of factors:

* Conferences give faster review and publication turnarounds than journals (implied but not stated: CS is a rapidly moving field where this is particularly vital).
* Publicity. "The best way to get your sub-discipline to know about your results is to publish them in the leading conference for that subdiscipline."

And it is problematic for a few reasons:

* Conference papers are usually limited to be shorter than journal ones, meaning that it's harder to explain results in reproducible detail.
* Conference papers are often not reviewed as thoroughly as journal ones.
* CS as a discipline has splintered into so many subfields and their corresponding conferences that presenting at a conference doesn't actually disseminate work to everyone who should see it.

The authors go on to suggest that the CS community shift their focus to journal publication for more thoughtful certification of quality work, and give a number of things that could support such a shift.

* Use centralized web archives to store papers publicly online
* Speed up journal review cycles
* Make everyone who submits a paper "pay" to have that paper reviewed by reviewing papers themselves
* Allow multiple certifications per paper -- that is, make it ok for a paper to get reviewed and approved by two or more publications.
|journal=Communications of the ACM
|pub_date=2011/08
|subject=Computer Science
}}

Journals for Certification, Conferences for Rapid Dissemination

2011-09-19T02:58:13Z

Mchua: Created page with "{{Summary |title=Journals for Certification, Conferences for Rapid Dissemination |authors=Joseph Y. Halpern, David C. Parkes |url=http://cacm.acm.org/magazines/2011/8/114942-jour..."

From Interests To Values

2011-09-19T02:42:26Z

Mchua:

{{Summary
|title=From Interests To Values
|authors=Betsy DiSalvo, Amy Bruckman
|url=http://dl.acm.org/citation.cfm?doid=1978542.1978552
|tags=cs education, african-american, vertical integration
|summary=The paper describes Glitch, a program from Amy Bruckman's Electronic Learning Communities Lab and Betsy DiSalvo's dissertation wrok at the School of Interactive Computing at Georgia Tech. Glitch hires African-American men in high school as game testers during the school year, including an hour daily of CS classwork taught by African-American undergraduate men. The program attempts to motivate them to consider the study of CS at the college level by making the high-school pursuit of such skills both financially feasible (the young men are hired for the program and paid as testers) and socially acceptable (gaming and competing for a computer is "ok" among that social group, whereas "studying" may be less so).

Early results are promising, but the sample size is still small. "Out of the seven students who graduated from high school in 2010, six are attending college -- 5 of them in computing-related majors... Of the seven students who will be graduating in 2011, all intend to attend college -- four have declared their major as CS and the other three are considering CS as their major. Before the program started, of the 14 only one had an interest in CS and one in computer engineering as a major."

"Why did it work... Being a computer programmer was no longer a mystical quality that was out of their reach but a natural progression from what they were already doing as game testers. They communicated with developers daily, and felt that developers really listened to them... They already felt like a valuable part of the software development process, so imagining themselves as a bigger part of that process was easy."
|journal=Communications of the ACM
|pub_date=2011/08
|subject=Computer Science
}}

User:Mchua

2011-09-19T02:42:08Z

Mchua: /* My notes */

{{User
|name=Mel Chua
|location=Purdue University
}}
== About me ==

I'm a PhD student in Engineering Education at Purdue University at the time of this writing (September 2011), got my BS in Electrical and Computer Engineering from Olin College in 2007, and worked across a variety of startups, nonprofits, S&P 500 companies, research labs, and open source projects in between. More at http://blog.melchua.com.

== My notes ==

* Bovy and Vinck (2003): [[Social Complexity and the Role of the Object: Installing Household Waste Containers]]
* Koen (2003): [[Discussion of the Method: Conducting the Engineer's Approach to Problem Solving]]
* Bucciarelli (2003): [[Engineering Philosophy]]
* DiSalvo and Bruckman (2011): [[From Interests To Values]]

From Interests To Values

2011-09-19T02:41:29Z

Mchua: Created page with "{{Summary |title=From Interests To Values |authors=Betsy DiSalvo, Amy Bruckman |url=http://dl.acm.org/citation.cfm?doid=1978542.1978552 |tags=cs education, african-american |summ..."

{{Summary
|title=From Interests To Values
|authors=Betsy DiSalvo, Amy Bruckman
|url=http://dl.acm.org/citation.cfm?doid=1978542.1978552
|tags=cs education, african-american
|summary=The paper describes Glitch, a program from Amy Bruckman's Electronic Learning Communities Lab and Betsy DiSalvo's dissertation wrok at the School of Interactive Computing at Georgia Tech. Glitch hires African-American men in high school as game testers during the school year, including an hour daily of CS classwork taught by African-American undergraduate men. The program attempts to motivate them to consider the study of CS at the college level by making the high-school pursuit of such skills both financially feasible (the young men are hired for the program and paid as testers) and socially acceptable (gaming and competing for a computer is "ok" among that social group, whereas "studying" may be less so).

Early results are promising, but the sample size is still small. "Out of the seven students who graduated from high school in 2010, six are attending college -- 5 of them in computing-related majors... Of the seven students who will be graduating in 2011, all intend to attend college -- four have declared their major as CS and the other three are considering CS as their major. Before the program started, of the 14 only one had an interest in CS and one in computer engineering as a major."

"Why did it work... Being a computer programmer was no longer a mystical quality that was out of their reach but a natural progression from what they were already doing as game testers. They communicated with developers daily, and felt that developers really listened to them... They already felt like a valuable part of the software development process, so imagining themselves as a bigger part of that process was easy."
|journal=Communications of the ACM
|pub_date=2011/08
|subject=Computer Science
}}

User:Mchua

2011-09-14T18:41:34Z

Mchua: /* My notes */

Discussion of the Method: Conducting the Engineer's Approach to Problem Solving

2011-09-14T18:41:11Z

Mchua: Created page with "{{Summary |title=Discussion of the Method: Conducting the Engineer's Approach to Problem Solving |authors=Billy Vaughn Koen |url=http://www.amazon.com/Discussion-Method-Conductin..."

{{Summary
|title=Discussion of the Method: Conducting the Engineer's Approach to Problem Solving
|authors=Billy Vaughn Koen
|url=http://www.amazon.com/Discussion-Method-Conducting-Engineering-Technology/dp/B000F6Z96Y
|tags=engineering education, engineering philosophy, problem solving, design methodology
|summary=This selection is a discussion what engineering is, addressed by a discussion on the sorts of qualities and constraints make a problem an "engineering problem," and the different ways and characteristics that would make somebody say they're solving that problem with "engineering" or "the engineering way." (Implicit but not exactly stated in this reading is that engineering involves the solution of problems, and that those who solve engineering problems via engineering are engineers.)
|relevance=Quote, p 8: "Most people think of the engineer in terms of his artifacts rather than his art." This ties back to [[Cultural boundaries of science: Credibility on the Line|Gieryn]]'s concept of engineering as a black box; messy world goes in, magic happens, and ''things'' come out.

Engineers cause change.

Engineers are constrained by available resources.

Quote, p 16: "To exist is to be some engineer's notion of best."

Quote, p 25: "If you, as with all humans since the birth of humankind, desire change: if the system you want to change is complex and poorly understood; if the change you will accept must be the best available as you balance often conflicting criteria; and if it is constrained by limited resources, then you are in the presence of an engineering problem. If you cause this change using the strategy described next, then you are an engineer." This was a huge point of contention during my reading group as we argued about the boundaries of who was and wasn't an engineer -- could we say a little kid was an engineer or doing engineering (and is there a difference between the two?) Would we call the same little kid in a junior football league "a football player who is playing football"? Why or why not?
|pub_date=2003
|subject=Philosophy
}}

User:Mchua

2011-09-14T18:39:24Z

Mchua:

{{User
|name=Mel Chua
|location=Purdue University
}}
== About me ==

I'm a PhD student in Engineering Education at Purdue University at the time of this writing (September 2011), got my BS in Electrical and Computer Engineering from Olin College in 2007, and worked across a variety of startups, nonprofits, S&P 500 companies, research labs, and open source projects in between. More at http://blog.melchua.com.

== My notes ==

* Bovy and Vinck (2003): [[Social Complexity and the Role of the Object: Installing Household Waste Containers]]
* [[Discussion of the Method: Conducting the Engineer's Approach to Problem Solving]]
* Bucciarelli (2003): [[Engineering Philosophy]]

Social Complexity and the Role of the Object: Installing Household Waste Containers

2011-09-14T18:38:49Z

Mchua: Created page with "{{Summary |title=Social Complexity and the Role of the Object: Installing Household Waste Containers |authors=Michel Bovy, Dominique vinck |url=http://books.google.com/books?id=R..."

{{Summary
|title=Social Complexity and the Role of the Object: Installing Household Waste Containers
|authors=Michel Bovy, Dominique vinck
|url=http://books.google.com/books?id=R_6x1aZLIC4C&pg=PA53&lpg=PA53&dq=social+complexity+and+the+role+of+the+object&source=bl&ots=YhPmBavg-y&sig=O_zz-79MzQ9tS_iKkJp9lymYdR4&hl=en&ei=ZvRwTsbCFPPF0AGZxfGZCg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBoQ6AEwAA#v=onepage&q=social%20complexity%20and%20the%20role%20of%20the%20object&f=false
|tags=engineering education, engineering philosophy, sociotechnical
|summary=This reading used a case study of an engineering project in a complex sociotechnical context (waste removal containers in a community where tourists and visitors frequently dumped trash in inappropriate places) as a way to discuss the differences between the ways we're able to "engineer" technologies and ''things'' and the ways we're able to "engineer" (if that's even an appropriate world) the behavior of social beings such as humans.
|relevance=Clearly the two approaches must differ; we can't deal with people the same way we deal with things, but we can deal with people ''through'' the things we make -- the engineering design process is itself a dialogue and a shaper of the society and individuals who participate in it.

Or shorter still: the iterative cocreation of technological artifacts can be a mediative act in a social world.

My classmate Dana did some digging and discovered that this work was the dissertation of the authors, which makes their roles in the waste removal project described a lot more sensible; we were originally confused as they jumped back and forth between management, implementation, and "let's stand back and philosophize about this project" postings, which would be a very strange sort of role-switching to have for a "normal employee" on the project.
|journal=Everyday Engineering: An Ethnography of Design and Innovation
|pub_date=2003
|subject=Sociology
}}

User:Mchua

2011-09-14T18:36:04Z

Mchua: /* My notes */

{{User
|name=Mel Chua
|location=Purdue University
}}
== About me ==

I'm a PhD student in Engineering Education at Purdue University at the time of this writing (September 2011), got my BS in Electrical and Computer Engineering from Olin College in 2007, and worked across a variety of startups, nonprofits, S&P 500 companies, research labs, and open source projects in between. More at http://blog.melchua.com.

== My notes ==

* [[Everyday Engineering: An Ethnography of Design and Innovation]]
* [[Discussion of the Method: Conducting the Engineer's Approach to Problem Solving]]
* Bucciarelli (2003): [[Engineering Philosophy]]

Engineering Philosophy

2011-09-14T18:34:33Z

Mchua:

{{Summary
|title=Engineering Philosophy
|authors=Louis L. Bucciarelli
|url=http://www.iospress.nl/loadtop/load.php?isbn=9789040723186
|tags=engineering philosophy, engineering education
|summary=This book is one engineer's (longwinded) attempt to develop a philosophy of engineering and engineering design, examining questions like "what is design?" and "how do engineers communicate?" and "what are we doing when we 'speak' in 'engineeringese'?"
|relevance=This book is likely best consumed as a book on tape (or as if it were one); the author is an engineer who's tried to learn and bridge to the discipline of philosophy, and ends up walking in long, slow mental circles around the terrain he's trying to describe. (Deliberately, perhaps; this is certainly a "journey" rather than a "destination" book that forces engineers reading it to stay and linger in the unknown and the discomfort instead of giving a pat answer to describe what it is they do and how they think and immediately moving on.)

Quote, p 4: "Philosophy's aim is to clarify, to analyze, to probe and explore alternate ways of seeing, of speaking, and ultimately, of remaking the world."

Engineering is spoken of as a timeless thing, but exists within a chaos of very timely things.

"Engineers are pragmatic" sounds like an excuse used by engineers to dismiss things that don't fall within their mental model.

Footnote, p 8: "That's the whole point of being skilled; you don't stop... to reflect upon what you have just accomplished or where the next note on the keyboard lies. Engineers are skilled too in different ways, but they do stop and think, and rethink, and redo and rethink as they go about designing." (This reminded me of the Dreyfuss model of skill acquisition.)

Since most engineering projects are multidisciplinary, we run into the "tower of babel" problem -- when there are so many different frameworks and representations and tools and languages, how do we move forward? One approach is breaking the problem into independent subtasks, but that isn't a perfect solution. Oftentimes we model things as independent but they're actually not. Also, if you keep breaking subtasks into subtasks into subtasks, you can go down this reducto ad absurdum path of siloization. (But that's ''much'' easier than talking with each other, because that's ''messy'' and ''hard.'')

Bucciarelli brings up the idea of failure as a social construct. This reminds me of when I was trained as a software QA engineer; one conversation that came up was the role of emotions in bug-finding. A bug is something "hard and technical," yet how do you know to identify something as a bug? Oftentimes, it's emotional -- this is wrong, this is frustrating, this makes me sad or tired or angry. Without those flags, it's not a bug, because a bug is something ''someone'' thinks is a problem.

Bucciarelli makes a point about decoupling information from knowledge that I didn't have much time to explore, but might make interesting reading later on.

Engineering is a language, in a way; drawing engineering diagrams, writing the sort of texts engineers write, and laying down the sort of math engineers use to describe the world is a sort of encoding that makes that dialogue less accessible to people who don't know it.

Bucciarelli makes the point that engineering knowledge is geared towards the future, not the past. I'm not sure what to make of this quite yet.
|pub_date=2003
|subject=Philosophy
}}

Engineering Philosophy

2011-09-14T18:34:08Z

Mchua: Created page with "{{Summary |title=Engineering Philosophy |authors=Louis L. Bucciarelli |url=http://www.iospress.nl/loadtop/load.php?isbn=9789040723186 |tags=engineering philosophy, engineering ed..."

User:Mchua

2011-09-14T18:30:29Z

Mchua: Created page with "{{User |name=Mel Chua |location=Purdue University }} == About me == I'm a PhD student in Engineering Education at Purdue University at the time of this writing (September 2011),..."

{{User
|name=Mel Chua
|location=Purdue University
}}
== About me ==

I'm a PhD student in Engineering Education at Purdue University at the time of this writing (September 2011), got my BS in Electrical and Computer Engineering from Olin College in 2007, and worked across a variety of startups, nonprofits, S&P 500 companies, research labs, and open source projects in between. More at http://blog.melchua.com.

== My notes ==

* [[Everyday Engineering: An Ethnography of Design and Innovation]]
* [[Discussion of the Method: Conducting the Engineer's Approach to Problem Solving]]
* [[Engineering Philosophy]]