[jacquesm]

There used to be two professions that we call programming today:

Systems Analysis

and (unsurprisingly)

Programming.

Arguably the systems analysis bit was the more interesting of the two, it is the one that I would equate with architecture, and to some extent (but certainly not as much as some would) art.

The other part, the programming part is best equated to engineering and construction.

I find I go through exactly those two phases when making something new. The first part I love to do it's where all the interesting bits are, the problems get solved.

By the time I hit the second phase, the joyful part is over, from there it is just typing stuff in and realizing the vision that I already have in my head and debugging stuff.

Rarely (but it does happen occasionally) do I get back in the 'fun' bits while coding something. That would mean I've made some terrible oversight during the analysis phase.

The analysis phase sometimes also includes some programming, it is where you come up with nifty little programs to test your assumption and where you let your inspiration go wild in order to see if you can solve the problem in an interesting way.

That is the most joyful kind of programming that I know, it is on a white piece of paper without any kind of connection to the real world of data processing. This is were algorithms are born. I love doing that.

The rest is just plumbing and brickwork.

[ericd]

This is interesting - I haven't heard this expressed explicitly, but it describes pretty exactly how I feel about "programming".

I've also found that almost all the interesting stuff is in the stuff upfront where I'm sketching out ideas on a notepad - roughly how things will work together, what the running time of different approaches will be and how it will scale, the user flow and interaction, and getting down the trickier algorithms to become reasonably sure that the main idea is feasible.

The rest really is just plumbing and brickwork. It seems like a lot is written online about the different ways to lay bricks, but I've never really felt that that was very interesting, except for resulting reductions in time spent bricklaying. Sometimes it's fun playing around to make extremely abstracted code, or some other challenge, but for the most part, it's pretty repetitive.

Thanks for expressing it, I didn't realize that the cool part used to be a distinct profession.

[baguasquirrel]

So if we are going to judge programming as such, then what about all the plumbing and brickwork associated with art? Didn't an analysis of the Mona Lisa detect multiple layers of paint, indicating that the artist had retouched many parts of it? From what I understand, it's common practice.

For some reason, the plumbing and brickwork in programming isn't viewed the same way by all people. Perhaps it's because of the use of low level languages (and by low level, I mean anything less abstract than Ruby, Lisp or Haskell. you can't meaningfully remove boilerplate in the C family of languages.). I personally find it gratifying to refactor code into something more elegant, and I'm sorry if you don't see it that way.

[jacquesm]

> So if we are going to judge programming as such, then what about all the plumbing and brickwork associated with art?

In 'real' art (painting and sculpture for instance) the execution and the expression are inseparable, in programming you can delineate the one from the other reasonably well.

For instance, a mathematician without any programming skills could sketch out the basis of an algorithm, which could then be implemented by programmers familiar with their particular language.

> Didn't an analysis of the Mona Lisa detect multiple layers of paint, indicating that the artist had retouched many parts of it?

Yes, so ? He didn't get it 'right' or 'satisfactory' the first time and decided to change it.

But there is a reason why artists sign their works and programmers can collaborate, even across vast distances on the same work.

In the end it is all bits.

If Da Vinci had reduced the idea of the La Gioconda to 4 squares and you asked four different painters to create the 4 squares and you'd merge them the painting would probably not be hanging in the Louvre right now.

Even if he had sketched it and sent it off in four pieces as a guide it still wouldn't have worked.

And that process works quite well for software, which indicates to me that the two are fundamentally different.

> For some reason, the plumbing and brickwork in programming isn't viewed the same way by all people.

No doubt.

> Perhaps it's because of the use of low level languages (and by low level, I mean anything less abstract than Ruby or Haskell). I personally find it gratifying to refactor code into something more elegant, and I'm sorry if you don't see it that way.

Refactoring code and optimizations are a step above simply putting layers of stone above each other, effectively you've temporarily switched back to architectural mode.

And I definitely agree with you that that is a gratifying thing to do. But it also indicates to me that I should be more diligent during the design phase because refactoring, no matter how satisfying is an expensive thing to do.

[baguasquirrel]

But there is a reason why artists sign their works and programmers can collaborate, even across vast distances on the same work. In the end it is all bits.

Ok, I have to admit, that is by and far the most compelling difference between art and programming that I've ever heard.

[ntoshev]

To me the real joy in programming comes when you integrate these two phases. Writing and debugging code should provide you the resistance of the medium to further shape your concept of what is it that you are implementing.