|
|
|
|
|
by gravypod
2054 days ago
|
|
Could you make your class project based and give everyone different, but equally difficult, projects of their choosing. Each check in into master would then be merged after a code review with you where you ask questions about why implementations are done specific ways to solve the problem/refactor. Code is only merged when it hits a quality marker you set. Students are graded by percentage of deliverable hit from original project specs. Ex: student is to implement a K&R C compiler + code generator in 1 semester. Help them break up the project into manageable chunks (tokenize, AST, register allocation, etc). Each feature includes tests, comments, docs, and is presented to you by X date. Code review and cycle as many times as needed as long as it gets in by X date. By the end of the class the student hit 100% of their deadlines but only pass 70% of some test C files you create so they get a 70% (or higher if their code was consistently good and did not need cleanup) in the class or something. It would never work because "you need to have a final exam" but it's the ideal I think we should strive for if you are "teaching programming" since this is how most work I've done in the real world has gone. |
|