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

101–110 of 171 posts

Re: GitHub Classroom

#101

Post by pacman128 »

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…

Back when I taught CS, I had a colleague who did this. He ran the program and compared the output char by char to what he expected. The assignments went into great detail on the expected format of the output (column-by-column). I believe this was all he did, no check of the source code. The sad thing was he was the chair of the department when I first got there. Fortunately, he retired soon afterward.

Re: GitHub Classroom

#102

Post by kasey_junk »

thomascgalvin wrote: post #100
elcomet wrote: post #97

Earlier quoted context omitted.

> 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…

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.

Re: GitHub Classroom

#103

Post by praveen9920 »

I love it.

Accountability of submissions and recorded specific feedback for each assignment is great way to learn.

One feature I would like to see is peer reviews. Although it might cause cheating or plagiarism, it could be useful tool for peer learning. Probably can add it as post assessment step.

Re: GitHub Classroom

#104

Post by IggleSniggle »

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…

That's exactly the point. There is more subjectivity and nuance, and the person marking it is forced to engage in a kind of dialog with the actual code and see it for itself instead of relying on some limited objective heuristic which has no capacity to understand the student and what the student is misunderstanding.

Re: GitHub Classroom

#105

Post by bayindirh »

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.

No. Code should be readable. When a code is fresh only you and God knows what it does and how it does. 6 month later, only God knows how your code works. You need to re-read and understand it to grasp it again.

Unless you marked all magic with big comments blocks or you wrote your code explicitly, it'll take some headache-inducing hours to re-understand it.

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

Again no. You can leave a non-working but readable code overnight and understand the problem tomorrow morning. You can't remember random noise after a good night's sleep (unrelated: This is why regex is hard for our brains).

Related read: http://raganwald.com/2013/04/02/explicit-versus-clever.html

Re: GitHub Classroom

#106

Post by bayindirh »

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.

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

Re: GitHub Classroom

#107

Post by k__ »

Nice!

I'm teaching software development and was using freeCodeCamp.

But my students are designers, so the curriculum is often too much and I would like to strip it down. Maybe this is a way to streamline things a bit more in the future.

Re: GitHub Classroom

#108

Post by 2OEH8eoCRo0 »

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…

Agree. Solving the problem is first and foremost. Looking pretty, being extensible, well commented, etc come secondary- especially when teaching.

Re: GitHub Classroom

#109

Post by 2OEH8eoCRo0 »

bayindirh wrote: post #106
kasey_junk wrote: post #102

Earlier quoted context omitted.

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.

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

Re: GitHub Classroom

#110

Post by petepete »

OhSoHumble wrote: post #23

Too bad it doesn't have enterprise support. Would be great for educational courses within a company.

I'm currently teaching git to a group of about 10 content designers in the department where I work. They are enjoying it and looking forward to work more closely with developers and other designers.

This would be ideal and would definitely make my job a bit easier.

Post reply on HN