5 ms·

This article has, as an analogy, a premise similar to: "Materials science graduates make rubbish bricklayers." Computer science is not software engineering, ju

This article has, as an analogy, a premise similar to: "Materials science graduates make rubbish bricklayers." Computer science is not software engineering, just like materials science is not structural engineering, and neither of those is that closely related to building a bridge or a building. Most of what we call "software engineering" is actually closer to what an engineer would call a "technician" in any other practical field. I've met many, many "computer science" graduates who are barely aware of the "science" element of what the field contains. This isn't helped at all by those of us in the field (and our academics who teach us) happily mixing up the terms "computer science", "software engineering" and "programming". Scientists expand the range of human thought in the field by discovering new truths, such as algorithms, design patterns, and conceptual relationships. Engineers turn these truths into techniques and building blocks/frameworks, and maybe designed solutions. Technicians take the building blocks and techniques and make artefacts, hopefully using best practices. We're suffering from the fact that our field is less than a century old, in real terms, and neither the terms for these things, nor indeed the techniques and literature, have become concrete.

jameshart 11y ago
I also imagine that fresh civil engineering graduates also make pretty rubbish bridge designers. They still need a few years working in the industry to understand how actual bridge construction projects work in the real world. It seems unlikely that a couple of fresh Civil Engineering graduates from a hot school could set up a startup to disrupt the bridge-building industry and expect to successfully bid on major civil works projects.
infogulch 11y ago
You're unlikely to find a scientist or structural engineer that designs a bridge physically putting it together, but the best or only implementation of an algorithm is often made by its' inventor. The line that separates technicians from designers and scientists is much blurrier in computer science etc. than most other fields.
- ArekDymalski 11y ago
  > The line that separates technicians from designers and scientists is much blurrier in computer science etc. than most other fields. I think that the GP provided a reasonable explanation for this situation by saying that the "field is less than a century old". If you go back in time you are more likely to find one person inventing a new brick, designing a house with it and then building it. But later when the body of knowledge was too big for one person, specialization started (the same happened in medicine and many other fields). And actually it is already happening in the IT area. Just several years ago it wasn't uncommon that a game or any other non-trivial piece of software was created (including some clever "inventions") and marketed by one person.
