Принято, учтем это - спасибо, что поделились. Но на самом деле, конечно, это упрощенное описание. При этом и сам лид часто не просто менеджер, а разработчик, и у него также есть разные стадии. Все это надо учитывать, а не просто ломать, согласны.
Хороший вопрос, и все зависит от понимания самими руководителями и от размеров компании. Наблюдаем, что в меньших по размеру коллективах инициатива не обязательно идет от руководства, но руководство быстрее воспринимает пользу. В больших - по-разному.
Рынок труда в ИТ действительно сжался, но и спрос сместился — теперь нужны не просто «трудолюбивые новички», а быстрообучаемые, самостоятельные и многофункциональные ребята, даже на старте. Тех, кого сократили, компании тоже разбирают выборочно: не всех, а тех, кто вписывается в новый бюджет и умеет работать в условиях ограничений.
У джуна здесь есть мощное преимущество перед сеньорами: он дешевле и часто готов на задачи, которые опытные специалисты считают не своим уровнем. Если джун показывает, что может быстро учиться, не боится рутины (в том числе с ИИ) и уже имеет хотя бы пет-проекты — его возьмут не вместо сеньора, конечно, а на параллельную позицию, куда опытному специалисту идти уже невыгодно
В основном, малый и средний бизнес, стартапы и студии, где меньше бюрократии и больше нужды в гибких руках. Крупные компании экономят, но аутсорсеры иногда берут под проекты с менторами. А в малом и среднем джуны окупаются за 3–6 месяцев реальными тасками. Если стек востребованный (JS/Python), шансы растут
Действительно, это так. И в этом есть парадокс. Мы рекомендуем сместить фокус с «написания кода» на «решение проблемы».
Учитесь не просто на курсах с типовыми TODO-листами, а на реальных продуктах. Выберите опенсорс-проект, который вам интересен, изучите его issues (особенно с labels «bug» или «enhancement»). Попробуйте разобраться в кодовой базе и предложите фикс.
Это и будет решением «сложной» задачи — нужно понять чужой контекст, архитектуру, договориться с мейнтейнерами. Именно этот навык — разбираться в неизвестном — и ценится.
Ментором на этом этапе может стать комьюнити, код-ревью в пулл-реквесте и собственное упорство
Проактивность и командную работу можно прокачивать соло или в «виртуальных» командах — без полноценной компании. Начните с опенсорса на GitHub: ищите issues с меткой good first issue, коммитьте, решайте мёрдж-конфликты, общайтесь в PR-ревью. Это даёт опыт фидбека, дедлайнов и коллаборации с незнакомцами.
Ещё можно попробовать хакатоны и митапы: там вы в команде 48 часов, распределяете роли, толкаете фичи под давлением. Помним и про волонтёрство.
2–3 месяца, и на собесе видно, что вы не только теорией владеете.
Практически нет. Действительно, курсы дают скорость и харды, не делая упор на софтах. Но их догоняют практикой в команде. Так что если есть желание и мотивация развивать софты — всё получится
Согласны, куча мелких коммитов в main усложняют чтение истории. Можно перед Pull Request выполнить git rebase -i HEAD~10 и объединить их в 1-2 содержательных коммита. Или настроить в GitHub опцию Squash and merge — история останется чистой
Всё-таки для force push лучше revert, чтобы не ломать историю команды. Но про Reflog отличный совет, спасибо) добавим в обновление. git reflog покажет все действия за сессию, git reset --hard <хеш> вернёт состояние
Conventional Commits внедряем через шаблоны в GitHub (.github/pull_request_template.md) и хуки pre-commit. Плюс, мы обычно проводим код-ревью с фидбеком — так что все уже привыкли
Понятно, что в моменте это кажется излишней душнотой, но полное описание коммита — некая инвестиция в будущее. Через год, когда нужно будет найти «когда мы добавили ту кнопку», «фикс» нам не скажет ничего. Мы, например, пишем: «fix: убрали дублирование кнопки в футере»
Вообще, сложнее, чем хотелось бы. Если уже запушили — используйте git revert хеш_коммита, чтобы создать новый коммит, который удалит пароли. Если ещё локально — git reset HEAD~1, отредактируйте файл и сделайте новый коммит
Принято, учтем это - спасибо, что поделились. Но на самом деле, конечно, это упрощенное описание. При этом и сам лид часто не просто менеджер, а разработчик, и у него также есть разные стадии. Все это надо учитывать, а не просто ломать, согласны.
Отдельно попробуем разобрать стадии руководителей, согласны :)
Хороший вопрос, и все зависит от понимания самими руководителями и от размеров компании. Наблюдаем, что в меньших по размеру коллективах инициатива не обязательно идет от руководства, но руководство быстрее воспринимает пользу. В больших - по-разному.
Кот Горох замечательный!
Рынок труда в ИТ действительно сжался, но и спрос сместился — теперь нужны не просто «трудолюбивые новички», а быстрообучаемые, самостоятельные и многофункциональные ребята, даже на старте. Тех, кого сократили, компании тоже разбирают выборочно: не всех, а тех, кто вписывается в новый бюджет и умеет работать в условиях ограничений.
У джуна здесь есть мощное преимущество перед сеньорами: он дешевле и часто готов на задачи, которые опытные специалисты считают не своим уровнем. Если джун показывает, что может быстро учиться, не боится рутины (в том числе с ИИ) и уже имеет хотя бы пет-проекты — его возьмут не вместо сеньора, конечно, а на параллельную позицию, куда опытному специалисту идти уже невыгодно
В основном, малый и средний бизнес, стартапы и студии, где меньше бюрократии и больше нужды в гибких руках. Крупные компании экономят, но аутсорсеры иногда берут под проекты с менторами. А в малом и среднем джуны окупаются за 3–6 месяцев реальными тасками. Если стек востребованный (JS/Python), шансы растут
Действительно, это так. И в этом есть парадокс. Мы рекомендуем сместить фокус с «написания кода» на «решение проблемы».
Учитесь не просто на курсах с типовыми TODO-листами, а на реальных продуктах. Выберите опенсорс-проект, который вам интересен, изучите его issues (особенно с labels «bug» или «enhancement»). Попробуйте разобраться в кодовой базе и предложите фикс.
Это и будет решением «сложной» задачи — нужно понять чужой контекст, архитектуру, договориться с мейнтейнерами. Именно этот навык — разбираться в неизвестном — и ценится.
Ментором на этом этапе может стать комьюнити, код-ревью в пулл-реквесте и собственное упорство
Проактивность и командную работу можно прокачивать соло или в «виртуальных» командах — без полноценной компании. Начните с опенсорса на GitHub: ищите issues с меткой good first issue, коммитьте, решайте мёрдж-конфликты, общайтесь в PR-ревью. Это даёт опыт фидбека, дедлайнов и коллаборации с незнакомцами.
Ещё можно попробовать хакатоны и митапы: там вы в команде 48 часов, распределяете роли, толкаете фичи под давлением. Помним и про волонтёрство.
2–3 месяца, и на собесе видно, что вы не только теорией владеете.
Практически нет. Действительно, курсы дают скорость и харды, не делая упор на софтах. Но их догоняют практикой в команде. Так что если есть желание и мотивация развивать софты — всё получится
зависит от компании) если инхаус-проект, то да - убирают тех, кто много зарабатывает. Если аутсорс, то всех, кто на бенче - тут нет дела до грейда.
Согласны, куча мелких коммитов в main усложняют чтение истории. Можно перед Pull Request выполнить git rebase -i HEAD~10 и объединить их в 1-2 содержательных коммита. Или настроить в GitHub опцию Squash and merge — история останется чистой
😁😁😁
Всё-таки для force push лучше revert, чтобы не ломать историю команды. Но про Reflog отличный совет, спасибо) добавим в обновление. git reflog покажет все действия за сессию, git reset --hard <хеш> вернёт состояние
Conventional Commits внедряем через шаблоны в GitHub (.github/pull_request_template.md) и хуки pre-commit. Плюс, мы обычно проводим код-ревью с фидбеком — так что все уже привыкли
Git blame <файл> покажет автора строки с хешем. Тыкнете хеш — откроется коммит с @author. Интегрируем с Jira через GitHub apps для трекинга
Понятно, что в моменте это кажется излишней душнотой, но полное описание коммита — некая инвестиция в будущее. Через год, когда нужно будет найти «когда мы добавили ту кнопку», «фикс» нам не скажет ничего.
Мы, например, пишем: «fix: убрали дублирование кнопки в футере»
Вообще, сложнее, чем хотелось бы. Если уже запушили — используйте git revert хеш_коммита, чтобы создать новый коммит, который удалит пароли. Если ещё локально — git reset HEAD~1, отредактируйте файл и сделайте новый коммит
говорят, поколение альфа сейчас использует 4 пальца, чтобы давить на кнопки. вся надежда на них
Хоронят наш любимый Flutter действительно ежегодно, спасибо автору, что поднимает снова эту тему. В прошлом году делали подобный ресерч.
Ответим в отдельной статье, спасибо за вопрос.