[thomascgalvin]

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

[kasey_junk]

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.

[bayindirh]

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

[2OEH8eoCRo0]

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.

[bayindirh]

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

[2OEH8eoCRo0]

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.

[the_af]

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.

[bpyne]

Your comment harks to a much broader concept. Are Computer Science programs supposed to produce software engineers or people grounded in the theory?

My own opinion is that separate tracks should exist.

Grading students more harshly without modifying the focus of their studies simply won't produce better people in the field.

[bayindirh]

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

[bpyne]

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.

[the_af]

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

[downerending]

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.