GitHub Classroom • Hacker News Board

Re: GitHub Classroom

#111

Post by maeln » Thu, Jun 04, 2020, 1:03 PM UTC

elcomet wrote: post #97

maeln wrote: post #94

Just on a minor note. Having taught programming classes in the past, don't use automated testing for grading, or at least not fully. First of, there is a lot more to judge in a program than just the correctness of its output. Is the code readable ? Re-usable ? Did the student understood the core concept of the language and used them correctly ? I saw some student fail to produce a correct program but had a well organ…

> I saw some student fail to produce a correct program but had a well organized code. I don't necessarily agree with this. Programs are not designed to be readable, they are designed to solve a problem. The first goal is to get the correct program, and only after, it is important to make the code readable. A readable code that doesn't work is not worth much. As a former student, I think automatically graded assignmen…

I was a student, a software engineer and a teacher :) ! I have to strongly disagree with you. The programmer mindset is not about the smallest error / typo make your code fail. This is just a restriction of the tool which you need to be able to manage if you want to use it. The electrician mindset is not about knowing which type of screwdriver to use.

As a programmer, the substance of your job is to solve a problem, which you do using various tools. Your ability to understand the problem and properly translate it within the restriction of your tool makes you a good programmer. Making no typo doesn't make you a good programmer, especially these days where you can usually really on extensive CI stack to check for this kind of small mistakes.

And, I do agree that producing a program that is correct is the first goal, but it doesn't mean that other consideration such has the quality of the code shouldn't be valued, has you said. In the same way, properly organizing code may not be the first goal, but it doesn't mean that you shouldn't reward student who clearly tried to think about their code. And, I would argue that a lot can be learned in school :) .

Overall it is all about incentive. By grading automatically, you are targeting the lowest bar possible. By grading also other aspect of the student work, you also give him intensive to work on those aspect, making him not just a machine that can pass unit test, but also a person that can reason about its own work and try to improve it.

Re: GitHub Classroom

#112

Post by Myrmornis » Thu, Jun 04, 2020, 1:06 PM UTC

darils wrote: post #95

GitHub Education listens intently to the needs of students and teachers. We are delighted to work alongside Relp.it to help students get started quickly in the same coding environment, and allow teachers to focus on teaching instead of troubleshooting. IDE Integration announcement: https://github.blog/2020-05-26-code-in-the-browser-with-gith... GitHub Classroom starter guide: https://github.blog/2020-03-18-set-up-you…

This just sounds like sales talk. “Listens intently” doesn’t mean anything. Even if you work in sales for GitHub/Microsoft, please just write like a human when you post to HN.

Re: GitHub Classroom

#113

Post by bo1024 » Thu, Jun 04, 2020, 1:08 PM UTC

maeln wrote: post #94

Just on a minor note. Having taught programming classes in the past, don't use automated testing for grading, or at least not fully. First of, there is a lot more to judge in a program than just the correctness of its output. Is the code readable ? Re-usable ? Did the student understood the core concept of the language and used them correctly ? I saw some student fail to produce a correct program but had a well organ…

