Developers Should Learn Photography

Photography is the love-child of art and technology: you need a tasteful eye and skilled hands to get a great shot. Dipping your toes into photography, even without becoming a great photographer, will make you a way better developer. Let's talk about why – I'll share some of my personal experiences with photography and how photography helped me improve as a software developer, then I'll help you out with getting started.

Photography and development have a lot in common. So much so that I find it odd that more developers don't dabble in digital darkrooms. How are photography and programming alike? Good question.

Programming is an inherently creative process – you literally create. As a developer, you take abstract ideas that exist only in your mind and turn them into the living machinery of working software. Photography is also creative, but unlike other creative processes like painting or drawing or writing, it has a very strict technological component.

Like a computer, light behaves in specific, predictable patterns. Photographs are short exposures of light – how you control light defines how a photograph will look. Nothing says "software developer" quite like fiddling with the kinds of esoteric controls found on the back of complicated-looking cameras. Photography fits software developers perfectly – it's creative and involves science and technology – but what value can developers get from pursuing this hobby?

One of the biggest revelations I had when I first learned how to take photos was that what I see and what the camera sees are not necessarily similar at all. A camera's perspective – by which I mean the way it sees the world, not just its focal length – is very different from a human's. While we use our eyes and our brains to interpret a scene, cameras use specific lenses set with specific settings to expose their light sensors. This disparity in perspectives is a lot like how users and developers see the world very differently; it should remind you that not everyone sees the world like you do.

Not only do perspectives other than your own exist, but in fact most people don't see things from your point of view. Being conscious of this fact has really helped me while writing software because it is a reminder that I need to put myself in users' shoes – just like taking a photo, I need to consider things from another perspective. I need to have empathy. How will a user feel about my interface? How will another developer interpret my method name? These are important questions to ask while programming.

Another aspect of learning photography is reflection. Improving your photography, like any creative endeavour, requires you to reflect on your work. In order to improve as a photographer, you need to stand back and objectively evaluate your work. This takes a lot of effort. Taking a digital photo involves having a vision in your mind and trying to create that vision within the camera. You take the photo and reflect on how it realizes, or fails to realize, your original vision. Then you try again. Maybe the exposures you get aren't what you originally intended. Maybe you change your mind about what your goal is. In any case, reflection is a critical component.

When I first started taking photos, I realized that seeing the results of my photography differ from my expectations is no different from seeing a program take an unexpected path of execution. I now see improving as a photographer as just a macro-level run/debug cycle.

Both photography and programming demand a technological understanding of the tools, but to be great at either, you need empathy and reflection. After developing these two habits, I've applied those skills to my code. I noticed that my coding skills had deficiencies. Long-standing ones. Then I fixed them.

These two values exemplify the value I've gotten from photography. In my experience, developers tend to suffer from a somewhat limited perspective – they don't think in terms of their users' goals and their products reflect this.

Studying the principles of photography has also enabled me to learn about composition, colour, and other components of design, even though I lack the ability to draw. After all, a good photograph is designed to elicit some response from the viewer; photography is steeped in design. This competency in design has helped me build more usable applications, which in turn helps my career as a software creator.

I've also found that when a puzzling programming problem has me beat and frustrated, I like to go outside and take photos. Programming doesn't have to be a developer's only creative outlet – I use photography to unwind and relax. Switching gears and getting my creative juices flowing is often exactly what I need to solve a tricky problem.

Alright. Say you're convinced that photography is something that will improve your development skills. You've seen how learning to take photos boosted my programming skills and you want to get in on this horizon-expanding and perspective-broadening action. So what's next?

Getting started is not hard at all. In fact, you can probably already start by taking shots with your smartphone – most smartphones have pretty capable cameras in them. So start shooting!

Download Instagram, Google the "Rule of Thirds", take photos, and reflect on your own shots. Explore Flickr or 500px and contemplate on why you like the photos you do. Is the composition technically compelling? Does the subject matter evoke an emotional reaction? Do you think the photographer used natural light or a flash?

Ask your friends what they think. If any of them have experience with photography, let them know that you want their feedback – tell them not to hold back. It's not easy to hear critiques like this, trust me, but it's a great way to learn. In fact, being able to take critiques is a great skill in general – you'll learn to appreciate it.

