Программисты проходят путь от усложнения к упрощению. Менеджеры же часто пытаются простыми решениями подойти к сложным задачам. Но что такое "просто" и "сложно"? Это можно как-то оценить объективно?

Обучившись программированию, я часто делал решения, перегруженные деталями, со сложными абстракциями, "магическими" функциями. Со временем я прокачался и осознал, что хороший программист - это не тот, кто пишет много кода, а кто может решить задачу без кода или с минимальным его присутствием.

Когда стал старшим разрабом команды разработки, аналогичное поведение я замечал за новичками и взял на себя задачу по их обучению. Зачастую мы говорили о том, что "решение классное, оверинжиниринг - это нормально, но смотри как можно было упростить". Тогда я окончательно закрепился в понимании, что хороший инженер должен быть ленивым.

Так я начал уходить в менеджмент, предлагая бизнесу более простые пути решения их задач, создавая MVP и тестируя гипотезы. Параллельно я принял мысль, что новичкам в программировании легко сделать сложное, но сложно что-то упростить.

Оторвавшись от программирования, работая уже с понятием клиентского сервиса, я немного позабыл про это явление. Поэтому в какой-то момент столкнулся с тем, что "ребята, это же так просто, почему вы не делаете так?" в разрезе новых задач. Хоть мои сотрудники сейчас производят абстрактную услугу, вместо видимого кода или физического продукта, они так же могут сделать сложно, но не знают как сделать просто.

Но термины "просто, легко, сложно, тяжело" - это абстракты. Можно ли их объяснить и визуализировать? Это сделал Rich Hickey в докладе Simple Made Easy. Поэтому рекомендую вам с ним ознакомиться: https://www.youtube.com/watch?v=LKtk3HCgTa8 Примерно до 40й минуты можно смотреть, а потом остановиться. Потому что дальше он уходит совсем в программирование.