> 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).
> 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".
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.
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.
Yes, that's good. Nobody is saying that code cleanliness is worth 0 and working code is worth 100. Working code is the most important metric but cleanliness, extensibility, etc are also important but secondary.
Your professor did exactly the same that mine did back when I was in university. Your code works? Good, you've met the minimum requirements, you'll pass. Your code has to be immaculately written and commented if you want a full perfect grade though.
Students who pass who can't code aren't the ones doing the coding (clear or unclear) in my experience. When doing homework, these students focus on higher level concepts and let the people who love coding do the actual coding.
This is based on my actual experience at university, not a random guess. It's never a case of "teachers weren't strict about working code", it's a case of "student didn't focus on coding, let others do it". Note that in proper CS (as opposed to a "coding school" or bootcamp) this is semi-acceptable, since CS is much more than just coding.
I do find it puzzling, because how can you study CS if you don't enjoy coding? But surprisingly enough, a lot of people who study CS don't actually love coding. Some actually love maths.
> Are Computer Science programs supposed to produce software engineers or people grounded in the theory?
I'm a graduate of a program called "Computer Engineering" which infuses a good deal of theory coupled with hardware and programming internals (gates, ALUs, programming language design, theory and implications, etc.)
As a person who absolutely loves coding, I immensely enjoy writing code while being able to visualize/understand how it will execute on the hardware. New CPUs blur the things continuously though.
CE mixes low and high level concepts well. I've never had a hardware class but have a copy of Tanenbaum's hardware book. It gives me hand-wavy notion of how the processor operates. But I'd never apply for a hardware programming job. Eventually I'm going to take a class in computer architecture.
While I used an "or" in my statement the reality is that most CS programs give a smattering of different CS areas including theory, SE, and hardware. SE is often one course in a 4 year program. A developer simply can't develop the skills for SE in one course.
When I was in grad school for CS I had a course with the department chair. I had been in the field for 20+ years at that point. One day she asked me for feedback on how to improve the undergrad program for students who want to go into the field. My response was a separate track that required practical year-long projects requiring SE skills. Each year the project could get progressively more involved. Students in this track would still need courses like data structures, algorithms, and programming language paradigms. But they would apply the knowledge from them to practical projects.
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).
Unfortunately, correct is a function of time, and almost all correct programs become incorrect at certain points of their lives. Maintainability is a thing, and I've learned to lean pretty sharply in the direction of just shitcanning unreadable code.
As a corollary, unreadable code almost always seems to have a lot of latent bugs that simply haven't been observed yet.
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.
> 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).
> Programs are not designed to be readable, they are designed to solve a problem
I assume you've not had much experience with any legacy code where: if statements span hundreds of lines, variables have cryptic names which mean nothing to anyone but the original author (who is gone), and a distinct lack of comments.
I'm in the middle of such a project, and the lack of readability is severely inhibiting my ability to move forward. In fact, I've had to write software to parse this source code, just to follow the flow of logic.
This might be an extreme example, but it highlights how important readability is.
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).