Using Instagram is a great way to get started because the app places significant limits on your technical abilities as a photographer, and those limits will inspire your creativity. We all know that constraints breed creativity You'll discover the bounds of those limits really quickly, like when learning a new programming language. And just like when learning a new language, you'll come up with workarounds to circumvent those limitations.

You don't need to spend thousands of dollars on gear to get good at taking photos. You only need a basic camera, like the one in your smartphone, and some patience.

The biggest reason for developers to know to take and appreciate photographs is to grow, to become more well-rounded people. Our industry relies on growth for the rapid pace of progress it's seen in its short existence. If you stop growing, you'll be left behind.

Programming Magic

When I was in university, every time I sat down to program I felt a rush of excitement and a sense of exploration. I would always learn something new, and things always felt new to me.

By the time one programming language was beginning to feel old, I would start learning another for a new course or a new project. Eventually I settled on Objective-C and I've spent the past four years refining that knowledge.

Somewhere along the way, programming lost its magic.

I've now become a professional who recognizes a problem and reaches for the exact tool to solve it. There's no room for exploration any more. The most enjoyable parts of programming have become the parts where I get to explore a new API, but most of my work has become routine.

Which brings me to ReactiveCocoa. A whole new paradigm to write programs in. I'd be lying if I said part of my infatuation with ReactiveCocoa wasn't rooted in the fact that it's brought back a sense of wonder and excitement to writing programs. However, ReactiveCocoa feels like magic because it is magic: a collection of clever tricks on top of the Objective-C runtime that gives programmers the freedom to program declaratively.

It's learning curve is steep, but the creators of the project are working on it. Every question I've asked about it has been promptly answered by one of them on StackOverflow.

I would highly encourage you to check it out. I'm working on a series of new blog posts that'll help flatten out that curve. Stay tuned.

ReactiveCocoa

A few weeks ago, I wrote an overview of ReactiveCocoa, the hottest newest hottest thing in the Objective-C community.

If you've ever wanted to write functional, stateless Objective-C code but didn't know how to start, ReactiveCocoa is your answer. Unforuntately, it's got a steep-ish learning curve, but I'm working on an introductory post. Stay tuned.

The Value of Cocoapods

Lately, I've been exploring more of the open source community and examining how it is interacted with by the Objective-C community. I think that iOS and OS X developers tend to be afflicted by the "not invented here" syndrome, which is ironic considering Objective-C's creators originally intended for compiled objects to be bought and sold as commodities.

This tendency to eschew open source software comes from the top, though: just look at how hard it is to integrate open source software in Xcode projects.

Recently, however, there is a new player in the open source iOS and OS X community: Cocoapods. This tool, written in Ruby, manages the dependencies and versioning of third party, open source libraries, integrating them into an Xcode workspace. Traditionally, this has been lot of work and a headache.

Many developers are sceptical of the tool – and rightly so. After all, this is a huge shift in the way we do our work and can demand a lot of time and effort – and therefore cost – in switching. That's hard to swallow if you're not completely convinced of the value of the tool.

Using Cocoapods means never having to worry about per-file compiler flags (e.g.: for ARC) again. It means not having to set linker flags or header search paths for every library you incorporate into a project. It makes upgrading libraries later a breeze. To me, that's worth the amount of work it takes to get up and running.

However, there are drawbacks. Using Cocoapods makes it difficult to contribute back to open source projects (when compared with git submodules). Cocoapods represents another step to follow when cloning a repository, and the initial setup can be nontrivial. It's also not perfect – the current version, 0.18.1, still has some bugs. 

Cocoapods is a maturing tool that's come a long way and shows a lot of promise. If you've previously looked at the tool but passed on it, I would encourage you to look again. It's a great way to easily incorporate lots of open source goodness into your project. As my friend Jason puts it, don't think of it as "not invented here", but rather "proudly discovered elsewhere."

Responsibility

Since I was little, I've always wanted to be a teacher. In university, I did a lot of tutoring, but after a Summer doing research, I decided that a career in academia was not for me.

