Are computer scientists really programmers?

[keyboard_me]

If you reason with science, technology and Engineering, you will understand that science deals with the study to understand whereas technology devices ways to use those theories and observable techniques, and then with the blueprint set, the engineer builds on the technologist's ideas/technology. Now to the issue at hand, Computer science obviously deals with the study of how computers operate and trying to device theories and techniques to make them faster. with the theories in place the technology can be derived and built upon. now computer scientists in their quest of studying programs- write computer instructions(Programs) and device ways of computing data; they might even build faster and modern computer hardwares which are prototypes based on their findings in research. with these arguments drawn and proven with logic, i'd say the computer scientist is a programmer and engineer of modern techniques with Information and communication Technologists(IT professionals) and Software engineers being programmers as well. Each programs to carry out their ideas.

[Momerath]

Computer science obviously deals with the study of how computers operate and trying to device theories and techniques to make them faster.

I have to disagree with you here. EEs and CEs do the hardware, CS does algorithms and software.

[mike_2000_17]

That's an interesting question. I would tend to disagree with your assessment.

Let me just rebut some of your specific statements:

If you reason with science, technology and Engineering, you will understand that science deals with the study to understand whereas technology devices ways to use those theories and observable techniques, and then with the blueprint set, the engineer builds on the technologist's ideas/technology.

As an engineer, your categorizations sound very odd to me. I think that what you call "technology" is actually "engineering", and what you call "engineering" is actually what a technician does. Here is a bit of standard terminology.

Fundamental science is the pursuit of knowledge for knowledge's sake, e.g., think of the theory of relativity (by Einstein). Applied science is the pursuit of knowledge towards some foreseeable application, e.g., think of the photoelectric effect (also by Einstein). That's not to say that fundamental science discoveries don't have applications, but only that the applications are not the primary focus of the research. And of course, actual scientists can be anywhere between those two extremes.

Engineering is the pursuit of concrete technologies and designs by applying scientific knowledge. It basically picks up where the applied scientists leave it. For example, creating image capture sensors (CCD or CMOS) by applying the photoelectric effect. There are three main kinds of engineering work. Engineering research (or eng. science) is about going back to study the scientifical principles in order to gain a more detailed understanding (i.e., fill in the gaps left by scientists) in order to improve the applicability, for example, figuring out that extreme cooling of the image sensors and their electronics can significantly improve the image quality. Then, there is development work, which is essentially about building upon and improving existing designs, like being able to fit a 20 megapixel camera inside a smart-phone. And then, there is the more technical work, which is a bit more mundane, that a lot of engineers do, e.g., maintenance, monitoring of systems, etc..

Your term of "technologist" doesn't really exist, as far as I know, except maybe in the area of philosophy, i.e., philosophy of science and technology, trying to predict future technology development and their impact, etc.. The standard term for what you seem to have in mind is "engineer" or "R & D engineer".

Computer science obviously deals with the study of how computers operate and trying to device theories and techniques to make them faster.

Like Momerath, I have to disagree with that. Computer science does not really study how computers operate or trying to create faster ones. That's called "computer engineering", and part "electrical engineering". There are some computer scientists that work on new theoretical models for computers, e.g., von Neumann architecture, Turing machines, Harvard architecture, and so on. But if there is ever a good theoretical model coming out of computer science, it will be picked up by computer engineers to make it into something real and that works.

Now computer scientists in their quest of studying programs- write [programs and algorithms]; they might even build faster and modern computer hardware which are prototypes based on their findings in research. With these arguments drawn and proven from logic, I'd say the computer scientist is a programmer and engineer of modern techniques [in IT] and Software engineers are programmers as well. They each program to carry out their ideas.

That's where I disagree the most.

First of all, the idea that computer scientists would build faster and modern computer hardware prototypes is a bit ludicrous, like it was already said, that's the realm of computer engineering. So, that's out of the question.

Now, to the main argument, which is that because computer scientists have to write programs and algorithms as part of their research work, they should be considered as programmers and engineers of modern techniques in IT. I think that this is indeed the de facto assumption, and the idea that many people (maybe naively) have about this. I beg to differ.

As a first little hint, in my experience, the best programmers that I've encountered were almost all engineers by profession and training (of various kinds, mech., elec., or comp.). And many computer scientists that I've encountered were really terrible programmers. That's not an argument, just my experience.

A parallel can be drawn with scientists of other fields. For example, an experimental physicist will have to get his hands dirty and design and build experimental testbeds to carry out his work. Does that mean that all experimental physicists should also be considered as being mechanical engineers? No. Not even close. And I know because a friend of mine used to do mechanical engineering work to assist experimental physicists in building those rigs, and one thing very clear came out of that experience for him: physicists are no engineers. I've encountered a few physicists myself, and as much as I respect their field of work, there is nothing worse than a physicist who thinks he's an engineer. This is a common occurrence, i.e., scientists who mistake their amateurish practical skills for the professional experience and training of an engineer. And as an engineer, when you encounter those scientists, it's an extremely annoying and aggrevating experience.

