Fish or Fowl?
Jun. 10th, 2003 07:02 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeurSo I was lying there last night, pondering the term "Computer Science" in my head, and noting that it's really kind of inappropriate. There's very little scientific per se about anything I learned about computers in college -- it was more a matter of learning the techniques of a craft. Which led me to pondering my field, and what exactly it is. None of this is terribly deep, but it's worth reflecting on a bit.
Thinking about it, I come to the conclusion that programming -- at least, the way I do it -- is roughly equal parts craft, engineering discipline, science (although not in anything I learned in school) and art. Here's the breakdown:
Craft: The essence of programming well is that it is a craft, and I learned it much like one would learn any craft. My first lessons were at my father's knee, from the time I was maybe seven. I did a more-or-less formal apprenticeship to him through high school and a bit beyond -- perhaps not quite the traditional seven years, but a good five or six anyway. In those years I learned most of the deep-down elements of the craft: how to put a program together, how to think of it, how to fashion it with care and how to deal with the customers. After college I struck out very much as a journeyman, skilled and experienced but still lacking the fine points. And somewhere in the past five years, I've come to think of myself as essentially a master progrogrammer, capable of working on my own and producing the occasional masterwork.
Engineering: While simply writing code is a craft, doing major projects has a lot more to do with engineering. It's all about the processes: how to start with an idea, proceed through the blueprints and eventually wind up with a structure that people can actually use. Industrial-strength programming is all about teams, not individuals -- how they work together and how they communicate. Little projects have room for big egos, but serious ones require that you set them aside. The bigger the project, the more it matters how you build, not just what, because you can't create a sound structure of real size unless you have the right processes for creating it and checking what you're doing.
Science: There's an important element of science in my day-to-day work, but it has nothing to do with the programming -- rather, it's in the debugging. When something goes wrong, my approach suddenly gets much more scientific. I gather all the information I can about the problem, and formulate theories about what might be behind it. I conduct experiments that can support or disprove those theories. Once I think the evidence is strong enough for one theory, I construct an experiment around it, which breaks before I fix the bug and succeeds afterwards. This scientific approach is slower than the usual slapdash approach to debugging, but it means I'm usually right, and am less likely to break additional things along the way.
Art: Art? Yes, art. Just as the serious potter needs to be both craftsman and artist, I've found it's the same way for me and code. The adjectives I use to describe bits of code are telling: a program is "elegant" or "crude", "pretty" or "ugly". I look at a program, and I see it as an aesthetic construct. As with any art, the rules aren't hard-and-fast -- there is lots of room for argument about whether a particular example is good art or bad. And I program very much like sculpting. Given the initial idea, I'll throw together a rough sketch, which might have roughly the right shape, but isn't very pretty. Then I'll begin to mold and shape it, poking and prodding at the code, changing a curve here and slicing off that unneeded bit there. Given the time and care, I can occasionally turn the original lump of clay into something of crystalline beauty, so achingly right that I am forced to admit that I can't improve it any more. Those moments are what keep me in this field -- not so much the ego-boo of seeing the product shipping, or even necessarily the pay, but those occasional moments of getting to produce some little system, hidden away from the user, that I know is an expression of my art.
Thinking about it, I come to the conclusion that programming -- at least, the way I do it -- is roughly equal parts craft, engineering discipline, science (although not in anything I learned in school) and art. Here's the breakdown:
Craft: The essence of programming well is that it is a craft, and I learned it much like one would learn any craft. My first lessons were at my father's knee, from the time I was maybe seven. I did a more-or-less formal apprenticeship to him through high school and a bit beyond -- perhaps not quite the traditional seven years, but a good five or six anyway. In those years I learned most of the deep-down elements of the craft: how to put a program together, how to think of it, how to fashion it with care and how to deal with the customers. After college I struck out very much as a journeyman, skilled and experienced but still lacking the fine points. And somewhere in the past five years, I've come to think of myself as essentially a master progrogrammer, capable of working on my own and producing the occasional masterwork.
Engineering: While simply writing code is a craft, doing major projects has a lot more to do with engineering. It's all about the processes: how to start with an idea, proceed through the blueprints and eventually wind up with a structure that people can actually use. Industrial-strength programming is all about teams, not individuals -- how they work together and how they communicate. Little projects have room for big egos, but serious ones require that you set them aside. The bigger the project, the more it matters how you build, not just what, because you can't create a sound structure of real size unless you have the right processes for creating it and checking what you're doing.
Science: There's an important element of science in my day-to-day work, but it has nothing to do with the programming -- rather, it's in the debugging. When something goes wrong, my approach suddenly gets much more scientific. I gather all the information I can about the problem, and formulate theories about what might be behind it. I conduct experiments that can support or disprove those theories. Once I think the evidence is strong enough for one theory, I construct an experiment around it, which breaks before I fix the bug and succeeds afterwards. This scientific approach is slower than the usual slapdash approach to debugging, but it means I'm usually right, and am less likely to break additional things along the way.
Art: Art? Yes, art. Just as the serious potter needs to be both craftsman and artist, I've found it's the same way for me and code. The adjectives I use to describe bits of code are telling: a program is "elegant" or "crude", "pretty" or "ugly". I look at a program, and I see it as an aesthetic construct. As with any art, the rules aren't hard-and-fast -- there is lots of room for argument about whether a particular example is good art or bad. And I program very much like sculpting. Given the initial idea, I'll throw together a rough sketch, which might have roughly the right shape, but isn't very pretty. Then I'll begin to mold and shape it, poking and prodding at the code, changing a curve here and slicing off that unneeded bit there. Given the time and care, I can occasionally turn the original lump of clay into something of crystalline beauty, so achingly right that I am forced to admit that I can't improve it any more. Those moments are what keep me in this field -- not so much the ego-boo of seeing the product shipping, or even necessarily the pay, but those occasional moments of getting to produce some little system, hidden away from the user, that I know is an expression of my art.
(no subject)
Date: 2003-06-10 06:44 pm (UTC)Twice, I have had discussions of "Computer Science isn't a science" thing, and twice I've come up with/been given different answers to why it is, in fact, a science.
This is not to say that one can't be quite a competant computer engineer without a CS degree, but I came out of Wellesley with a CS degree and it very much was a Computer Science degree.
We discussed the theory of programming languages - the difference between Object-Oriented vs. Function-Oriented vs. Imperitive. We discussed the mathematical fundamentals behind programming - why one function is Order of N vs. Order of N^2 or Order of N(log N) - which was lots of math. We also discussed why the logical gates in a computer chip are set up the way they are and the math involved there - that part felt like chemistry. We did, in fact, do science when learning about what a Deterministic vs. a Non-Deterministic function was - more math. Or how a computer operating system interacted with programs and hardware - that part was a lot like studying an ecosystem in biology.
And none of this prepared me for the actuality of being a Computer Engineer. My programming skills were -woefully- inadequate compared to what I needed them to be - and I'm a System Administrator, not even a fulltime programmer! But I knew the theory behind -why- all these things worked, so once I did start taking courses that taught me the syntax of a programming language, I took off like gangbusters and started writing code left and right.
So I think a CS degree can very much be a science, or an engineering degree, but you can do computer engineering easily without a degree. People won't always do it well - some will, but there's always folks like a coworker of a friend friend of mine who had a CS degree. Said coworker was working on a program of iterating through a list, and he did it the brute force method and ended up with O(n^2) instead of O(n log n). But on the other hand, it's possible to learn how to build bridges without ever taking a physics course. :)
I also agree that to be a good programmer, you need a lot of Art and Craft thrown in with your science, or you're going to be bored and frustrated, in order.
I will also offer this other proof in case it is needed: Any science will have jokes made about practitioners of it.
A physicist, a mathematitian, an engineer, and a computer scientist all check into a hotel for the night. During the night, a fire breaks out in their rooms. The physicist wakes up in his room, scribbles some hasty calculations on an envelope, empties a bucket of water on the fire, then seeing it's not quite out, does some additional math, empties a glass of water on the fire, and goes back to sleep. The mathematitian wakes up, does some hasty calculations on an envelope, says, "The fire exists," and goes back to sleep. The engineer wakes up, scribbles some hasty calculations on an envelope, then empties ten buckets of water on the fire, and goes back to sleep. The computer scientist wakes up, looks at the fire, scribbles some notes on the back of an envelope, glares at the fire and says, "It's not supposed to be doing that!"
This proof satisfied a physicist that CS degrees were in fact science degrees. :)
That's odd...
Date: 2003-06-10 08:13 pm (UTC)(no subject)
Date: 2003-06-10 08:22 pm (UTC)The question is, can it really be "science" per se if it doesn't have an experimental component? The experimental aspect of most CS courses is accidental at best, and absent at worst.
So while I agree that a CS degree is generally about engineering to a greater or lesser degree, I'm less sure that it's really about science...