Still, I loved teaching. More than the love of teaching, I felt a responsibility to teach. No one gets where they are on their own. We all have help from mentors, friends, and Stack Overflow. I write, blog, and podcast not just because I enjoy teaching, but because I feel a responsibility to pass on knowledge.

Yesterday, tickets for Apple's Worldwide Developer Conference sold out in less than two minutes. I'm one of the lucky 5 000 people who got a ticket. All of us have a responsibility to gather bugs to report to the Apple engineers and to learn from the sessions to teach others what we learn.

UICollectionView: The Complete Guide

My second book, UICollectionView: The Complete Guide (Kindle) was released this week.

It's a relatively short eBook at 176 pages, but I cover every aspect of using UICollectionView. It's only $20 (cheaper on Amazon), so if you're looking for a comprehensive walkthrough of the framework, this is perfect.

Running From and Running To

I listened to the latest episode of my friend's podcast the other day and its story really resounded with me. The episode tells the tale of a man who left his life behind to explore India and how that didn't really work out very well for him.

One of the key parts of the message was near the end: that running away from something because it's difficult is the easy way out. The difficult thing isn't taking a leap and finding yourself – the difficult thing is staying where you are and working to improve your situation. The point was that the man thought he was running toward something new, but he was really running from where he was.

I recently quit my job at an established Toronto startup and started a new job at a well-known digital agency. Since listening to the podcast episode, I've been reflecting on my choices, the actions I took because of those choices, and the motivation behind them. To be completely honest, I was running from a situation, but only after trying everything I could to improve it. However, I was also running to a company that I knew I wanted to work for.

I'm proud of the choices I made and how I handled the situation. That'll be my motivation the next time I have to make a difficult decision – any difficult one. Will I be proud of this decision in three months, or will I regret it?

Google Street View Hyperlapse

Today my coworkers in the Teehan+Lax Labs group launched Google Street View Hyperlapse that you should totally check out.

Imagine programmatically stitching together hours of Google Street View imagery to create moving time-lapse videos. Amazing.

The source is up on GitHub.

I feel so lucky to get to work with really creative people who would come up with an idea like this, and then execute it so well. This is the firsts T+L Labs project that I've seen from beginning to end, and it's been awesome to see the team work on it. Good job, guys.

Some Thoughts on Crowdfunding with Indiegogo

My Indiegogo campaign to raise money for my next book has reached its goal and I couldn't be happier.

I've got a couple of thoughts that are worth sharing. First, a lot of people asked why Indiegogo and not Kickstarter. The answer is pretty simple: Kickstarter doesn't let you fundraise from Canada. I didn't mention this in the Indiegogo writeup because I wanted them to hopefully feature me on their front page (to date, they have not).

People also wanted to contribute more. My perk contribution tiers were $9 for the book, $18 for early access, and $100 for a writeup in the book itself. Lots of people contributed $50, but didn't get anything extra for their contribution. In hindsight, I left a price umbrella of sorts. I'm still contemplating what I can do to thank people who contributed more than they had to to reach a park – I'm open to suggestions.

I was unabashed about sharing the campaign on Twitter to my followers, nor about asking influential people in the community to help me spread the word. Obviously, I didn't want to be a nuisance, but I had a lot of positive feedback from people I contacted about helping me.

Indiegogo's Field Guide has some suggestions for a successful campaign, including adding new perks. They point out that most repeat contributions are to gain newly added perks. I'm reluctant to do this just because it feels a little dirty asking people for even more money, especially where I've already met my goal.

If I had to do it all over again, I would not have launched on a Friday night and I would have included more perk levels – one at $50 and one at $250.

I'm incredibly grateful for everyone who has helped out, either by contributing or helping to spread the word. You all rock.

Springboard is a Success

Springboard, the podcast I launched only nine days ago, is already a success. I've bene overwhelemed by the response from the Internet. Thanks to everyone who's gotten in touch.

The show is a success in the one dimension that I care about: it's being listened to. The show's site receives over three hundred visitors a day. In contrast, it took years of blogging before my own site ever approached that figure.

I've recorded a number of episodes now, and it's been remarkable to meet with really interesting people and get them to share their stories with listeners. Absolutely fantastic.

If you've enjoyed the show, please consider rating it on iTunes, which would help new listeners find it.

I'm really excited about where this is going.