Skip to content
Home » How to Shop Like a Software Engineer

How to Shop Like a Software Engineer

Shopping with a software engineer process

No, I’m not talking about coding and building your own automation system for buying. Actually, the perception of software engineers coding most of the time is misplaced. Nowadays, the actual coding part isn’t as big of an issue.

No, what I am talking about is the way software engineers think when they are building behemoths software like Netflix, Google, Uber, <insert cool tech company you’ve heard of here>, etc.

Problem Solving.

It might sound very abstract but it’s something that we do day-to-day, with varying levels of success. Any decision we make has some level of thinking behind it that could be considered your approach to solving the problem.

Let’s go shopping

Not so long ago, I decided I wanted to buy a new lens for my camera. Just starting out in photography(check it out here) and it’s incredibly hard not to drown in the different technology in the space.

From tons of lenses, cameras, tripods, bags, and who knows what else, to choose from, it was time to bust out the skills that help me make a living.

Photo by Egor Myznik on Unsplash

1. Understanding the goals

When thinking of designing any software, it’s fun to think about the latest “container management system”, but the reality is, you have no idea what you’re in for. So now isn’t the time to think about what specifics of the implementation, but the understanding of the goals.

Why do I want to buy a new lens?

What type of photography do I want to explore?

What will this new lens get me?

Asking these questions is like having water splashed over me while I’m daydreaming. But it does its job. To get me to concretely think about my desire to buy a lens. Specifically, I really had no idea what I wanted to explore. I just knew that the kit-lens is good for beginners, but I wanted to be a pro **cringe.

But thinking deeply, I realized I wanted to improve the sharpness of my images and be able to take better landscape and scenic photography.

2. Determine the scale of your design

I might be able to code up a quick version of Google’s search engine right now. But do I really think I’ve accounted for the scale of billions of queries per day, and the massive amount of data I need to be able to store?

If I have to be honest, hell no. Even if I lied it would probably not be believable. Different scales require different approaches. To search a page for information, I can just use ctrl+f, but to search millions of files for a word, unless I’m willing to wait several minutes/hours, requires a much different approach.

So let’s understand the scale of the problem.

In terms of lens, let’s reframe to thinking about versatility. Different lenses have different capabilities. Some lenses, like the Sigma 60-600mm f/4.5-6.3 cost a whopping $2000 but have stupidly strong zoom capabilities. If I want a one-size-fits-all and was focused on being most flexible about focal length, this might be the solution.

But unless you can outright buy everything and anything, it doesn’t make sense to design for a scale that you don’t need. For me, My priorities were more focused on the quality of the image, and versatility took the second seat.

My scale could be brought down significantly.

One caveat to that though, is I might not be planning for future thought. But since camera electronics’ prices hold relatively well, I could afford to not have to worry about upgrading later on without a hitch.

3. Brute force solution

How would you determine if the number 73 was in the sorted list of : 1,2,19,49,49,57,73,89,93,94,95,102,111,345893 ?

Well if your eyes didn’t immediately dart to the center and start looking from there, the most direct approach is to start from the beginning and scan from there. This is what we call a brute-force solution. One where efficiency isn’t really the concern.

The idea is that once we have a brute force solution, we can often find ways to improve from there.

For me, if I didn’t know what type of features in a lens mattered more for my goals, or what the different price indicated, a straightforward approach is to quickly do a google search for “Best Lens for Camera <XYZ> for <enter goal here>“.

You now have a starting point. You could choose to outright buy the #1 item, but if you’re doing this much work, it’s likely that you have some constraints to meet. Most likely it’s the $$$$.

4. Copy/Paste

A lot of the time, the software you interact with is rarely made up of novel code. Copy/Paste is an expected ingredient in the code. But what’s more though is that the system itself might have leveraged designs of other software, even from other tech companies.

I mean, we do it all the time. That’s what Google is there for. To search for existing solutions. Thanks to the internet, the problem isn’t finding a solution, it’s finding a solution that fits. But nevertheless, it can act as a way to gauge your thoughts against the world’s.

This usually can come in the form of just reading reviews or blog posts. But the thing about reviews is that we want all positives. A few negative reviews and our risk-averse psychology kicks in, making it hard to get over the negative review.

Unless you’re paying top-dollar, you’re unlikely to get perfect reviews. So what I did instead, is to focus directly on the photographers I admire and follow. Looking at the difference in photography across different lenses gives a much better idea of what solutions work well, cross-sectioned with my own budget constraints.

5. The imperfect, perfect solution

Perfect software doesn’t exist. That’s actually why most of us continue to have jobs. Whatever you build today, might not fit the needs tomorrow. It can be incredibly frustrating to not be able to meet all the constraints, but that’s the world we live in.

A world without limitations would be pretty boring.

The key is to find the solution that fits the most crucial constraints. Failing that, maybe it’s important to re-evaluate the constraints and the needs themselves. Software projects that don’t seem viable get shelved. Even with a design that meets the budget, it’s likely giving up something.

The same goes for deciding whether or not to buy something. The lens I ended up going with was the Sigma 16mm f/1.4 wide-angle lens. It doesn’t have any zoom capabilities, but what it does do, it does well. Also, if I decide to upgrade my camera, I won’t be able to use this.

Although I want to be able to buy something and be happy with it for a lifetime, I know my requirements will likely change. The goal might shift, the scale I want to operate at will change. But being constrained means if this really is a problem worth solving, it has to fit within the limitations.


It’s easier said than done to approach problem-solving in a systematic way. Especially when we become overloaded with different options, with marginal differences. For someone who is incredibly price-sensitive, even a $5 difference might seem worth spending 3-4 more hours of research. But time itself is a constraint.

Obviously, the solution I laid out isn’t a one-size-fits-all, but more of a framework to help guide how to actually think about finding a product. Intentionally treating all decisions as problems to be solved allows you to apply different strategies to get where you want to be.