[derefr]

> CS degrees are for people who want to solve problems that are actually hard and new.

No; not any more than theoretical-physics degrees are for people who want to solve "hard and new" automotive-engineering or pharmacology problems. That there exist lessons from a given academic discipline that have practical application within a given profession, does not mean that you need to become an academic of that discipline (i.e. someone who can advance the state of the art in that discipline — which is what "getting a degree in X" means, if you're doing it right) in order to become a professional in said profession; or even to advance the state of the art of the profession (rather than of the associated academic discipline.)

In schools for professional (rather than academic) disciplines — e.g. medical schools, law schools, trade schools, etc. — the lessons from academia with relevant practical application to your field are taught together with the more practical material. For example, in learning to be an optometrist, you learn optics. That's physics! But it's only a certain part of physics, and it's presented through the lens (heh) of the problem domain that you care about.

Coding boot camps are shit, I'll agree. Software Engineering programs aren't. I'll take a professional Software Engineer over an academic Computer Scientist any day — especially to have on my team when working on entirely-novel problems. The professional has been taught the problem space, whereas the academic only knows the solution space. It's a lot easier to have a professional read a few books and papers to learn about the solution-space relevant to solving their problem; than it is to fix an academic's lack of appreciation of the constraints imposed by the problem being solved.

[barry-cotter]

> In schools for professional (rather than academic) disciplines — e.g. medical schools, law schools, trade schools, etc. — the lessons from academia with relevant practical application to your field are taught together with the more practical material.

Teachers mostly don’t think their education degree made them better teachers and there’s no evidence they do[1]. It’s widely agreed that at least the third year of USAn law school is useless[2] and there are testing providers whose entire thing is teaching graduates what their law school didn’t but should have if it was professional training [3].

Professional schools are run for the benefit of the staff, so they teach what the admins and teachers want to teach. It has to have some relationship to the field but it can be completely attenuated. People learn to do their job at work, not on a university campus.

[1] It's easier to pick a good teacher than to train one: Familiar and new results on the correlates of teacher effectiveness

https://www.science-direct.com/science/article/abs/pii/S0272...

[2] https://www.businessinsider.com/third-year-of-law-school-is-...

https://forgottenattorney.wordpress.com/2013/02/01/the-usele...

[3] https://abovethelaw.com/2017/05/teaching-you-what-law-school...

[derefr]

Education is IMHO uniquely problematic / a bad example of a professional discipline, because nobody knows what works. Academia is horrible at running RCTs on education methods; and industry is horrible at incentivizing good teaching (i.e. ineffective teachers, whether in kindergarten or college, never get fired just for being ineffective.) Our current "theory of education" is probably just 1000 P-hacked studies in a trenchcoat.

It's likely pretty easy to measure that lawyers from professional law schools win more cases than self-taught lawyers. Or that doctors from medical schools have higher patient satisfaction / produce higher average QALYs in their patient cohort than self-taught doctors.

I think a more closely analogous question to the one of CS vs SWEng might be: if a group of psychiatrists (professionals) and psychologists (academics) switch places, who performs better in the other context?

[seanmcdirmid]

> if a group of psychiatrists (professionals) and psychologists (academics) switch places, who performs better in the other context?

The psychiatrist is an MD who can prescribe drugs. The psychologist wouldn’t have that kind of authority, so they can’t do the job of the former. A psychologist can actually do therapy, which a psychiatrist isn’t trained for. These are very different professions.

[barry-cotter]

Psychiatrists in the US overwhelmingly have to be trained in psychodynamic therapy, aka Freudianism. The only thing we know for certain works in therapy and that has worked consistently is the client and counselor having a good relationship.

> Conclusions and Recommendations of the Interdivisional (APA Divisions 12 & 29) Task Force on Evidence-Based Therapy Relationships

http://societyforpsychotherapy.org/evidence-based-therapy-re...

> The therapy relationship makes substantial and consistent contributions to psychotherapy outcome independent of the specific type of treatment.

> The therapy relationship accounts for why clients improve (or fail to improve) at least as much as the particular treatment method.

[sdenton4]

omg, my least favorite thing in the education literature:

Prof does a 'study' where they teach a class with both hands vs with one hand tied behind his back. Each class has 200 students, and he finds that the one-handed class outperforms the two handed class with p=0.045 with N=200...

And I'm like NO! This is basically an N=1 study because the teacher is common across both classes. Have you never heard of pen-effects?!?!?!

Unfortunately, fixing the problem in the study design means convincing a bunch of your friends that one-handed teaching might be better and engaging in an experimental study together... But that's obviously way too hard.

[_zywo]

Slightly OT, but if you want an official word for "USAn", you can try using "usonian".

[Aeolos]

> I'll take a professional Software Engineer over an academic Computer Scientist any day — especially to have on my team when working on entirely-novel problems.

Fully, 100%, whole-heartedly agreed!

I'm leading a multi-disciplinary machine learning R&D team comprising multiple experienced Computer Scientists, Software Engineers and one Electrical Engineer who jumped from EE to SWE to ML research.

All of them are efficient in their own way, but the EE blows everyone else out of the water in sheer _effectiveness_. He may not be the strongest programmer, but his solutions have an elegant simplicity, take the right trade-offs and solve the damn problem.

The CS members are exact opposite: they care about the solution more than the problem, leading to hard-to-maintain / partial / sometimes outright wrong approaches. If they don't find the problem mentally stimulating, they redefine it to make it so, and then solve that problem instead.

Problem: display one point in an image

EE/SWE solution: calculate the xy pixel location and pass it to the renderer

CS solution: define a novel normalized coordinate space, so (0,0) and (1,0) are two specific locations in the image (not center, not corner, but two content-sensitive locations); for every image in the database, calculate a 4x4 "normalization" matrix to map pixel coordinates to normalized coordinates; now calculate a 4x4 "location" matrix with the location of the object in this normalized space; problem solved.

Note how this not only fails to solve the original problem, but it also creates multiple new ones.

Our team then had to point out that all of our user data, generated data, rendering code, user interface, user manual are standardized in pixel coordinates (_industry_ standard, with strict regulations), and that no, defining a new coordinate space, migrating terrabytes of data, and convincing the industry to switch over is not going to happen.

So yes, give me an EE/SWE problem-solver over a CS academic any day of the week!

[hedora]

The problem space changes every few years, though. What does the career progression of these "professional Software Engineers" with no understanding of the solution space look like? Do you just fire them each time the problem space changes?

What about tech debt? Are they writing shovelware or something? Over time, as requirements drift, how do they even know their stuff is way off of being a reasonable solution?

[kortilla]

> Over time, as requirements drift, how do they even know their stuff is way off of being a reasonable solution?

CS doesn’t even start to scratch the surface of reasonable solutions though. CS programs don’t teach you anything about architecture, technical debt, testing, source control, bug tracking, etc.

[feoren]

> CS programs don’t teach you anything about architecture, technical debt, testing, source control, bug tracking, etc.

Bug tracking you can learn in a day. It's more about which tool your company is using than anything fundamentally difficult to understand.

Source control you can learn in three days, and I was (briefly) introduced to git in my CS degree. How source control systems work under the hood with diffs, Levenshtein distance, etc. -- that's the kind of thing CS covers. A CS major understands source control way better than someone who's just been using it for a while.

Testing is more of a habit or practice than a subject to learn about. And you absolutely learn to test your own code if you don't want to fail your assignments, because the professor sure is going to test it.

"Technical debt" is a communication term that was invented to help business people correct misconceptions about how software engineering works. If you mean they don't learn how to make maintainable software, I agree that's not a focus. Maybe it should be. But of course nobody in the industry seems very good at that either.

"Architecture" is a tremendously vague term. Are you talking about large-scale, multi-system architecture? The MVC architecture? A web tech stack? Most of those things are either just putting together things you already know, or a subject that you can learn about in a CS degree if you want.

[kortilla]

> Bug tracking you can learn in a day.

No you can’t. You can learn how to use a specific bug tracking tool in a day. That’s not related to learning how to write/use/organize/prioritize bugs.

This is something that all of my junior engineers sucked at at Google and it took months of prodding to get them to write useful bugs and years before understanding how to prioritize bugs.

> Source control you can learn in three days, and I was (briefly) introduced to git in my CS degree. How source control systems work under the hood with diffs, Levenshtein distance, etc. -- that's the kind of thing CS covers. A CS major understands source control way better than someone who's just been using it for a while.

This is completely wrong. Knowing how a diff is generated is completely useless when learning how to use git, perforce, whatever. 99% of learning source control is about the concepts of that particular tool and how to manipulate them (e.g. branching, rebasing, squashing, merging, cherry-picking, etc).

> Testing is more of a habit or practice than a subject to learn about. And you absolutely learn to test your own code if you don't want to fail your assignments, because the professor sure is going to test it.

This is what someone who knows nothing about testing thinks testing is. Running code before you submit it is a specific type of test, and it’s a pretty bad one. Making code testable involves architecting your code in specific ways and knowing when to use fakes, mocks, functional tests, unit tests, fuzz tests, performance regression tests, etc.

To claim it’s just a habit or practice you follow just right before you submit is a joke. This is one of the hardest thing to train new grads on when they join a company. Part of it is they have notions like yours implanted by completely out of touch CS professors and grad students.

>Technical debt" is a communication term that was invented to help business people correct misconceptions about how software engineering works.

CS doesn’t teach people how software engineering works either. That’s the point.

> Most of those things are either just putting together things you already know, or a subject that you can learn about in a CS degree if you want.

No, you cannot reasonably learn about these things in a CS degree because they are completely uninteresting from a CS academic perspective so the professors don’t care about it. A professor who teaches you about the lambda calculus is just as qualified to teach you about making a maintainable and scalable service as the professor who taught you newtons calculus.

The whole point is that CS only has a small intersection with writing software at the leading tech companies and an even smaller intersection with writing software at normal businesses. It’s useful for distinguishing between new grads but it’s garbage compared to industry experience.

I say this as someone who got a phd on the CS side and then went to Google. They are just completely different universes.

[derefr]

I think you've misunderstood the terms I used.

By "problem domain" I mean the things that impose constraints — for a structural engineer, that'd be e.g. building materials, soil, weather, etc. The things that have tolerances.

By "solution domain" I mean the space of human ingenuity that we can apply in our designs, in order to make something possible that wouldn't be possible with a naive approach. For a structural engineer, that's things like "suspension-bridge cabling" (more general principle: tensegrity) and, I dunno, "flying buttresses."

The problem domain of building software — the parts that impose constraints — are things like what factors lead to robustness (or lack thereof) of a language runtime under production load; programming-language error-rate as a function of language-syntax UX design; evidence-driven software project scope analysis; the trade-offs involved in attempting to scale a process horizontally vs. vertically; the effects of state on ability to scale; etc.

Someone who understands these things knows how to engineer software, the same as someone who understands material tolerances knows how to engineer a structure. If they only know that, then they can't draw you a building (that'd be an architect) — but they can take that architect's blueprint, and tell you whether the building described by it will fall over, and whether there's any simple thing you can do to solve that, or whether you need to draw a different building.

But note that you learn the solution space naturally, over time, as you're exposed to the solutions people use in the field. A machinist will learn the tools of their trade as they run into them in the shop, and as other machinists demonstrate them, and as books refer to them, and as job-lots demand them. None of this requires academic rigor. It's just learning on your feet.

A SWEng might not be aware of the academic result proving some more-optimal data structure exists for something. Just like a machinist might not be aware of a not-yet-commercialized maser CNC lathe. But they don't need to be, either. Very rarely does solving novel problems require novel tools. You can build the part you want to build with the machines you already have in your shop, and maybe one new one you buy off eBay. You can write the code you want to write with your not-so-optimal data structures, and maybe one new one you find in an ecosystem library.

Every once in a while, getting things done might require you read a journal paper written by an academic. But let's be very clear: it doesn't take a degree in some field, to be able to read — and make use of! — journal papers from that field. We've got educational vloggers — people who perform on camera for a living — operationalizing stuff they saw in journal papers all the time! If they can do it, a professional in an adjacent field to the academic discipline can certainly do it.