Привет! Меня зовут Давид Шекунц, я – Full-Stack Go & TS Tech Lead и вы находитесь на сайте с постами из моей 🦾 IT-Качалки 💪
2021-02-12 18:45
🦍 Эволюция разработчика v1 "Ветки развития" 👨💻
Раз уж пошла тема про эволюцию разработчика, решил что лучше будет начать с самых низов и постепенно пройти весь путь.
Первая статья будет посвящена общим путям развития разработчика (я беру только front и backend разработчиков) и ключевым отличиям.
Итак, дерево развития персонажа:
1. Zero – человек с несколькими пет проджектами, способный начать постепенно решать детально расписанные микротаски. Не умеет ставить сроки.
2. Junior – 1 год в разработке, уверено владеет основным языком и способен уже самостоятельно решать таски, иногда задавая вопросы старшим коллегам. Учиться оценивать срок, но ошибается на 70%.
3. Middle – 2-3 года в разработке, спокойно решает 80% задач своего стека, автоматизирует работу, способен залезть на соседнюю поляну (back / front) и сделать там пару тасков, осознано использует паттерны разработки и знает как гуглить. Учиться искусству баланса между "красивым кодом" и "рабочим решением". Может решить задачу практически любой сложности в формате "хуяк-хуяк и в продакшен".
4. Senior – 3+ года в разработке, спокойно решает Full-stack задачи, заранее думает об архитектуре и стратегии развития проекта, знает когда можно "быстро шоб работало", а когда нужно инвестировать время в проектирование фичи. Способен оценить таску на глаз и попасть с 20% ошибкой. Находит баланс между скоростью и качеством. Знает как надо делать.
5. Team Lead – 2-3+ года в разработке, можно прыгнуть из Middle, потому что тут больше ценятся soft-skills, навыки управления людьми, анализа требований к продукту, построение процессов разработки и договоренностей с бизнесом. Умеет оценивать пропускную способность всей команды с учетом не только техническим, но и психологических аспектов. Лидер для которого его команда – это его семья.
6. Architect – 5+ лет в разработке. Нужен, когда кол-во разрабатываемых связанных сервисов и выделенных команд переваливает за 5-10 штук (и я не про микросервисы), поэтому часто встречается как "архитектор холдинга". Знает все самые тонкие особенности работы всех кусок системы и может ответить на любой вопрос (за скромное жертвоприношение). Занимается инфраструктурой, низкоуровневыми оптимизациями, решает вопросы нагрузки и чаще всего способами хранения и обработки данных. Результат работы – схемы, ответы и решения.
7. CTO – 5+ лет работы, как и другие "директора" должен отлично разбираться в бизнес аспектах кампании, занимается бюджетированием и квотами на найм, способен предлагать прорывные технологические решения для развития бизнеса, строит бэклог на 3-6 месяцев+. Чаще всего уже кода сам не касается, а работает с Team Lead-ами, Architect и Senior разработчиками
А еще существует множество интересных сторонних веток развития среди которых: Web Animation Developer, Business System Analyst, GameDev, Data Engineer и самое вкусное Product Engineer.
Если вам интересно, чтобы я продолжал раскрывать каждую из этих позиций, рассказывать про особенности работы, плюсы и минусы, спектр задач и критерии успеха, финансовые и рыночные возможности, а также раскрыл приколюхи сторонних веток развития залетайте в комментарии и ставьте 👌секси-эмоджи 🐅
#evolution
Раз уж пошла тема про эволюцию разработчика, решил что лучше будет начать с самых низов и постепенно пройти весь путь.
Первая статья будет посвящена общим путям развития разработчика (я беру только front и backend разработчиков) и ключевым отличиям.
Итак, дерево развития персонажа:
1. Zero – человек с несколькими пет проджектами, способный начать постепенно решать детально расписанные микротаски. Не умеет ставить сроки.
2. Junior – 1 год в разработке, уверено владеет основным языком и способен уже самостоятельно решать таски, иногда задавая вопросы старшим коллегам. Учиться оценивать срок, но ошибается на 70%.
3. Middle – 2-3 года в разработке, спокойно решает 80% задач своего стека, автоматизирует работу, способен залезть на соседнюю поляну (back / front) и сделать там пару тасков, осознано использует паттерны разработки и знает как гуглить. Учиться искусству баланса между "красивым кодом" и "рабочим решением". Может решить задачу практически любой сложности в формате "хуяк-хуяк и в продакшен".
4. Senior – 3+ года в разработке, спокойно решает Full-stack задачи, заранее думает об архитектуре и стратегии развития проекта, знает когда можно "быстро шоб работало", а когда нужно инвестировать время в проектирование фичи. Способен оценить таску на глаз и попасть с 20% ошибкой. Находит баланс между скоростью и качеством. Знает как надо делать.
5. Team Lead – 2-3+ года в разработке, можно прыгнуть из Middle, потому что тут больше ценятся soft-skills, навыки управления людьми, анализа требований к продукту, построение процессов разработки и договоренностей с бизнесом. Умеет оценивать пропускную способность всей команды с учетом не только техническим, но и психологических аспектов. Лидер для которого его команда – это его семья.
6. Architect – 5+ лет в разработке. Нужен, когда кол-во разрабатываемых связанных сервисов и выделенных команд переваливает за 5-10 штук (и я не про микросервисы), поэтому часто встречается как "архитектор холдинга". Знает все самые тонкие особенности работы всех кусок системы и может ответить на любой вопрос (за скромное жертвоприношение). Занимается инфраструктурой, низкоуровневыми оптимизациями, решает вопросы нагрузки и чаще всего способами хранения и обработки данных. Результат работы – схемы, ответы и решения.
7. CTO – 5+ лет работы, как и другие "директора" должен отлично разбираться в бизнес аспектах кампании, занимается бюджетированием и квотами на найм, способен предлагать прорывные технологические решения для развития бизнеса, строит бэклог на 3-6 месяцев+. Чаще всего уже кода сам не касается, а работает с Team Lead-ами, Architect и Senior разработчиками
А еще существует множество интересных сторонних веток развития среди которых: Web Animation Developer, Business System Analyst, GameDev, Data Engineer и самое вкусное Product Engineer.
Если вам интересно, чтобы я продолжал раскрывать каждую из этих позиций, рассказывать про особенности работы, плюсы и минусы, спектр задач и критерии успеха, финансовые и рыночные возможности, а также раскрыл приколюхи сторонних веток развития залетайте в комментарии и ставьте 👌секси-эмоджи 🐅
#evolution
Развернуть
2021-02-04 17:03
🥋 Приемы результативности 🥋
Оставлю красивые техники типа: "Встань перед зеркалом и начни орать на себя какой же ты ахуенный" – всяким селфмотивыйшен коучам и расскажу несколько приемов, которые использую для личного структурирования деятельности и работы с хаосом мыслительного потока:
1. Планирование – самая важная составляющая любой деятельности.
2. План = Точка "А" → Набор действий → Точка "Б" (`function plan(A: point): point { // actions; return B;}`)
3. Самое важное в планировании – четкой определить точку "Б" (в цифрах, датах и фактах)
4. Самое важное после определения точки "Б" описать точку "А" (в таких же цифрах, датах и фактах)
5. Только со знанием точки "А" и точки "Б" можно приступать к планированию действий
6. Если что-то может выражаться конкретной цифрой или датой – это должно выражаться цифрой или датой
7. Ограничивать планирование нужно по времени ("буду планировать не более недели, а дальше начну с тем, что получилось"), а не качества (качество плана – слишком субъективная вещь, так никогда не закончишь)
8. Заранее поставьте отметки в плане, когда вы будете его пересматривать
9. Когда будете пересматривать план, лучше выкинуть его нахер и построить новый с учетом новой ситуации
Интересна ли вам вообще тема методологий и инструментов структурирования своих знаний и деятельности? Если да, ставьте классы (👌) у меня появилась интересная идейка на этот счет.
Оставлю красивые техники типа: "Встань перед зеркалом и начни орать на себя какой же ты ахуенный" – всяким селфмотивыйшен коучам и расскажу несколько приемов, которые использую для личного структурирования деятельности и работы с хаосом мыслительного потока:
1. Планирование – самая важная составляющая любой деятельности.
2. План = Точка "А" → Набор действий → Точка "Б" (`function plan(A: point): point { // actions; return B;}`)
3. Самое важное в планировании – четкой определить точку "Б" (в цифрах, датах и фактах)
4. Самое важное после определения точки "Б" описать точку "А" (в таких же цифрах, датах и фактах)
5. Только со знанием точки "А" и точки "Б" можно приступать к планированию действий
6. Если что-то может выражаться конкретной цифрой или датой – это должно выражаться цифрой или датой
7. Ограничивать планирование нужно по времени ("буду планировать не более недели, а дальше начну с тем, что получилось"), а не качества (качество плана – слишком субъективная вещь, так никогда не закончишь)
8. Заранее поставьте отметки в плане, когда вы будете его пересматривать
9. Когда будете пересматривать план, лучше выкинуть его нахер и построить новый с учетом новой ситуации
Интересна ли вам вообще тема методологий и инструментов структурирования своих знаний и деятельности? Если да, ставьте классы (👌) у меня появилась интересная идейка на этот счет.
Развернуть
2021-02-02 16:00
Градиент от Senior разработчика <-> Team Lead <-> CTO
Череда постов, в которых я размышляю над различиями этих ролей
Сразу договоримся о правилах:
1 роль != 1 человек – 1 человек может находиться сразу в N (нескольких) ролях
1000 и 1 полутон – границы всегда размыты и области одной роли будут пересекаться с другой
Каждому свое – у каждой фирмы могут быть свои обозначения той или иной роли, я беру медиану совокупного опыта
Для чего эта информация? Я думаю, что во многом даже для того, чтобы отвадить некоторых людей от становления, например, CTO 🙂 Потому что там все не так сладко, как многим кажестя
Если же наоборот эта информация преисполнит вас интересом и мужеством, то я тоже буду считать свою миссию выполненной
Ставьте классы (👌), если тема для вас интересная и я на следующей неделе начну выпускать посты
Череда постов, в которых я размышляю над различиями этих ролей
Сразу договоримся о правилах:
1 роль != 1 человек – 1 человек может находиться сразу в N (нескольких) ролях
1000 и 1 полутон – границы всегда размыты и области одной роли будут пересекаться с другой
Каждому свое – у каждой фирмы могут быть свои обозначения той или иной роли, я беру медиану совокупного опыта
Для чего эта информация? Я думаю, что во многом даже для того, чтобы отвадить некоторых людей от становления, например, CTO 🙂 Потому что там все не так сладко, как многим кажестя
Если же наоборот эта информация преисполнит вас интересом и мужеством, то я тоже буду считать свою миссию выполненной
Ставьте классы (👌), если тема для вас интересная и я на следующей неделе начну выпускать посты
Развернуть
2021-01-21 18:00
⚖️ Адвокат клиента ⚖️
Неважно какая у вас орг структура и кто за что отвечает, у вас всегда должен быть человек, представляющий интересы ваших клиентов:
- Изучать потребности текущих и потенциальных клиентов
- Их недовольство предоставляемыми продуктами
- Изучение рынка
- Формирование из всего вышесказанного карты развития продукта
Во многих фирмах эту роль на себя берет CEO / CPO / Product Manager / Product Owner
Но вполне себе может быть ситуация, когда на роль "адвоката" должен встать отдельный человек
Например, у вас настолько разные клиенты (B2B + B2C, клиенты из разных стран или рынков, etc.), что на роль "адвоката" какого-то типа клиента должен встать отдельный человек
Его роль можно назвать Client Owner / Lawyer
Подумайте: а в вашей компании есть конкретный человек, который способен ответить за потребности ваших клиентов и помочь выстроить бэклог? Если нет, то обязательно назначьте такого
Неважно какая у вас орг структура и кто за что отвечает, у вас всегда должен быть человек, представляющий интересы ваших клиентов:
- Изучать потребности текущих и потенциальных клиентов
- Их недовольство предоставляемыми продуктами
- Изучение рынка
- Формирование из всего вышесказанного карты развития продукта
Во многих фирмах эту роль на себя берет CEO / CPO / Product Manager / Product Owner
Но вполне себе может быть ситуация, когда на роль "адвоката" должен встать отдельный человек
Например, у вас настолько разные клиенты (B2B + B2C, клиенты из разных стран или рынков, etc.), что на роль "адвоката" какого-то типа клиента должен встать отдельный человек
Его роль можно назвать Client Owner / Lawyer
Подумайте: а в вашей компании есть конкретный человек, который способен ответить за потребности ваших клиентов и помочь выстроить бэклог? Если нет, то обязательно назначьте такого
Развернуть
2020-12-11 12:40
⛏ Вакансия: QA Engineer ⛏
Моему замечательному коллеге в команду нужен QA уровня middle-senior (который хочет расти в менеджмент) или не успевший ахуеть в край lead
Вакансия: https://hh.ru/vacancy/40640115
Работы куча, задача – сделать заебись, платить, сказали, будут (а это, между прочим, редкость в наши времена) и главное – топовая команда разработки и дизайнеров (в частности мой коллега)
Если что, можете писать в hh с пометкой “своячество – зло” или мне в личку, я вас направлю
Моему замечательному коллеге в команду нужен QA уровня middle-senior (который хочет расти в менеджмент) или не успевший ахуеть в край lead
Вакансия: https://hh.ru/vacancy/40640115
Работы куча, задача – сделать заебись, платить, сказали, будут (а это, между прочим, редкость в наши времена) и главное – топовая команда разработки и дизайнеров (в частности мой коллега)
Если что, можете писать в hh с пометкой “своячество – зло” или мне в личку, я вас направлю
Развернуть
Вакансия Lead QA Engineer в Москве, работа в компании Студия Пинкман (вакансия в архиве c 25 декабря 2020)
Вакансия Lead QA Engineer в компании Студия Пинкман. Зарплата: от 100000 ₽ за месяц. Москва. Требуемый опыт: 3–6 лет. Полная занятость. Дата публикации: 25.12.2020.
https://hh.ru/vacancy/40640115
2020-11-30 12:01
☠️ 4 всадника «Требования» ☠️
О том “что такое требование” из чего оно состоит, а главное, как ахуенно удобно и просто его описывать:
https://davidshekunts.ru/2020/11/30/4-vsadnika-trebovaniya/
Спойлер: Требование = Потребность + Проблема (с оценкой боли) + Ожидание (DoS) + Факт завершенности (DoD)
———
Кстати, контента и активности нет, потому что я 6-ю неделю болею короной… Когда поправлюсь, тогда все опять активизируем
О том “что такое требование” из чего оно состоит, а главное, как ахуенно удобно и просто его описывать:
https://davidshekunts.ru/2020/11/30/4-vsadnika-trebovaniya/
Спойлер: Требование = Потребность + Проблема (с оценкой боли) + Ожидание (DoS) + Факт завершенности (DoD)
———
Кстати, контента и активности нет, потому что я 6-ю неделю болею короной… Когда поправлюсь, тогда все опять активизируем
Развернуть
2020-11-09 16:00
🏚 -> Хотите масштабируемую систему? -> 🏰
Системы состоят из:
. Знания – какой-то набор скомпонованных данных, отражающих состояние какого-то понятия / объекта (“Заказ” в интернет-магазине)
. Действия – действия над Знаниями, чаще всего это или CRUD (“получить список Заказов”), или более комплексный набор действий, который производит много CRUD (“оформить Заказ”)
. События – данные, оповещающие о фактах (всегда глагол и всегда в прошлом времени), произошедших в системе над Знаниями во время Действий (при оформлении: “изменился статуса Заказа”, “сформирована накладная в системе доставки”, “произведена оплата”, etc.)
Если про первые 2 понятия присутствуют в любой программе, то про 3-е все успешно забывают, а оно не менее (а часто более) важно!
Ведь именно События позволяют:
1. Разбивать систему на небольшие независимые куски, реагирующие на события друг друга
2. Расширять функционал, создавая системы, который реагируют на события, а не переписывая существующие
3. Знать состояние системы в прошлом (или как минимум поток событий), что позволяет удобнее дебажить
4. etc.
Это сейчас относиться не только к backend или frontend, так можно писать даже библиотеки
О том, как работать с Событиями гуглите:
. DDD Domain и Application Events
. Event Driven Architecture
. Saga pattern
. Orchestration vs Choreography
Ну, или поставьте 15 классов (👌), тогда я сделаю воркшоп на эту тему
———
Системы состоят из:
. Знания – какой-то набор скомпонованных данных, отражающих состояние какого-то понятия / объекта (“Заказ” в интернет-магазине)
. Действия – действия над Знаниями, чаще всего это или CRUD (“получить список Заказов”), или более комплексный набор действий, который производит много CRUD (“оформить Заказ”)
. События – данные, оповещающие о фактах (всегда глагол и всегда в прошлом времени), произошедших в системе над Знаниями во время Действий (при оформлении: “изменился статуса Заказа”, “сформирована накладная в системе доставки”, “произведена оплата”, etc.)
Если про первые 2 понятия присутствуют в любой программе, то про 3-е все успешно забывают, а оно не менее (а часто более) важно!
Ведь именно События позволяют:
1. Разбивать систему на небольшие независимые куски, реагирующие на события друг друга
2. Расширять функционал, создавая системы, который реагируют на события, а не переписывая существующие
3. Знать состояние системы в прошлом (или как минимум поток событий), что позволяет удобнее дебажить
4. etc.
Это сейчас относиться не только к backend или frontend, так можно писать даже библиотеки
О том, как работать с Событиями гуглите:
. DDD Domain и Application Events
. Event Driven Architecture
. Saga pattern
. Orchestration vs Choreography
Ну, или поставьте 15 классов (👌), тогда я сделаю воркшоп на эту тему
———
Развернуть
2020-11-08 09:06
🕸 Как рождаются и почему работают системы 🕸
В начале моей карьеры меня интересовало: “как и зачем появился MVC, MVVM, DDD, Clean Architecture и другие архитектурные паттерны? А главное, почему это работает?”
Дальше, уходя в предринимательнство у меня стали возниакть вопросы: почему работает именно такие правила построения фирмы, деления ответственностей, определения продуктов, бизнес-процессов и подобного
Я нашел ответ и самое крутое, что он относиться к абсолютно любым системам: лекарства, науки, дисциплины, все что может определяться как “методологи”, etc.
Система – это много раз повторенный и проверенный в схожих ситуациях набор вариаций понятий / объектов / действий / etc. из который были выделены вариации, достигающие цель в более 90% случаев
Поэтому, если правильно взвесить требования и условия, подобрать под них готовую систему и начать следовать ее правилам, есть большой шанс, что она будет как минимум “приемлемой”
Да не “идеальная”, но задачи решать вы сможете
И так до момента пока задачи не кончаться или придет время подбирать и использовать новую систему под изменившиеся условия
Так стартап начинает с общего канбана и MVC framework монолите на бэке, а со временем перерастает в наборы холакратических кругов каждый со своей методологией менеджмента и развития и кучей распределенных микросервисов, написанных с использованием DDD
А урок тут следующий:
Если вам очень хочется “полностью с нуля придумать свою систему” (менеджмента, бизнеса, архитектуры приложения, etc.) сначала тресните себя хорошенько по яйца и попробуйте найти и имплементировать (с доработками) уже какую-то готовую систему и если по-прежнему свербит сильнее чем боль в машонке, то ударьте себя еще раз и тогда начинайте изобретать что-то свое
Но, скорее всего, вы обнаружите, что подходящая система под ваши условия уже есть (вы в 99% случаев не уникальны), ее осталость только немного подштриховать под вашу ситуацию
#architecture
В начале моей карьеры меня интересовало: “как и зачем появился MVC, MVVM, DDD, Clean Architecture и другие архитектурные паттерны? А главное, почему это работает?”
Дальше, уходя в предринимательнство у меня стали возниакть вопросы: почему работает именно такие правила построения фирмы, деления ответственностей, определения продуктов, бизнес-процессов и подобного
Я нашел ответ и самое крутое, что он относиться к абсолютно любым системам: лекарства, науки, дисциплины, все что может определяться как “методологи”, etc.
Система – это много раз повторенный и проверенный в схожих ситуациях набор вариаций понятий / объектов / действий / etc. из который были выделены вариации, достигающие цель в более 90% случаев
Поэтому, если правильно взвесить требования и условия, подобрать под них готовую систему и начать следовать ее правилам, есть большой шанс, что она будет как минимум “приемлемой”
Да не “идеальная”, но задачи решать вы сможете
И так до момента пока задачи не кончаться или придет время подбирать и использовать новую систему под изменившиеся условия
Так стартап начинает с общего канбана и MVC framework монолите на бэке, а со временем перерастает в наборы холакратических кругов каждый со своей методологией менеджмента и развития и кучей распределенных микросервисов, написанных с использованием DDD
А урок тут следующий:
Если вам очень хочется “полностью с нуля придумать свою систему” (менеджмента, бизнеса, архитектуры приложения, etc.) сначала тресните себя хорошенько по яйца и попробуйте найти и имплементировать (с доработками) уже какую-то готовую систему и если по-прежнему свербит сильнее чем боль в машонке, то ударьте себя еще раз и тогда начинайте изобретать что-то свое
Но, скорее всего, вы обнаружите, что подходящая система под ваши условия уже есть (вы в 99% случаев не уникальны), ее осталость только немного подштриховать под вашу ситуацию
#architecture
Развернуть