Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Classroom

classroom.github.com

Post reply on HN
Print view View original

91–100 of 171 posts

Re: GitHub Classroom

#91

Post by hanniabu »

ricksharp wrote: post #89
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…

The entire reason kids and adults should write in plaintext is in order to focus on the content of their message. Markdown is excellent because it prevents the writer from formatting except where that has semantic meaning (headers, lists, etc). I’m teaching my son (14) how to use the best tools: The first assignment I gave him was to write a short essay in markdown, using vscode, and commit and push the answer in a p…

You can still submit .txt documents

Re: GitHub Classroom

#92

Post by divyavaishnavi »

jsumrall wrote: post #19

Happily using GitHub Classroom for programming assignments for the interview process at work. HR has the URL they send to the assignment, candidates do the work and create a PR, and then HR assigns developers as PR reviewers when the candidate is done.

Its interesting to see you use Classrooms for the interview process :)

Re: GitHub Classroom

#93

Post by divyavaishnavi »

davidbanham wrote: post #62
jsumrall wrote: post #19

Happily using GitHub Classroom for programming assignments for the interview process at work. HR has the URL they send to the assignment, candidates do the work and create a PR, and then HR assigns developers as PR reviewers when the candidate is done.

Does it allow you to set a hard time limit on how long the candidate has to complete the challenge?

Yes you can set deadlines for assignments.

Re: GitHub Classroom

#94

Post by maeln »

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 organized code. On the other hand, one of my student once created a program that was just made of switch instruction in switch instruction (up to 5 level of switches) and spread for more than 3000 lines, just because he failed to understand how function where working.

You can try to plug a linter in your testing stack, a quality gate, all kind of software to measure the code quality, but it will never be truly fair. 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. And those rules tend to be even more arbitrary with than the teacher himself.

Trying to automate grading is an engineer trying to apply its vision to education, and it my honest opinion, it is an awful idea. Providing tools to facilitate education is awesome, trying to automate education is a dystopia.

Re: GitHub Classroom

#95

Post by darils »

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-your-digital-classroom...

Autograding with GitHub Classroom: https://github.blog/2020-03-17-improve-student-success-and-i...

Re: GitHub Classroom

#96

Post by rhinoceraptor »

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 had a very frustrating experience in an operating systems class, the first assignment was a few very basic C programs (pointer use, C strings, etc.). I used some C99 features that didn't compile without a flag in the version of GCC the grader used, so I just got a zero even though the programs were correct.

Re: GitHub Classroom

#97

Post by elcomet »

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 assignment are very nice because they force you to have a programmer mindset (the smallest error / typo will make your code fail).

If you want to grade also the organization of code, fine, but I think the first one is more valuable (how to organize code properly is not learned at school anyway, it is learned by months / years of practice).

Re: GitHub Classroom

#99

Post by dom_hutton »

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 marking it.

Re: GitHub Classroom

#100

Post by thomascgalvin »

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…

> 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, but they're by far the minority case and should be clearly marked as "deep magic".

https://en.wikipedia.org/wiki/Magic_(programming)

Post reply on HN