Будешь ли обращать внимание на уровень сложности задачи при ее выборе среди других задач

# Будешь ли обращать внимание на уровень сложности задачи при выборе

Да, обязательно буду обращать внимание, но это не одинокий фактор в решении. Подход зависит от контекста и этапа разработки.

Когда я выбираю сложные задачи

1. Когда они критичны для продукта

# Пример: оптимизация алгоритма поиска в огромной БД
# Это может быть сложно, но это узкое место продакшена
# Нужно взять её и решить, несмотря на сложность

# Метрика: ROI = Выигрыш в производительности / Время на разработку
# Если выигрыш большой — берёшь сложную задачу

Сложность не должна быть причиной избегать её, если она:

• Даёт значительный выигрыш (скорость, надёжность)
• Влияет на UX всех пользователей
• Кровоточит техдолг

2. Когда я хочу развиваться

На позиции senior я сознательно выбираю задачи посложнее, чтобы:

• Улучшать навыки в новых областях (например, распределённые системы)
• Mentored junior разработчиков через эту задачу
• Оставить хороший code example для команды

# Пример: нужно внедрить паттерн Event Sourcing
# Это сложнее стандартной ORM разработки, но:
# - Я научусь новому
# - Код будет полезен для будущих features
# - Буду mentor для других, кто будет использовать это

Когда я выбираю простые задачи

1. Когда надо быстро доставить value

# Спринт заканчивается через день
# Нужно закрыть features для release
# Берёшь простые задачи, чтобы:
# - Быстро закрыть stories
# - Не рисковать с багами
# - Дать всей команде время на сложное

2. Когда я "выгорел" или устал

Это нормально:

• После месяца сложных задач нужен перерыв
• Простые задачи дают чувство прогресса
• Но я говорю об этом lead разработчику, не скрываю

3. На начальном этапе в новом проекте

# Я приходил на новый проект
# Сначала беру простые задачи, чтобы:
# - Узнать кодовую базу
# - Познакомиться с процессом работы
# - Адаптироваться к стилю команды
# Потом постепенно беру сложные

Матрица выбора (как я думаю)

        ВЫСОКАЯ        |
        ВАЖНОСТЬ       |  Сложная            | Сложная
                       |  Критичная          | Но не срочная
                       |  (Делаешь сразу)    | (Планируешь время)
        ───────────────┼─────────────────────┼──────────────
        НИЗКАЯ         |  Простая            | Простая
        ВАЖНОСТЬ       |  Техдолг            | Техдолг
                       |  (Если есть время)  | (Можно отложить)
                       |
                   НИЗКАЯ          ВЫСОКАЯ
                   СРОЧНОСТЬ       СРОЧНОСТЬ

Практический подход

На планировании спринта

# Я говорю lead разработчику:
# "Я хочу сделать:
# 1. Сложную задачу X (3-4 дня) — хочу разобраться с async/await
# 2. Простую задачу Y (1 день) — для срочного release
# 3. Среднюю задачу Z (2 дня) — критичную для продакшена"

# Это баланс:
# - Развиваюсь (сложная)
# - Служу срокам (простая)
# - Решаю боль продукта (средняя)

Важный момент: я говорю о сложности открыто

# ❌ Плохо
# (молчу, потом срезаюсь на сложной задаче)
# (или растягиваю простую на неделю из страха)

# ✅ Хорошо
# Я: "Эта задача выглядит сложнее, чем я думал, вот почему..."
# Lead: "Окей, давайте разберёмся вместе"
# Результат: я учусь, не срезаюсь, и deliver quality

Как я оцениваю свою подготовку

# Сложность задачи = A
# Мой скилл уровень = B

# Если A > B на 50% — идеальная зона развития
if A == B:
    # Скучно, не развиваюсь
    pass
elif A > B * 1.5:
    # Слишком сложно, не сделаю
    # Нужен mentor/pair
    pass
else:
    # Идеально, можно расти
    take_task()

Red Flags на собеседовании

Когда я слышу:

• "Я беру только простые задачи" → Я бы заподозрил, что либо:

  • Кандидат боится ошибиться
  • Не стремится развиваться
  • Может не справиться с растущей сложностью проекта

• "Я беру только сложные задачи" → Это может означать:

  • Не умеет выставлять приоритеты
  • Может упустить срочные deliverables
  • Может не пригодиться для стабилизации кода

Мой честный ответ на интервью

"Я обращаю внимание на сложность, но это не основной фактор. Я выбираю задачи на основе:

1. **Влияние на продукт** — сложная ли, но критичная?
2. **Сроки спринта** — нужна ли срочная доставка?
3. **Личное развитие** — это заполнит пробел в навыках?
4. **Реальность** — хватит ли времени с учётом других обязательств?

Если задача выглядит слишком сложной для меня, я обсуждаю с lead:
- Нужен ли мне mentor?
- Можно ли разбить на подзадачи?
- Есть ли примеры кода в кодовой базе?

Я не боюсь сложности, но я тоже не героиня, которая молча срезается на deadlines."

Итого

✅ Сложность важна, но не определяющий фактор ✅ Иду на баланс между развитием и доставкой ✅ Открыто говорю о своих сомнениях ✅ Стараюсь расти, но реалистично оцениваю возможности ✅ На разных этапах карьеры разные приоритеты (junior → senior)