Talk:Field Guide/Mammals/Rock Vole

I think the world of programming needs more Engineering and less Art. We're probably all familiar with the book "The Art of Programming", but I believe the term "art" has become over-emphasized in CS. In my experience, thinking of programming as an "art" has led to less documentation and artsy code (i.e. only legible to the artist). The results I've seen of artists are poor maintainability / portability.

Sorry for the tirade, it's just my impression when I read "Computer programming is an intricate and elegant art form."

Am I alone? If I am, then leave it be.

There are two common threads on that issue. One asserts that problems in software happen because people don't take the issues seriously enough, or treat development enough like an engineering discipline. The other thread points out first that engineers make mistakes too, and second that software is inherently unlike engineering.

To the first, I say that I've worked with people who are serious about good code, and take good precautions to make sure that things work out well. I've also worked with jack****es who don't seem to care. The lay person is not prepared to evaluate the difference until or unless things break, so preventing disgrace often means cleaning up their messes.

The biggest problem with claiming a particular similarity or difference between software and engineering is that it's a broad generalization. The same goes with art. There is theatre, music, painting, sculpture, and each of these can be divided further into myriad ways. I'm not an art student, and I wouldn't presume to compare sculpture with theatre, much less assert that one could be made more like the other. Similarly, I'm not a chemical engineer, but I'm sure that chemical engineering differs wildly from civil engineering or industrial architecture.

On the other hand, we can make certain observations. At heart, art satisfies the desire to express or appreciate some kind of message, be it a moral message or an emotion. On the other hand, the engineer in any field is faced with a set of constraints and a functional goal, and his work product is the detailed description of a system that satisfies the constraints while accomplishing the goal. In this sense, software is engineering and there's no two ways about it. Yet, any engineered system necessarily expresses a message. There are beautiful bridges, like that over the Golden Gate in the San Francisco area, and there are rather dull ones, like the one over 38th street in Austin. There are great cathedrals, like Notre Dame, and there are hole-in-the-wall churches that meet in a section of a strip mall, like the "Praise Chape" which is missing an L from its signpost. In any event, each is an intelligent response to the actual constraints and economic presures that affected their creation. Occasionally, an engineer or architect is lucky enough to work on a project that allows him to express something the world thinks of as artistic. Frank Lloyd Wright made a career of only ever working on that kind of project, and grew to fame and fortune as a result. Of course, his houses were (and still are) expensive, but they also have had "undesirable features" from time to time.

Let's observe that most houses aren't works of art, and most software projects aren't either. However, most architects (sample size one: my architect friend) want to work at an artistic level, and most software developers seem to want to work on projects with some opportunity for an artistic expression in their chosen medium, which amounts to code.

Coming back from the other direction, again the artist must support his art. If his day job won't pay the bills, then he'd better be a pretty good artist. This implies that it's possible to compare the "quality" of an artist and the art so produced. That's true; art that sells is better for the artist than art which does not sell. Naturally, it pays the artist to understand his market and his potential clients. If he can send a message they understand and will buy into, then they'll buy his art. Otherwise, it's art for art's sake, and that usually isn't appreciated during the artist's lifetime.

Samples of art and engineering both can be compared at the level of how well they serve their purpose. A bridge which collapses in high wind does not serve its purpose, and neither does the unskilled tapping of the ivories at a fine dining establishment. Thus, to become good in any of the fields thus far mentioned, one must first understand how quality is to be measured. Next, you can practice and improve your abilities to produce high-quality work.

Ultimately, such a controlled feedback cycle is engineering, even when the product in question is art. Bridge design is engineering, and so is programming also engineering. A bad engineer will design a faulty bridge, and a bad programmer will create a faulty program.

However
That's all about software engineering. This course is not about software engineering. It's about computer science, which is an entirely different field. Let me explain what I mean:

Chemical engineers don't do what chemists do. The chemist works typically with many tiny quantities of many different reagents and discovers or invents new things that can be done with chemicals. Upon learning the results, the chemical engineer can then work out how to scale the process up to an industrial level. The chemist might invent a new platic, while the chemical engineer then finds a way to build a plant to produce an endless stream of the new plastic. These are entirely different problems, but naturally both involve quite a bit of brainwork. A third person may be responsible for finding uses for the new plastic and bringing them to market.

The software engineer is tasked to apply the discoveries of the computer scientist to solve real-world problems. The computer scientist, then, must invent or discover new solutions in search of a problem. The corresponding third role is to find an audience for, and distribute knowledge of, the latest developments in computer science.

Afterward
We teach natural science and mathematics by first instilling the skills to perform and then setting the educated loose on open problems in the field. The same is done with CS: You'll learn a few programming languages, but you'll also learn why programming languages are the way they are. You'll learn what makes them tick, and why. You'll learn the known concepts by applying them, which is why everyone has to write a linked-list program and a database manager. (What's a linked list? Have patience, Grasshopper.) Eventually, you'll get to work on something really deep, and if the faculty is suitably impressed, the university will try to make money off it. (Usually, this takes the form of patent licensing.) Then, you graduate and you are considered ready to be a computer scientist. However, you are not a software engineer. That will take a different kind of work.