That would be lovely in a world where the teacher-to-student ratio was say 20:1 rather than 200:1. Most major CS programs use automated grading for lower-level programming classes; check out Berkeley's huge infrastructure and toolset for their curriculum. There just isn't enough money (or competent TA's, often) to give good individual feedback on code style in intro courses.

Perhaps it is our own fault for somehow giving administrations the impression it is possible to teach well at scales where individual attention is impossible. I don't know.

Re: GitHub Classroom

#114

Post by sradman » Thu, Jun 04, 2020, 1:08 PM UTC

ShamelessC wrote: post #67

sradman wrote: post #22

This type of system seems obvious for programming courses but I wonder how intuitive it is for pure documents; the classic essay or report style assignments. At what age do kids embrace Markdown as the single source of truth for their documents? Do technical writers within Google use Gerrit, or whatever their Perforce based review process is called, as a core part of their collaborative workflow like coders do?

This is peak hacker news. I'm not entirely certain I'm understanding your concern as I don't see anything in the feature list about how they handle "pure documents". My assumption is that they expect you to use markdown for such submissions (a valid choice for programming-based learning) and you're suggesting this should be more widespread and used for teaching other subjects? > At what age do kids embrace Markdown a…

> I don't see anything in the feature list about how they handle "pure documents".

True, but I’m taking the product name “Github Classroom” seriously. Maybe it should have been named “CSLab”. I think that the Scrum-like tools and processes that developers have refined over the last decade can be used in any endeavour that generates digital artifacts from text source files.

Github/Gerrit workflows seem ideal for these types of collaborative projects but I really don’t know; thus the question marks. My conclusion from your feedback is that a Google Docs-like WebUI is a requirement and my question switches to when is it appropriate to peak under the covers and see the plumbing.

Re: GitHub Classroom

#115

Post by yepthatsreality » Thu, Jun 04, 2020, 1:09 PM UTC

> “all while using GitHub, the industry-standard tool developers use.“

They mean “service” not “tool”.

Re: GitHub Classroom

#116

Post by maeln » Thu, Jun 04, 2020, 1:14 PM UTC

dom_hutton wrote: post #99

maeln wrote: post #94

Just on a minor note. Having taught programming classes in the past, don't use automated testing for grading, or at least not fully. First of, there is a lot more to judge in a program than just the correctness of its output. Is the code readable ? Re-usable ? Did the student understood the core concept of the language and used them correctly ? I saw some student fail to produce a correct program but had a well organ…

> It will make your evaluation a game where the student challenge is not understanding the concept of the class, but instead, understanding the rules of the various test you put in place. I agree with most of what you have to say, however you're arguing for replacing one 'game' with another. If the goal is not to understand the grading engine then by the same logic the goal is to understand what appeals to whom is ma…

I do agree that you are replacing one subjectivity (the tests and tools rules) with another (the teacher view of what is a good code).

But the idea is that a teacher is not as strict as a tool and is not here to punish student, but to instead grade them fairly in order for them to see what they can improve, and provide assistance for them to improve on those point. Well at least in theory, its not that easy to do :) .

The main reason why I disliked automated grading was that, a lot of time, I could see that a student almost got the right answer, but either didn't have the time to finish, or made some small mistakes. A automated tool would have given him 0, the same grade that a student who failed to understand anything or didn't work would have had, which I see has highly unfair. He cannot have all the point, but he should have some.

Not valuing the work of students is the quickest way I found to demoralize student and ultimately have them fail the class. And this is the opposite of what a teacher should strive for.

Re: GitHub Classroom

#117

Post by maeln » Thu, Jun 04, 2020, 1:19 PM UTC

bo1024 wrote: post #113

maeln wrote: post #94

Just on a minor note. Having taught programming classes in the past, don't use automated testing for grading, or at least not fully. First of, there is a lot more to judge in a program than just the correctness of its output. Is the code readable ? Re-usable ? Did the student understood the core concept of the language and used them correctly ? I saw some student fail to produce a correct program but had a well organ…

