Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
На собеседовании с программистом: "Вы нам не подходите, у нас в команде лимит умных людей исчерпан. Немного потупеете и приходите снова".
На самом деле в статье всё описано, просто нужно читать внимательно. Ключевая фраза:
Не существует проблемы команд со слишком большим количеством «умных людей» или «сеньоров». Существует проблема команд со слишком большим количеством «авторитетов» — людей, считающих, что их задача не писать код, а «заниматься стратегией».
Выгоните этих «аторитетов» к чертям собачьим — и всё, проблема нехватки «лошадиных сил» исчезнет сама собой.
Потому что в этом случае проблема выбора междлу двумя-тремя-десятью отличнейшими архитектурами — решается мгновернно: кто пишет код — тот и выбирает архитектуру. И всё. Чего тут обсуждать-то?
Если у вас в команде нет авторитетов, а только лишь одни «сеньоры» с 20 годами опыта в среднем и ни одного джуна… эта команда будет отлично продвигаться вперёд — если только эти «сеньоры» будут код писать, а не стратегии стратегизировать…
P.S. Конечно если у вас менеджеров, которые в принципе код никогда писать не должны, больше чем джунов и сеньоров вместе взятых… вам уже ничего не поможет — но это совсем другая история…
Кроме того, непонятно кто должен «поднять мыло», ой, то есть, кто должен пилить эту фичу?
Не существует проблемы команд со слишком большим количеством «умных людей» или «сеньоров». Существует проблема команд со слишком большим количеством «авторитетов» — людей, считающих, что их задача не писать код, а «заниматься стратегией».
Выгоните этих «аторитетов» к чертям собачьим — и всё, проблема нехватки «лошадиных сил» исчезнет сама собой.
Потому что в этом случае проблема выбора междлу двумя-тремя-десятью отличнейшими архитектурами — решается мгновернно: кто пишет код — тот и выбирает архитектуру. И всё. Чего тут обсуждать-то?
Если у вас в команде нет авторитетов, а только лишь одни «сеньоры» с 20 годами опыта в среднем и ни одного джуна… эта команда будет отлично продвигаться вперёд — если только эти «сеньоры» будут код писать, а не стратегии стратегизировать…
P.S. Конечно если у вас менеджеров, которые в принципе код никогда писать не должны, больше чем джунов и сеньоров вместе взятых… вам уже ничего не поможет — но это совсем другая история…
кто пишет код — тот и выбирает архитектуру. И всё. Чего тут обсуждать-то?
20 «сеньоров» пишут код пилят проект, и у каждого своя архитектура. Действительно, чего тут обсуждать-то...
Они же не буквально одно и то же делают. Один пишет анимации, другой рендеринг, третий ИИ, четвертый скрипты, и так далее. У каждого свой фронт работ, своя и архитектура под этот фронт.
Команды бывают действительно большими. 20 java программистов пишут бэкенд, 20 js пишут фронтент, 20 мобильных разработчиков и 32 тестера должны все это тестами покрыть. Без слаженной командной работы и системы принятия решений ничего не выйдет: половина тестеров будет писать код на java, а вторая половина — на groovy. Ну а что, «кто пишет код — тот и выбирает архитектуру»?
Без слаженной командной работы и системы принятия решений ничего не выйдет: половина тестеров будет писать код на java, а вторая половина — на groovy.И кому от этого плохо, собственно?
У нас подобным образом образовалась система сборки, написанная на Go — и ничего, никто не умер.
Кроме того уж по используемому языку можно уж принять решение, пусть и потратив некоторые усилия. Это не каждый день делается.
Если у вас так, то ваш проект подвержен рискам значительно более серьезным, чем неправильное кодирование.
Во первых, лимит для команды — 9 человек. Во вторых, команда кроссфункциональна, то есть, из этих 9 двое пишут обработчики запросов, один деплоит, еще один администрирует БД, еще двое тестирует, один верстает макет, а еще один его оживляет, и один аналитик. Вот так это работает.
Кроме того, сейчас как раз в ходу микросервисы, каждый из которых может быть написан на чем угодно, и они все крутятся на единообразных контейнерах.
Во первых, лимит для команды — 9 человек. Во вторых, команда кроссфункциональна, то есть, из этих 9 двое пишут обработчики запросов, один деплоит, еще один администрирует БД, еще двое тестирует, один верстает макет, а еще один его оживляет, и один аналитик. Вот так это работает.
Кроме того, сейчас как раз в ходу микросервисы, каждый из которых может быть написан на чем угодно, и они все крутятся на единообразных контейнерах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перевернутая пирамида как конец вашего проекта