Что не нравится на текущей работе?

О профессиональном росте и ценности в работе

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

1. Отсутствие чёткого стратегического видения

Самое деструктивное – это когда долгосрочная цель продукта или команды размыта или постоянно меняется без внятного обоснования. Это приводит к:

• Техническому долгу: когда в угоду быстрым правкам накапливаются хаки, а не качественные решения.
• Демотивации команды: разработчики перестают видеть ценность своей работы, чувствуя себя "винтиками".
• Неэффективному планированию (спринтов, ресурсов).

// Пример симптома: постоянные срочные задачи, ломающие архитектуру
// Вместо планомерного:
async function implementFeatureA() {
  await refactorCoreModule(); // Плановый рефакторинг
  await addNewApiLayer();
}

// Мы постоянно пишем:
function hackForUrgentDemo() {
  // Срочный костыль, который потом станет legacy-кодом
  if (window.legacyGlobalVar) {
    window.legacyGlobalVar.newHack = true; // Нарушение всех принципов
  }
}

2. Процессы ради процессов

Бюрократия в разработке убивает креативность и скорость. Я верю в разумный минимализм:

• Чрезмерные согласования для мелких изменений в UI/UX.
• Многочасовые митинги без ясных outcomes и action items.
• Жёсткие, негибкие методологии (когда SCRUM становится догмой, а не инструментом).

3. Недооценка качества frontend-инфраструктуры

Frontend перестал быть просто "рисовкой кнопок". Это сложная инженерная дисциплина, и часто сталкиваешься с:

• Отсутствием инвестиций в инструменты: нет CI/CD для фронтенда, тестов, линтеров, систем дизайна.
• Пренебрежением производительностью ("и так сойдёт" для Core Web Vitals).
• Слабой кросс-браузерной и кросс-девайсной проверкой.

4. Изоляция фронтенд-команды от бизнес-контекста

Когда разработчиков ставят перед фактом: "Сделай вот этот макет", без объяснения бизнес-задачи, это снижает вовлечённость и убивает возможность предложить лучшее техническое или UX-решение.

// Плохо: требование "сделать точно по дизайну" без понимания "почему"
interface BadRequirement {
  implementModal: (designUrl: string) => void; // Только исполнитель
}

// Хорошо: участие в обсуждении решения
interface GoodCollaboration {
  discussModalGoal: (userProblem: string, businessMetric: string) => Solution;
  proposeTechnicalOptions: (Solution) => void; // Со-автор решения
}

5. Токсичная культура обсуждения кода

Конструктивный code review – основа роста. Мне не нравится:

• Личные выпады в комментариях ("кто так пишет?").
• Безликие approve без внимательного просмотра.
• Жесткое навязывание субъективных предпочтений (пробелы vs табы) вместо следования принятому в команде code style.

В качестве резюме: мои "не нравятся" – это не просто критика, а сформированные болью точки, которые я, как старший разработчик, стараюсь proactively решать. Я ценю среду, где есть прозрачность, уважение к инженерной культуре, фокус на долгосрочном качестве продукта и возможность влиять на процессы. Поиск такого баланса – это и есть профессиональный вызов, который делает работу осмысленной. Идеальных мест нет, но важно, чтобы вектор движения команды и компании был направлен на устранение именно таких системных проблем, а не на их игнорирование.