Any problem must be solved at the right level
#principles
В роли консультанта моя работа это задавать правильные вопросы. Самый информативный: "Почему данный функционал реализован на этом уровне?". Поделюсь субъективным разделением уровней.
1️⃣ Уровень бизнес-кода. Реализуется сервисами, моделями, репозиториями, миграциями, шаблонами и т.п. Создает всю бизнес логику, в том числе ее представление на уровне данных. Не может быть перенесен между проектам. Имеет особую коммерческую ценность и защищается NDA.
2️⃣ Уровень кода-приложения. Реализуется контролерами, валидаторами, роутерами, обработчиками ошибок, логгерами и т.д. По сути это код использующий методы фреймворка для вызова бизнес-логики.
3️⃣ Уровень кода-фреймворка. Реализуется набором библиотек и паттернов, с помощью которых команда создает проект. При правильной реализация, этот код может быть переиспользован между проектами. При идеальной реализации: это open-source, качественная тех. документация, 100% покрытие тестами. Именно здесь чаще всего происходит техническая инфляция.
4️⃣ Уровень сервисов и инфраструктуры. Реализуется сторонними API, очередями, базами данных, лоад балансерами, автоскейлерами и т.д. Команда разработки отвечает за выбор и конфигурация, но не за реализацию. Чем больше технических и бизнес задач решено на данном уровне, тем лучше для бизнеса.
5️⃣ Уровень команд и процессов. Реализуется договоренностями между людьми. Отражается прямым образом в архитектуре. Тут важны здравый смысл, дисциплина и умение понять других.
Чем эта философия может быть полезна для #nodejs разработчика? Чтобы определить свое профессиональное развитие! Понимайте где вы хотите находиться. Например, Тимур Шемсединов не любит заниматься прикладным программирование (1️⃣+2️⃣), ему интересно системное программирование(3️⃣+4️⃣)
#principles
В роли консультанта моя работа это задавать правильные вопросы. Самый информативный: "Почему данный функционал реализован на этом уровне?". Поделюсь субъективным разделением уровней.
1️⃣ Уровень бизнес-кода. Реализуется сервисами, моделями, репозиториями, миграциями, шаблонами и т.п. Создает всю бизнес логику, в том числе ее представление на уровне данных. Не может быть перенесен между проектам. Имеет особую коммерческую ценность и защищается NDA.
2️⃣ Уровень кода-приложения. Реализуется контролерами, валидаторами, роутерами, обработчиками ошибок, логгерами и т.д. По сути это код использующий методы фреймворка для вызова бизнес-логики.
3️⃣ Уровень кода-фреймворка. Реализуется набором библиотек и паттернов, с помощью которых команда создает проект. При правильной реализация, этот код может быть переиспользован между проектами. При идеальной реализации: это open-source, качественная тех. документация, 100% покрытие тестами. Именно здесь чаще всего происходит техническая инфляция.
4️⃣ Уровень сервисов и инфраструктуры. Реализуется сторонними API, очередями, базами данных, лоад балансерами, автоскейлерами и т.д. Команда разработки отвечает за выбор и конфигурация, но не за реализацию. Чем больше технических и бизнес задач решено на данном уровне, тем лучше для бизнеса.
5️⃣ Уровень команд и процессов. Реализуется договоренностями между людьми. Отражается прямым образом в архитектуре. Тут важны здравый смысл, дисциплина и умение понять других.
Чем эта философия может быть полезна для #nodejs разработчика? Чтобы определить свое профессиональное развитие! Понимайте где вы хотите находиться. Например, Тимур Шемсединов не любит заниматься прикладным программирование (1️⃣+2️⃣), ему интересно системное программирование(3️⃣+4️⃣)
Как я провожу собеседования?
#principles
Мое обычное собеседование длиться 1 час. В текущих условиях рынка у бизнеса нет возможности просить у кандидата больше времени. За этот час я проверяю, что кандидат умеет писать код и у него есть понимание тех.стэка.
Написание кода !== составление алгоритма
Написание кода это технический навык, который не должен требовать когнитивных усилий. Для его проверки я использую live-coding c однострочными задачками. Если кандидат гуглит как вернуть Promise из функции, то он скорее всего не писал на современном JS.
Составление алгоритма это сознательная работа, требующая когнитивных усилий. Способность составлять алгоритмы проверяют задачками с Leetcode. В ходе интервью и в повседневной жизни люди по-разному выполняют алгоритмизацию, поэтому я не даю задач на алгоритмы.
Понимание !== знание
В ходе интервью задача проверить, что кандидат способен выполнять задачи на проекте. Для этого ему необходимо не знание документации, а понимание и опыт работы с тех.стэка проекта. В этом помогают вопросы "В чем различие ...?", "Зачем/Почему...?", а не "Что такое ...?" или "Дайте определение ...". Обычно, глубина понимания прямо коррелирует с систем дизайном и алгоритмизацией.
Soft-skills работают всегда
За час кандидат показывает не только свои технические навыки, но и то как он общается. Сосредоточившись на тех. составляющий собеседования кандидат показывает свои повседневные навыки активного слушания, ведения тех. дискуссии, умение признать свою ошибку или незнание.
Матрица скилов
По итогам любой работы должен оставаться артефакт. Артефактом собеседования является матрица скилов кандидата. На ее основание бизнес принимает решение о дальнейшем сотрудничестве с кандидатом. У меня это это 4-7 пунктов с пятибальной шкалой и комментариями.
#principles
Мое обычное собеседование длиться 1 час. В текущих условиях рынка у бизнеса нет возможности просить у кандидата больше времени. За этот час я проверяю, что кандидат умеет писать код и у него есть понимание тех.стэка.
Написание кода !== составление алгоритма
Написание кода это технический навык, который не должен требовать когнитивных усилий. Для его проверки я использую live-coding c однострочными задачками. Если кандидат гуглит как вернуть Promise из функции, то он скорее всего не писал на современном JS.
Составление алгоритма это сознательная работа, требующая когнитивных усилий. Способность составлять алгоритмы проверяют задачками с Leetcode. В ходе интервью и в повседневной жизни люди по-разному выполняют алгоритмизацию, поэтому я не даю задач на алгоритмы.
Понимание !== знание
В ходе интервью задача проверить, что кандидат способен выполнять задачи на проекте. Для этого ему необходимо не знание документации, а понимание и опыт работы с тех.стэка проекта. В этом помогают вопросы "В чем различие ...?", "Зачем/Почему...?", а не "Что такое ...?" или "Дайте определение ...". Обычно, глубина понимания прямо коррелирует с систем дизайном и алгоритмизацией.
Soft-skills работают всегда
За час кандидат показывает не только свои технические навыки, но и то как он общается. Сосредоточившись на тех. составляющий собеседования кандидат показывает свои повседневные навыки активного слушания, ведения тех. дискуссии, умение признать свою ошибку или незнание.
Матрица скилов
По итогам любой работы должен оставаться артефакт. Артефактом собеседования является матрица скилов кандидата. На ее основание бизнес принимает решение о дальнейшем сотрудничестве с кандидатом. У меня это это 4-7 пунктов с пятибальной шкалой и комментариями.
Complexity vs Incomprehensibility
#principles
Я рекомендую различать сложность, т.е. метрику количества элементов системы/кода/задачи и понятность, т.е. необходимые когнитивные усилия, чтобы понять систему/код/задачу. На английском это Complexity vs Incomprehensibility. Оба этих параметры определяют стоимость создания и поддержки кода. Но именно непонятность вносит большую часть.
Вещи, которые позволяют делать ваш код понятным:
- хороший нейминг
- абстракции и паттерны
- консистеная организация кода
- код ревью
- качественно поставленные задачи
Закончу своей же цитатой: "Все сложное — это состыкованное с друг другом простое. Поэтому делай просто и одинаково. А сложным оно станет само"
#principles
Я рекомендую различать сложность, т.е. метрику количества элементов системы/кода/задачи и понятность, т.е. необходимые когнитивные усилия, чтобы понять систему/код/задачу. На английском это Complexity vs Incomprehensibility. Оба этих параметры определяют стоимость создания и поддержки кода. Но именно непонятность вносит большую часть.
Вещи, которые позволяют делать ваш код понятным:
- хороший нейминг
- абстракции и паттерны
- консистеная организация кода
- код ревью
- качественно поставленные задачи
Закончу своей же цитатой: "Все сложное — это состыкованное с друг другом простое. Поэтому делай просто и одинаково. А сложным оно станет само"
Что прокачивать, если вы Team Lead?
#principles
Ребята в @tlbootcamp сделали отличную карту навыков и компетенций для тимлидов – tlroadmap.io. Карта представлена в виде mindmap-а. Каждая ветка имеет теорию, практику и обоснование, почему этот блок важен. Работа над картой происходит коллективно через GitHub.
PS На прошлой неделе не было заметок. Я был полностью погружен в изменения структуры на основном проекте. Мне добавили обязанностей Engineering Manager-а. Так что мне снова нужны инженеры. Пост с вакансией будет чуть позже.
#principles
Ребята в @tlbootcamp сделали отличную карту навыков и компетенций для тимлидов – tlroadmap.io. Карта представлена в виде mindmap-а. Каждая ветка имеет теорию, практику и обоснование, почему этот блок важен. Работа над картой происходит коллективно через GitHub.
PS На прошлой неделе не было заметок. Я был полностью погружен в изменения структуры на основном проекте. Мне добавили обязанностей Engineering Manager-а. Так что мне снова нужны инженеры. Пост с вакансией будет чуть позже.
tlroadmap.io
Teamlead Roadmap
👩🏼💻👨🏻💻Карта навыков и модель развития тимлидов
Что такое стоимость владения софтом и из чего она состоит?
#principles
На прошлых выходных у меня был запрос на консалтинг от CEO одной украинской продуктовой компании. Ключевой вопрос был: "На какой архитектуре нам стоит начинать новые проекты в компании – на микросервисах или монолите?" Боль как представителей украинского бизнеса, так и разработчиков не умение брать на себя ownership. Эта концепция хорошо расписана в Amazon Leadership Principles.
Для софта его стоимость владения (ownership cost) состоит из стоимости создания (development cost) и стоимости поддержки (maintenance costs). В outsource компаниях не принято следит за этими параметрами. Новый проект нужно запилить как можно быстрее, т.е. уменьшаем development cost за счет увеличения стоимости поддержки. А в легаси не дай бог тебе уменьшить maintenance cost – это будет означать меньше работы и денег от заказчика. В продукте же один из главных вопросов от разработчиков: "Как мы будет поддерживать то что разработали?"
Приведу конкретные примеры. Далее OC – Ownership Cost, DC – development cost, MC – maintenance costs.
– Тесты или TypeScript уменьшают OC, за счет уменьшение MC, но увеличения DC. Почему: вносить изменения в код можно с меньшими рисками, что-либо поломать.
– Линтинг, код-стайл уменьшает MC. Почему: читать становиться проще!
– Внутренний, легаси или экзотический фреймворк увеличивает OC и MC. DC как правило тоже увеличивается. Почему: находить и онбоардить новых разработчиков сложней.
– DevOps процессы – уменьшают OC, причем существенно. Почему: автоматизация деплоя, разворачивание и мониторинг инфраструктуры все это уменьшает MC и требует сравнительно не больших затрат в DC.
В завершение дам ответ на вопрос из начала рецепта: "микросервисы VS монолит". Ownership cost для микросервисов дороже пока не появилась проблема масштабирования нагрузок (железо не справляется) и/или команды разработки (больше 20 человек).
#principles
На прошлых выходных у меня был запрос на консалтинг от CEO одной украинской продуктовой компании. Ключевой вопрос был: "На какой архитектуре нам стоит начинать новые проекты в компании – на микросервисах или монолите?" Боль как представителей украинского бизнеса, так и разработчиков не умение брать на себя ownership. Эта концепция хорошо расписана в Amazon Leadership Principles.
Для софта его стоимость владения (ownership cost) состоит из стоимости создания (development cost) и стоимости поддержки (maintenance costs). В outsource компаниях не принято следит за этими параметрами. Новый проект нужно запилить как можно быстрее, т.е. уменьшаем development cost за счет увеличения стоимости поддержки. А в легаси не дай бог тебе уменьшить maintenance cost – это будет означать меньше работы и денег от заказчика. В продукте же один из главных вопросов от разработчиков: "Как мы будет поддерживать то что разработали?"
Приведу конкретные примеры. Далее OC – Ownership Cost, DC – development cost, MC – maintenance costs.
– Тесты или TypeScript уменьшают OC, за счет уменьшение MC, но увеличения DC. Почему: вносить изменения в код можно с меньшими рисками, что-либо поломать.
– Линтинг, код-стайл уменьшает MC. Почему: читать становиться проще!
– Внутренний, легаси или экзотический фреймворк увеличивает OC и MC. DC как правило тоже увеличивается. Почему: находить и онбоардить новых разработчиков сложней.
– DevOps процессы – уменьшают OC, причем существенно. Почему: автоматизация деплоя, разворачивание и мониторинг инфраструктуры все это уменьшает MC и требует сравнительно не больших затрат в DC.
В завершение дам ответ на вопрос из начала рецепта: "микросервисы VS монолит". Ownership cost для микросервисов дороже пока не появилась проблема масштабирования нагрузок (железо не справляется) и/или команды разработки (больше 20 человек).