Привет! Меня зовут Давид Шекунц, я – Full-Stack Go & TS Tech Lead и вы находитесь на сайте с постами из моей 🦾 IT-Качалки 💪
Привет! Сможешь помочь консультацией по менеджеру состояний на фронте?
Развернуть
🌉 Оффлайн встреча в Питере 🌉
Ребятки, кто сейчас в Питере, пишите мне в ЛС (@davidshekunts) давайте встретимся, предположительно, в воскресенье вечером в центре Питера
Более подробное место и время согласуем в ЛС
Всем доброй прокачки 💪
Ребятки, кто сейчас в Питере, пишите мне в ЛС (@davidshekunts) давайте встретимся, предположительно, в воскресенье вечером в центре Питера
Более подробное место и время согласуем в ЛС
Всем доброй прокачки 💪
Развернуть
💸 Просить повышение – ваша ответственность 💸
Я решил прокачать инстаграмм, потому что реклама в ТГ и приток пользователей пока неочень активный, а хочется больше людей, чтобы нести больше пользы
Поэтому приглашаю вас всех присоедениться и вместе прокачивать свои скиллы 💪
В ближайшее время я буду много говорить о росте и развитии в IT, о стрессе и выгорании и что с ними делать, о способах и подходах к проектированию IT-систем и менеджменту проектов
https://www.instagram.com/p/CMaWEhpKkRq/
Я буду по-прежнему писать в ТГ, но всякое более хардкорное
Заходите, подписывайтесь и осталяйте свои мысли 💋
Я решил прокачать инстаграмм, потому что реклама в ТГ и приток пользователей пока неочень активный, а хочется больше людей, чтобы нести больше пользы
Поэтому приглашаю вас всех присоедениться и вместе прокачивать свои скиллы 💪
В ближайшее время я буду много говорить о росте и развитии в IT, о стрессе и выгорании и что с ними делать, о способах и подходах к проектированию IT-систем и менеджменту проектов
https://www.instagram.com/p/CMaWEhpKkRq/
Я буду по-прежнему писать в ТГ, но всякое более хардкорное
Заходите, подписывайтесь и осталяйте свои мысли 💋
Развернуть
🧠 Знания пораждают скорбь 💧
Я ненавижу проходить собеседования у менее квалифицированных специалистов, чем я.
Вот задают тебе вопрос:
"Занимались ли вы масштабированием High Load баз данных?"
И поскольку у меня был достаточно большой опыт я вспоминаю как мы проектировали распределенную систему, с георепликацией, кучей master-slave реплик, шардированием, подключением OLAP системам, локальными БД с проекциями из основной и кучей другой очень сложной шелупони.
Но сам, я не раскрывал эти БД и не настраивал их коммуникацию, потому что это настолько сложно, что даже несколько Senior Архитекторов БД месяцами бились над этой задачей.
Поэтому я честно отвечаю:
"Я проектировал, но сам не занимался"
Интервьюирующий пишет у себя:
"Не имеет опыта масштабирования баз данных"
И так проходит куча тонких вопросов, я честно отвечаю на каждый из них, а в самом конце, начинаю сам задавать вопросы, и тут выясняется...
Во-первых, текущая БД просто не подходит под задачи архитектуры и ее масштабирование в 10 раз дороже, чем использование стороннего доступного решения, которое полностью закроет всю потребность. И нет никаких причин его не использовать.
А во-вторых, у интервьюера всего 1-2 года за плечами...
Вот он в свои 1-2 года уверен, что "надо масштабировать БД".
А я, поскольку уже много лет сталкивался с этими проблемами, понимаю, что не БД надо масштабировать, а немного архитектуру поменять, так чтобы сэкономить х10 времени и сил.
Только по итогу я со своими знаниями и сомнениям – полупокер лоховской, а вот этот мидл – маестро ле монефик.
Потому что меня обуревает тяжесть своих знаний и понимание бесконечности своего незнания, а его пока нет.
Короче, господа Суньеры и другие опытные спецы, чаще бы нам с вами уверенности юнцов, ведь на деле вообще никто ничего не знает и нет в этом ничего плохого.
Я ненавижу проходить собеседования у менее квалифицированных специалистов, чем я.
Вот задают тебе вопрос:
"Занимались ли вы масштабированием High Load баз данных?"
И поскольку у меня был достаточно большой опыт я вспоминаю как мы проектировали распределенную систему, с георепликацией, кучей master-slave реплик, шардированием, подключением OLAP системам, локальными БД с проекциями из основной и кучей другой очень сложной шелупони.
Но сам, я не раскрывал эти БД и не настраивал их коммуникацию, потому что это настолько сложно, что даже несколько Senior Архитекторов БД месяцами бились над этой задачей.
Поэтому я честно отвечаю:
"Я проектировал, но сам не занимался"
Интервьюирующий пишет у себя:
"Не имеет опыта масштабирования баз данных"
И так проходит куча тонких вопросов, я честно отвечаю на каждый из них, а в самом конце, начинаю сам задавать вопросы, и тут выясняется...
Во-первых, текущая БД просто не подходит под задачи архитектуры и ее масштабирование в 10 раз дороже, чем использование стороннего доступного решения, которое полностью закроет всю потребность. И нет никаких причин его не использовать.
А во-вторых, у интервьюера всего 1-2 года за плечами...
Вот он в свои 1-2 года уверен, что "надо масштабировать БД".
А я, поскольку уже много лет сталкивался с этими проблемами, понимаю, что не БД надо масштабировать, а немного архитектуру поменять, так чтобы сэкономить х10 времени и сил.
Только по итогу я со своими знаниями и сомнениям – полупокер лоховской, а вот этот мидл – маестро ле монефик.
Потому что меня обуревает тяжесть своих знаний и понимание бесконечности своего незнания, а его пока нет.
Короче, господа Суньеры и другие опытные спецы, чаще бы нам с вами уверенности юнцов, ведь на деле вообще никто ничего не знает и нет в этом ничего плохого.
Развернуть
🤐 Главный секрет проектирования и архитектуры 🤐
Абсолютно все, что мы делаем в IT сводиться к 3-м функциям: (1) передача, (2) обработка и (3) хранением данных.
Мы делаем запрос на сервер и передаем с него данные на фронт.
Мы визуализируем эти данные в формах и таблицах, передавая их во внешний мир через дисплеи компьютеров, мобилок и других устройств.
А потом внешний пользователь через интерфейсы доступа (клавиатура, touch панель, переключатели) в обратную сторону передает данные в устройство.
Мы трансформируем эти данные заполняя формочки на фронте, а потом трансформируем их же на бэке.
В конце мы сохраняем эти данные в базах данных и цикл повторяется заново.
И все это работает не только в вебе:
Нажав на кнопку умной кофеварки, мы передаем команду устройству, мы трансформируем и сохраняем изменившийся бит в микроконтроллере, это дает положительный заряд на пластинку кремния, который в свою очередь активирует транзисторы, пропускающие 5-12 вольт на реле, где заряжается магнитная подушечка, происходит соединение металических контактов и по ним начинает течь 220 вольт. Наш умный кофе поступает в тупой стакан.
В итоге, абсолютно все задачи по проектированию архитектуры IT-систем сводятся к 3-м вопросам:
1. Как мы будем передавать данные?
2. Как мы будем их трансформировать?
3. И как мы будем их хранить?
Вы просто снова и снова задаете себе эти вопросы и ищите ответы. В разрезе всех участвующих систем: интерфейсов, серверов, сетей, устройств, etc.
Хороший проектировщик / архитектор не только знает как построить все эти цепочки, но знает как это сделать максимально оптимизировано и чтобы при этом на разработку не ушли годы.
P.S.
Я – бездарь и неучь и уверен, что эти мысли были сформулированы задолго до меня, поэтому предлагаю вам поправить меня, если вы не согласны с какой-либо из формулировок. Поскольку только вместе мы – сила 💪
Абсолютно все, что мы делаем в IT сводиться к 3-м функциям: (1) передача, (2) обработка и (3) хранением данных.
Мы делаем запрос на сервер и передаем с него данные на фронт.
Мы визуализируем эти данные в формах и таблицах, передавая их во внешний мир через дисплеи компьютеров, мобилок и других устройств.
А потом внешний пользователь через интерфейсы доступа (клавиатура, touch панель, переключатели) в обратную сторону передает данные в устройство.
Мы трансформируем эти данные заполняя формочки на фронте, а потом трансформируем их же на бэке.
В конце мы сохраняем эти данные в базах данных и цикл повторяется заново.
И все это работает не только в вебе:
Нажав на кнопку умной кофеварки, мы передаем команду устройству, мы трансформируем и сохраняем изменившийся бит в микроконтроллере, это дает положительный заряд на пластинку кремния, который в свою очередь активирует транзисторы, пропускающие 5-12 вольт на реле, где заряжается магнитная подушечка, происходит соединение металических контактов и по ним начинает течь 220 вольт. Наш умный кофе поступает в тупой стакан.
В итоге, абсолютно все задачи по проектированию архитектуры IT-систем сводятся к 3-м вопросам:
1. Как мы будем передавать данные?
2. Как мы будем их трансформировать?
3. И как мы будем их хранить?
Вы просто снова и снова задаете себе эти вопросы и ищите ответы. В разрезе всех участвующих систем: интерфейсов, серверов, сетей, устройств, etc.
Хороший проектировщик / архитектор не только знает как построить все эти цепочки, но знает как это сделать максимально оптимизировано и чтобы при этом на разработку не ушли годы.
P.S.
Я – бездарь и неучь и уверен, что эти мысли были сформулированы задолго до меня, поэтому предлагаю вам поправить меня, если вы не согласны с какой-либо из формулировок. Поскольку только вместе мы – сила 💪
Развернуть
🦍 Эволюция разработчика v1.3 "Вкусные ветки развития" 👨💻
В прошлых постах мы поговорили про рост в качестве и про сторонние ветки развития.
А сейчас я добью последние 3 ветки развития разработчика.
Вот эти ветки очень крутые и вполне доступные любому разработчику от Middle+ за 2-3 месяца.
! Дисклеймер ! В ближайшие 2 недели я устрою серию вебинаров, в которых буду разбирать все плюсы и минусы каждой позиции, как до них расти, какие перспективы заработка и что нужно для трудоустройства. Следите за новостями в канале.
1. Бизнес Системный Аналитик (БСА) – об этой роли не так много говорят, но она невероятно интересная.
Условно это локальный бизнес Архитектор. Его задача – полностью изучить бизнес-процесс и потребность пользователей, а после спроектировать систему и передать ее разработке (Team Lead, например), которая сформулирует уже конкретные спринты.
Вы уже не будете заниматься кодом, ваша основная задача будет анализировать огромные объемы информации и придумывать самые оптимальные способы решения, создавая документацию и схемы. Но по-прежнему потребуется много технологических скиллов в архитектуре и проектировании, поскольку все ваши решения должны будут лечь в основы кода множества сервисов.
Вакансий достаточно много и они высокооплачиваемые.
2. Data Engineer – мало кто знает про эту роль, но ее основная задача: спроектировать и реализовать потоки данных и их трансформации до целевых систем.
Чаще всего, это работа с созданием хранилища источника данных, валидации и чистки, подготовке к решению бизнес задач (через BI визуализацию и Data аналитику).
Вы будете писать код выгрузки из источников, трансформации и визуализации данных (ETL). Эти задачи требуют хорошего знания бизнеса, работы со структурами данных и базами, но при этом не особо много от дата саенс или аналитики.
Рынок среднего размера и платят хорошо.
3. Продуктовый инженер (Product Engineer) – а вот это самое интересное и новое. Тренд, который я подметил на начало 2021-го года, который скоро станет "де-факто".
Это не совсем "специализация", это скорее роль / подход к мышлению, когда вы ставите перед разработкой задачу не "разработать менюшку", а "сделать более эффективный способ пользователю работать с системой".
Продуктовый инженер знает чего хотят пользователи и ставит себе задачи по удовлетворению этих потребностей через разработку фич.
Это нечто среднее между PO, БСА и Team Lead.
Рассказывать об этой роли я могу долго, поэтому готовьтесь к серии статей, в которых я буду раскрывать особенности его работы.
---
Если вам понравилось, то ставьте 🔥 секси-эмоджи 🚀 в комментарии, пишите о чем вам больше хотелось бы услышать и ждите вебинаров 😘
В прошлых постах мы поговорили про рост в качестве и про сторонние ветки развития.
А сейчас я добью последние 3 ветки развития разработчика.
Вот эти ветки очень крутые и вполне доступные любому разработчику от Middle+ за 2-3 месяца.
! Дисклеймер ! В ближайшие 2 недели я устрою серию вебинаров, в которых буду разбирать все плюсы и минусы каждой позиции, как до них расти, какие перспективы заработка и что нужно для трудоустройства. Следите за новостями в канале.
1. Бизнес Системный Аналитик (БСА) – об этой роли не так много говорят, но она невероятно интересная.
Условно это локальный бизнес Архитектор. Его задача – полностью изучить бизнес-процесс и потребность пользователей, а после спроектировать систему и передать ее разработке (Team Lead, например), которая сформулирует уже конкретные спринты.
Вы уже не будете заниматься кодом, ваша основная задача будет анализировать огромные объемы информации и придумывать самые оптимальные способы решения, создавая документацию и схемы. Но по-прежнему потребуется много технологических скиллов в архитектуре и проектировании, поскольку все ваши решения должны будут лечь в основы кода множества сервисов.
Вакансий достаточно много и они высокооплачиваемые.
2. Data Engineer – мало кто знает про эту роль, но ее основная задача: спроектировать и реализовать потоки данных и их трансформации до целевых систем.
Чаще всего, это работа с созданием хранилища источника данных, валидации и чистки, подготовке к решению бизнес задач (через BI визуализацию и Data аналитику).
Вы будете писать код выгрузки из источников, трансформации и визуализации данных (ETL). Эти задачи требуют хорошего знания бизнеса, работы со структурами данных и базами, но при этом не особо много от дата саенс или аналитики.
Рынок среднего размера и платят хорошо.
3. Продуктовый инженер (Product Engineer) – а вот это самое интересное и новое. Тренд, который я подметил на начало 2021-го года, который скоро станет "де-факто".
Это не совсем "специализация", это скорее роль / подход к мышлению, когда вы ставите перед разработкой задачу не "разработать менюшку", а "сделать более эффективный способ пользователю работать с системой".
Продуктовый инженер знает чего хотят пользователи и ставит себе задачи по удовлетворению этих потребностей через разработку фич.
Это нечто среднее между PO, БСА и Team Lead.
Рассказывать об этой роли я могу долго, поэтому готовьтесь к серии статей, в которых я буду раскрывать особенности его работы.
---
Если вам понравилось, то ставьте 🔥 секси-эмоджи 🚀 в комментарии, пишите о чем вам больше хотелось бы услышать и ждите вебинаров 😘
Развернуть
Развернуть
🇵🇳Никто не знает английский и что с этим делать 🇲🇸
Чем больше я работаю с иностранными коллегами, тем больше убеждаюсь в том, о чем ни в школе, ни в институте, ни на курсах практически не говорят:
Основная проблема – это не "знание как правильно что-то написать/сказать", а "как понять, когда собеседник ошибается"
Так вот: абсолютно все люди, всегда ошибаются
Ошибаются не только грамматически, но и лексически, и ОСОБЕННО СЛОЖНО УЛОВИМЫЙ БАГ это когда они ошибаются логически
Ну вы же сами знаете, когда у вас путаются мысли и вы пишите не: "мы письмо заказчику отправили на рассмотрение" – а: "я – толостожопый говноклюв" – ну и всех же бывало, правда? правда?... сранный Т9... но не важно, я к тому, что мы часто даже на своем языке ошибаемся из-за усталости, перенапряжения, а иногда просто потому что решаем написать "хоть как-то" в надежде, что нас поймут
Вот тоже самое происходит и с людьми, которые общаются с вами на английском
Особенно часто это происходит с нэйтив спикерами, потому что они привыкли писать на отъебись, ведь их же сограждане понимают, значит и вы поймете
И вот ты сидишь, читаешь ересь, которую тебе прислал твой зарубежный коллега и думаешь: "Я что, реально настолько не понимаю английский? Какой 'говноклюв'? Ну, он же знает английский, значит, это я не понимаю что здесь написано..." – и вот с этой уверенностью, что на той стороне все сделали правильно, вы начинаете копаться в том, что никогда правильным и не было
Это проблема лечиться очень просто:
Если вы не можете понять, что написал вам собеседник или у вас закралась толика сомнения о правильности написанного, ВСЕГДА переспрашиваете, что человек имел ввиду
Любой специалист, который работает с зарубежными коллегами более 1 года уже привык разъяснять свои мысли и искать альтернативные способы донести информацию – это норма международной переписки
Короче, иногда нужно понимать, что не вы дебил (даже, если вы дебил), а ваш собеседник, потому что все бывают дебилами
Чем больше я работаю с иностранными коллегами, тем больше убеждаюсь в том, о чем ни в школе, ни в институте, ни на курсах практически не говорят:
Основная проблема – это не "знание как правильно что-то написать/сказать", а "как понять, когда собеседник ошибается"
Так вот: абсолютно все люди, всегда ошибаются
Ошибаются не только грамматически, но и лексически, и ОСОБЕННО СЛОЖНО УЛОВИМЫЙ БАГ это когда они ошибаются логически
Ну вы же сами знаете, когда у вас путаются мысли и вы пишите не: "мы письмо заказчику отправили на рассмотрение" – а: "я – толостожопый говноклюв" – ну и всех же бывало, правда? правда?... сранный Т9... но не важно, я к тому, что мы часто даже на своем языке ошибаемся из-за усталости, перенапряжения, а иногда просто потому что решаем написать "хоть как-то" в надежде, что нас поймут
Вот тоже самое происходит и с людьми, которые общаются с вами на английском
Особенно часто это происходит с нэйтив спикерами, потому что они привыкли писать на отъебись, ведь их же сограждане понимают, значит и вы поймете
И вот ты сидишь, читаешь ересь, которую тебе прислал твой зарубежный коллега и думаешь: "Я что, реально настолько не понимаю английский? Какой 'говноклюв'? Ну, он же знает английский, значит, это я не понимаю что здесь написано..." – и вот с этой уверенностью, что на той стороне все сделали правильно, вы начинаете копаться в том, что никогда правильным и не было
Это проблема лечиться очень просто:
Если вы не можете понять, что написал вам собеседник или у вас закралась толика сомнения о правильности написанного, ВСЕГДА переспрашиваете, что человек имел ввиду
Любой специалист, который работает с зарубежными коллегами более 1 года уже привык разъяснять свои мысли и искать альтернативные способы донести информацию – это норма международной переписки
Короче, иногда нужно понимать, что не вы дебил (даже, если вы дебил), а ваш собеседник, потому что все бывают дебилами
Развернуть
🦍 Эволюция разработчика v1.2 "Сторонние ветки развития" 👨💻
В прошлом посте рассматривал основные градации развития web разработчика.
Теперь хочу рассказать про сторонние ветки, куда может уйти разработчик сделав несколько пет-проджектов:
(указанные сроки я беру с учетом занятости на основной работе, но выделению хотя бы 6 часов в неделю на разработку пет проджектов)
! Дисклеймер ! Этот пост скорее про небольшое разочарование, потому что в реальности перейти на специализации, указанные ниже, гораздо сложнее, чем кажется.
1. Native Mobile Developer (срок перехода 6 месяцев) – вроде очевидно, но скажу из личного опыта: это другой мир. Здесь работают другие принципы: разработка через GUI, релизы – это невероятная боль, поскольку нельзя резко обновить скачанное приложение (хотя и есть механизмы), нужно гораздо больше знать спецификации платформы и языка, если iOS, то переход на Swift более менее, а вот когда увидите Objective C заплачите, etc. Короче, переход непростой, но если мобильные платформы – это ваш фетиш, то оно будет того стоить. Вакансий с хорошей оплатой очень прилично.
2. Hybrid Mobile Developer (срок перехода 6 месяцев) – приложеньки на React Native (RN) / Flutter (Fl). Тут переход гораздо более нативный и приятный. Вы по-прежнему столкнетесь с кучей сложностей отсутствия знания нативных платформ + добавятся проблемы самих платформ (RN, Fl) + если вы не сделали хотябы нативных 1-2 приложения, то скорее всего вы не быстро найдете работу не в стартапе (говорю конкретно про 2021-ый). Короче, непростой путь, но если у вас уже хороший навык JS и вы достаточно технологически верткий, то попробовать точно стоит. Рынок небольшой и платят средне.
3. Game Client Developer (срок перехода 9 месяцев) – вот тут очень интересно. Мне повезло поработать над гиперказуальными играми, как в формате Hybrid, так и с Unity. Скажу следующее: если вы готовы в математику, написание гиперсложной бизнес логики, начать работать с графикой и движками рендеринга, изучить с физику, овладеть новым языком (все JS движки гавно), то добро пожаловать. В эту индустрию нужно не просто быть влюбленным, нужно ей жить и с ней умереть. Найти работу сложно (особенно, если не хочется в гэмблинг), платят не так много, но от интереса аж анус пригорать будет.
4. Game Back Developer (4-6 месяцев) – вот тут проще, но зависит от того, что вы делали до этого. В чем смысл смены Web на Gamedev? Сложность и нетривиальность задач возрастут до небес. Неисключено, что все описанное в пункте 3 вы будете тоже делать, НО с кучей работы с БД и инфраструктурой. Мир backend для разработки игр очень сексуальный, я поработал однажды над архитектурой одной высоконагруженной онлайн игры и был невероятно впечатлен. Найти работу проблематично, но денег платят хорошо. Лучше материалы на эту тему читайте в блоге Pixonic.
5. Web animation developer (4 месяца) – это очень узкая ниша (особенно в России), но я знаю достаточно людей, у которых стоит на веб-графику. Лучшими примерами подобных работ будет сайт awwwards. И опять же, мне повезло сделать несколько продакшен проектов с использованием полностью самописной графики и анимации и вот мое заключение: если вы готовы в математику и векторную графику, интересуетесь механиками построения анимации и работы графических движков, готовы изучать программы 3d моделирования и погрузиться в самые дебри JS, чтобы вытаскивать из него крупицы фреймов, то добро пожаловать. Найти работу будет тяжело, но оплата будет достойная.
Сторонних веток оказалось настолько много, что я решил разделить этот пост на 2, так что далее вы узнаете про уже гораздо более воодушевляющие роли с более быстрым переходом, так как: Бизнес Системный Аналитик, Data Engineer и Product Engineer.
А также 2 бонус статьи:
1. Про преимущества и недостатки смены стэка (например с PHP на Golang или даже Elixir)
2. И о бытие IoT разработчика
Может я не перечислил еще какие-то роли или пути развития? Если у вас есть идеи, пишите в комменты 😘
#evolution
В прошлом посте рассматривал основные градации развития web разработчика.
Теперь хочу рассказать про сторонние ветки, куда может уйти разработчик сделав несколько пет-проджектов:
(указанные сроки я беру с учетом занятости на основной работе, но выделению хотя бы 6 часов в неделю на разработку пет проджектов)
! Дисклеймер ! Этот пост скорее про небольшое разочарование, потому что в реальности перейти на специализации, указанные ниже, гораздо сложнее, чем кажется.
1. Native Mobile Developer (срок перехода 6 месяцев) – вроде очевидно, но скажу из личного опыта: это другой мир. Здесь работают другие принципы: разработка через GUI, релизы – это невероятная боль, поскольку нельзя резко обновить скачанное приложение (хотя и есть механизмы), нужно гораздо больше знать спецификации платформы и языка, если iOS, то переход на Swift более менее, а вот когда увидите Objective C заплачите, etc. Короче, переход непростой, но если мобильные платформы – это ваш фетиш, то оно будет того стоить. Вакансий с хорошей оплатой очень прилично.
2. Hybrid Mobile Developer (срок перехода 6 месяцев) – приложеньки на React Native (RN) / Flutter (Fl). Тут переход гораздо более нативный и приятный. Вы по-прежнему столкнетесь с кучей сложностей отсутствия знания нативных платформ + добавятся проблемы самих платформ (RN, Fl) + если вы не сделали хотябы нативных 1-2 приложения, то скорее всего вы не быстро найдете работу не в стартапе (говорю конкретно про 2021-ый). Короче, непростой путь, но если у вас уже хороший навык JS и вы достаточно технологически верткий, то попробовать точно стоит. Рынок небольшой и платят средне.
3. Game Client Developer (срок перехода 9 месяцев) – вот тут очень интересно. Мне повезло поработать над гиперказуальными играми, как в формате Hybrid, так и с Unity. Скажу следующее: если вы готовы в математику, написание гиперсложной бизнес логики, начать работать с графикой и движками рендеринга, изучить с физику, овладеть новым языком (все JS движки гавно), то добро пожаловать. В эту индустрию нужно не просто быть влюбленным, нужно ей жить и с ней умереть. Найти работу сложно (особенно, если не хочется в гэмблинг), платят не так много, но от интереса аж анус пригорать будет.
4. Game Back Developer (4-6 месяцев) – вот тут проще, но зависит от того, что вы делали до этого. В чем смысл смены Web на Gamedev? Сложность и нетривиальность задач возрастут до небес. Неисключено, что все описанное в пункте 3 вы будете тоже делать, НО с кучей работы с БД и инфраструктурой. Мир backend для разработки игр очень сексуальный, я поработал однажды над архитектурой одной высоконагруженной онлайн игры и был невероятно впечатлен. Найти работу проблематично, но денег платят хорошо. Лучше материалы на эту тему читайте в блоге Pixonic.
5. Web animation developer (4 месяца) – это очень узкая ниша (особенно в России), но я знаю достаточно людей, у которых стоит на веб-графику. Лучшими примерами подобных работ будет сайт awwwards. И опять же, мне повезло сделать несколько продакшен проектов с использованием полностью самописной графики и анимации и вот мое заключение: если вы готовы в математику и векторную графику, интересуетесь механиками построения анимации и работы графических движков, готовы изучать программы 3d моделирования и погрузиться в самые дебри JS, чтобы вытаскивать из него крупицы фреймов, то добро пожаловать. Найти работу будет тяжело, но оплата будет достойная.
Сторонних веток оказалось настолько много, что я решил разделить этот пост на 2, так что далее вы узнаете про уже гораздо более воодушевляющие роли с более быстрым переходом, так как: Бизнес Системный Аналитик, Data Engineer и Product Engineer.
А также 2 бонус статьи:
1. Про преимущества и недостатки смены стэка (например с PHP на Golang или даже Elixir)
2. И о бытие IoT разработчика
Может я не перечислил еще какие-то роли или пути развития? Если у вас есть идеи, пишите в комменты 😘
#evolution
Развернуть