Ну если это стартап, где не парятся, то это хорошая область, куда можно залезть и сделать самому)

Но это конкретные технические штуки, которые вообще млаовероятно, что будут играть решающую роль в твоем решении оставаться\устраиваться туда или нет. А выше речь шла о более глобальных вещах, типа "как получить повышение".  И тут и говорю, что не существует такого, и не понимаю, какой ответ вы в реале слышали, отличный от предложенного мной, который бы был "Хорошим" для вас.

Это был не стартап :)

Ну если я тебе скажу, что строгой проверки код стиля для джава кода у нас в соседней команде нет и как раз сейчас ребята внедряют? А до этого 5 лет проект разрабатывали

pre-commit вот тоже не все слышали

Но это ж просто хорошая область, куда можно прийти и проявить инициативу)

Меня бы такое оч напрягло. Сорри, я просто не джавист не разу и мои примеры из-за этого могут выглядеть паршиво

Еще возник вопрос, какая фича считается маленькой, а какая большой? И какая задача считается простой, а какая сложной? (в крупных компаниях) Понимаю, что размер измеряется в сторипоинтах итп, больше интересует формулировка задачи. На примере бэкенд-разработки мне было бы понятнее.

То есть, например, простая - написать парсер чего-нибудь, который складывает данные в базу и все. Сложная - спроектировать сервис, который принимает от пользователей некоторые параметры, в зависимости от них генерит события, которые нужно выполнить. Затем  добавляет их в очередь, а отдельные воркеры ее разгребают и эти события выполняют. Под все это нужно самому выбрать БД, придумать схему. Сделать максимальное покрытие тестами и документацией, логирование, мониторинг. Разворачивать в контейнерах, релизы выкатывать по CI/CD. Для управления системой сделать REST апишку, которую нужно подробно описать в OpenAPI спецификации.

Если кто-то сможет привести подобные примеры, буду очень благодарен. Так как работал пока только в одном месте и мне не с чем сравнивать, то непонятно, насколько сложные штуки делаю)

Я видел такое разбиение: маленькая задача - импакт на одну или несколько комманд, средняя - импакт на отдел/функцию, большая - импакт на множество отделов/функций.
Соответсвенно, для примера, для промоушена с синьора до принципла нужно 2 большие задачи. ( обычно 1 - 2 в год такие бывают )

Вот примерны больших: организация редизайн, новая локализация, создание ownership процесса, создание дизайн платформы если ее еще нет

средних: внутряя библиотека для чего-либо которая будет использоваться другими коммандами ( перформанс, сетевой слой и т.д. )

маленьких: сделал что-то сверх своих комптенций/обязанностей. ( что-то порефакторил, улучшил, поднял какой-то показатель )

Ну вот я написал тулу для автоматизации процесса, который (процесс) нужен половине компании. Тулу свою рекламирую, используют сейчас в разных командах. Считается за "большую" таску?
Я конечно немного горжусь, но вообще не считаю, что это что-то, чем можно аргументировать в первую очередь повышение)

Все зависит от импакта. Если это ускорило работу всех разработчиков на x, то да большая. Или позволило заработать компании на х% больше денег. Не важно сколько это занимает усилий, все смотрят только как это помогло компании в целом.

Ну это понятно. Конечно, ускорило работу ответственных людей, условно с часа в неделю до 10 минут в месяц)

По крайней мере, так обстоят дела в компаниях от 300 разработчиков.

Еще одно такое решение и подавай на повышение )

Спасибо! Думаю теперь, как это переложить на маленькую компанию с одной небольшой командой разработки)

Только в наших командах 60, суммарная численность команд, где пользуются моей тулой (не каждый, конечно, но каждая команда) - ну раза в два поболе)

Ну вот, собственно, так можно

👌

А разве большие задачи не стоит декомпозировать и делать по маленьким кусочками?

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