Механизм

  Частенько руководители компаний сравнивают сотрудников с деталями большого механизма с названием "Компания" (корпорация, фирма и т.п.). Мой бывший руководитель не исключение. А вот я хотел бы продолжить аналогию. Продолжать буду на примере конторы по разработке ПО. Деталь - программист.
  Что нужно механизму от деталей? Чтобы они были плотно подогнаны и работали без сбоев. Любое изменение вида детали может привести к дисфункциям механизма. Желательное изменение детали - её уплотнение, укрепление. А теперь перехожу от аллегориям к примерам.
  Укрепление программиста - доведение текущих навыков до механической памяти. Выполнение задач без лишних временных затрат - сел и кодишь, кодишь и кодишь. Изменение программиста - появление новых функций, изучение новых технологий, приемов и получение новых знаний.
  Если программист повышает навыки ИТ менеджмента - он начинает понимать приемы, применяемые к нему, начинает видеть недостатки системы - это начинает влиять на его действия - деталь меняется. Программист изучает рефакторинг, узнает о паттернах - ему уже не нравиться то, что он накодил - его тянет изменить и улучшить код. Программист набирается знаний - деталь растет и уже не помещается в рамках его места в механизме. Если нет другого места под его новые размеры - программист вынужден уйти.
  Любое изменение детали в механизме, так или иначе - конфликт. Идеальная ситуация для механизма - постоянные статические детали. Появляется новое место для детали - находится новая деталь, ставится на место.
  Для каждого сотрудника есть выбор - держаться за свое место, не тратя время на активное развитие (совсем без него не получиться), не рискуя и не переживая, либо, рискуя потерей своего места в "механизме" изменяться.
  Скоро придут новички. Вот думаю, двинуть им такую тему, или все таки не стоит? :)