The Camera Taught Me Before Any Codebase Did
How a photography career made me a better software architect, and why your “unrelated” skills might be your biggest advantage.
Nobody takes you seriously when you say “I’m a photographer AND a software architect.“
I get it. On paper, the two don’t connect. One lives in pixels and light meters. The other lives in database schemas and deployment pipelines. When I tell people I spent years behind a camera before I ever designed a system, I can see the mental filing happening in real time. Creative type, probably not technical enough.
But what everyone misses is that both disciplines are built on the same foundation: composition with constraints. Knowing what to crop out of a frame is the same muscle as knowing what to cut from a system. The camera taught me that before any codebase did.
And I’m not speaking in metaphor. The parallels are structural.
The Exposure Triangle Is Every Architecture Decision You’ll Ever Make
Every photographer learns the exposure triangle early. ISO, shutter speed, aperture. Three variables that control how light hits the sensor. The catch is that you can’t max all three. Push one and the others compensate. Crank your ISO for a dark room and you introduce noise. Open your aperture wide for that creamy bokeh and your depth of field collapses. Freeze motion with a fast shutter and you starve the sensor of light.
There is no perfect setting. There is only the right tradeoff for this specific moment.
Software architecture works the same way. Speed, cost, quality. They’re always in tension. You can ship fast and cheap, but you’ll pay for it in technical debt. You can build it beautifully and thoroughly, but the market window closes while you’re refactoring. You can throw money at the problem, but budget is a constraint, not a suggestion.
The architects who struggle most are the ones still looking for the setting that maxes everything out. The ones who thrive are the ones who read the scene and decide, deliberately, with full awareness of the consequences, which dial to sacrifice.
Photography trained that instinct into me thousands of times before I ever opened the code editor.
Focal Length Is Abstraction
A wide-angle lens captures everything in the frame. Every tree, every person, every distraction. It’s comprehensive. It’s also overwhelming. A telephoto strips it down to the single element that tells the story. One face. One detail. One moment isolated from the noise.
That’s abstraction.
The best systems aren’t the ones that expose every detail to every consumer. They’re the ones that know what to put in focus and what to blur into the background. When I design a service boundary or define an API contract, I’m choosing a focal length. What does the caller need to see? What should be invisible to them? What level of detail serves the story this interface is trying to tell?
Junior developers tend to build wide-angle systems. Everything is visible, everything is accessible, every implementation detail bleeds through every layer. It works. The same way a wide-angle snapshot of a landscape “works.” It captures the scene. But it doesn’t guide the eye. It doesn’t tell you what matters.
Senior architects zoom in. Not because they don’t understand the full picture, but because they understand that the user (whether that’s an end user, another developer, or a downstream service) doesn’t need the whole landscape. They need the one thing in focus.
Golden Hour Is Market Timing
Every photographer knows golden hour. That window just after sunrise or just before sunset when the light turns warm, directional, and impossibly flattering. The light is only right for about twenty minutes. Miss that window and no amount of post-processing saves it. You can adjust the white balance, push the shadows, grade the color. But you cannot manufacture what the sun gave away for free to the person who showed up on time.
Shipping software has the same rhythm.
There’s a moment where the market need, the team’s capability, and the architecture all align. The feature is scoped right. The dependencies are resolved. The customer is ready. That’s your golden hour.
Over-engineering is missing it because you were still adjusting the tripod. I’ve watched teams burn months perfecting infrastructure for a product that hadn’t validated a single assumption with real users. I’ve watched founders delay launches because the codebase wasn’t “clean enough” while a competitor shipped something ugly that worked and captured the market.
The photographers who get the shot aren’t the ones with the best gear. They’re the ones who showed up, read the light, and pressed the shutter. The architects who ship products that matter aren’t the ones with the most elegant systems. They’re the ones who recognized the window and made the decisive call.
See What’s Actually There
If I had to distill both disciplines down to a single skill, it would be this: see what’s actually in front of you, not what you wish was there.
A photographer who falls in love with the shot they imagined before arriving on location will spend the whole session fighting reality. The light isn’t right. The background is wrong. The subject isn’t cooperating. Meanwhile, there’s a better photo happening three feet to the left. One they’d see if they stopped trying to force their preconception onto the scene.
Architects do this constantly. They fall in love with a pattern, a framework, a technology, and they spend months forcing it onto a problem it doesn’t fit. The elegant solution was always available, but it required letting go of the one they’d already committed to in their head.
The camera taught me to arrive with intention but without attachment. To observe before composing. To let the constraints of the scene (the light, the space, the moment) inform the frame instead of fighting them.
That’s the same discipline I bring to every architecture engagement. What does the business actually need? What are the real constraints, not the aspirational ones? What’s the simplest composition that tells the right story?
Your “Unrelated” Skill Is Probably Your Superpower
I’m writing this because I spent years downplaying the photography side of my career when talking to technical audiences. It felt irrelevant. Unprofessional, even. Like admitting I had a hobby when everyone else was listing certifications.
I was wrong. The camera didn’t distract from my architecture career. It built it. Every principle I rely on daily (composition, constraint management, knowing when to ship, knowing what to leave out) I learned through a viewfinder before I learned it through a terminal.
If you’ve got a background that doesn’t fit neatly into a LinkedIn headline (music, carpentry, teaching, athletics, cooking) I’d challenge you to look harder at the transfer. The disciplines that feel unrelated are often the ones that gave you instincts no bootcamp or CS program could.
The best architects I know didn’t all come from the same path. They came from everywhere. And the weird, winding, “unrelated” parts of their journey? Those are usually the parts that make them exceptional.
Tim Wood is the founder and principal architect at Always Curious LLC, a software consultancy specializing in architecture strategy for fintech, payments, and data-intensive applications. He’s also an award-winning photographer, and he doesn’t think those two things are as different as you’d expect.
