Programming for self satisfaction vs. Product value

I think all engineers have been through this phase during their career. Some may never leave this phase whilst others grow to see different values. This is to do with crafting for enjoyment.

I remember when I was having so much fun building components in React and I understood everything. My work felt like it had value and I was getting job satisfaction. It was code first, product second. I enjoyed developing the code quality, but I didn't look into the value of the product and future for the customer.

When a new product lead moved into our team and shared a vision of a new and improved product scepticism and debates started to occur. It was to move all Frontend logic to the Backend. Make all components generic and reusable. The components are to be composed from a server-side response, a domain specific language (DSL).

What this meant to me is that I will no longer feel that the Frontend code has much value anymore. Once I've built all the modular components, my job is done. Due to this a number of people left the organisation. They felt no longer valued, and moved on. I stuck to it as I was curious to learn the direction. It made sense from a product perspective.

The idea was that designers and product teams can come up with ideas and test them fast. The source of truth would come from the server and the clients (Android, iOS, Web) would interpret the response and build the components. Since the components would be compiled into the Android and iOS apps, they won't have to create app releases to the stores and test fast, like it is on the Web.

As someone who likes building products from a young age, this idea excited me. I learned that I cannot focus on just the craft and enjoyment in building but also focus heavily on being customer centric and building a great product.

It helped push me from being too complacent in my craft and focus on finding solutions to help solve the product. From working on a lot of Frontend code, I moved to help design GraphQL schemas to serve scalable responses. Helped lead other teams into building schemas and using the platform. I got to solve real complex issues due to the goal of the product. If I had not leaned into this, I wouldn't have learned as much and be complacent in building React components.

If you believe in a vision but it goes against your normal ways of developing, break out of comfort and lean in. It's far more rewarding.