Hello dear reader!
In this issue:
- Why developers end up behind a camera
- What coding gave my photography, and the other way around
- The tools I built at the intersection
Last year while attending a photowalk, I started to talk to another photographer about the usual topics people in these situations talk about: what are you shooting today, which camera are you using, lenses, and geeking out about photography and the city. As the conversation was flowing, we started to talk about what brought us to Amsterdam, and our day-to-day job. We were both software engineers. And we were not the only ones, it turned out that a bunch of us walking there were developers too.
The moment prompted a question: why is photography for developers such a common path?
I have some ideas about it. As a developer who makes time for photography alongside a full-time job, I see it as a medium to interact with the physical world, a way to capture something that is happening, and to communicate with others. Both camera and code serve as a buffer mechanism between the person and the world. They give permission to look and create. As an introvert, having a camera in hand is like having a shield — it allows me to interact in situations I’d otherwise avoid, like observing people at a celebration, or taking the time to notice something small without feeling out of place. Code does something similar: it gives you a reason to look closely at how things work.
In both code and photography, we are transmitting an idea. When I take a photo, I’m trying to capture an instant, a detail, or a situation that I believe is worth noticing — it’s a way to communicate what I observe with others. While coding, the communication goes to machines that interpret the code, the set of instructions to produce something, and to other humans that will read the code or use the product. In that sense the code is like the camera, the tool to create.
I find this comparison interesting, as in both processes the audience never — or almost never — gets to see the process. The code is usually consumed as the final product, and the photo is usually seen after a selection process and edits.
Surprisingly, I have found that some skills are transferable, from dealing with bugs or bad photos, to thinking in different zoom levels, moving between architecture-level and line level or wide shot to detail shots.
There are some lessons I’ve taken from coding into photography: recognising patterns, identifying repetition, symmetry, edge cases. It is about noticing the regularities and what stands out. The details, or not so subtle elements that make the scene unique, such as the grocery car that was dumped in a canal, or the pop of colour that contrasts with everything else.
One similarity I have found in both worlds are bugs. Not everything goes as planned, and there are issues to be resolved. Not every photo works — the idea I had in mind turns out to be a bad photo, or the composition was not as good. The way I treat it is as a bug: rather than deleting the code, I try to understand why it didn’t work, how it could be improved, and try again. On a recent walk I spotted a little car with a trailer, the kind of toy kids play around with. I shot it from below, almost at ground level, thinking the perspective would work. It didn’t — it looked flat, lost between the other elements. So I tried again from eye level. Better. More reference points, more context, a clearer way to show the thing in its environment. Test, iterate, resolve, and keep building.
In a similar way photography has influenced the way I write code and how I work on technical domains. Slowing down and taking the time to review the full scene or codebase, to identify where the anchor points are, and how to better understand all the relationships in the space. In code, as in photography, the way the elements are arranged plays a key role.
Finally, a duality I see between software development and photography, is the act of creation. I believe that’s why developers get into photography, we like to create new stuff, to build. The full process of experimentation and creation becomes addictive in a way, and in some cases one practice contributes to the other. Take for example PostFlow, a tool I built to cross-post across networks and schedule posts so I don’t have to spend time publishing in different places one by one. It also gives me analytics on my photos that I’d otherwise need to collect and process manually — everything in one place, the full picture at a glance. Or Pixels & Patterns, a creative coding experiment to identify the colour patterns and rhythms in my photographs, a way to bridge code and photography. The cross-pollination is there.
As I reflect about the question from that photowalk I realised that it wasn’t really why developers do photography. It was what each side gives to the other. Photography for developers is less about the gear and more about having a second practice that sharpens the same instincts: observation, composition, iteration.
What’s the one habit from your creative practice that has shaped how you work? Do you recognise some duality and cross-pollination? Let me know!
If you enjoyed this issue, share it with a friend! Know someone interested in photography or development? Send it their way, they might like reading it too.
Luis
