After we started with jobs (or to say once we are out of school), initial year are about experimentation. As learning is need of the hour. We write more non-production code than production code. This makes us understand and then implement what we are told to. This goes on for few years but after that we gather so much of experience that we really don’t need to write sample codes before we implement something. Still we do get new kind of implementations to do and we do what we did before, write some non-production codes. Introduction of testing tools for test first programming even allow us not to spend our time on sample codes but just write direct production codes. As those are always tested every-time you run the build. So the journey from an ad-hoc code to a mature code that even solves the problem at hand can happen while writing production code only. This conservers your energy and only channelizes in solving the problem at hand. This approach normally reaps great results and most of the time error free codes. I can’t remember an instance were my code failed in a scenario that I had thought of before. Even after reaping so much from test first programming I felt dissatisfied. There was something missing from this coder’s diet -- Unbound-creativity.
What author refers to as Unbound-creativity?
An unstoppable desire to, create on a limitless canvas.
Every time you put a new layer – you add new constraints. Those help do work faster and neater. Even using testing frameworks make you work in their constraints. From creativity standpoint standardization is a necessary evil. Standardization has all the benefits in the world for commercial organizations and large-distributed coding teams but in end of the day, it comes in the way of the creativity of an individual. Coding isn’t an exact science by any means; it’s an Art of instructing a computer. Per say physics also relies on an Art -- Art of reading and understanding nature. Nothing that human does can just be science; it will have an element of art to it.
In true sense we all programmers are artists, we create something that a beholder can admire. It can be your code or its output but most of the firms don’t think so they just think programmers as resources, in a simple mathematical model. They have helped commercialization of this art. To sustain and keep resource outputs predictable, they shortlist languages and create a pool of commodity programmers by increasing demand. As they have money and we need some every month, we have to ourselves strike a balance. Don’t ever stop learning; to help this you can do innovative things. Like learn a language every week/month, or select a language else than what you work with. Then try to create all you can think-off with the new language.
Whatever you do start-writing some code again for yourself, enjoy writing code without any specifications or guidelines. May be a few layers below you normally code at work!? Write some nonsense, fun-sake, enjoyable, masterpiece, state of the art non-production code, just for yourself regularly.
And remember what Donald Ervin Knuth wrote once;
“A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better”
( http://nitin.tumblr.com/post/1761267 )