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