How to explain to non-programmers that programming is not a repetitive task?

You can always say that programming is repetitive typing to exactly the same extent as writing prose is repetitive typing. Will one write a great (or even mediocre) novel by sitting and carefully putting letters together?

Well, it is in a way. You repetitively type the same letters (A-Z,a-z,0-9) over and over again. Just in different combinations.

I usually try to avoid such discussions with such people.

Programming is about abstractions. The more you write the more similarities you can see. But then its time to abstract. By refactoring a framework evolves which eliminates duplication. This reduces complexity in the problem domain code.

Repetitive programming is possible. But it is inefficient.

Aside from the other answers that point out how the repetitiveness or typing/clicking is superficial, you could also point out that programming is usually much more about problem solving than it is about typing (and I think it was Djikstra who said computer science is as much about computers as astronomy is about telescopes - or something similar).

Typing is just one way to implement the solution (and currently the most popular), though there are other ways, such as:

• pseudocode on a white board (which illustrates the solution, but doesn't actually run or do anything, unfortunately)
• punch cards (now considered obsolete)
• Maybe programmable logic arrays or if you want your solution to be implemented directly in hardware (though mostly likely there will be some typing to get the solution from your brain to the PLA, I don't know how common it is to "code" these things directly - I don't really work with them , just know of them from others who do).
• people (I heard about a group recently that implemented sorting algorithms as a dance)
• rocks in a desert. ;)

If it really were, we'd just use copy and paste :D

One of the key challenges in programming is to fashion building blocks of high quality, such that you

• can use them to build up your edifice (i.e. the software you are building) of solid components, thus increasing stability
• can reuse them multiple times in the same edifice or even in different edifices (to reduce repetition) and thus increasing your productivity
• will be able to change a block without causing your whole building to collapse, thus increasing local flexibility
• will be able to change all instances of a block at once, thus increasing global flexibility

By its very nature, this challenge demands you not to repeat yourself.

As a corollary: If you repeat yourself as a programmer, you waste time on building software, that is neither stable, nor flexible.

If you want to be good at programming it is repetitive but the same can be said for anything. Repetition is at the heart of mastering any skill.

Programming is pretty much like music composition. Which is far from being a repetitive process.

• You start think about the overall view of what you need to achieve
• You think about a small chunk of your composition and you write it
• Once it's done, you play it (F5 in Visual Studio)
• You repeat the process, as needed
• Sometimes you borrow ideas or get inspired by other compositors
• Sometimes you refactor your song by moving or reworking parts

Sometimes, you don't know what you want, and you play around. Probably the best way to get most interesting compositions...

Tell them that programming is similar to creating cross-word puzzles, and that puzzles are usually different...

I usually explain that programming is creative problem solving. You have a problem - you want a feature in a product (and I usually pick a well known product, Amazon.com, MS Word, etc), and it's not there. It's never been done before, and you are the first, so this is like any art project - you have a vision, but you need to figure out a path.

I also focus on the fact that there's more than one way to solve the problem, a bunch of really bad ways, and probably more than one good way. In the long run there might be a best way, but that best way won't be obvious for a long time (extensibility, re-usability, etc), so at the time of development, there's a lot of important judgment calls.

Finally, the end product may be loved or hated by the recipient. Just like some people love Picasso and some can't make heads or tails of modern art - some people may love a feature, and some may hate it. You do the best you can for the most people, and figure you can't please everyone.

Focusing on:

• unknown territory
• no one answer
• subject to interpretation

Shows that this work is a lot more like art, and a lot less like repetitive boring work.

I talk this over with artists quite frequently (and they seem to have an instinctive belief that computer work is uncreative. Usually I also can manage to relate it to the artist's favorite form of art. At some level, most artists are also technicians - painting, dancing, making music and probably any other art - all involve a series of repetitive activities that bring you to the point of execution of something new, different and creative. Put this way, the artists generally have problems denying that seemingly repetitive activities can lead to works of inspiration and beauty.

At that point, they are usually willing to admit that just because my "art" involves a set of bizarre looking syntax statements and bland-looking UML diagrams, it doesn't mean that it isn't creative in that those lines of code and models of the system eventually make something quite different than the sum of its parts.

Well programming can really be a pretty repetetive task. Especially when the infrastructure has been built, the boring process of building the same dialog/business software (only slightly different) over and over again starts. You're lucky if you don't have to participate to meet deadlines or if you have enough juniors to do that kind of work.

Much of the act of programming is typing. Painting involves stroking with a brush but calling repetitive is pretty superficial.

Would they apply that logic to: - Sales people talk on the phone a lot. - Managers go to a lot of meetings. - Singers just sing. - Actors repeat scripts.

If so, that's why they're not a programmer.