In the company, there were people who, from my perspective, wrote the worst code I had ever seen and didn’t seem to have the analytical skills to break down a problem in an orderly way. Yet they remained. Over time, I realized these people had a solid grasp of the “time” the company was in (hypothesis).

Nobody gets credit for the problems that didn't happen,

Over time, I learned a valuable lesson: companies evaluate performance based on the moment they are going through. In “times of war”, the most important thing is to deliver—even if the code is a disaster, is not scalable, without tests or documentation. In “times of peace”, code quality, documentation, and best practices matter more.

Companies should learn to choose the right soldiers for their war and programmers should know which war they want to fight.

Times of War: There is a heavy workload, with rapid and frequent deliveries, strict deadlines, and a less relevant hierarchy. The key is to launch the product or feature as quickly as possible, even if it isn’t perfect.

Times of Peace: There is more stability and planning. Deployments happen weekly or at a slower pace, with better documentation, validation of functionalities, thorough research, and a more careful process. This scenario also tends to offer a better work-life balance.