Я не согласен с некоторыми вашими утверждениями, но соглашусь, что статья больше для джунов и мидлов с обеих сторон. Впрочем, не вижу в этом ничего плохого :)

К сожалению, не во все команды можно нанять только сеньоров. Более того, не все сеньоров действительно зрелы и развиты именно в этом контексте — понять продукт, задачу и решить её максимально эффективно. Все мы люди :)

Ок, берет напрямую. Проект растёт. Промотаем чуть времени — проекту несколько лет, он выстрелил. Для его успешного развития уже недостаточно просто «чуйки» заказчика или вашей. Нужны исследования рынка, работа с фокус группами, приоритезация, беклог на несколько команд, стратегия, OKR, KPI...

Если это все продолжает делать заказчик — тогда он менеджер. Если вы — то вы.

Я понимаю ситуацию, о которой вы говорите, просто говорю о немного других масштабах. Там необходим decision maker от бизнеса, а не от технологий, а ему уже нужны люди, которые будут давать точечную инфу, в том числе техническую.

А кто этому фрилансеру задачи даёт?)

Я же не писал что отвечает за это :) Но для него это важно. Я понял суть ваших слов, и согласен с ними — наверное, в статье выбрал неудачную формулировку.

В этом плане согласен, но на то менеджер и есть, чтобы нужную долю этой информации отдать программисту и довериться его экспертизе в принятии решения. Да и подобные технические решения обычно проводятся через лида или engineering manager (тот же лид), они способны и технические детали понять, и бизнес контекст выполняемой задачи.

А насчет перфекционизма — бывают и менеджеры-перфекционисты :)

«Качественно и надежно» — сложное понятие, ведь оно зависит от конкретной ситуации.

Если сроки горят, то «качественно и надежно» — одно. Если проект играет в долгую — совсем другое. И тут важно, что менеджер понимает, какие последствия у технических решений, но при этом ему не обязательно понимать их суть.

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

Хороший summary :)

Не соглашусь. Чем глубокая осведомленность о технических подходах в реализации фичи поможет менеджеру в его работе? Важный нюанс — я подразумеваю, что technical ownership несет лид или другой технический специалист.

Классная статья, потому что на самом деле измерение продуктивности программиста — офигенно сложная задача. Не смотря на то, что приведенные показатели не являются истиной в последней инстанции, уже круто, что вместо субьективного «нравится/не нравится» вы попытались подойти к вопросу научно.

Интересно одно — вы, как я понял, не являетесь непосредственным лидом в описанной команде и были человеком «со стороны». И если так, то насколько результаты вашей оценки совпадают с простым опросом программистов и менеджеров из этой команды?

Скажу за себя — самореализация и деньги. Думаю, что у других людей они могут отличаться.

Но я соглашусь, что разработчику жить во многом легче, и если его все устраивает — идти в лиды глупо и вредно. В принципе, как и вообще делать то, что не нравится.

Спасибо!

На самом деле, наша команда проходила долгий путь от forming до performing, спотыкаясь, но не сдаваясь :) Было и становление процесса как такового (с 0 до 2-3 уровня process maturity model), и формирование команды, и осмысление культуры — как работы, так и коммуникаций.

Просто решил делать акцент статьи не на этом. Возможно, напишу на эту тему в будущем.

Плюс-минус :) Прораб он и в айти прораб.

Довольно точное сравнение, кстати. Хоть в статье и есть немного специфики именно нашей индустрии, но принципы и подходы абсолютно такие же, как и в любой другой. Только акценты другие.

Стесняться? Вы ошибаетесь.

Насчет ВУЗа — я просто написал то, что у меня в дипломе.

А насчет кафедры и ее пед. состава — это те люди, которые дали мне образование и сделали из меня программиста (во всяком случае, начинающего). И я им действительно глубоко благодарен за человеческое отношение к студентам и искреннее желание научить. Это и Александр Семенович Зеленский, и Владимир Сергеевич Лысенко, и Сергей Владимирович Баран, и еще десятки прекрасных людей.

Надеюсь, во время моего следующего визита домой найду время проведать и сказать им это лично :)

Спасибо! Очень приятно читать такие комментарии :)

Ви частково праві. Проте, я не намагався пояснювати чи нав’язувати іншим (тим паче лідам), як робити цю роботу. Моїм завданням було якось осмислити той справді невеликий досвід, що я отримав за ці 6 місяців, і поділитись ним — не у вигляді догми, а лише певних висновків, щодо яких можна дискутувати.

