This is a topic that I find recurring between myself and my non-programmer friends, as well as people providing freedback on some of the Open-Source repositories I contribute to and help maintain. Questions such as “what drives you” or “if you aren’t getting paid, why do you do it?” Sorts of questions.

My normal response is “Why do painters paint?”. The old standby. But I think it’s an interesting question too. The reasons that I like to develop, design, and implement software can be traced to the same things. I Enjoy programming for a multitude of reasons. It’s something I’ve found that I’m good at, and that I can continue to grow better at over time; there is no glass ceiling of skill that I will hit. Something about it makes it far more expressive than it would seem at first glance. There is more than one way to write a program to do a non-trivial task, and with experience and skill you are able to become familiar with both the language in question as well as how you use it; and you can carry over some of this skill and ability into everything you do.

There is something innately fulfilling about looking around and seeing people benefit from software you’ve written, regardless of what it is. Arguably depending on the software there is also responsibility for that software that you implicitly take on regardless of any “Terms of use” that remove such warranty. For example even though you are legally in the clear if a piece of software does something it shouldn’t or causes a problem for a user, you are still bound by the contract of not being a massive douchebag to at least try to help especially in terms of fixing the bug if not helping to recovery any lost time or data that the user lost.

Even in the most boring and otherwise dry Application, there is some consideration to be made for how maintainable the software is going to be. If you go into a large project and just code what you need by the seat of your pants you are just going to make more work for yourself in the long run; so you have to try to get an idea of the larger picture, and then focus on drawing out the details in each area so it flows smoothly; like the charcoal pre-painting step of an accomplished painter, you are able to see if this will work in the overall composition as per the software requirements. Additionally even in the most restrained set of requirements there are choices and decisions to be made by the programmer in terms of the actual make-up of the code and logic- eg, what will be represented by classes and how those classes will interoperate. A common quotation, (though I’ve forgotten the attribution) is, “The definition of Insanity is doing the same thing twice and expecting different results”. I guess you could say the definition of Art is getting two people to do the same thing and getting vastly different results.

This takes me to the almost separate topic of whether Software Development is an “art”. I’d say that it is in many ways- the aforementioned tongue-in-cheek definition being a good example of why this is. But at the same time, how is it “Computer Science” when it’s actually an Art? This is something that baffles onlookers to the subject- some Programmers feel they are artists. Others feel they are academics working in a professional Science.

The answer is simply that they are separate. For example, when you study light and colour and pigments in chemistry and science classes- that is science. It is when you apply that understanding as well as a understanding of how we [i]interpret[/i] colour that it becomes an art; and in terms of painting (or any graphical art) the “art” is more in terms of using the skill with the medium to give a message. When it comes to Programming, we have a bit of a different thing going on; I’d say that for Software Development you actually have to deal with two things- you need to deal with the Compiler/Interpreter/Computer that is compiling and running your code, but you also have to deal with the people who will read your code later on, including yourself. It becomes an “art” to balance the requirements of the program and try to come up with the most elegant, and easy to read Source code to describe an otherwise complex problem.

I imagine this is partly why I find it so fascinating. Another reason is that once I’ve written something well, and moved on- I can always both revisit that project or class to make improvements, or simply touch it up and post it here on my blog (which I’ve done for a few classes) which actually has another interesting sidebar in that those improvements I do make often come as a result of my actually opening that project or class to try to touch it up for a new blog post. In that way I build up a library of small libraries, and classes that I can use for a variety of common tasks, making complex requirements such as high-level automatic support for List View Sorting UI handling almost trivial. I think this sort of “art” helps the end-user because it means for example that the otherwise complex functionality, which now takes a single line to actually implement, basically needs a good reason to not exist. You cannot argue that it would take too much time to add a single line of code to add the implementation, and the class itself being reasonably well-tested is a sort of assurance of how well it will work.

That isn’t to say it’s always fun and games. TO be honest I’m actually a bit disappointed with how little work I’ve done- I mean I do have a good number of projects, but I feel I could have a lot more, and even then those projects I do have suffer from neglect because unfortunately there are only 24 hours in the day and I’ve decided against moving to Venus because I prefer to not have my skin boiled off and corroded by a real-life dutch oven planet, even if that would give me a day that is 100 times longer. And that joke had far too much setup and a delivery that makes me glad I didn’t pay shipping. Anyway- I don’t even remember when I last opened BASeBlock- and even then it was probably to see how I did something to try to adapt it for a work project; I would have to look back even further to see what the last time was that I actually opened it to try to get some work done on it. Another issue I’ve found for those projects recently is that now that I actually do this sort of thing for my actual work I find that- unlike my previous Jobs- At the end of the day I simply don’t want to see Visual Studio anymore. This is actually fine by me- it tells me that what I am doing is mentally engaging and I’m still learning.

This actually makes me understand some of the weird habits I’ve seen from career programmers. I’ve noticed for example that many career programmers that have hobby projects will make their hobby projects in another language from their work, which I’ve never entirely understood. But Now I can see- they want to distance those hobby projects from the work they do to make their living, if only in their own mind. Even using a separate IDE for the same language can sometimes make the difference. For some Java Work Projects I used Netbeans, but for my hobby programming in Java I used Eclipse (And now finally switched them to IntelliJ IDEA). The fact that you are in a different environment is a “cue” to your brain to do stuff your own way, I suppose.

That said, I still hope to eventually get back into developing Prehender. It’s fun to learn new stuff and even deal with OpenGL while still being able to rely on my skills with C#. And it would have the advantage of being a completely different playing field from anything else I do or have done.

Speaking of “Prehender” who’s name’s origin I’ve forgotten, but there was a reason for it- I ought to write a blog post on the gameplay ideas I had for that. It’s not revolutionary but it’s simple enough to be something I feel capable of even with my limited 3-D experience while still being something I think would be a playable and engaging game experience.