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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Simple
Date: 2003-06-10 04:42 pm (UTC)This, it is a science.
Liam
(no subject)
Date: 2003-06-10 05:14 pm (UTC)Paul Graham had something to say about this. [greps through yet-to-be-posted QotD entries...] Aha, here it is:
Good essay, about how much art there is in programming, and how there's more science in the study of programming than there is in programming itself. Probably worth reading while you're thinking in this direction.There are a bunch of good essays on that site. "Design for Makers" was a good one to read just before visiting the Baltimore Museum of Art...
(no subject)
Date: 2003-06-10 05:24 pm (UTC)Science: Very good point about debugging entailing a shift into science-brain. Paul Graham says that debugging is actually the real essence of programming. I see enough difference in the ways I think for the two activities, that I've thought it would be good to have a separate course in the CS curriculum specifically about debugging.
(no subject)
Date: 2003-06-10 08:17 pm (UTC)Hmm. I'd intended to make exactly that point, but it seems not to have made the transition from brain to keyboard. Thanks for pointing it out. Yes, I regard one of the key duties of a "master programmer" as trying to help the apprentices to get the hang of it...
I've thought it would be good to have a separate course in the CS curriculum specifically about debugging.
Year by year, I have less and less respect for the conventional CS curriculum. Too much time spent on fiddly details (many of which become quickly obsolete), not enough on the nuts and bolts of practical engineering.
(Although it may depend partly on the school. I was talking a little while back with a friend who came out of a technical school, which apparently had a very different balance, with much more focus on real engineering...)
(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...
(no subject)
Date: 2003-06-10 09:23 pm (UTC)As a fundamental point, CS should not be considered a true science despite having scientific parts within it. As a whole it is a field devoted to developing new technologies, not to the study of extant phenomena. So what is it? Generally it is the combined outgrowth of two other fields: Mathematics and Electrical Engineering. The former begat Information Theory, and latter Electronics. This is precisely the reason that at Binghamton, where
I would agree with most parts of your breakdown to some degree, but I don't see them as separate fundamental aspects of the discipline. The line between craft and engineering can be blurry, but what helps keep them distinct is largely the shadows of art in craft, and the shadows of science in engineering. Programming is, in my opinion, strongly on the scientific side of that line. Its aesthetic charm derives not from emotional or intellectual expression, as in Art, but in raw perfection. This is the same perfection as a well-written proof or an ideal arch. It is simple, elegant, and beautiful, but not expressive. On the other hand, the science of debugging is very near a true science, in that one applies the scientific method to study a phenomenon in the hopes of understanding it better. It ultimately fails as a science only because the process is interactive, with the ulterior goal being to change the phenomenon. This is broadly the same process one must undertake in designing, prototyping, and fixing any large engineering project.
I would say that, with its basis in practical application of scientific and mathematical principles, Software Engineering is in fact aptly named.
(no subject)
Date: 2003-06-11 06:17 am (UTC):-) This is exactly how I think of programming - sculpting in an intangible medium, simultaneously concieved of as algorithm-space, the set of All Possible Programs(*), and a dynamic sort of ether that doesn't just exist but acts, according to its form.
(*) = Rather larger a set than all potential algorithms, as a single algorithm can be implemented in many ways, in many languages. What's elegant in one language may not be in another.
(no subject)
Date: 2003-06-11 08:08 am (UTC)I've also been asked why computer people are often up late into the night hacking out code or perfecting an assignment, or why some of them don't even start until late at night. I think it might be that it might make it easier to tap into the creative levels of the brain. Although sometimes you end up with something that is quite artistic and ingenious, but doesn't work. :P Always debug in the daytime.
It also occurs to me that there are more disciplines that could be assessed this way. As you mention pottery, so could you mention woodwork, or architecture. Computers are in many ways like a material craft, but you are sculpting intangible things, rather than tangible ones: data and algorithms and routines. Like making things out of raw materials, there are different ways of doing it, with different levels of quality. And manipulating code is sometimes like how artists manipulate space, or light, or color to achieve a certain effect taht is above and beyond the putting of paint onto a canvas, or of choosing the right stone to carve.
Another Side of the Subject
Date: 2003-06-11 12:29 pm (UTC)My education touched, just barely, on all of those under the guise of "Computer Science". I can describe the physical reality behind amplifiers and flip-flops down to the semiconductor layer, evaluate algorithmic complexity, characterize the amount of information in a system, design and build a peripheral device, understand CPU architecture, criticize a GUI (and do user testing and suggest improvements), write automation scripts to make my life easier, write a utility to get results faster than I can get by hand, consult with people to understand what they want to do and subsequently spec out systems that will do it, and design and manage complex networks.
And I'm not a programmer, though I (obviously) do some programming to achieve these things. I'm essentially a "complex systems engineer" with a specialty in UNIX and TCP/IP networks. And this is all Computer Science... and very little of it was available as course material in Binghamton's Computer Science dept circa 1992-96.
There is some scientific method, there is some engineering rigor, and there is some esthetic elegance when it all comes out right.
-dsr-