My point is, computer scientists, like other scientists, do have to "get their hands dirty" and actually write programs and software. But that does not make them professional programmers or software developers, far from it, because these things require a whole different set of professional experience and training that computer scientists never really get (or barely scratch the surface of).

Another analogy that I like to draw on is the analogy between "biologist vs. medical doctor" and "computer scientist vs. programmer". The skillsets required for each discipline are about as different from each other in both cases. A biologist and a medical doctor obviously share a lot of common knowledge. A medical doctor has to know enough biology to be able to make informed decisions and diagnostics, and to understand what's happening in his patient's body. If I was in a post-apocalyptic world and in need of a doctor, finding a biologist would certainly be much better than the average Joe, but not nearly as good as an actual doctor. Furthermore, the job of a doctor is, for the most part, about making quick and educated diagnostics of the problem (illness) and apply standard solutions (remedies) that have proven effective, and to develop the skills to carry out that problem-solving work effectively on a daily basis. Part of this is having good understanding of the biology, but it's only one part of it, there is a lot more practical knowledge needed and developing certain intuitions, and so on. We need biologists to find cures for cancer or other illnesses, just like we need doctors to treat patients, but those two professions are clearly not the same. I would generally say that the distinction between computer scientists and programmers is about the same, and it's a big mistake to confuse the two.

The real problem right now is that a lot of people think as you do, i.e., "study computer science and you will become a programmer". Even college degrees are structured with that weird and confused concept of the hybrid computer scientist-programmer. This is reminiscent of the pre-scientific days when there was no real distinction between scientists and engineers (they were called "natural philosophers"), or between a biologist and a medical doctor. I think that a separation has to occur sooner rather than later, and it has already started to some extent with the "software engineering" field, although that field is having trouble departing from traditional computer science, IMHO.

[jwenting]

In any real world (rather than acedemic) environment, people tend to do whatever needs doing and not insist on "that's not part of my job description as per paragraph 325423.542435423 section a2".

Now, not every CS grad will be a programmer, just as not every programmer will be a CS grad. But a lot of them do end up as programmers.

[Schol-R-LEA]

I have long argued that 'Computer Science' is a poor term for what most people study in college, as it generally has very little to with science in even the broadest sense. Most CS classes are either the sort of hybrid curriculum Mike mentions, or else (more often than not) a pure trade-oriented curriculum with no real theoretical content at all.

The term 'Software Engineering' isn't much better, but at least it reflect the prgamatism inherent in working software development. Software engineering as it currently exists has little to do with the rigor of modern physical engineering, however; even achitecture, the 'softest' of the engineering fields, is far and away more rigorous. Software engineering may exist someday, but it is generations - human generations - away from being realized. We are at the mud hut level of software architecture; the Pyramids are at least a lifetime off, and Roman aqueducts and Gothic cathedrals far beyond the horizon, never mind skyscrapers and hydroelectric dams.

I have long advocated a separation of 'computer science' into distinct fields of study, with the main field, Software Management, falling under the rubric of the Psychology or Sociology departments rather than either Engineering or (especially) Mathematics. Why? Because the real fundamental work in software development is social interactions, and the main thing being 'engineered' are the programmers' understand of the clients' needs. Practical IT is more about social psychology and cognitive science (perception of need vs. actual need) than about coding.

The Second field would be Algorithmics and Data Organization, which is 'computer science' proper and would fall under Mathematics. This is where the theory the res of the field needs is developed. One would expect that working programmers would have some exposure to this, just as a working mechanical engineer must know so calculus to do their jobs, but would not get into the depths of the field.

The third, and predominant, field would be Program Development. This would be a trade course rather than a university curriculum, and end with an multi-year apprenticeship and a professional certifcation - a real, serious one, not the junk certificates put out by companies to flog their own products or services.

I am quite specific about this last part: working programmers should be licensed and bonded, and be under regular review for the quality of their work. The field needs, absolutely needs, some kind of professional standards if it is to hold professional standing. Business needs be damned - poor code costs a lot more than no code at all, and it is time the industry faces up to that fact. Bad code kills - not often, but it does; a poorly-written hardware controller is as deadly as a poorly-designed bridge. Even software that seems inoculous can have severe repercussions when it works badly. Things have been moving too fast up until now for this sort of oversight, but now that the field seems to be cooling down, there is some hope for it.

[mike_2000_17]

Software engineering as it currently exists has little to do with the rigor of modern physical engineering, however; even achitecture, the 'softest' of the engineering fields, is far and away more rigorous.

Amen to that!

The field needs, absolutely needs, some kind of professional standards if it is to hold professional standing.

I totally agree. I was fairly recently at a conference about guidance systems (i.e., software for drones, airplanes, rockets and spacecrafts), and 3 out of 4 keynote speakers talked exclusively about the very serious need for strict methodologies to guarantee safety and correctness of software. This is actually an insanely difficult problem, and the advances in this department are ridiculously insufficient right now.

This would be a trade course rather than a university curriculum, and end with an multi-year apprenticeship and a professional certifcation

