Hacker News Reader

In the case of debugging I would say that the academic side would benefit from the teaching of the fundamentals of debugging: this is because debugging at its core is just science, the process of measuring and perturbing a system to understand something about how it works. You can teach someone gdb but if they don't get the fundamentals then they will struggle to actually debug anything

I think you are right when you frame debugging as a scientific process. It really is about observing and measuring while perturbing a system in some way to provoke it to provide you with observation.

But as roenxi points out, academia doesn't see programming as something they are supposed to teach. Academia sees programming as a vocational skill. Something to be learned "on the job" - or done by "other people" (whoever they might be). They see it as their job to, mostly, teach you the math that is needed to model behaviors of software and systems.

I think the closest I ever got to something that was practical was system design/modeling. And as to demonstrate how terrible academia is at keeping itself updated, the methods we learned were, without fail, known to be impractical, outdated and wasteful. Nobody who took that class would ever apply anything they had learned in that class later in life.

Computer science is a bit odd. If you become an architect (the kind that draws houses) it is understood that you are not going to be actually building houses. You will probably never even touch a hammer in any professional capacity. You will work with someone who understands the mechanical bits, building code etc and together you produce a package of instructions that someone else has to realize.

However, if you are a CS grad, it is fairly likely that you will be writing software. Which makes the whole thing a bit absurd. It is as if you expected architects (the house-designing kind) to build houses, but never even give them any training in how to nail two planks together.

This strikes me as so odd. My CS degree had tons of practical classes but it was all application of things you learned because, being quasi vocational, the best way to learn to program is by doing so the learning to program portion of the degree were the assignments to the classes. We had loads; your standard welcome to Java course, the second level where we had some of the early Google Nexus phones and experimented with building little apps [0], then a whole class on development methodologies which had a lab/group project portion where we were adding to a little digital health document system that was actually passed from class to class taking the best version(s) from each semester and adding to it on the next, and at the end a Senior capstone project. Each semester generally had at least one largely practical class.

> It is as if you expected architects (the house-designing kind) to build houses, but never even give them any training in how to nail two planks together.

Well architects don't build houses, they design them. The learning of computer programming is best to learn by doing after an introduction to the basics of some language. I have a hard time believing programs just fail to mention the existence of debuggers over the entirety of their program. There's a lot of the programs that expect you to figure out the precise tools you want to use for yourself.

[0] The core assignment of this actually kind of failed because it was flawed from the beginning but it was still quite useful. We were supposed to build a lock screen that "locked" the phone when we went above a configurable speed. The main issue was the GPS data available to the apps in that early version of Android was very spotty.

The academia teaches practical programming. The CS department usually doesn't, as it's not their job.

You can see the same situation with the mathematics department. They teach mathematics, not doing calculations. If another department has a need for more practical mathematical skills (physics is the usual example), they often teach their own classes.

Like many other biases in the academia, this is mostly a matter of self-selection. If you want a career in software, the industry is clearly the better option. If you want a career specifically in CS, there are not that many good alternatives to the academia. Which means that CS departments are populated by people with no particular interest in software.

> Which means that CS departments are populated by people with no particular interest in software.

This is bunk, from my experience at UC Berkeley (PhD) - the professors I knew/worked with loved to program. One explained to me that teaching+research+academic duties left no time for programming on campus, so he spent another 40 hours a week programming at home.

Your experience supports the statement. If the professors you knew had a particular interest in software, they would turn their work focus towards that, not focusing on teaching, research, and other academic duties that are at odds with software.

They prioritize the latter as those are in line with their particular interest. Software is just a sideline, just like I'm sure most of us here have some kind of other interest that we partake in at home.

They were programming language professors. They most definitely had an interest in both programming and academia.

Nobody is questioning their dual interest, but it is clear what their particular interest is (hint: not software).

I see. So anyone flipping burgers at McDonald's must have a passionate interest in and life goal to be flipping burgers. Otherwise, why would they spend so much time on it?

If I understand your argument correctly, you're saying that if someone in practice spends their time doing X and not Y, then they cannot actually be more interested in Y. I believe this flies in the face of human experience.

If you love software, there are a limited number of careers that involve writing software. If you do not have the privilege of a large trust fund, you're looking at industry or academia. Neither tends to involve just sitting in a room and coding all day. (Those situations that do probably won't satisfy a post-teenaged love of software.) Especially if you have a more academic love of software, academia is not a stupid option, even though you realize that your time is going to be filled with a lot of non-programming duties. Yes, you would probably spend more of your time programming if you got a corporate programming job, but loving software does not mean automatically loving any situation where you are typing code into an editor.

This doesn't fit with my experience. Most (90+%) of the developers I've worked with have a CS degree. Those who didn't mostly had math, physics or chemistry degrees. A small minority have no degree at all.

Maybe universities would benefit from a formal programing lab discipline, like they have for physics and chemistry. One where you document what you are going to do, go into the lab and do it, and document what you concluded from it.

And yeah, finding bugs on code that was already there when you came can be an exercise.

Or just require CS students to take at least one lab science course. I started in the engineering program and switched to CS, but by then had already taken lab-based chemistry and physics. Those courses taught me more about “debugging” than any dedicated engineering or computer science course I took (and I did take the software engineering courses that were offered). In fact, at a reception dinner during graduation week I was seated at the same table as one of the deans, who asked if I had any recommendations for improving the program. I said that they should require students to take physics and he was shocked - what would that do for students??? I explained my reasoning and he understood what I was getting at. But I don’t believe they ever acted on my suggestion.

> "How to program" isn't something the academy understands, so they generally can't teach it

This was my (limited) experience with (introductory) formal CS.

Which is sort of amazing to me as art schools seem in broad agreement that “how to draw” can be taught, albeit in many different ways.

There isn't a single fine arts program in the world that will teach you how to draw lines on a piece of paper. If that isn't something you have figured out how to do in the first 18 years of your life, you probably shouldn't be pursuing it at university.

> [Younger profs] think they can teach every student. Very few (none?) of the older ones.

I buy that argument, but I would ask: if they can only teach some of the students, then are they teaching the right ones? Bess's example in the article suggests the answer is "no".

It is easy to "teach" only the students who don't need to be taught, and pat yourself on the back for your success. The students who sink are a mixture of people who are going to sink no matter what, and people who are only sinking because the teacher isn't giving them what they need. The students who swim are a mixture of people who have the right background to take advantage of what is being taught, and people who already know enough to not need to be taught (either by knowing the material already, or by being far enough along to pick it up along the way when working on the next step).

It sounds like professors today only care about swimmers, not sinkers. They would produce more value by ignoring some of the swimmers and paying attention to some of the sinkers. (Not saying this is possible within the current system, just that it would be better.) If your goal is to fill up a bucket, you will fail if either the bucket has a hole in it, or if it's already full.

> Universities are supposed to teach academic skills

The passive voice does a lot of rhetorical heavy lifting in this sentence. Who supposes that?

The people who control the syllabus? The research staff? Adminsitrators?

Take your pick. Universities teaching academic skills is not some novel innovation, these are traditions that have been ongoing for centuries. If they were interested in practical skills, entire departments would be removed immediately.