Problems Already Solved

Somewhere I recently heard someone say something like, "Programming is easy; all the interesting problems have already been solved by mathematics." I was a bit taken aback by this at first, but it got me thinking about what problems I am solving when I write code. When I'm programming, am I more often addressing a real-world problem, or some kind of software problem? How much of my code is spent on converting, transforming, serializing, deserializing, logging, formatting, validating, and error handling? Usually too much to be very interesting. It's all plumbing, but what I really want is water.

If I look at the systems I have worked on professionally, an alarming number of them do exactly the same thing, regardless of the business or the problem domain. It's just setting up a place to store data, a way to present it to users, and a way to translate it back and forth. There is still the question of where and how to build in domain logic and intelligence, and that's where most of the interesting debates take place, but this is still a woefully small slice of the pie. Maybe this is why I love writing command line programs. Come to think of it, maybe this is also why I love writing unit tests. There's no user interface, no data persistence, just logic. Okay, you're right, there is still setup and teardown plumbing, but it's not too hard to keep that stuff separate and out of the way. I also love working through the Project Euler problems. The programs feel pure. Just find the answer, and that's it.

I recently completed an online course in machine learning from Stanford Engineering. I loved it. It covered common applications of machine learning such as reading human handwriting, recognizing objects in images, and recommending movies and music. These applications are driving major features of Gmail, Facebook, Amazon, Netflix, and Pandora, to name a few. I was surprised to find that most of the course focused on math. The programming part was not much more than an afterthought. We did programming exercises in a language called Octave, but the work could have been done in any language. These problems are solved by math, not by programming. The programming just does the math. It's a lot like the role your calculator plays in your calculus class. You solve the problems; the calculator just does the math.

I was intrigued by the scene in the The Social Network where Zuckerberg has the idea and hacking skills to slam Facemash together, but he has to ask his buddy Eduardo Saverin, not a code slinger, for the "key ingredient": a ranking algorithm. The problem has already been solved by mathematics.

There are countless opportunities in the world today to make a dent in the universe by applying some existing mathematical solution to a modern problem. I'm looking for one.

Compassion-Driven Development

I have been developing software for a pretty long time now. I have worked on a lot of systems in a lot of different environments. In several of these places my orientation process included a visit to the place where the end users were, a call center or client site or whatever, to see what they did and how they used the system. Oddly enough, this usually happened once when I first started, but pretty much never again.

I recently wrapped up a project that afforded me an opportunity I had never had before as a software developer. I sat with my end users every day. I lived with them. This may sound like a bad idea, and in many cases it might be, but in this particular context I loved it. I have never had such a tight feedback loop. I could push out a new feature and within five minutes hear someone down the row yell, "Hey, look at this!"

Not only did it give me the chance to experience their reactions to my work, but more importantly it gave me the chance to see what they needed. While we geeks love to complain about users asking too much, sometimes they ask too little. Being in the midst of these folks gave me the chance to see them doing what they did everyday. They were working with a legacy system that left a lot to be desired in the way of user experience, and they had come to accept far too many inconveniences as facts of life. They were doing so many manual tasks that were easy to incorporate into the system. They had built processes around design flaws and browser limitations.

They may have had ideas, complaints, and requests, as users always do, but they often overlooked the most obvious things. There is pain in every job, and sometime users can't quite imagine how software improvements could relieve it. Or maybe they've lived with the pain for so long that it no longer occurs to them that they're wasting time and energy. Being with these folks every day as they worked gave me the chance to say to them, "You should not have to do this."

I call this Compassion-Driven Development.