What is programming?
When you first start programming, the answer is painfully obvious: Programming is making the computer do what you want.
However, if you have any aptitude for it at all, you will rapidly get to the point where making the computer do what you want really isn't that hard. Oh, you may be betrayed by your environment, your libraries, even your hardware sometimes, and you never get to the point where you are immune to the multi-day debugging sessions, but in general, getting the computer to do what you want ceases to be a challenge.
The true challenge of programming is learning to want the right things, and then how to obtain those things, beyond the mere first-order consideration of "does it run right now?"
When you work on the same product for three years, you will learn to want maintainable code. Writing code that works is easy; learning how to write maintainable code is a worthy challenge.
When you start work on a project that has fifty man-years already put into it, you will learn to want code that is properly documented. Learning exactly what "properly documented" truly entails is a worthy challenge.
When a project exceeds the size that one person can comfortably hold in their head, you will learn to want code that is conceptually clean and easy to come back to; a worthy challenge.
And so on, for a number of worthy challenges.
If only it were so easy as "making the computer do what we want"!
Programmers that can make computers do things are a dime a dozen. Programmers that have learned to want the right things are unusual.
The core point of the entire Programming Wisdom blogbook.
Expanding the points made in Compression and Compression in Languages up to the Methodology level, and beyond.
Wherein the point I was setting up in Compression is made.
Below the fold, a discussion about compression, using this as a clear example of a principle I intend to relate to other programming principles, and indeed engineering principles in general.
|<- Future Posts||Past Posts ->|