PhasmaFelis 11y ago
> This article has, as an analogy, a premise similar to: "Materials science graduates make rubbish bricklayers." Computer science is not software engineering, just like materials science is not structural engineering, and neither of those is that closely related to building a bridge or a building. Most of what we call "software engineering" is actually closer to what an engineer would call a "technician" in any other practical field. There's a lot of people in this thread saying the same thing. You're not wrong in the abstract, but in saying "haha, this article doesn't understand computer science" you're missing the hugely important point that most universities also don't understand computer science, or else knowingly lie about it to increase enrollment. If a starry-eyed high school kid shows up for a campus tour and says "I've always wanted to be a bricklayer," nobody is ever going to tell him "Oh, we have a wonderful materials science program that you'll just love"; but that was exactly the experience that I had with CS, along with many millions of other would-be programmers.
- jeremysmyth 11y ago
  you're missing the hugely important point that most universities also don't understand computer science, or else knowingly lie about it to increase enrollment Not at all. It's pretty central to my point that both we in the industry and the academics who teach us are mixing up the terms and not paying heed to the "science" in "computer science" (and I said as much in the comment). I agree that the starry-eyed kid who wants to write apps and games would likely be turned away if he was faced with actual computer science instead of what is sold as such: If you showed him TAoCP and said "This is an example of broad-based computer science", he'd get blurry-eyed instead, because there is no visible relationship between one end of that desire and the other. But that might not be a bad thing if we get our stuff together and fix our expectations and our terminology: An 11 year old tinkering with electronics in her bedroom, or mixing up colours and smelly stuff with her "my first chemistry set", or dragging her family fossil hunting in the hills is not doing "science", but she knows that "science" is that way, and at the end of a degree course in science--assuming she doesn't stay in academia--she gets a job as a lab technician, not a scientist; much of that role might actually involve sitting in front of a computer processing statistics and analytics anyway, rather than mixing up fun stuff in a test tube (which, after all, is what she was originally passionate about). The technician stuff is not what she wanted when she was 11, but it's still a part of the journey, and the science education is what sets her up for later participation in chemical engineering work or even some actual science (if she's very driven or fortunate).
kazinator 11y ago
Computer science is also not hardware engineering. A computer science student has no idea how to get trains to report their position, because that requires hardware. For example, sensors laid along the track at reasonably closely spaced intervals which read an RFID transponder carried by the train, and send a message to some concentrator which forwards it to a data centre. It's okay not to have all the answers; transit systems are not a one person job. A good answer to the question is "I don't really know the specific technology for sensing the positions of trains. If the sensing is used to make automatic driving decisions, it is of crucial importance that it be accurate and reliable, for safety reasons. If trains are automatic, then the system must not only know their positions, but the trains must know that the system knows their position; if a train's computer loses touch with the system, it must come to an emergency stop. A rogue train whose position isn't known must not continue moving, for obvious reasons. I think I would survey how all this has been successfully done in existing transit infrastructures around the world and borrow the best elements from the existing designs".

jameshart 11y ago

I also imagine that fresh civil engineering graduates also make pretty rubbish bridge designers. They still need a few years working in the industry to understand how actual bridge construction projects work in the real world. It seems unlikely that a couple of fresh Civil Engineering graduates from a hot school could set up a startup to disrupt the bridge-building industry and expect to successfully bid on major civil works projects.

infogulch 11y ago

You're unlikely to find a scientist or structural engineer that designs a bridge physically putting it together, but the best or only implementation of an algorithm is often made by its' inventor. The line that separates technicians from designers and scientists is much blurrier in computer science etc. than most other fields.

ArekDymalski 11y ago
> The line that separates technicians from designers and scientists is much blurrier in computer science etc. than most other fields. I think that the GP provided a reasonable explanation for this situation by saying that the "field is less than a century old". If you go back in time you are more likely to find one person inventing a new brick, designing a house with it and then building it. But later when the body of knowledge was too big for one person, specialization started (the same happened in medicine and many other fields). And actually it is already happening in the IT area. Just several years ago it wasn't uncommon that a game or any other non-trivial piece of software was created (including some clever "inventions") and marketed by one person.

PhasmaFelis 11y ago

> This article has, as an analogy, a premise similar to: "Materials science graduates make rubbish bricklayers." Computer science is not software engineering, just like materials science is not structural engineering, and neither of those is that closely related to building a bridge or a building. Most of what we call "software engineering" is actually closer to what an engineer would call a "technician" in any other practical field. There's a lot of people in this thread saying the same thing. You're not wrong in the abstract, but in saying "haha, this article doesn't understand computer science" you're missing the hugely important point that most universities also don't understand computer science, or else knowingly lie about it to increase enrollment. If a starry-eyed high school kid shows up for a campus tour and says "I've always wanted to be a bricklayer," nobody is ever going to tell him "Oh, we have a wonderful materials science program that you'll just love"; but that was exactly the experience that I had with CS, along with many millions of other would-be programmers.

jeremysmyth 11y ago
you're missing the hugely important point that most universities also don't understand computer science, or else knowingly lie about it to increase enrollment Not at all. It's pretty central to my point that both we in the industry and the academics who teach us are mixing up the terms and not paying heed to the "science" in "computer science" (and I said as much in the comment). I agree that the starry-eyed kid who wants to write apps and games would likely be turned away if he was faced with actual computer science instead of what is sold as such: If you showed him TAoCP and said "This is an example of broad-based computer science", he'd get blurry-eyed instead, because there is no visible relationship between one end of that desire and the other. But that might not be a bad thing if we get our stuff together and fix our expectations and our terminology: An 11 year old tinkering with electronics in her bedroom, or mixing up colours and smelly stuff with her "my first chemistry set", or dragging her family fossil hunting in the hills is not doing "science", but she knows that "science" is that way, and at the end of a degree course in science--assuming she doesn't stay in academia--she gets a job as a lab technician, not a scientist; much of that role might actually involve sitting in front of a computer processing statistics and analytics anyway, rather than mixing up fun stuff in a test tube (which, after all, is what she was originally passionate about). The technician stuff is not what she wanted when she was 11, but it's still a part of the journey, and the science education is what sets her up for later participation in chemical engineering work or even some actual science (if she's very driven or fortunate).

kazinator 11y ago

Computer science is also not hardware engineering. A computer science student has no idea how to get trains to report their position, because that requires hardware. For example, sensors laid along the track at reasonably closely spaced intervals which read an RFID transponder carried by the train, and send a message to some concentrator which forwards it to a data centre. It's okay not to have all the answers; transit systems are not a one person job. A good answer to the question is "I don't really know the specific technology for sensing the positions of trains. If the sensing is used to make automatic driving decisions, it is of crucial importance that it be accurate and reliable, for safety reasons. If trains are automatic, then the system must not only know their positions, but the trains must know that the system knows their position; if a train's computer loses touch with the system, it must come to an emergency stop. A rogue train whose position isn't known must not continue moving, for obvious reasons. I think I would survey how all this has been successfully done in existing transit infrastructures around the world and borrow the best elements from the existing designs".