I used to think of and describe programming as writing a bunch of instructions for a computer to execute. In low level programming where you are more closely approximating how the inner details of how a computer works, this is more closely the case.
High-level programming — where many lower level computing details are automated behind the scene by the programming language and operating system — and where you can define and use many other coding abstractions/automaticities, writing instructions for a computer to execute isn't really what you're doing.
In high-level programming, you aren't telling a computer what to do, you're describing scenarios and problems and solutions in a language that a computer can mathematically translate into its own computations.
High-level programming is about communicating, it's expression. You want to write your code so that it describes clearly and succinctly what is going on. It's about how well you communicate, and when you get into this sort of thing you get into art, because what is art but how well you communicate something, aesthetics, quality of communication1.
When you write a high-level program, a computer reads it and duplicates it, that is it parses it and translates it into its own data structures and computations. It doesn't necessarily follow your exact instructions. It looks at what you said and makes computations based on ways that are most efficient for the computer to compute, and maybe other criteria such as interoperability between systems. In your code you may say addition, and your computer might actually do multiplication. You might say to call a function at line 42 of your program, but the computer doesn't actually call this function until line 45. The point of the computer is to give you the result you describe in your code, how it actually achieves this result is its own business.
When you are writing code, you're not writing it for the computer really, you're writing it for your and other's understanding. The computer incidentally just has to be able to duplicate the code and come up with its own computations that match the program description. It's like you're writing a story, but it happens that you can feed it into a computer and the computer animates it, like it's happening in real life!
Why does it matter how clearly and succinctly you write code? Why does art in programming matter? Because great software depends entirely on how well it is understood. It is people that make software great. Great software is great because someone(s) really understood it. How structured, clear, and succinct a program is written determines how well and how fast it can be understood if you begin to write programs of any complexity. How short a program is matters because it is generally easier and faster to understand programs of shorter length. This isn't always the case however. You can write short code which obscures clarity. Skill, expertise and experience enters into this as conciseness with clarity is entirely possible.
When you really understand a software application, your flexibility with it is enormous. You can change it pretty easily, add functionality, etc. Bugs are pretty much nothing because they are easy to fix. You are really efficient with this code and application. You can duplicate it and change it a lot for a new application for a different use. You can do lots of things. Programming is fun.
When you start dealing with a lot of software, and you write code that depends on other code or systems (including your own code and systems), it matters whether you understand that other code or systems. Other code is not just "Yippee! the work is already done. I can just use this without understanding it." By entering in code or systems you do not know about, you are entering in non-understanding into your software. As programming is expression or communication, you're adding elements to your communication that you don't know about. If you did this enough you could say that you didn't know what you were talking about. What kind of quality of communication is that?
If code that you have written or others have written is a good program description, i.e. does what it is supposed to do well and is clear and concise, then it provides a developer the opportunity to take the time and effort to really understand it and so use it well in other code and applications.
Other people's reusable software and systems aren't free, it costs the work and time to understand them, which can still be faster than writing everything from scratch. Perhaps a good way to write software is to study how someone else did it and model your software off that.