What a lot of people don't know about what makes software interesting.

I had a quick conversation with a grocery-store cashier yesterday that stuck with me for a while. He overheard Sarah and I talking about some technical stuff that piqued his interest and it came out that I was a software developer. He seemed pretty interested in that and asked me what kinds of projects I write. I mentioned that most recently I had written software for a museum installation and that for my full time job I work at a software company where I write software for doctor's offices.

His response was what stuck with me. He mentioned how it was nice for me to have some interesting side-projects to fill in the gaps I that must have from my boring day job. I didn't get into this with him due to the brevity of our conversation but I think his response is indicative of a very commonly held misconception about software development.

The irony of it is that if we're just considering the amount of rewarding technical challenges and interesting design decisions, his notions about the two projects are pretty much the exact opposite of reality. As fun an interesting as the museum installation, Round, has been for me, it's really not all that technically interesting. I'm not going to say it was easy for me but most of the reason that it was challenging was for two major issues. The first being that I had to learn a lot of new things as a result of being the only technical person on the project. Secondly I had relatively very little time to cram in all the work since I have another job.

On the other hand when it came to system design decisions, algorithms, abstraction decisions, code organization, or any of the important things we learn in a computer science degree, the decisions on Round were pretty straight forward. This comes in direct contrast to my day job, which I am very happy to say, provides very challenging and interesting problems.

Currently I work on a contract modeling system that enables doctors to analyze the contracts that they have with health-care insurance companies, cross reference them with their billing history, and figure out if they are being underpaid. I'm sure for anyone that is not a computer scientist this sounds incredibly boring. It's actually very fitting that it would considering the nature of the computing world. We invented computers specifically to do our boring work for us. It seems obvious that the work they do would sound boring. It's rare for a computer to get to spend it's CPU cycles on something fun an exciting like playing Chess. Such computers should consider themselves very lucky.

The challenges involved with the contract modeling project range from designing fast algorithms for cross referencing with billing history, creative mechanisms for caching previously computed values when the user will not be slowed down by the computation, and most importantly, the design of a sufficiently expressive language and interface for modeling the contracts that will not destroy the performance of the aforementioned algorithms. The work involves a lot of engineering and creativity as well as a lot of collaboration with other developers and non-developers alike.

Now don't get me wrong, writing Round was very interesting for me. I had total design control over the project, which is always nice and I had some creative input on the user interface and audio. I also learned new technologies which were really fun to use but really the allure to this project was that the result was fun. I was making art and helping my friend see his own art career come to fruition. It was (in direct contrast to my day job) something that my friends could go see and say "Wow, Mike, this project is really cool." It's a project that I personally enjoy using a lot.

Since none of my friends, save Todd, are doctors I don't really get that from my work. Actually I myself have no use for the software that I write at work, but that's not important. It's fascinating and it's solving a real-world problem. The state of health care in the United States, in my opinion, is on the verge of a logistical crisis, and has been for years. The company that I work for, AthenaHealth, is working to fix what it can with really good technology.

It does feel good to be working to solve a problem that effects us all on a political level and it's true that if a company's goals were too far off or even opposed to my own, I would not do the work. But I honestly, feeling good about the cause is mostly an ancillary benefit. For me, it's all about the technical challenge, not the result. I think most programmers would agree with me here. It just goes to show that you really can't conflate how interesting a software project is with how exciting the result is.