I agree, but I'm not sure that a trade course (a.k.a. vocational curriculum) would be sufficient. If the aim is to uphold standards and methodologies similar to those in engineering fields, then it's gonna require a curriculum of a similar caliber. In most science vs. engineering fields, a science degree is 3-4 years long, while a engineering degree is 4-6 years long (and often, add a year or two of internship/junior work). Of course, given the primitive state of software engineering science as of now, it might be hard to create a comprehensive curriculum deserving of the "Engineering" label.

That said, if you just want to be a programmer (not a software engineer, assuming that had the same weight as in other engineering fields), then there are preferrable options with vocational schools (not in the U.S., which is the wild-west when it comes to vocational schools). I think far too many people enter computer science degrees when what they really want is to become a programmer, i.e., they want to write apps, not develop algorithms and data structures. The majority of programming work is technician-level work.

It's like HVAC systems (Heating Ventilation and Air Conditioning), it takes some serious engineers to develop good technology for that, but the majority of people working on HVAC systems are the technicians that install them. In software development, you need serious engineers to work on core software components (e.g., database servers), but the majority of programmers just plug together those components for their clients.

with the main field, Software Management, falling under the rubric of the Psychology or Sociology departments rather than either Engineering or (especially) Mathematics.

Hmmm... I'm having a bit of trouble picturing that. I can't see a management (and marketing) curriculum that specializes in software, technology and/or the web. I'm sure they already exist, at least in the form of elective courses and concentrations (study tracks). I can easily imagine a software equivalent to "industrial design", i.e., learning to design "good" software ("good" from a user's perspective, as in, nice, appealing, easy to use, feature-rich, etc.). But I have trouble seeing what this could have to do with psychology or sociology. And, it's my opinion that nearly all the attempts at making psychology or sociology into a rigorous discipline have failed miserably, and is now little more than blabber and conjectures.

Why? Because the real fundamental work in software development is social interactions, and the main thing being 'engineered' are the programmers' understand of the clients' needs. Practical IT is more about social psychology and cognitive science (perception of need vs. actual need) than about coding.

I agree, but you can say that of many fields, if not most. I'm all for dedicating significant attention (through several courses in the curriculum) to these issues (and my engineering curriculum certainly did include many courses on this). And, I'm all for employing people who specialize in these issues, rather than the coding (maybe, they don't even need to know anything about coding at all). In fact, I know that several very serious software development teams hire "soft scientists" (e.g., psychology, education, etc.) to handle that side of the equation. But at the end of the day, if you need programmers, you need programmers; if they are good at team-work, communication and all that, then that's all for the better, but they still need to be good programmers. There's a balance to have there. You could have a great team of very social people who communicate super well among themselves and with clients and understand their needs, but it's all gonna be a complete waste if none of them have any idea how to write code.

[rory.starkweather.7]

Odd that this should come up. My brother and I both got Bachelors degrees from the same university. His was in Computer Science, and he even went on to get a Master's degree in that field. My degree is in Engineering Mechanics, a field that probably doesn't exist anymore.

I took the mandatory FORTRAN WATFIV course, and decided that I hated programming and computers in general. (This was back in the Hollerith card days.)

Well, my brother ended up as a networking specialist for a major corporation and worked almost exclusively with hardware. I became a programmer.

[jwenting]

the main problem defining whether a piece of software is correct is the lack of a closed definition of what that piece of software is supposed to do.
More often than not (even with mission critical systems where even a cornercase failing could lead to a loss of life or massive financial or material loss) the specifications documents are not closed. They don't define what the system is to do in any well defined way, especially fault conditions and border cases (e.g. things like what do in case of a lack of input data is often not described, even if there is an expected way for the system to react to such a condition, which is then only discovered during field testing, with the software engineers being blamed rather than the people missing that when writing and accepting the specifications).

Most teams of professionals can deliver a reasonably solid piece of software, or at least know how to deliver such.
But if they get faulty specifications and/or don't get the resources required to create that product, they can't be expected (yet are expected) to do so.
E.g. a team gets told that they shouldn't write unit tests "because that takes time away from writing the actual software" (and yes, that's still an extremely common mantra coming out of managers).
Or they're not supplied with the equipment and time to do proper testing (can't count the number of times I've experienced the situation where we had to create or maintain a product that needed to run on specific hardware or interface with hardware but were not granted access to that hardware for testing purposes for example).
Result is that you end up having to make educated (and more or less wild) guesses about your runtime environment, with the inevitable consequence of things failing once it gets out into the wild.

No aerospace company would dream not giving its engineers who're designing and building components for a new missile or aircraft the means to properly test those components in flight, or fail to supply them with basic information like what environmental conditions it will be expected to work in.
Yet the equivalent data and opportunities are rarely supplied to software engineering teams.

I was literally once asked to write a system for interbank money transfers in 2 weeks time, without being handed any specifications or requirements documents, on my own, and put it life without any testing or other quality assurance (because there had been no budget set aside for that).
I refused the assignment of course. Didn't want the near certainty of ending up blamed for a failed transaction in the tens of millions of dollars.