For me, coding(*) is neither art nor science nor engineering.

• Art

  The first thing that many think of when they think of 'Art', is creativity and whilst coding undoubtedly involves a good deal of creativity, I think that there are more defining terms and attributes of 'Art' that cannot easily be applied to code.

  The greatest value--in monetary terms--in Art, is uniqueness. I doubt we will ever see a piece of elegant, avant-garde or modern Perl code going under the hammer at Sotheby's and fetching a fortune. The value in code is in it replication. Sell many copies and make a reasonable buck. Give away many copies and make the world a better place. One-off pieces of code are often fun to write, and can even be the source of some remuneration, but noone is ever going to get rich from it. In art, a limited edition is always worth considerably more than a mass reproduction. In code, the opposite (usually) holds true.

  That leads to another difference. Works of art can rarely, if ever, be reproduced en-masse and retain either their aesthetic appeal or monetary value. The very nature of programs means that they can always be reproduced in quantity, and that ability is often intrinsic in their value.

  Art is usually the work of an individual, though occasionally you do get collaborations between 1, 2 or 3 artists--I'm thinking about the traditional use of the term as applied to painters, sculptors and the like as opposed to those in the performing arts for whom the road to proficiency, fame and wealth takes a different course. Whilst programming can be an individual affair, it can also be a collaborative affair, and often on a large scale. Mores the pity:)

  The produce of artists is usually valued for it's aesthetic worth, and usually with huge multiples over the intrinsic costs of it's components. Even if you incorporate the artists time, it rarely makes a dent upon the huge multipliers that are applied to works of note.

• Science.

  At a cursory glance, this seems appealing. Further examination shows that it doesn't hold water. The main aim of science is discovery & classification, and the determination--through step-wise refinement and/or disapproval of theorems--of explanations and fundamental rules for natural phenomena. At least until the much vaunted Quantum bit computer makes it's debut, there's little about programming that can be classified as natural:)

  There are a few exceptions of course. Turing discovered a few fundamental truths and few others since have complemented his findings. On the other hand, there have been very few if any truly new discoveries in programming since the days of Ada Lovelace. Almost everything we do is a rediscovery, rehash or minor variation on stuff that was invented long ago and was, for the most part, long since written down and structured, by the likes of Donald Knuth.

  Mostly what we coders do is just futz with stuff. Re-inventing, re-structuring and recombining, but mostly futzing:)

• Engineering.

  This has the strongest appeal of all. In many ways the processes and procedures of the coder appear superficially similar to those performed by engineers in many disciplines. We take a limited selection of usually small, independent pieces, string them together in to larger pieces and then mass produce them for consumption or use. Whether it's the nuts and bolts that go into the making of a car or airplane; the brick & mortar, concrete, steel and glass of the civil engineer; or the transistors, nand, nor and not gates of the electronics industry. They all bear a remarkable resemblance to the machine instructions, keywords, library functions and classes of software development.

  However the similarities begin to fade under closer scrutiny. The fundamental difference is metrics. It is nearly always possible to quantify the nature of any single component or subsystem in engineering and further, to describe it in such a way that you could give the same description (think engineering drawing for example) to any engineer in any of many companies world-wide and they would produce the same thing. The process of machining a piece of metal is a process of setup, cut, measure, possible cut again and you have it. There is skill involved. The semi-experienced lathe or grinder operator learns to make all his final cuts before measurement in the same direction to negate the effects of backlash in the drive screw. The even more experienced operator will learn to cut slightly more than his measurements imply, to allow for tool wear. However, even these skills can be measured, formulated and encoded such that CAD/CAM software will automatically account for tool wear when it supplies the dimensions of the part to fully automated turret lathes and the like. There are even standard formulae for accounting for the distorting effects of expansion due to the heat created by the cutting process itself. All these things have--as yet--no equivalent in the development of software. Heck. To date, we still don't have reliable metric for pre-determining how long it will take to write yet-another-shopping cart/database update/sort routine.

