Our overall goal in 6.171 is producing professionally competent software engineers. If by the end of the semester, you have the skills of a professional programmer you will get an A for the class.
A professional programmer ought to be able to pick worthwhile problems to attack. Engineering is the art of building cost-effective solutions to problems that society regards as significant. A person who blindly does what he or she is told, without independently figuring out the context and significance of the problem, is not doing engineering. A professional programmer needs to be able to sit at a meeting with decision-makers, prepared with substantial domain knowledge, and make significant contributions to the discussion. In evaluating your performance in 6.171, we look at (i) how well you've steered your client into solving the most important problems for users first, (ii) what you've said during in-class discussions of potential projects, and (iii) whether you've made useful suggestions to other teams in the realm of service design.
A professional programmer needs to be skilled at realizing clean-sheet-of-paper designs: (i) taking vague organizational aspirations and turning them into concrete specifications, (ii) selecting appropriate tools for a substrate, (iii) building and testing a prototype, (iv) using that prototype to obtain feedback from users and the sponsoring organization, (v) implementing and launching Release 1.0, (vi) refining the specs for Release 2.0 based on experience with 1.0. In evaluating your performance in 6.171, we look at whether you managed to launch your service to real users and how successful your project was at meeting technical and organizational goals. The mid-term exam is also aimed at figuring out whether you can look at a desired user experience and perform the most critical aspects of system design such as data modeling.
Notice that a critical element of the realization process, selecting appropriate tools, requires that a programmer maintain a network of professional colleagues. It is extremely risky to pick software tools based on vendor claims, 99 percent of which have proven to be, uh, optimistic. A programmer who can draw on a group of friends and get unbiased information as to which tools are reliable is much more effective than a programmer working in isolation, reading press releases and advertising. You'll get extra credit in 6.171 if you can say "I really liked feature X from Team Y's project so I asked them how they did it and adapted their ideas and code for our project."
A professional programmer needs to have a dedication to the quality of the end-user experience. A coder, ripe for outsourcing to the Third World, can unthinkingly implement whatever system design that results from management and graphic designer whims. An engineer, however, makes sure that what he or she is doing makes effective use of the end-user's time, partially by reference to established principles of user interface design and partially by conducting prototype tests with a handful of potential users. In evaluating your performance in 6.171 we look at whether you made effective use of user testing, ideally beyond the minimum required in the exercises.
A professional programmer is skilled in communicating. This means writing documentation that will enable another programmer to take over a project. Communicating also means writing white papers that explain the significance of a problem, how it was attacked, and what the results were. A programmer also ought to be good at making short oral presentations that communicate the main points of a project to a technical or non-technical audience. Finally, a programmer should know how to make good use of face-to-face interactions with users and customers. In evaluating your performance in 6.171, we ask "Can we understand all of this structure and source code purely by reading what is in the /doc directory?" We also look at (i) whether you gave clear and compelling presentations in class, (ii) whether your client felt that he or she was kept apprised of project status, and (iii) the quality of your final overview document.
A professional programmer is not afraid of a challenge. An MIT graduate certainly should never be afraid of a challenge. You get extra points in 6.171 for tackling a hard problem and solving it in an elegant or clever way.
Speaking of challenges... most software projects are too difficult for one person to tackle alone. Consequently, a professional programmer is good at working within a team, managing risks, establishing milestones, and meeting deadlines. In evaluating your performance in 6.171, we'll look at whether you helped your projectmates function as a team and whether you discharged the responsibilities for the role(s) that you assumed within the team.
For a software engineer to have a successful career, he or she must have a portfolio of projects that actually launched and customers who were satisfied and say "I would really like to work with this engineer again." We look at whether you did the last painful 5 percent of work that is necessary to push your project out into the hands of real users and how your client feels about the overall experience of working with you.