.reduce is like a fancy adjective with an obscure origin, or a expensive scotch that is only broken out for special occasions. It's not part of your everyday vocabulary. It feels ethereal. To be honest, I rarely use it for most common use cases. But until recently, I kept it away at a friendly distance.

I've grown an appreciation for its essence lately and believe the concept of the reducer offers lessons beyond your code.

In programming, we use reduce to enumerate an array of items, perform some calculation, and return a single value.

In practice, some simple examples would include taking an array of numbers and returning the sum. Or an array of strings and returning a concatenated version of all of them.

In theory though, the main idea is that you create some Box to distill ideas; An array of different ideas go in, and the box distills them into a unified, simplified concept.

The idea of reduction is a useful mental model for how to think about adding value and impact in your career.

As an engineer, the best way to make an impact is to take on more responsibility and to work more cross-functionally. This means working across complex systems and reacting to wide-ranging requirements. Oftentimes, when working on a product with a single, many teams will weigh in on how to best achieve that goal. What ultimately happens is teams start with the solution, because that is the most concrete way to solve the customer's problems. However, it's rare that the product, marketing, customer success, and engineering teams all agree on a solution. As a product-focused engineer, it's important to be able to evaluate the potential solutions across multiple dimensions: time & complexity ( effort ), and perceived impact ( reach ).

To do this effectively, you will need to reduce the array of different options and formulate a single POV on the best path forward.

Your job is to be the reducer.