Мені здається, що цей матеріал більш цікавий не для лідів, а для розробників, які хочуть розвиватися в цьому напрямку — тому навіть базові для досвідчених лідів речі можуть бути корисними.

Погоджуюсь с кожним пунктом. Хоча, з 5м у мене складніше — все ж таки я людина й усе людське мені не чуже :)

Игнат, у меня нет огромного опыта найма людей в свои / чужие команды и компании, но немного с этим я уже столкнулся. Мне кажется, что вы (как это не забавно) переоцениваете значение объективности при оценке специалиста (спойлер: её не бывает).

Вы ведь пытаетесь нанять человека в свой продукт, свою компанию. Работать с собой, «на соседних стульях». Для этого вам не нужен объективно хороший кандидат. Вам нужен тот, кто докажет свою экспертизу конкретно в тех задачах, что сейчас нужно решать, и с которым вам и вашим коллегам будет приятно работать. Ваш кандидат.

Со звездами (а в текущих условиях рынка те, кого вы ищете, именно звезды) у вас будет много проблем. Им нужны задачи их уровня (верстать формы или пилить круды не пойдет), отношение, соцпакет и тому подобное. Может вы и найдете таких, но они нужны для брендинга компании, продаж, чего угодно, но не писание огромного количества разного качества кода сутками.

Нанимая к себе в команду, я в первую очередь оцениваю, может ли человек делать работу, которую нужно — то есть, оцениваю хард скилы не «объективно», а ситуационно, относительно целей и ожиданий здесь и сейчас + пару месяцев вперед (что, мне кажется, валидно и для стартапа). Также, думаю впишется ли этот человек в команду и будет ли мне и остальным с ним комфортно работать.

И тут скажу крамольную вещь — человек может подходить по скилам, но если я точно знаю что мы (или члены команды) с ним не сработаемся — я его не найму. И обычно, это к лучшему для обеих сторон. И это НЕ ОБЪЕКТИВНО, но правильно.

Bottomline: не ищите лучших. Ищите тех, кто подходит вам сейчас, с кем вам комфортно работать, и растите вместе с ними.

Во многом согласен, но все же хочу возразить по нескольким пунктам.

1. Реакт — view library. Angular — opinionated framework. Это как сравнивать лопату и гараж. Реакт дает больше свободы, что во многих ситуациях нежелательно (например, когда нет опытных разработчиков), но в крупных проектах есть возможность подстроить процесс разработки более гибко под свои нужды.
2. JSX не зря считается одним из крутейших преимуществ Реакта. В первую очередь, он хорош тем, что имеем минимум library-specific синтаксиса, декларативен и читаем. Темплейты обычно имеют более высокий порог вхождения из-за специфичных для конкретной имплементации конструкций. Хотя, тут на вкус на и цвет.
3. Компонент в Реакте — это чистая функция отображения от данных. Если не нравится функциональщина и больше по душе ванильный ООП, это личные предпочтения, а не аргумент. А все данные точно также инкапсулированы внутри компонента. Если можете, то покажите код где нарушается изоляция — возможно, это просто неправильно написанный пример.
4. Controlled components.
5. Реакт дает больше свободы — хочешь Редакс прикрути, хочешь MobX / rxjs, хочешь свое что-то. Ну а со свободой приходит обязанность писать некий бойлерплейт, который более полный фреймворк инкапсулирует. Тут уж от проекта зависит что лучше.
6. Redux + Reselect = reusable state selectors + memoization, и доставай не хочу.
7. Same in React.
8. Были.
9. Роутер не часть Реакта, а сторонняя либа стороннего вендора. Не вижу причем тут FB. Тем более, если предлагают лучшее и дают пользоваться старым — в чем проблема? Breaking changes в Реакте — только после перехода на Fiber. И то, процесс миграции супер простой. Опять же, если либа стала лучше и мощнее — почему бы и не перейти?
10. Сложно дискутировать. Кладбище технологий Гугла, однако, на дает такого большого перевеса, как вы описали. Одно дело поддержка — другое развитие.

В общем, я бы советовал Реакт в те команды, где есть люди, которые умеют его правильно готовить. Если стоит выбор перед командой, которая не умеет ни в Ангулар, ни в Реакт — берите Ангулар.

П.С. Тайпскрипт таки хорош.

Можете посоветовать литературу, которая учит «мыслить» на JS? Без особого синтаксического сахара (он все время меняется, насколько я понимаю), больше с реальными примерами архитектуры, проектирования и тестирования. Сейчас для себя проблему я вижу не в том, чтобы выполнить задачу, а как лучше её выполнить — иными словами, best practices. Заранее спасибо всем кто откликнется :)