Well, no, I would not be able to agree at all. Don't confuse the fact that we don't fully grasp math and physics with the idea that they're somehow theoretical, fluid concepts.
Gravity works. It will always work. We can't stop it from working. We just haven't fully comprehended or described how it works.
Similarly, 2+2=4. For all time, those quantities add up in that way, and it is literally impossible to get anything else out of it. You can change the names on the quantities, describe the problem differently, but the principle that addition and the quantities describe is real, has always been, and will always be.
You only described how our understanding of the laws changes and breaks down. The laws themselves are beyond our present grasp, but they're there, complete and unbreakable.
By contrast, we invented every rule of computer science. We decided to use binary for storage (granted, it was the most efficient, but there are other working systems). We wrote assembly code. We decided what instructions a CPU could process. We designed the behaviors and specifications of every single language. The rules, flaws, foibles, and factors of programming are entirely the result of one human-created design piled on top of another.
Thus, it is more akin to an art, such as music or painting, than to building a bridge.
In fact, I'd venture that you'll have a very hard time finding any Founding Fathers of Modern Programming who would equate software to engineering. By way of example, Donald Knuth, Eric Raymond, Alan Kay, Gerald Weinberg, and Fred Brooks have all made these observations before. Programming isn't a science. Trying to cram it into that box is what keeps getting us into trouble.
I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
The vast majority of computer science theory doesn't have much to do with physical computer hardware and programming. A lot of it is the study of problems and algorithms, which is much closer to math than to computers. In other words, it is a theoretical science that can be applied to real problems. That is very all similar to Math and Physics.
You are right that Programming isn't a science, but Computer Science is absolutely a science.
Confusing computer science with programming is similar to confusing math with woodworking.
Well, and I think we can agree there. The trick is, when 99% of people say "computer science," they mean "programming," and that gets really tricky, because it's wrong.
So, in general, I avoid the term "computer science", and separate things out - programming, computer engineering (a branch of engineering, definitely a science), and...whatever you call algorithmic mathematics. (Dangit, I'm two mugs of coffee shy of remembering what you call that.)
Incidentally, "computer science" was itself coined by the ACM with the intention of approaching computer programming as a science, centuries after mathematics first began studying algorithms.
But, bringing the point back around, software architect and software engineering, as well as "computer science" in the context of programming, are...definite misnomers.
I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
I covered this in the post, but software engineering is not just about programming. Software architecture is also not just about programming. Programming is part of it, but it is not the same thing.
The terms describe exactly what they describe, and that is not programming.
That's why, in my view, they are levels on a path, like belts in a martial art.
What a black belt can do and understands is not the same as what a yellow belt studies. It is not "more of the same", it is "more and different."
Many people who code can't architect systems. Many people who code also cannot engineer systems. The confusion stems from using programming and those other terms interchangeably. The entire premise of the post is to differentiate between the terms, which mean different things and describe different levels on a path.
To be honest, I hadn't caught that the first time around, but I can see now that's the point your making. And, once again, I would have to disagree. To place them in a continuum would somehow suggest that a programmer must become a "computer scientist" (algorithmic mathematician), and must become a software architect, etc etc, to progress in career.
Yet Donald Knuth, who is regarded as one of the greatest programmers and mathematicians in computer science history wasn't a "systems architect", and yet he was far more skilled in the computer industry than most systems architects ever will be. You'll find the same true of many other greats. Meanwhile, some of those greats do not have degrees in computer science, and quite a few people with CS degrees aren't half as skilled as many peers with no degrees.
So, in short, I'd say that to place these differing fields on the same continuum is missing the point; it's like saying that a sculptor is more advanced than a painter, and therefore a painter must become a sculptor to move up in career. Clearly, that is not the case - painting and sculpting are different, but they are in no way inferior or superior to one another.
But, if you were to stop short of blurring entirely different branches of study into one continuum, and focus purely on one's skill in software development, you'd be onto something.
I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
Programmer is before computer scientist, so no... a programmer does not have to be a computer scientist. At all. In the post I also talked about how many people stop at Programmer, and have fine careers. Sometimes great careers.
I knew that a 3000 words post would not be read completely by lots of people. Oh well.
Well, yes, I saw that part. The problem is, if we were to equate this to levels of marshal arts, the problem remains that Donald Knuth, Alan Kay, and many other true black-belts would get relegated to a lower level, below people they can code circles around. See my issue?
I started writing software in 1984. Over the years I worked with many languages, technologies, and tools. I have been in leadership positions since the early 2000s, and in executive roles since 2014.
You don't have to be a black belt in martial arts to kick a win a fight against a black belt. That is a fallacy. There are masters of martial arts in their 90's who don't have a chance against strong and much younger athletes. That's why the analogy works so well.
Lots of people become masters of their niche and don't need to progress past it to have an amazing career. Donald Knuth is a master computer scientist and programmer. I am not sure what is the point you are contending. You call that "true black belt," but what does that mean? In many schools of martial arts, if you don't study certain Katas and other things, it doesn't matter if you are a super strong fighter. To get a new belt you need to master certain skills.
Does he also possess the skills that I described for Software Engineers and Software Architects? If not, then in my book he is not a "black belt," even if he can run circles in programming and computer science theory around people who I define as architects.
Anyway, I think I described a model in the post and I also made it clear that I expect some people to disagree. I am happy to see that I was right on that one at least :)
Well, no, I would not be able to agree at all. Don't confuse the fact that we don't fully grasp math and physics with the idea that they're somehow theoretical, fluid concepts.
Gravity works. It will always work. We can't stop it from working. We just haven't fully comprehended or described how it works.
Similarly, 2+2=4. For all time, those quantities add up in that way, and it is literally impossible to get anything else out of it. You can change the names on the quantities, describe the problem differently, but the principle that addition and the quantities describe is real, has always been, and will always be.
You only described how our understanding of the laws changes and breaks down. The laws themselves are beyond our present grasp, but they're there, complete and unbreakable.
By contrast, we invented every rule of computer science. We decided to use binary for storage (granted, it was the most efficient, but there are other working systems). We wrote assembly code. We decided what instructions a CPU could process. We designed the behaviors and specifications of every single language. The rules, flaws, foibles, and factors of programming are entirely the result of one human-created design piled on top of another.
Thus, it is more akin to an art, such as music or painting, than to building a bridge.
In fact, I'd venture that you'll have a very hard time finding any Founding Fathers of Modern Programming who would equate software to engineering. By way of example, Donald Knuth, Eric Raymond, Alan Kay, Gerald Weinberg, and Fred Brooks have all made these observations before. Programming isn't a science. Trying to cram it into that box is what keeps getting us into trouble.
The vast majority of computer science theory doesn't have much to do with physical computer hardware and programming. A lot of it is the study of problems and algorithms, which is much closer to math than to computers. In other words, it is a theoretical science that can be applied to real problems. That is very all similar to Math and Physics.
You are right that Programming isn't a science, but Computer Science is absolutely a science.
Confusing computer science with programming is similar to confusing math with woodworking.
Well, and I think we can agree there. The trick is, when 99% of people say "computer science," they mean "programming," and that gets really tricky, because it's wrong.
So, in general, I avoid the term "computer science", and separate things out - programming, computer engineering (a branch of engineering, definitely a science), and...whatever you call algorithmic mathematics. (Dangit, I'm two mugs of coffee shy of remembering what you call that.)
Incidentally, "computer science" was itself coined by the ACM with the intention of approaching computer programming as a science, centuries after mathematics first began studying algorithms.
But, bringing the point back around, software architect and software engineering, as well as "computer science" in the context of programming, are...definite misnomers.
I covered this in the post, but software engineering is not just about programming. Software architecture is also not just about programming. Programming is part of it, but it is not the same thing.
The terms describe exactly what they describe, and that is not programming.
That's why, in my view, they are levels on a path, like belts in a martial art.
What a black belt can do and understands is not the same as what a yellow belt studies. It is not "more of the same", it is "more and different."
Many people who code can't architect systems. Many people who code also cannot engineer systems. The confusion stems from using programming and those other terms interchangeably. The entire premise of the post is to differentiate between the terms, which mean different things and describe different levels on a path.
To be honest, I hadn't caught that the first time around, but I can see now that's the point your making. And, once again, I would have to disagree. To place them in a continuum would somehow suggest that a programmer must become a "computer scientist" (algorithmic mathematician), and must become a software architect, etc etc, to progress in career.
Yet Donald Knuth, who is regarded as one of the greatest programmers and mathematicians in computer science history wasn't a "systems architect", and yet he was far more skilled in the computer industry than most systems architects ever will be. You'll find the same true of many other greats. Meanwhile, some of those greats do not have degrees in computer science, and quite a few people with CS degrees aren't half as skilled as many peers with no degrees.
So, in short, I'd say that to place these differing fields on the same continuum is missing the point; it's like saying that a sculptor is more advanced than a painter, and therefore a painter must become a sculptor to move up in career. Clearly, that is not the case - painting and sculpting are different, but they are in no way inferior or superior to one another.
But, if you were to stop short of blurring entirely different branches of study into one continuum, and focus purely on one's skill in software development, you'd be onto something.
Programmer is before computer scientist, so no... a programmer does not have to be a computer scientist. At all. In the post I also talked about how many people stop at Programmer, and have fine careers. Sometimes great careers.
I knew that a 3000 words post would not be read completely by lots of people. Oh well.
Well, yes, I saw that part. The problem is, if we were to equate this to levels of marshal arts, the problem remains that Donald Knuth, Alan Kay, and many other true black-belts would get relegated to a lower level, below people they can code circles around. See my issue?
Martial arts (not marshal).
You don't have to be a black belt in martial arts to kick a win a fight against a black belt. That is a fallacy. There are masters of martial arts in their 90's who don't have a chance against strong and much younger athletes. That's why the analogy works so well.
Lots of people become masters of their niche and don't need to progress past it to have an amazing career. Donald Knuth is a master computer scientist and programmer. I am not sure what is the point you are contending. You call that "true black belt," but what does that mean? In many schools of martial arts, if you don't study certain Katas and other things, it doesn't matter if you are a super strong fighter. To get a new belt you need to master certain skills.
Does he also possess the skills that I described for Software Engineers and Software Architects? If not, then in my book he is not a "black belt," even if he can run circles in programming and computer science theory around people who I define as architects.
Anyway, I think I described a model in the post and I also made it clear that I expect some people to disagree. I am happy to see that I was right on that one at least :)
Well, I can appreciate your perspective, even if I don't agree with it.