The 6.S194 team is holding an information session about the course this coming Wednesday 12/11, 4pm at 34-304.
If you cannot attend the session, feel free to direct any queries to josmasflores at gmail.
]]>A way for you to practice communicating, critiquing, and iterating technical design.
When you are acting as presenter, your role is to communicate your work in a way that both conveys its technical design and also the reason why this work was necessary. A presentation should last about ten minutes. A good breakdown for these ten minutes would be:
Introduction: One or two sentences about what you’re going to be presenting.
2 Minutes: Broader context of the problem.
What is the software involved and who uses it? What is the particular area of the software that you’ve been working in? (i.e., the database layer, the reporting code, the front-end interface). Who uses this layer software? What is its significance to the project? What is its design philosophy? Its goals?
For example, if you are working on a bug-fix for a database library, explain the database library to us — who uses it? Why? What is its overall design philosophy? How does it integrate with other components?
3 Minutes: Technical overview of the feature, bug, or design task that you have been working on. Why is it important or necessary? How will it affect users? What technical details are involved? What are some of the risks and tradeoffs involved? What is interesting or hard about this problem? If relevant, have code prepared to show.
2-3 Minutes: Your solution, even if its still in progress. Why did you make the choices you did. Have code prepared to show Audience Role
The audience has the responsibility to ask questions which probe the design space and the presenters decisions. Avoid problem solving: this is a space to understand and critique a particular idea rather than solve problems.
The second role of the audience is to provide feedback. Focus on how or why the proposed design is good or unfitting for the problem. This includes both technical (i.e., code technique) and design feedback.
Be expedient and to the point.
Appreciate and respect the importance of “ordinary” technical decisions. Especially at MIT, we all have a tendency to disregard technically easy things as being uninteresting. Do not. We aren’t interested in the technical difficulty of solutions here. We are interested how and why you decided your solution is the right solution. And the challenge of picking the right solution is nearly always interesting to talk about, even if all the choices you are choosing between are technically simple to implement.
]]>The 6.S194 team is holding an information session about the course this coming Wednesday 12/11, 4pm at 34-304.
If you cannot attend the session, feel free to direct any queries to josmasflores at gmail.
]]>Due to the International nature of this course, pre-registration is already open. You will need to pre-register before 12/15 and register by 1/6.
Pre-Registration: 12/15/13
Registration: 1/6/14
Please use this form to express your interest in the course. More information can be found in the registration page.
Have a look at the projects page for more details.
Any queries can be addressed to josmasflores on gmail.
]]>