p.s. далее речь пойдет на примере разработки, но думаю актуально многим

Многие в IT страдают от перфекционизма. Например, в разработке есть фраза «нормально делай – нормально будет». Но она часто употребляется в контексте, что, мол, либо делай очень заебись, либо не делай вообще. В итоге, у IT-инженера часто задачи не двигаются, дедлайны нарушаются

Иногда в командах это ок, например среди таких же коллег разработчиков. «Полировать» код и делать идеально, даже нарушая сроки. Иногда, даже бизнесу это ок, если аргументировать задержку той или иной задачи… но не всегда такое ок

В начале своего пути я больше страдал перфекционизмом, чем сейчас. С опытом пришло понимание, что нужно найти золотую середину и идти иногда на компромиссы. Бывает, хочется все отрефакторить и сделать «по красоте», но бизнес хочет другого – быстро и не дорого. Часто ещё бывает так, что фичи, которые хочется долго «полировать», в итоге окажутся на «мусорке» и не стрельнут… 🥲

Именно поэтому нужно находить золотую середину, но как научиться этому? Нужно выйти из «есть только хорошо-плохо», расширив промежуточными значениями. Для начала можно ввести «достаточно хорошо», а потом вообще перейти на «достаточно» 😁 Если «хорошо» у нас 100%, то «достаточно хорошо» наверное 75-80%

Главное, чтобы этого было достаточно для решения задачи. Если пользователь не заметит оставшиеся 20%, а бизнес не получит от них пользы, возможно, и не надо делать идеально на 100%? Всегда можно вернуться и улучшить позже, если фича вообще окажется нужной

Мне кажется, что умение вовремя остановиться и отдать результат – очень важный навык. Возможно, даже важнее, чем стремление всегда сделать всё идеально