Categories
Customer Experience Software Development

Classics Week #1: What Photography and Programming have in Common

This post is part of the Classics Week(s) feature, which will run for three weeks while I’m off overseas. It’s the first of three posts from the early days of the blog, dug up from the archive and polished ’til good as new!

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

Back in the summer of 2010, my fiancée and I were featured in a piece for our local newspaper. The columnist wanted an image to accompany her content, and sent a photographer to our apartment to take a photo of me and my soon-to-be bride.

The photography session played out as I’d expected. Some nondescript ‘dude’ with a camera sauntered 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. Took around ten minutes.

A few days later, the writer called back and asked if she could send over another photographer. Apparently the shot the boring fellow took 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 different one.

The second photographer was Christopher Pike.

Christopher ran things a bit differently. After introducing himself, he spent a few minutes looking around our humble abode and the surrounding area. He then asked what my fiancée and I thought of a few potential shots, and started taking pictures.

Many pictures.

We posed on our balcony. We posed on a bench. We posed near a wall, and then next to a fence. Every time Christopher noticed something that might make for a cool shot, he asked if we wouldn’t mind another photo.

After about an hour of this, he thanked us and left.

Like the first photographer, Christopher was a freelancer hired by the newspaper. Presumably, the two of them were each paid the same amount for their work. But while the former spent ten minutes taking a picture he had decided upon in advance, Christopher spent 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 couldn’t be bothered to remember, was just in it for the job. The columnist wanted a cute photo of a young couple, so our unremarkable photographer snapped an equally (un)impressive shot, and left.

This is how 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, and he approached photography as a craft. Yes, the result was still just a photo to sell to a newspaper, but believe me when I tell you that’s not why Christopher is a photographer.

Here’s how I look at coding (and hopefully how you do too):

You need a function that converts X inputs into Y outputs? Ok. Let’s first consider the context, ask a few questions, then create a proper solution. Functionally, it may be the same as Joe-first-photographer’s solution, but a programmer that cares about his craft took the time to:

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

Which photographer would you rather hire?

Which programmer would you rather have on your team?

Categories
Customer Experience Software Development

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?