• So how do I regard coding.

  To me, it's a craft. As someone's signature line has it--Programmers are the carpenters of the modern age!.

  Like the woodworker--and I apologise for re-using this analogy, but like all the best ones, it has a lot of mileage in it--the coder creates each piece anew. Whilst the metal worker can happily select any piece of the designated raw material for his work, the woodworker cannot. He has to deal with the produce of nature, complete with it's variable grain, texture, and strength. He must check for knots, sapwood, and insect damage. Even when he is making yet-another chair leg, table top or window frame just like the previous 2 dozen. Each one is individual.

  So it is with coding. Whilst it's hard to see the raw ingredients of a program as natural--they are!

  The requirements of most pieces of code are based upon subjective rather than quantitative criteria.

  We tend to put the house number/road name fields above the town/city name or post/zipcode. Even though it would actually make more sense to do it the other way around. Give me the Zipcode first and I can complete at least the state field for you, probably the town/city as well. In the UK, the postcode usually selects right down to a handful of houses in a given street. So why does every dratted on-line form put the postcode at the bottom of the form? (The same is probably true for Zipcodes/postcodes in other countries also, but I am not familiar enough with them to know for sure).

  Personally, I think that the invention of hierarchical directory structures has done our industry more harm than good. Without their invention, file systems that allowed useful designation of, and selection by, meta-data would do away with much of the nonsense that hierarchical directory structures cause. Further discussion on that is for another time and place, but think how much simpler it would be if you could ask the file system to show you all the files on your hard drive that you had edited in the last five days. Yes. You can write a program to do it, but it should be as easy as a glob(myEditor, -5).

  Programming based on human, usually traditional, subjective criteria rather than logical or quantitative ones.

  The other 'raw ingredient' in the coding process is very natural. It's the human brain, and it's capacity to see patterns and apply them. It's the innate ability of the human brain to detect and isolate patterns that make it unlikely that either woodworking or coding will go the way of metal-working and become a process primarily carried out by the robots and computers. The advent of software that can reliably detect the flaws in a piece of wood, or read between the lines of a program specification, and then translate either into the required end product are a long way off.

Hopefully, that will remain the case at least until after I retire. As for all you youngsters out there...good luck:)

++ for a great post.

Without their invention, file systems that allowed useful designation of, and selection by, meta-data would do away with much of the nonsense that hierarchical directory structures cause.

I think what you're asking for here is a database. BeOS actually does what you ask for; a pity that OS died at such a young age. Let's hope the open source thrust that is attempting to breath new life into it will succeed.

Makeshifts last the longest.

A database? Yes, in the generic sense of the term rather than any specific sense like RDBMS etc. I never encountered BeOS, but I did have passing flirtations with two other systems who's filesystems retained more information about a given dataset than just name/who/when/how big, namely PICK and MUMPS. Both also went to the great bit bucket in the sky although there are still small pockets of resistance clinging on to the use of both.

---

Examine what is said, not who speaks.

The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.

Since the beginning, which is way too long ago now, I've always done most of it in my head during more mundane activities like driving the car, mowing the lawn or visting relatives -- oops I didn't say that, did I?

I also like to try and find something at least similar to what I want that's already out there and check it out, both playing with it and looking at the code to see how other people solved similar problems. I've always felt I have more of a strength extending something someone else has started than coming up with extremely novel new ideas. For years I worked with a great idea guy and I just grabbed what he started and took it further. It was a very satisfying working relationship. It's not that I didn't come up with anything on my own -- he just was more of the frontier guy and I'd latch on and go for the ride.

A few other quirks I know I have in this area: I need to see code blocks when I read and write code. I've never been able to see blocks with the old kernel style braces which is why I've almost never used them. To me, identifying code blocks is the first thing my brain tries to do when looking at code. When I code I invariably stub out a bunch of empty blocks and functions/methods first, then fill them in later (often breaking them down further). But contrast that with another quirk I've picked up in my old age: Line level comments primarily serve as a distraction, whereas I used to comment every line when I was right out of college. I think my brain has just learned to scan code over the years. An interesting observation here too: The absolute best coders and designers I've worked with are much better than their peers at "sucking in" existing code and making sense of it. That, IMO, is a much harder skill to master than writing brand new code and it is where much of our time is spent.

Too bad I can only ++ you once, steves.

I've always done most of it in my head during more mundane activities like driving the car, mowing the lawn or visting relatives

I get a good deal of work done this way. Once I get an idea of the data I'll be working with, I start thinking about the data structures I'll use within my application. I often find that this kind of design is easier to do when I'm not at my desk.

When I'm into it a bit I also usually write some throw-away test code to help solidify the ideas. I've never been a fan of the design first/code second method -- I just have to try things out or it gets too abstract.

