Course Assessment Report
College of Engineering, The University of Iowa
(Revised January 2012)
Course # and Name: 059:006 Engineering Problem Solving II
Semester and Instructor: Fall 2011, Terry Braun, Justin Garvin
Coordinator: Terry Braun, BME Department
Student Head Count: 192
Teaching Assistants Head Count and FTE: 8 (2 FTE)
Catalog Description: Engineering problem solving using computers; introduction to digital
computations, problem formulation using a procedural high-level language; structured, top-down
program design methodology; debugging and testing; introduction to use of software libraries;
examples from numerical analysis and contemporary applications in engineering. Co-requisite:
22M:031.
I. Course Goals and Program Outcomes
Indicate the Program Outcomes associated with each Course Learning Goal along with the extent
(moderate or substantial) of these associations
Course Learning Goal
1. Students will have a thorough understanding of the for, while and do-while
looping structures using the C programming language.
2. Students will have a thorough understanding of logical operators (AND, OR) and
selection statements using the C programming language.
3. Students will understand how to design, implement and test an algorithm to solve
an engineering problem using the C programming language.
4. Students will understand how to use functions to divide an algorithm into
component pieces using the C programming language.
5. Students will be able to demonstrate goals 1-5 using MATLAB.
Program Outcome
a(●), e(●), k(●)
a(●), e(●), k(●)
a(●), e(●), k(●)
a(●), e(●), k(●)
a(●), e(●), k(●)
Notes: ○ denotes moderate contribution to the outcome ● denotes substantial contribution to the outcome
II. Program Outcomes (provided for reference).
New graduates from the College of Engineering Undergraduate Programs will have:
(a) an ability to apply knowledge of mathematics, science, and engineering
(b) an ability to design and conduct experiments, as well as to analyze and interpret data
(c) an ability to design a system, component, or process to meet desired needs within realistic constraints such as economic,
environmental, social, political, ethical, health and safety, manufacturability, and sustainability
(d) an ability to function on multi-disciplinary teams
(e) an ability to identify, formulate, and solve engineering problems
(f) an understanding of professional and ethical responsibility
(g) an ability to communicate effectively
(h) the broad education necessary to understand the impact of engineering solutions in a global, economic, environmental, and
societal context
(i) a recognition of the need for, and an ability to engage in life-long learning
(j) a knowledge of contemporary issues
(k) an ability to use the techniques, skills, and modern engineering tools necessary for engineering practice.
III. Assessment
Part A. Log of Recent Improvements, Recommendations and Comments. Append a brief, dated,
summary of improvements and recommendations made during the current offering along with
motivations and significant comments. If the course is meeting its objectives and no comments are
needed, say this. Six year and older entries may be deleted.
SUMMARY OF PRIOR REMEDIATION ACTIONS: (and their estimated effect)
In 2006, the staff felt that the discussions sections should be held in classrooms with computers. In 2007, the
discussion sections were rearranged so that every discussion section occurred in a computer lab.
In 2007 the staff addressed students’ complaints that the homework was taking too much time by carefully
reviewing each homework assignment to ensure that the problem were not too difficult or time consuming. In
addition, practice exams were provided online so that the students could drill themselves on the relevant
concepts to ensure that they were properly prepared for the exam. This year students did not complain about the
amount of time consumed in solving homework problems.
In 2007 we also discussed developing an online tool so that students could assess their basic skills before
attempting the homework problem. We developed such a tool, then abandoned it because pilot testing suggested
that it did not significantly improve the student experience, primarily because the tool was too complex.
In 2007 we discussed moving all discussion sections to a classroom in which each student will have their own
laptop. This was achieved and the discussion sections went quite well and the students enjoyed the programming
experience.
In 2007 we changed the syllabus to eliminate the concentration on pointers and structures in order to increase
the course’s emphasis on design and the study of MATLAB. Student comments and the experience of the
professors suggests that this approach leaves holes in the exposition. We plan to modify the course substantially
next year and continue to avoid pointers, in the hope that the revisions may satisfactorily cover the holes in the
exposition.
In 2008 we substantially changed the structure of the course by eliminating lectures, dividing the course into six
sections and holding these sections in the laptop classroom in 2, 1:15-length sections each week. In addition,
the course learning goals recommended in the previous Course Assessment Report were adopted.
In 2008, we recommended that the course goals be changed to the following.
Students will have a thorough understanding of logical operators (AND, OR) and selection statements
using the C programming language.
Students will understand how to design, implement and test an algorithm to solve an engineering
problem using the C programming language.
Students will understand how to use functions to divide an algorithm into component pieces using the C
programming language.
Students will be able to demonstrate goals 1-5 using MATLAB.
The following recommendations are made (Spring 2010):
1. There is urgent need of a C development environment that student can use outside of class staring from
the beginning of the semester. Eclipse would be a nice choice if a C compiler were available for
Windows.
2. The current recommendation for lecture structure is: 20 minutes of lecture followed by 50 minutes of
in-class programming. However, especially earlier in the semester (first 2-5 lectures), instructors may
find that they need to spend more time lecturing to bring students up to speed. This is only a suggestion,
as other lecture styles may work too, such as demonstrating functionality of C, have the students try it,
then repeat.
3. A clear, and concise document on a cheating policy should be written (and tailored by each year's
instructors).
4. Keep the reading quizzes and in-class programming problems. Discard the "programming quiz."
5. The current class used 5 take-home programming assignments. Based on this, it is recommended that at
least 7 assignments are needed (5 C, and 2 Matlab).
6. Material needs to be developed and added (at least 1 lecture) dedicated to the topic of systematic
strategies for debugging (divide and conquer, profiling, debuggers, etc.)
7. Managing all of the quizzes and assignments on the Icon website can be problematic. The original
instance simply numbered quizzes (Quiz 1, Quiz 2, … etc.). This has the problem of making it difficult
to know what day each quiz occurred without inspecting timestamps (which is possible, but requires
actually looking at the quiz). It has been proposed to list quizzes by date (Quiz 1 – 01/25/2010, … etc.).
However, this has the flaw that if a quiz is delayed, then all subsequent list dates have to change.
Currently there is not a good solution.
8. Matlab – the book is fine. Recommend only covering chapters 1-6. Chapters 2 and 5 probably need
two lectures each to cover the material. It is suggested that developing a mechanism to have the
students type in the examples before class would be beneficial.
9. Reading quizzes – the spacing of days and topics needs to be adjusted. For example, covering 50 pages
from Tuesday to Thursday is not optimal. Conversely, covering 2 pages from Thursday to Tuesday is
bad pacing as well.
10. "Clickers" may increase student engagement and participation. (Maybe SWD could develop a software
clicker as part of a project, so students could use the laptop as a clicker, as opposed to introducing more
complexity to the course through another device.)
During the Fall of 2010 (note, this was the first offering of this course for Fall), the following changes were
made.
1) “As per the suggestion from Spring 2010, reading quizzes” were utilized and “programming
quizzes” were not used. Reading quizzes had questions presented in random order.
2) A smaller number of PowerPoint slides (less than 10 slides) were used during class to convey
material.
3) Fewer MatLab chapters were covered (2-5).
4) 6 take-home programming assignments were assigned. It is recommended to number these 1
through 6 (instead of 0 through 5).
5) We recommend that stricter cheating detection and enforcement policies be used.
Spring, 2011, the following changes were made:
1. A stricter cheating policy was adopted. In the past, if a student got caught cheating on one
assignment, that student would receive a zero for that particular assignment. The new policy was
designed so that if a student got caught cheating on an assignment, the student would receive a zero
for the entire homework section (roughly 30%) and a letter would be written to be put in the
student’s permanent file in the Dean’s office.
2. CodeBlocks development environment was used both in class and for home development in a
portion of the sections. Other sections used Gedit/gcc. Gedit/gcc has the advantage that it
emphasizes the separation between compiler and development/editing. It also offers more exposure
a Unix-like environment – which is also used in later courses. CodeBlocks is more portable to
Windows (which is more widely used by students).
In Spring 2011, the following changes are suggested:
1. A pre-course and post-course exam could be used to assess Course Learning Goals.
2. In the past, letter grades have not been assigned to mid-term exams because of the size of the
course, and synchronization across multiple instructors and sections makes this onerous. Future
instructors may consider assigning midterm exams to facilitate collection of data on “Course
Learning Goals.”
3. Adoption of clickers could be useful.
Invariably, the following exchanges will occur between students and instructors/TAs. Typically, it increases
with frequency in the later and more difficult assignments. It can be very demoralizing for the instructors and
TAs. Instructors and TAs have described this as “the grind” and that it “wears you out.” These exchanges are:
1. A few hours before an assignment is due, there will be a rash of questions (either in person or by e-mail)
that demonstrates that the students have waited until the last minute to work on the assignment – and
thus has no real hope of completing it. On the extremes, an instructor may respond with, “Well, clearly
you waited until the last minute, it is too late to help you.” This seems to be particularly mean and not
instructive. On the other end of the spectrum, the instructor could spend several hours trying to bring
the student up to speed while being careful not to divulge too much information so that the student ends
up with a plagiarized solution. This is a huge burden on the instructor and would take time away from
assisting other students. It may be useful if there was some mechanism for a student to demonstrate
how much time they have already spent on the problem. One way to do this is to ask for pseudocode or
a flow diagram.
2. Another similar question is when a student says, (usually 5 hours before an assignment is due) “I am
completely lost, and have no idea where to begin.” Generally, this most likely means the student did not
start on the assignment soon enough to spend enough time to find a reasonable solution. One strategy to
mitigate against this would be to talk about it early and often in the course. Explain how it is really not
a reasonable question, discuss how to not end up in this situation – and that it is just an admission of not
starting early enough.
3. Never have an assignment due late at night – this appears to exacerbate the situation. 5:00 PM at the
latest.
Fall 2011:
During the Fall of 2011, the primary change that was implement was the use “clickers” during class. Professor
Braun used clickers with in-class questions and kept track of the number of questions answered correctly (only
as an exercise for proof of concept). This proved to be modestly difficult as the “clicker” software only provides
a clicker ID and the number of correct responses. Clicker IDs had to be cross-referenced with student IDs to
assign grades. Professor Garvin used the “clickers” on for presence/absence. Professor Braun scored questions
in this manor as well.
Perhaps the most difficult aspect is that slides (with questions) have already been prepared for the course. So
each instructor would need to develop novel questions/slides for each lecture. This represented a significant
amount of additional work. Professor Braun would probably not use clickers in the future.
Clickers are difficult. The questions are currently at the beginning of slides. We typically made slides available
at 8:00 AM (one ICON site, all sections). That means the questions and answers are exposed. So the instructor
can have a different set of slides with different questions -- which is much more work. Alternatively, there
could be a different set of slides with questions (available after all sections are over with), and lecture slides,
available at the beginning of the day.
SUGGESTED CHANGES (from 2011):
Teach a systematic strategy for debugging programs.
When starting functions, first introduce functions alone (no parameters) and the shifting of program control flow
to another part of the program. Then add parameters in a subsequent lecture. A lecture would need to be added
(and one subtracted from somewhere).
The course should spend 1 day on Linux.
Need an assignment on style guide. Should do an example on style guide in class.
No compile, no points. HW submissions -- if it doesn't compile, students receive 0. It would simplify grading.
Remind TA's -- put in 0 for grades, don't leave something blank.
ADDITIONAL IDEAS:
Additional Ideas that were discussed, but are not necessary suggested at this time:
One idea we came up with was to cut the number of in-class assignments by half (call them weekly
assignments). There would be an assignment due every week. We could keep (or get rid of) the 2-week
assignments.
Essentially, Tuesday would be lecture day. It would be used to a) introduce the new material (20 mins), b)
discuss/go over the previous weeks in-class assignment or HW. Show examples of bad ones -- and how to fix,
and good ones. Cover the common mistakes. (20 mins) c) introduce the next in-class assignment (remaining
time).
The Thursday lecture would be primarily lab/coding day. Could take a few minutes to review/introduce
material. Then the weekly assignment would be due Friday, 5:00 PM. TA's would use the Tuesday class time
to grade the submissions from Friday. This way more time is spent on going over the problems in class.
RECOMMENDED CHANGES TO COURSE LEARNING GOALS:
None.
Part B. Quantitative Assessment Results. Enter in the table below an assessment of the percentage
of passing students achieving mastery (B+ to A+ level achievement), competency (C- to B level
achievement) or exposure (D- to D+ level achievement) for each course learning goal.
To make room for the rightmost “new” entry, delete the leftmost “old” entry.
SP
2010
Course Learning Goal And
Assessment Basis
Fall
2010
SP
2011
Fall
2011
54/42/4
195/129/20
113/61/11
1. Students will have a thorough
understanding of the for, while and do-while
looping structures using the C programming
language.
2. Students will have a thorough
understanding of logical operators (AND, OR)
and selection statements using the C
programming language.
3. Students will understand how to design,
implement and test an algorithm to solve an
engineering problem using the C
programming language.
4. Students will understand how to use
functions to divide an algorithm into
component pieces using the C programming
language.
5. Students will be able to demonstrate goals
1-5 using MATLAB.
Assessment:
-- in-class programming assignments
M/C/E
-- homework assignments
M/C/E
-- reading quizzes
M/C/E
-- exams
M/C/E
-- overall
M/C/E
Part C. Please attach a current syllabus.
59:006 Engineering Problem Solving II, Fall 2011
Course Policies and Procedures
Instructors:
Section 1 and 2:
Instructor: Justin Garvin (justin-garvin@uiowa.edu)
Class Room: 2217 SC
Time: 8:00am-9:15am (section 1), 11:00am-12:15pm (section2) on Tues/Thurs
Office hours: 9:30am-10:45am Tuesday/Thursday in RM 1139 SC
Section 3:
Instructor: Terry Braun (terry-braun@uiowa.edu)
Class Room: 2217 SC
Time: 3:30pm-4:45pm (section 3) on Mon/Wed
Course Description:
An introduction to programming using the C programming language and MATLAB. Students learn
how to plan, execute, diagnose failures, and iterate through a logical design. The C language
programming introduces low-level concepts of data types, logic flow, and compiling programs, while
the MATLAB portion emphasizes interactive manipulation of complex data to solve engineering
problems.
Learning Objectives:
1. Students will have a thorough understanding of the for, while and do-while looping structures using
the C programming language.
2. Students will have a thorough understanding of logical operators (AND, OR) and selection
statements using the C programming language.
3. Students will understand how to design, implement and test an algorithm to solve an engineering
problem using the C programming language.
4. Students will understand how to use functions to divide an algorithm into component pieces using
the C programming language.
5. Students will be able to demonstrate goals 1-4 using MATLAB.
Background:
The course will meet in a computer lab. Each day students will 1) complete a reading assignment, 2)
take a reading assignment quiz (due 8am the day of class), and 3) write a program in-class.
The class will begin with a discussion led by the professor, followed by an in-class programming
exercise (TAs are available during class to provide help on the in-class assignment). There will also be
roughly 6 outside of class homework assignments. During the summer, the schedule is compressed so
the class meets four times a week rather than twice a week.
Textbooks:
This course will use two textbooks: C How to Program, by Deitel and Deitel, 6th Edition, Prentice
Hall Publishers, ISBN: 978-0-13-612356-9; and an Introduction to Matlab 7 by Etter ISBN: 0-131474792-8.
Clickers:
We will be using "clickers" in class. More information will be provided in class.
Getting Help:
The in-class assignments are designed to create opportunities to ask the professor and TA's your
programming questions. The at home assignments are designed to be completed by
yourself. WORKING TOGETHER ON HOMEWORK IS CONSIDERED CHEATING and will not be
tolerated. Think of these outside of class homeworks as take-home quizzes -- you must work alone!
If you need extra help, please visit the TA or professor during office hours or send an email.
Computer Accounts:
You will need an account on the college's Computer Support Systems (CSS) infrastructure. If you do
not already have an account, see http://www.icaen.uiowa.edu/for instructions or go to the CSS office
on 1st floor (1253 SC).
Assignments:
You will normally have 1 reading assignment and one on-line reading quiz due every class day.
Approximately every other week (this may vary depending on difficulty) you will also have one
homework assignment. Homework assignments are to be worked onindividually, unless explicitly
stated otherwise. While you may discuss the problem specification with other students, the work you
turn in for grading must be your own.
Unless otherwise stated, all homework should be turned in to ICON by the time specified on ICON.
If you complete your in-class assignment early, you are encouraged to help other students, but you
should try to help them learn, not do their work for them. Don't expect to hurry through your work and
leave class early.
In addition, we are going to drop two of your lowest scores for your in-class assignments and two of
your lowest reading quiz scores.
Exams:
There will be two (2) exams and a final exam.
Midterm exams are in
MH AUD have been reserved for the "059:006:001-006 Midterm Exams" from 8:45-10:15pm on:
Thursday, Sept 29, 2011
Tuesday, Nov 8, 2011
Makeup Exams:
For those having verified conflicts with the exam schedule, makeup exams will be arranged on an
individual basis. In order to arrange a makeup, you must contact your instructor or TA by email at
least one week prior to the scheduled test date. Serious illness, of course, is an exception to this
policy. All cases of sudden illness must be verified with a Doctor's note through the Dean's office to
arrange an "after the fact" makeup exam. Approval of verified conflicts will be at the discretion of the
instructor.
Retrieval of Graded Materials:
All exams will be individually returned in your class. Please allow a minimum of one week for grading
of exams and homework assignments.
Final Course Grading:
The breakdown of the parts that contribute to the final grade are as follows:
Homework (outside of class)
Reading quizzes
In-class programming submissions
Clicker
30%
15%
18%
2%
Midterm 1
10%
Midterm 2
10%
Final
15%
Incompletes:
A grade of "I" will be given only for cases in which there are documented circumstances beyond the
student's control; it is not a substitute for "F".
Academic Honesty (Cheating):
See the full statement on cheating under the Content tab. To summarize the policy:
Cheating is a very serious academic offense and is grounds for SERIOUS punishment in this course. If
caught cheating once, you will RECEIVE A ZERO FOR ALL ASSIGNMENTS, which amounts to
30% of your grade. Also note that if two assignments are similar enough to represent the same piece
of work, BOTH PARTICIPANTS RECEIVE THE PUNISHMENT. We will not distinguish between
the original and the copy.
Briefly, cheating in this class means working together. Do not copy from anybody, do not take
anyone's code and try to change it in order to "make it your own". Do not even talk with one another
about the homework other than the problem specifications. You will get caught! We have a program
that runs through all of the assignments once they are turned in and checks for similarities. If the
similarities are too coincidental, all parties will receive a zero -- both the copier and the copyprovider.
DO NOT ATTEMPT to fool the system and cheat, I guarantee you will get caught as it as happened
many times in the past. If you are having problems with the assignment, see your instructor or TA.
Remote Access:
Lots of information is available on this ICON site. Look around for it under the content tab/link.
Persons With Disabilities:
We would like to hear from anyone who has a disability which may require some modification of
seating, testing or other class requirements so that appropriate arrangements may be made. Please see
the professor or teaching assistant after class or during office hours.
Privacy:
Grades and other class data will be posted on ICON. Your grade information will be only available to
you, although statistical information about all the students' grades will be available to all students. If
the grades are not yet posted on ICON, you can assume that they are not yet available.
Class Participation:
Please feel free to ask questions when you don't understand something that is presented in the lecture.
Further, more material will be covered in lecture than is simply "in the book." You are responsible for
all reading and all material presented in lecture.
Reading Assignments:
Take them seriously and always attempt to complete reading before class each day. Don't forget to do
the reading quizzes each day.
Recommendations for Success
Don't get behind.
Do master material. Try to work out examples from the book, even if we didn't get to cover them in
class.
Do the reading diligently.
Do outline notes and reading. Review the text, your homeworks, and lecture notes to prepare for
exams.
Don't get behind!
Don't simply cram for exams -- keep up all the way along.
Don't just study problems. The concepts in this course can be tested through asking you to solve
original problems on exams. Be prepared to think.
Do take advantage of office hours to get extra help. Communicate with your instructor or discussion
section leader if you are getting into trouble. Don't wait until the last minute to do this.
Do keep backup copies of your computer files.
Don't wait until the last minute to submit your assignment electronically.
Did we forget to say, don't get behind?
Finally, a note of warning.
This is a demanding, difficult course -- if you work hard. If you do not work hard, or get behind, it is
not hard -- it is impossible. Do not get behind. Start work on assignments as soon as they are given. Do
not underestimate the demanding nature of this course. Expect the system to crash the night before
your program is due. Aim to have a homework assignment done the day before it is due. This practice
will be important when you get a job. After you graduate, your boss will not be impressed by claims
that you lost your files because the system went down. He or she will simply expect you to deal with it,
or better yet, to have planned ahead to overcome unforeseen problems.
59:006 – Engineering Problem Solving-II
Cheating Policy
Fall 2011
The Policy: In a word – Don’t.
The Policy: In a few more words – Cheating will not be tolerated. A single detected incident will almost certainly result in
your failing the course. And cheating is very unlikely to go undetected. – This is a fair warning. This policy has changed for
this course from semesters prior to Spring 2011, but this policy is the standard policy for the College of Engineering.
If this isn’t clear, read on. On second thought, read on even if you think you understand …
Cheating is defined as any attempt to claim credit for work which is not entirely your own. This is a very absolute and strict
policy. It includes discussing the approach that you or your classmates or anyone else outside this class might take to the
same problem. It includes using any part of a solution that someone other than you created in your solution. If you still need
more clarification, read on…
DO NOT COPY
DO NOT COPY it. Do not e-mail it. Do not transfer it on a jump drive and give (or take) it. Do not print off someone
else's solution, and look at it while you type it in for yourself. That is copying. You need to compose your own lines of
code, your own variables, your own logic, your own comments, and type each and every character yourself. Also, protect
your work. There have been instances of people “dumpster diving” to acquire printed copies, stolen jump drives and room
mates accessing a computer and stealing files. There may be a few instances where an instructor or TA will give you part of
a program or "stub" to use as a starting point, but those cases will be rare, if at all. Think of Homework as "take-home
quizzes or exams." There will be many opportunities to work in teams in other classes. But not in this one!
Unsuccessful work avoidance techniques previously tried in this course (aka cheating)
Here is the extent to which some students in the past have gone to avoid performing work for this class.
One industrious student posted an assignment to a "programmer for hire" web page, and hired someone to
write a solution for them. The solution submitted was clearly not the student's work as it used very advanced
topics that were not even covered at that point in the course (e.g., pointers and data structures). Upon interviewing
the student, it was clear that this was not the student's work. This student received a zero and eventually failed the
course. Not surprising, the student was unable to do well on the exams since the student did not perform any of
the work on homeworks.
Two not-so-industrious students once submitted "exactly" the same program. By "exactly," I mean that
not even the name at the top of the program was changed.
Fred and Barney received a zero on all homework assignments for submitting homeworks that were too
similar. Fred was vehement about his innocence, he demanded that we meet so that he could describe his program
and display that he understood how the program worked. I watched as he logged into his account. He went to his
homework directory (i.e. "folder"). In his directory were two files: HW4.c, and hw-4.c Fred walked me through
HW4.c and gave a very convincing argument about his knowledge of the problem and a description of his
solution. When he was done, I asked if I could examine his program. I immediately opened the file "hw-4.c" and
found a copy of "Barney's" submission. Fred did not deny the accusation after that.
But won't my solution look like everyone else's?
The reality is that we utilize very sophisticated software tools for comparing student programs to detect high-similarity and
collaboration. The level of similarity flagged by these tools is too high to be coincidental. We can and do compare every
submission against every other submission in every other section. We also compare to a Google database of programs that
you might find if looking on the web. We perform the same kind of plagiarism detection done in most Rhetoric and Writing
classes. For a class of 400 students, a minimum of 79,800 comparisons is needed. If you are thinking we are bluffing, read
on. If your instructors or TAs had to perform these 79,800 comparisons, the task would be impossible – obviously.
However, it takes the computer about 30 seconds to perform this operation. Every pair of program files that is deemed too
similar is manually inspected by TAs and instructors, and if cheating is determined, then you will receive a zero for all
assignments for the first offense. Because homeworks (programming) in this course are an essential part of your learning
experience, they are worth about 30% of your final grade. It would be very difficult to pass the course without this 30% of
the possible points. The College of Engineering policy on cheating is stated in detail here:
(http://www.engineering.uiowa.edu/current-students/academic-misconduct.php)
Whatever you do, please do not come to an instructor and say, "But won't my solution look like everyone else's – since
there are 400 students, the problem is narrow and the solution is simple." No, we won't analyze your first, "Hello, world,"
program the first day. But we will analyze pretty much everything after that. You are simply displaying your lack of
understanding of how varied and complex, even a simple programming solution can be. Don't do it. Also, if you think
changing all of your variable names, comments, whitespaces and re-ordering some lines of code will mask the similarity of
your code from someone else's, then you do not understand what is called "control flow" and "logic" of a program, nor how
the similarity detection techniques in our software work. The beauty of our system is that to truly beat it, you really have to
understand the program and change it fundamentally, at which point it would just be less effort to simply do the
assignment.
Here is a simple example: I have come up with a novel story called Stellar Hostilities. It is a story about coming of
age. Where a boy learns to use his laser rapier and develops his psychic powers to fight evil and the oppression of the
Confederation. Joined by a band of miss-fit insurgents, he destroys the mighty Confederation base in the final climatic
scene, as the evil, masked overlord is thrown into space by the explosion.
Although it is not called “Star Wars”, George Lucas wouldn't let you make that movie. The point is, programs have things
we can see, like variable names, comments and white spaces. But they also have "control flow" and "logic." When you
piece them together, it still looks like "Star Wars" no matter the quality of your thesaurus.
If there is so much danger in talking to someone about my program, how can the TA or instructor help me in case I
get stuck?
Excellent question! The main difference between the instructor or TA and your fellow students are that the instructors are
trained to help you understand the concepts used in your assignments, and not just tell you a solution. To do so, they may
provide you with examples that are similar in nature to your assignment. In certain situations, they may point you in the
right direction on a specific aspect of your program or may give you a heads up if they think you are going in the wrong
direction. They will also answer questions about any part of the actual problem specification that you don't understand.
TA’s and instructors will talk about the general concepts (conditionals, loops, variables), but they will not discuss how to
implement those in the context of the assignment.
Finally, don't forget that expensive textbook you bought, and all the examples found therein! You have a wealth of
information and a wealth of examples of other programs to use. But you have to open the book!
Summary
The bottom line is that the computer (and skill in programming that computer) is the most powerful, general, all-purpose
problem-solving tool ever created. You can either perform the work for this course and learn how to program and have at
your disposal a general, all-purpose problem-solving tool for the rest of your career…
… or not. Your choice.
-----------------------------------------------------------------------------------------------------------------------------Please fill out the lines below and sign and return to the instructor, thereby accepting the terms and consequences of this
policy. Turn this form in by the end of lecture Wednesday/Thursday, August 24/25 2011.
Printed name: _____________________________________
Student ID #: ______________________________________
Signature: _________________________________________
Section (circle one): 1 2
3