That would be lovely in a world where the teacher-to-student ratio was say 20:1 rather than 200:1. Most major CS programs use automated grading for lower-level programming classes; check out Berkeley's huge infrastructure and toolset for their curriculum. There just isn't enough money (or competent TA's, often) to give good individual feedback on code style in intro courses. Perhaps it is our own fault for somehow gi…

I do understand the issue. I personally only taught in small classes of less than 30 student, and most of my own education was in small classes to. Even with fewer student, it took my a lot of time to prepare classes, evaluations and then grade them in a way that I perceive was "fair". I don't think it would have been possible if they were twice the number of student.

Re: GitHub Classroom

#118

Post by bayindirh » Thu, Jun 04, 2020, 1:29 PM UTC

2OEH8eoCRo0 wrote: post #109

bayindirh wrote: post #106

Earlier quoted context omitted.

> A readable incorrect program is worse than an unreadable correct one. That neither is acceptable doesn’t negate that. I will happily fix a readable but non-working code rather than maintain a working but unreadable code any day under the sun.

We are talking about teaching. You guys wonder why students graduate who can't code- professors who passed them because their shit that doesn't work looked nice.

> We are talking about teaching.

I'm heeding the way of my professor. She cut serious points from non-working code as expected but commented on our code in great extent regardless of its state.

She one to one explained to all of her students why their code didn't work. She similarly reduced grade of a working but, non-readable code and she clearly told why she did that. Also you got bonus points for informed experimenting, going the extra mile.

She always asked us hard tracing questions in exams. I complained once: "Why do I need to compile this in my mind while the compilers can do all the job?" She calmly answered: "If you can't compile that code in your mind, the compiler can't do it either.". It took me 6 years to sink that in but, when it did, I really enlightened.

With her style, you got to write working code to pass the course, regardless of all bonus points. If you can't code, you can't pass the exams either. She was great because of this.

Professors shall teach to write readable and working code, there's no exception. She was actively developing NLP systems when I last talked with her. I develop scientific applications. Both of these fields create convoluted code by default so, writing readable code is a really great ability to have.

Re: GitHub Classroom

#119

Post by ShamelessC » Thu, Jun 04, 2020, 1:34 PM UTC

sradman wrote: post #114

ShamelessC wrote: post #67

Earlier quoted context omitted.

This is peak hacker news. I'm not entirely certain I'm understanding your concern as I don't see anything in the feature list about how they handle "pure documents". My assumption is that they expect you to use markdown for such submissions (a valid choice for programming-based learning) and you're suggesting this should be more widespread and used for teaching other subjects? > At what age do kids embrace Markdown a…

> I don't see anything in the feature list about how they handle "pure documents". True, but I’m taking the product name “Github Classroom” seriously. Maybe it should have been named “CSLab”. I think that the Scrum-like tools and processes that developers have refined over the last decade can be used in any endeavour that generates digital artifacts from text source files. Github/Gerrit workflows seem ideal for these…

> but I’m taking the product name “Github Classroom” seriously. Maybe it should have been named “CSLab”.

I also was confused about the scope they are going for with this. My initial assumption was that since it's GitHub, it's probably mostly for coding lessons. I read your comment though which implied it could be used for more generic lessons and I mistakenly assumed you had used the offering and had more info about it than me.

> Github/Gerrit workflows seem ideal for these types of collaborative projects

Are you suggesting complicated version control could be useful for e.g. some group of teens doing a 6 paragraph research paper in their social studies class? Again, that is just...so bizarre. That has an even lower chance of being easy for teachers or students to use than markdown.

> conclusion from your feedback is that a Google Docs-like WebUI is a requirement and my question switches to when is it appropriate to peak under the covers and see the plumbing.

That's totally valid. The difference between manually editing markdown and using a GUI toolbar is all that it takes for me to approve of the idea really. If there's a way to make the underlying format be markdown and still maintain the broad appeal of Docs/Word then I think that sounds great!

Re: GitHub Classroom

#120

Post by the_af » Thu, Jun 04, 2020, 1:35 PM UTC

kasey_junk wrote: post #102

thomascgalvin wrote: post #100

Earlier quoted context omitted.

> Programs are not designed to be readable, they are designed to solve a problem. This is 100% incorrect. If a developer submits a PR that works and if fast, but cannot be understood by the rest of the team, it can, should, and will be rejected. 80% of software's lifetime is spent in maintenance. That clever hack or ugly patch might work today, but you're going to hate yourself for it in a month. There are exceptions…

The broader theme of that comment was that ‘correct’ is table stakes. A readable incorrect program is worse than an unreadable correct one. That neither is acceptable doesn’t negate that.

There's wisdom out there that an incorrect but clear and well-commented program is better than a correct but unclear one. This is quoted at least in O'Reilly's "Practical C Programing" [1], which is a pretty good book. A lot of programmers believe this, too. I think the concept has merit (without taking it to extremes, of course).

[1] https://www.oreilly.com/library/view/practical-c-programming...