Hi all, I've adapted the SC bash, git, and python lessons for our *Introduction to Computational Techniques for Materials Scientists and Engineers *course at Boise State University, taken by freshmen and sophomores with (usually) no coding experience.
In my case, I don't find it makes sense to have exams or quizzes. All of my assessment of students is based on projects where students worked collaboratively on code, or reports/presentations on those projects. For example in their first project they earned points for making commits, reviewing their peers' commits, being thoughtful about those reviews, and a 2-page summary report. Assignment link: https://www.dropbox.com/s/tqwcmldzz85ynav/Project1.docx?dl=0 Sample report: https://www.dropbox.com/s/7k8uuln7r0szy7c/SampleReport.docx?dl=0) Project repository: https://bitbucket.org/mse197/diffusion The grade breakdown was: 30% - did you make at least 10 commits? 30% - did you review at least 5 commits (provide a comment, question, suggestion)? 30% - are your peers finding your reviews helpful? (6% per helpful code review (up to 5) as reported by your peers) 10% - summary document (can you communicate the point of the assignment, what you did, and that you're thinking critically about your work/code?) Basically, I worked backwards from the skills I wanted students to have and figured out the practices and feedback they would need from me to help them achieve this. The same principle governed my selection of assessment: What are authentic metrics for measuring how much students are helping make code better? I found it to be both authentic and efficient to have students self-policing the coding and code reviews. Hope this helps, Eric PS: I'm redesigning this course for next semester and am currently soliciting ideas for raspberry-pi based projects. If you have any favorites, I'd love to hear them! On Tue, Dec 6, 2016 at 3:18 PM, Henry Neeman <[email protected]> wrote: > > I teach programming for non-majors: > > http://cs1313.ou.edu/ > > We assume zero programming experience, though > some modest fraction of them have a little. > > These are mostly engineering students, with > some science students, and rarely more than a > handful of non-STEM students. They tend to be > mostly first and second year students, but we > get some upper division students too. > > We assess as follows: > > 55%: programming assignments (45% projects, 10% web exercises) > 35%: 3 exams plus weekly quizzes (25% exams, 10% quizzes) > 10%: lab attendance > > Exams tend to have the following sections: > > (1) Short answer (mostly conceptual) > (2) What is the output of this program? > (3) Write some code > > We do open book, open notes -- in my > experience, memorizing isn't a skill that > aligns well with programming, but looking > things up is. > > If you look at the homeworks posted on our > course website, the quiz questions are a > verbatim subset of the homework questions, > and the exam questions are pretty similar. > > Frankly, I put a lot more stock in their > programming assignments than in their > exams and quizzes, which is why things are > weighted the way they are. > > Henry Neeman ([email protected]) > > ---------- > > On Tue, 6 Dec 2016, Olav Vahtras wrote: > > >Dear all,In Software Carpentry/Data Carpentry workshops we try to adopt > >pedagogical principles that are proven to enhance student learning > >outcomes. However, one aspect of the teaching/learning process is not > dealt > >with at all: assessment (no exams!) > > > >As I am sure many of you are teaching programming courses with similar > >content using similar principles in your home institutions, I would like > to > >ask about your experiences with assessment of different forms. Does it > make > >sense to have a traditional written exam? How do you handle grading of the > >students, do have pass/fail or some other scale with more levels and how > do > >you define those levels. > > > >I am currently developing an undergraduate Python course for students in > >biotechnology which have normally have basic computer skills, but limited > >programming experience. > > > >Best regards, > >Olav Vahtras > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/listinfo/discuss
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
