Compromise isn’t indifference

Engineering is about weighing trade-offs of different options and determining a course of action afterwards. It's very common in problem-solving, but the challenging part lies in where to draw the line for solutions to be considered reasonably good.

I have always been working in product teams with a keen interest to learn about how things work behind the scenes. It serves me well to form a more solid understanding of how components connect to each other, as well as exposing me to many more "broken window" experiences.

Some coworkers suggested that I learn to live with things as they are in a job. Aside from genuine appreciation for the advice, I'd like to point out the other side of the spectrum:

Don't confuse compromise with indifference.

Let me share an example.

Our internal website's login flow had been broken for years and became an elephant in the room due to its negative impact on productivity.
I attempted to raise concerns on it. Not surprisingly, all I got back was "learn to live with it".
Gradually, the tech debt turned into the "de facto" way of doing things for the new members who are lack of context of the issue.

I finally decided to fix it myself and came up with a compromised solution.
Fortunately, It caught the attention of the infrastructure team, and we worked out an improved solution together.
The problem was solved without much compromise in the end.

All of this happened silently, except the de facto way of doing things needed an update.
Yet, this time, it was my turn to be indifferent .