I've learned that in my job, the users often don't really know what they want, and they will agree to a paper specification without really reviewing it. I think a lot of people have a tough time visualizing the end product from some words and mocked up screens on paper. So I like to hack up a prototype application as soon as I get the basic requirements, then let the users comment on that. Not to mention that this increases the fun factor by minimizing the amount if spec. writing and maximizing the amount of coding.

I tend to think of programming as somewhat akin to proving theorems (which, despite the awful formal connotation, involves a lot of intuition) and writing non-fiction (which, despite the artsy connotation, involves a lot of structured thinking). Programming isn't even close to a well-defined, rigidly structured decision procedure; if it were, we'd get computers to do it.

I approach programming the same way I approach writing, or proofs: I start by gathering information (doing research for a paper, taking stock of useful already-proven theorems in the field for a proof), then put that together into an outline of some sort, and finally assemble it into a working (hopefully) final form.

Then I go back and edit the hell out of it. :-)

I also tend to anthropomorphise my programs, subroutines, and constructs:

• "This routine takes three inputs from the caller, does a few calculations, then hands them back."
• "When this printf(3) call got handed a NULL pointer, it got confused and dumped core."
• "This optimisation routine loops over the data, making local improvements until it gets bored."

See also Writing Habits.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!

How do you view your code building process? How do you view your data structures, design role, program flow, etc.

1. seperation
2. single function per routine/method

Where appropriate i seperate the business logic from the implementation specific detail from the presentation detail. Most of the perl i'm doing these days is around the web so this works really well with HTML::Template. At the end of the day we end up our own set of reusable modules/templates.

In the guts of the apps I write, as a general rule each method will perform a single task, and the second i think "cut and paste" i start refactoring my design. (if i had thought about design more, i'd not need to do this, right?).

We use quite a formal structure and set of design guidelines (eg for email you must use "this" module, and to interact with the database you must use "that" module, libraries must go "there" and templates must go "there"). While it may not be too everyones taste, my experience has shown to date, as our as our structure matures, the TTL for new apps is quite rapid, which makes the business happy.. :-)

In terms of code specific detail, i dont use the deep magic of special vars and the like very often. I do however like to find new ways of doing things, so the balance between readible (junior level) code and "fun code" is sometimes hard to find in my professional life.

In my personal life i'm left with quite often not enuff time to pursue the more complex options, so usually go for the easiest option to implement. Fortunately for me, the "easiest option" is a moving line.

Let me refer to Plato's dialogue on language: Cratylus. What we do when we program is we name things. The question is whether things have the names assigned by nature beforehand or is it a matter of convention in naming things. We rediscover things through programming - give a name to a matter appearing from void. One might think that the names we give to things is conventional, but on the other hand we cannot call horse a cow, there is an idea of "a horse" and not a cow in the thing you're trying to name. Thus programming is a neverending flux, we talk programming words, name things. Give a thing it's true name and it will connect your mind to the nature of the thing and help you in your path.

How do you view your code building process?
I view it as a nice rosy shade of pink.

How do you view your data structures, design role, program flow, etc...?
Well, that is an interesting question! My data structures tend to be a nice slate gray while the design role is bright shades of yellow and orange. The program flow is the most beautiful shade of teal.

What is it like for you?
Ah, the colors! They all blend together to make a work of art.

Do you view variables as containers or simply some type of way to get your data back from the void which is memeory?
Variables are (for the most part) translucent. They take on a lighter hue of whatever type of data that is stored in them. And I do not consider memory to be a void. Voids are dark and gloomy. Memory is a cheery place of vivid greens. Oh what a joy it is to view the data flitter hither and yon through those lucious fields of green!

Was this simply a random response, due to a mood or are you attempting to state something about the question?

Just trying to figure out where this came from, as it smacks of a Dilbertish type reponse to PHB.

PHB: We need a Database server to increase productivity
Dilbet: .o0( !!!! Does he know what he is talking about or is this a random statement !!! )
Dilbet: What color do you want the database to be
PHB: I was thinking of a light blue....

You *did* see the sign about no fun in the monastary right :P

/* And the Creator, against his better judgement, wrote man.c */

It's semi-serious. It's easier to learn things when they have colors associated with them and colors have been shown to affect our moods.

• Pink is soothing.
• Gray is a mix of black & white. Black shows discipline. White unifies. So gray would be a unifying discipline.
• Yellow and orange both add cheer.
• Teal is a greenish-blue. Green is refreshing. Blue is relaxing.