Why do you enjoy programming?

Recently a friend of mine asked me to participate in a study that he is conducting. He asked me to answer the following questions, and I thought that they were interesting enough to share...

1. You’ve mentioned before how you enjoy programming and choose to do it in your free time, and I was wondering what aspects of the work do you enjoy the most and what reasons you think you have for enjoying it?

I am going to try to answer those questions in reverse order.

What reasons do I have for enjoying programming? I think that programming is problem solving its purest form; it is the application of raw logic to a very specific and well defined problem. As a person who has always enjoyed math and science, my brain just seems to naturally gravitate towards computer science. To me programming is like solving a puzzle, and I get the same high from making my code compile as I do from beating a video game.

What aspects of the work do I enjoy the most? This question is much easier to answer! Anyone can solve any problem using only their mind. You can define languages and protocols to meet your needs. You can communicate between any number or parties at the speed of light. You can literally engineer entire worlds. It’s fun, it's challenging, and it is always rewarding when you build something that impacts others in a positive way.

2. In addition to that, how do you view the projects you are working on while you are working on them, and how do you view them once they are done?

These are opinions that have evolved overtime, often through trial by fire.

How do you view projects while you are working on them? During a project you need to keep your eyes on the prize, the best thing any engineer can do is to try and deliver the minimal viable product as soon as possible. During this time engineers need to engage in a very difficult balancing act of trying to make the best long term decisions, while still tempering their ideas and ambitions with more reasonable compromises to achieve short term goals and deliverables. After you have something that works, then designs can be iterated upon, implementations refactored, and schedules revised. In short, I think every project that does not ship is a failure, regardless of how perfectly it was designed or optimally it was implemented.

How do you view projects once they are done? First and foremost, I feel that the quote "art is never done" applies to software. There are almost infinite ways to solve a problem, each with their own set of pros and cons, so projects can always be improved. That being said, after a project is complete you need to be honest about it. You can, and should, be proud of what worked. You should also be open to talking about what didn't. No matter how good a project was, you can always do it better next time!

Those are my answers...what are yours?

Thanks,
Tom