What Photography and Programming have in Common

Ladies and gentlemen, allow me to share with you a tale of two photographers.

My fiancée and I were featured in a piece for our local newspaper a couple of weeks ago. The columnist wanted an image to accompany her content, so a photographer was sent to my apartment to take a photo of me and my bride-to-be.

This went down about the same way I expected. Some nondescript dude with a camera walked in, looked around the room for all of about six seconds, arranged a semi-interesting shot involving a mirror, snapped a few pictures and left. This took around ten minutes.

A few days later, the writer for the aforementioned article called back and asked if she could send over another photographer. Apparently the shot the first guy had lined up was too similar to a shot the newspaper was running on another article, on the same day, in the same section, so they needed a new one.

The second photographer was Christopher Pike.

Christopher ran things a bit differently. After introducing himself, he spent a few minutes looking around my humble abode and the surrounding area. He then asked my fiancée and I what we thought of a few potential shots, and started taking pictures. A lot of pictures. We posed on our balcony, on a bench, near a wall, next to a fence, under a tree, and probably in other places that I’ve since forgotten about. Every time Christopher noticed something that might make for a cool photo, he asked if we wouldn’t mind posing for it. In total, this process took over an hour.

It’s important to note here that the first photographer and Christopher were both freelancers hired by the newspaper. They were probably both paid the same amount. But while the first guy spent ten minutes taking a picture he had decided upon in advance, Christopher spent about seven times that long experimenting and looking for the perfect shot.

What does this have to do with programming?

Just like photography, programming is a craft.

That first photographer, the one whose name I can’t remember, was just in it for the job. The editor wanted a cute photo of a cute couple, so our unremarkable photographer took one and took off.

This is how a lot of equally unremarkable coders look at programming. You need a function that converts X inputs into Y outputs? Sure. Let me whip up a quick algorithm that does that. Done. What’s next?

Christopher, on the other hand, was there to take great pictures. He was passionate. He approached photography as a craft. Yes, the output was a photo that he could sell to a newspaper, but believe me when I tell you that’s not why Christopher is a photographer.

This is how I look at coding (and hopefully how you do too). You need a function that converts X inputs into Y outputs? Ok, let me consider the context, ask a few questions, then create a solution. Functionally, it will be the same as Joe-first-photographer’s solution, but as a programmer that cares about his craft, I took the time to:

• Verify that yes, a single function is the best solution.
• Keep future maintenance and extensibility in mind.
• Write clear, reusable code.
• Add useful comments where necessary.
• Refactor my function to be as simple as possible.
• Change all my spaces to tabs to match the existing code-base.

Which photographer would you rather hire? Which programmer would you rather have on your team?