4 ms·

I think you are trying to make some good points, but your language could have been clearer. If I'm understanding correctly you mean: 1. Treat Computer Science

I think you are trying to make some good points, but your language could have been clearer. If I'm understanding correctly you mean: 1. Treat Computer Science (CS) as a specific field, and don't dilute the curriculum with related items. 2. Introduce a course that covers these broader, non-CS items, and actually push it out beyond the audience of CS? Did I get that right? I think you might have meant the term "informatics" (https://en.wikipedia.org/wiki/Informatics https://en.wikipedia.org/wiki/Informatics). Depending on your position CS is either subordinate, equal, or above informatics. I have a degree from a UK university and there is a much wider spectrum degree types in this field than exist here in the US where I now live. I'm conflicted on the original post that elicited your response. I have that background where I inherited a broken PC, a bunch of floppy disks, and some manuals. In some ways this gives me an advantage, especially given that I'm comfortable being dropped into a messy project or some problem that is debugged. I've seen lots of folks who can't handle this, but can churn out code on to need more support around the edges. I now see more and more folks attempting things like devops and at least being able to learn some of these skills later on. I think where it stands me in better stead is problem avoidance, but even that is subjective.

mattmanser 9y ago
Better to stop trying to create programmers by teaching them a theoretical discipline like CS and to teach them software engineering instead?
- eropple 9y ago
  Frankly, I think we would need to know what software engineering looks like, outside of the spaces where engineers (like, ones with PEs) more than developers own the project, before we start teaching it to novices. I mean, I've been getting paid for this for going on fifteen years now and I'm not an engineer. I try to build resilient, reliable systems, I try to test heavily and comprehensively...but I'm not an engineer, and most of the time I'm worried when somebody calls themselves one. What "software engineering" is, in the context of a web app or a point of sale system, rather hard to define. Worth taking a crack at. But we shouldn't put the cart before the horse.
  - arbie 9y ago
    Completely agree. The mantle of _engineer_ is not passed on simply via a job title. Responsible engineers (i.e., those that I aspire to emulate) seem to spend non-trivial amounts of time predicting and avoiding potential-negative outcomes. They also seem to have a near-total understanding of the processes that impact these outcomes. If only I could figure out how they _know so darned much_ about everything ...
    - KMag 9y ago
      > If only I could figure out how they _know so darned much_ about everything ... As someone with a degree in Mechanical Engineering, I'd say that your observation is mostly due to (1) several hundred years' worth of head start (2) the field not shifting under them (much) over their careers (3) intuition from interacting with the real world being applicable and (4) you're also unaware of the crazy amount of accumulated computer knowledge you have. Now, due to the changing nature of software development, a lot of that accumulated knowledge is useless, but it wouldn't be useless in a more mature field. Imagine if all of the random arcania I've had to pick up from AppleSoft BASIC, Pascal, Perl 5, Tcl, ANSI C , etc. were directly applicable in my day job using C++, Scala, and Java. Sure, there's some overlap, particularly from ANSI C to C++, but with Mechanical Engineering the basic tool kit changes much more slowly. I learned about common steel and Aluminum alloys, polyethylene, ABS... advantages and disadvantages of each, things to watch out for. If a Mechanical Engineer really gets to know 1040 vs 1045 vs. 4130 steel alloys, that's knowledge that's going to pay dividends for the rest of her career. It's not like 10 years ago or 10 years in the future there was/will be a massive shift away from Aluminum and steel and the majority of engineers had/have to throw out most of what they knew/know about metals and learn how to design for Nickel and Titanium alloys. 3D printing brings something new, and heat treatment and machining techniques have improved, but even 3D printed metal parts aren't fundamentally different from the powdered metallurgy that my dad's cousin was researching in the 1940s. You're also accumulating a ton of arcane knowledge, it's just that most of it has a relatively short useful life. There's also survivor bias. The engineers that were promoted and kept through economic downturns tended to be the ones that were really interested in their field and readily soaked it in.

mattmanser 9y ago

Better to stop trying to create programmers by teaching them a theoretical discipline like CS and to teach them software engineering instead?

eropple 9y ago
Frankly, I think we would need to know what software engineering looks like, outside of the spaces where engineers (like, ones with PEs) more than developers own the project, before we start teaching it to novices. I mean, I've been getting paid for this for going on fifteen years now and I'm not an engineer. I try to build resilient, reliable systems, I try to test heavily and comprehensively...but I'm not an engineer, and most of the time I'm worried when somebody calls themselves one. What "software engineering" is, in the context of a web app or a point of sale system, rather hard to define. Worth taking a crack at. But we shouldn't put the cart before the horse.
- arbie 9y ago
  Completely agree. The mantle of _engineer_ is not passed on simply via a job title. Responsible engineers (i.e., those that I aspire to emulate) seem to spend non-trivial amounts of time predicting and avoiding potential-negative outcomes. They also seem to have a near-total understanding of the processes that impact these outcomes. If only I could figure out how they _know so darned much_ about everything ...
  - KMag 9y ago
    > If only I could figure out how they _know so darned much_ about everything ... As someone with a degree in Mechanical Engineering, I'd say that your observation is mostly due to (1) several hundred years' worth of head start (2) the field not shifting under them (much) over their careers (3) intuition from interacting with the real world being applicable and (4) you're also unaware of the crazy amount of accumulated computer knowledge you have. Now, due to the changing nature of software development, a lot of that accumulated knowledge is useless, but it wouldn't be useless in a more mature field. Imagine if all of the random arcania I've had to pick up from AppleSoft BASIC, Pascal, Perl 5, Tcl, ANSI C , etc. were directly applicable in my day job using C++, Scala, and Java. Sure, there's some overlap, particularly from ANSI C to C++, but with Mechanical Engineering the basic tool kit changes much more slowly. I learned about common steel and Aluminum alloys, polyethylene, ABS... advantages and disadvantages of each, things to watch out for. If a Mechanical Engineer really gets to know 1040 vs 1045 vs. 4130 steel alloys, that's knowledge that's going to pay dividends for the rest of her career. It's not like 10 years ago or 10 years in the future there was/will be a massive shift away from Aluminum and steel and the majority of engineers had/have to throw out most of what they knew/know about metals and learn how to design for Nickel and Titanium alloys. 3D printing brings something new, and heat treatment and machining techniques have improved, but even 3D printed metal parts aren't fundamentally different from the powdered metallurgy that my dad's cousin was researching in the 1940s. You're also accumulating a ton of arcane knowledge, it's just that most of it has a relatively short useful life. There's also survivor bias. The engineers that were promoted and kept through economic downturns tended to be the ones that were really interested in their field and readily soaked it in.