)

2021-06-30 09:30:42 Двигайся дальше

За последних 3.5 года я сменил 4 компании, три из них - по собственной инициативе, а четвертый стартап не взлетел и всех распустили. Каждое рабочее место дарило мне возможность для профессионального роста, повышение зарплаты и новые полезные знакомства.

Раньше люди могли работать всю жизнь на одном заводе. Сейчас динамика сильно изменилась, а смена рабочего места каждых полгода - год уже обычная практика, особенно в IT.

Как понять что пора двигаться дальше? Конечно же все зависит от твоих индивидуальных целей и приоритетов. Кому то важен лишь доход и стабильность, кто-то хочет развиваться как специалист, для кого-то необходим гибкий график, а еще кто-то хочет гореть разрабатываемым продуктом.

Для меня работа должна приносить высокий доход, давать возможность профессионального развития, чувство удовлетворенности и иметь гибкий график. Когда закрыты все требования - это джекпот, но так бывает крайне редко. 

Если текущее место не удовлетворяет тебя по каким-либо критериям и не соответствует твоим личным и профессиональным целям - это повод задуматься о поиске новых возможностей.

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

Это образ мышления жертвы. Мыслить в таком формате значит принимать свою ситуацию как должное, вместо того чтобы быть проактивным и самому отвечать за свою судьбу.

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

Не устраивает зарплата - получи новый оффер. Не нравятся задачи - найди интересный проект. Не хватает профессионального роста - займись этим самостоятельно или поищи новые возможности.

На рынке сейчас много спроса и не так много предложения. Действительно хороших специалистов не так уж и много. Развивай свои навыки и сможешь выбирать для себя самый подходящий вариант. Відкрити / Коментувати

2021-06-23 09:30:26 Ценность разработчика

В чем ценность разработчика? В его знаниях? В высоком уровне экспертизы? В красивом коде, который он пишет?

Компании нанимают программиста, чтобы результат его труда приносил больше денег, привлекал больше клиентов или экономил текущие затраты. И далеко не всегда высокий уровень экспертизы или умение писать красивый код способствуют этому.

Ценность разработчика заключается в его способности приносить пользу. А для этого важно иметь не только техническую экспертизу, но и понимать особенности бизнеса. Часто это еще называют “продуктовым мышлением”.

Хочу уточнить что все сказанное применимо больше к продуктовым компаниям. Разработчику на аутсорсе сложно вникнуть в бизнес и вся его ценность действительно сводиться к количеству закрытых тикетов из таск трекера. 

Однако при работе над продуктом, хороший девелопер стремиться понять конечного пользователя, понять контекст проблемы, который продукт хочет решить. Это понимание помогает правильно расставлять приоритеты и предлагать бизнесу собственные решения.

Задачи, которые спускают на программистов менеджеры часто делать не стоит  вообще. Если вы имеет несколько лет опыта в индустрии, то думаю сталкивались с “кладбищем фич” - набором функционала который так и не дошел до прода.

В основном это происходит из-за того что в самом начале работы над задачей не было задано правильных вопросов: “какую проблему мы решаем?”, “какую пользу принесет эта задача?”, “как это отразиться на пользователях?” и тд.

Пожалуй одно из ключевых различий Junior и Senior разработчиков - джун сразу бросается делать то, что его просят. Senior же ставит все под сомнение, вникает в суть и пытается предложить самое оптимальное решение. Відкрити / Коментувати

2021-06-16 09:30:44 Меньше, но лучше

Примерно 2 года назад я прочитал книгу “Эссенциализм” от Грега МакКеона, которая оказала на меня сильное влияние. Эссенциализм это набор идей и принципов, которые помогают более рационально, эффективно и счастливо жить свою жизнь. Он учит фокусироваться на том что действительно важно, отсекая все второстепенное.

Один из ключевых постулатов данной философии - “less, but better”, что переводиться как “меньше, но лучше”. Это правило можно применять абсолютно к любой сфере деятельности, а в разработке цифровых продуктов оно особенно актуально.

В начале 2019-го мне посчастливилось устроиться инженером в Figleaf - B2C стартап нацеленый на рынок США, который давал пользователю большой набор фич для обеспечения приватности в сети: маскировочные имейлы, маскировочные кредитные карты, прокси, VPN, мониторинг паролей на факт утечки и многое другое. Можно сказать это швейцарский нож в мире privacy.

Проект так и не взлетел, спустя два года со старта его закрыли. Конечно это случилось из-за набора причин и ошибок топ-менеджмента, но одни из главных - максимализм и отсутствие фокуса. В продукт хотели запихнуть как можно больше фич, из-за чего их качество сильно страдало.

В то время на рынке США появился продукт Privacy, который выполняет только одну задачу - дает пользователям возможность делать безопасные покупки в сети с помощью маскировочных кредитных карт. В Figleaf это была только одна из многих фич, в то время как в Privacy это и есть весь продукт.

Privacy достаточно успешный и хорошо развивается. Я уверен что одна из причин - они делают меньше, но лучше. Они сфокусировались на одной проблеме и решают ее хорошо. Вместо того чтобы добавлять они отсекли. И в этом их конкурентное преимущество.

Вместо погони за количество, стоить стремиться к высокому качеству. Не важно о чем идет речь, это правило применимо к любой области.

Стоит делать меньше, но лучше. Отсекать лишнее, фокусируясь на самом важном. Відкрити / Коментувати

2021-06-09 09:31:05 MVP без единой строчки кода

Одна из самых распространенных ошибок технологичных стартапов - потратить огромное количество ресурсов на разработку того что никому не нужно.

Чтобы этого избежать, в начале работы над новым проектом стоит сделать MVP (Minimum Viable Product) - минимально жизнеспособный продукт. Его главная задача - провалидировать или опровергнуть гипотезу за минимальное количество времени и ресурсов.

Давайте разберем пример. 

Компания DoorDash - один из первых сервисов доставки еды в США. В самом начале у основателей появилась гипотеза “а что если можно было бы заказать еду из любого заведения города себе домой?”. 

Как проверить данную гипотезу? Как вариант, можно нанять команду разработчиков, сделать мобильное приложение или веб-сайт, систему отслеживания заказа, интерфейс для курьеров, потратить полгода, кучу денег и только после этого узнать, верна эта гипотеза или нет. Если верна, замечательно, если нет - очень много времени и ресурсов потрачено впустую.

Основатели DoorDash поступили следующим образом - создали на конструкторе лендинг, на который загрузили PDF файл с меню из двух или трех ресторанов и оставили свой номер телефона. Спустя несколько дней им начали звонить первые клиенты и оставлять заказы, после чего они самостоятельно ехали в ресторан, покупали еду и привозили ее первым клиентам. Так у них получилось валидировать идею и развить ее до одного из самых крупных сервисов доставки еды в США.  

В данном случае в качестве MVP послужил лендинг, сделанный на коленке за один вечер и самостоятельно выполненный сервис доставки.

Подобных примеров куча. Много успешных компаний начинались с очень примитивного продукта.

Этой зимой ко мне пришел хороший друг Олег, который несколько месяцев занимался исследованиями рынка медицины и цифрового страхования. У него появилась интересная идея по созданию цифрового сервиса для больших компаний. Он мог бы изменить традиционный подход к предоставлению медицинского страхования в Украине. 

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

Так мы провели целую серию брейнштормов, описали ТЗ для нашего MVP и отдали его дизайнеру. Спустя одну неделю и 50 долларов у нас был кликабельный прототип в Figma, который полностью демонстрировал весь функционал и логику продукта.
 
Мы провели множество звонков с представителями разных компаний, на которых демонстрировали прототип, получали обратную связь и начинали лучше понимать что нужно в продукте, а от чего можно отказаться. 

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

Если бы я решил сразу же начать разрабатывать приложение и писать код, представьте сколько времени и энергии было бы потрачено просто впустую. Но в данном случае обычный прототип в Figma был отличным вариантом MVP.

Валидация гипотез - творческий процесс. Выбор решения зависит от самой идеи и вашей фантазии. Главное помнить - когда вы хотите запустить новый проект, попробуйте провалидировать идею на коленке, используя готовые инструменты прототипирования или конструкторы для создания лендингов. Відкрити / Коментувати

2021-06-02 09:30:59 Разработать продукт не достаточно
 
Мы как представители творческих профессий любим созидать. Программисты кайфуют от кодинга, архитекторы от проектирования зданий, дизайнеры от создания креативов, а писатели от написания текстов.
 
Конечным результатом творческой работы является некий продукт - книга, фильм, картина, скульптура, здание, алгоритм, программный продукт или новое устройство. Однако просто создать продукт не достаточно - нужно позаботиться чтобы о нем узнала целевая аудитория.

Многие создатели об этом забывают. Они закрываются в комнате и молча работают над своим детищем, будь это разработка софта, написание книги, запись онлайн-курса или рисование картины. Они думают что создав качественный продукт, целевая аудитория обязательно узнает о нем самостоятельно. 

Но это не так.

Маркетинг - неотъемлемая часть нашей жизни. Возможно вы об этом не задумывались, но даже когда вы ищите новую работу, заказчика или партнера - это чистый маркетинг. Трудно найти заказчика если о ваших навыках никто не слышал. Трудно найти работу если вы не рассылаете свои резюме или не делитесь портфолио. Трудно найти первых клиентов для вашего цифрового продукта если они никогда о нем не узнают.

Рецепт успешного проекта - качественный продукт и эффективный маркетинг. Поскольку я из тусовки программистов то не по наслышке знаю как инженеры любят фокусироваться на первом пункте и совсем забывают о втором.

Вы хотите разработать свою игру для мобилки и зарабатывать на продажах или внутриигровых покупках? Замечательно! 

А вы подумали кто ваш потенциальный пользователь? Где он проводит свое время, какие сайты читает, в каких соц. сетях залипает, как проводит досуг, что смотрит на YouTube и, самое главное, как он узнает о вашей игре?

Если вы стремитесь к созданию новых продуктов, учитесь не только создавать, но и продвигать. 

По этой теме могу порекомендовать отличную книгу от одного из моих любимых авторов современности Райана Холидея “Маркетинг Будущего”. Он разбирает принципы так называемого “Гроуз хакинга” и демонстрирует примеры из разных областей - от книг до технологичных стартапов. Відкрити / Коментувати

2021-05-26 09:30:45 Не усложняйте
 
Начинающие разработчики часто грешат высокой сложностью своего кода. В качестве решения простых проблем они любят изобретать велосипеды. 
 
Что скажете про следующий кусок кода?
 
case "en":
    switch month {
    case "January":
      date = " January"
    case "February":
      date = " February"
    case "March":
      date = " March"
    case "April":
      date = " April"
    case "May":
      date = " May"
    case "June":
      date = " June"
    case "July":
      date = " July"
    case "August":
      date = " August"
    case "September":
      date = " September"
    case "October":
      date = " October"
    case "November":
      date = " November"
    case "December":
      date = " December"
    }
}
 
Его я написал несколько лет назад на своей первой работе. Честно сказать, я не знаю как мои нейронные связи умудрились сгенерировать подобное решение. А еще я не понимаю как это прошло код ревью от команды. Ну да ладно, главное что работает.

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

Работая с начинающими специалистами я заметил что они любят усложнять. Как из-за неопытности, так и преднамеренно. Новички в программировании любят писать сложно, потому что думают что это признак мастерства. 
 
Чувство красивого кода приходит с опытом. Однако не забывайте себя постоянно спрашивать “Что тут можно убрать? От чего можно отказаться? Как сделать этот код проще? Сможет ли другой программист после меня разобраться с этим?”
 
Помните, если вы работаете в команде, то с вашим кодом будут сталкиваться коллеги. Поймут ли они ваше решение? Смогут ли быстро разобраться? Сделают они это спокойно или их будет при этом сильно бомбить? Відкрити / Коментувати

2021-05-19 09:30:58 От идеи до прода. Запуск Zhashkevych Workshop
 
Когда я начинал учить Go, материала в сети было крайне мало. Из-за этого мне хотелось внести свой вклад в сообщество и собрать все фундаментальные концепции языка в одном месте. Поэтому в июле прошлого года я опубликовал на Medium курс “Язык Go Для Начинающих”. На эту серию статей я потратил несколько недель, а в итоге их никто не читал. 
 
Сегодня не достаточно сделать продукт - нужно чтобы о нем узнала целевая аудитория.

Тогда я перенес материалы курса в PDF файл, который разослал в несколько тематических пабликов в VK. В итоге книжка разлетелась, этот телеграм канал начал понемногу расти, а я наконец решился записать серию видеоуроков для YouTube спустя несколько неудачных попыток.
 
За это время я получил множество позитивных отзывов о книге, а также начал осваивать новое ремесло - регулярное создание контента, что приносит мне огромное удовольствие и вдохновение.
 
В ноябре прошлого года меня посетила идея записать плейлист для YouTube на тему архитектуры веб-приложений. Мною двигала та же мотивация - помочь начинающим разработчикам легко разложить все самые важные темы современной веб-разработки по полочкам. Я не понаслышке знаю, что собрать и систематизировать огромный объем информации достаточно сложно, особенно если ты самоучка.
 
Эта идея сразу переросла в книгу, а проведя опрос в этом канале я окончательно решил приступить за работу над этим амбициозным проектом.
 
Вторую книгу я решил дополнить видеоматериалами и в итоге понял, что она тянет на формат полноценного онлайн-курса. 
 
Забавно, что как первый курс так и второй начинались с небольшой идеи, а со временем выросли в большие проекты. Никогда не знаешь к чему ты придешь в самом начале пути.
 
Темой онлайн-образования я интересуюсь уже давно и наблюдаю за тем, как это делают другие создатели инфопродуктов. Я увидел интересную возможность - рынок онлайн-обучения стремительно развивается, а удобных программных продуктов для создания и распространения курсов не так уж и много.
 
Так началась работа над конструктором онлайн-курсов, процессом разработки которого я делился у себя на YouTube, а исходный код серверной части лежит у меня на Github.
 
Спустя четыре месяца мы вместе с командой готовы анонсировать Zhashkevych Workshop - площадку для моих курсов, которая сделана с помощью данного конструктора.
 
Подробно о процессе работы над данным проектом я делюсь в недавнем видео на YouTube.
 
Пока что на платформе доступен курс “Язык Go Для Начинающих”, но уже в скором времени я опубликую “Архитектуру Современных Веб-Приложений”.

Кстати, в этом курсе, помимо большого объема теории, я подробно разбираю техническую часть данной платформы: архитектуру, стек технологий, модель данных, инфраструктуру и тд.
 
На данный момент платформа еще в сыром виде. Впереди предстоит много работы и пространства для оптимизаций. Я буду очень признателен услышать от вас обратную связь по поводу вашего опыта прохождения курса, удобства интерфейса и возможных улучшений!
 
Без вашей поддержки и интереса ничего этого бы не было
Поэтому спасибо. Я это ценю. Відкрити / Коментувати

2021-05-12 09:30:49 Инженерная культура

Большинство IT проектов улетают в мусорку. Говорят что 9 из 10 стартапов умирают не запустившись.

Происходит это по разным причинам. Самые популярные: отсутствие PMF (Product/Market Fit), нехватка денег, плохой маркетинг, слабые продажи или низкое качество программного продукта.
 
Обидно, когда перспективный продукт с хорошей идеей не взлетает из-за слабой реализации, множества багов или неспособности быстро реагировать на запросы клиентов. 
 
Почему продукты обладают низким качеством? Я думаю ключевыми являются два фактора: слабая команда и/или инженерная культура. 
 
Вопрос построения сильной, сплоченной команды крайне интересный, но в этот раз я хочу поговорить о формировании культуры внутри команды разработки.
 
Давайте для начала обсудим, что вообще такое инженерная культура? 
 
Для меня это набор принципов, правил, привычек и договоренностей, которым команда следует в процессе работы. Даже если никто об этом не задумывается, культура присутствует в любой команде. 
 
Однако развитая инженерная культура не появляется из ниоткуда - это заслуга всех участников команды, которые сознательно прилагают к этому усилия.
 
Формирование инженерной культуры нацелено на повышение скорости разработки и качества программного продукта. Это позволяет сократить Time To Market, снизить количество багов, быстрее проверять бизнесовые гипотезы и выкатывать новые фичи на прод.
 
Как этого достичь?
 
Стоит выделить несколько основных моментов, которые определяют качество и скорость разработки: автоматизация рутинных задач, настроенный CI/CD и линтеры, высокое покрытие модульными, интеграционными и авто тестами, стандартизация написания кода, исчерпывающая и актуальная документация, а также обязательный код ревью. 
 
Когда на проекте развертывание происходит вручную, разработчики не придерживаются единого стиля написания кода, никто не ведет документацию, тестирование и код ревью игнорируются - разработка стоит дорого, длится долго, а в результате получается говно.
 
Со временем подобные проекты обрастают костылями и техническим долгом, разработчикам часто приходиться овертаймить, поскольку работа, которую можно сделать за 4 часа выполняется 3 дня. Бизнес теряет гибкость и способность быстро тестировать новые гипотезы.
 
Хорошие разработчики и управленцы выделят время на формирование правильных процессов и заложат прочный фундамент на начале проекта. Слабые специалисты же побегут сразу писать код, а со временем увязнут в куче проблем и неэффективном рабочем процессе. Відкрити / Коментувати

2021-05-03 13:30:13 ZHASHKEVYCH pinned «21 урок за 21 год Сегодня мне исполнилось 21. В детстве день рождения воспринимался как праздник, сейчас это повод проанализировать свои ошибки, пересмотреть вектор движения, а также провести время с моими близкими   На этот раз я хочу оставить тут памятку.…» Відкрити / Коментувати

2021-05-03 13:30:13 21 урок за 21 год

Сегодня мне исполнилось 21.

В детстве день рождения воспринимался как праздник, сейчас это повод проанализировать свои ошибки, пересмотреть вектор движения, а также провести время с моими близкими
 
На этот раз я хочу оставить тут памятку. Будет интересно вернутся к ней в 25, 30, 50 лет и посмотреть как изменятся мои взгляды за это время.
 
Ниже собраны принципы, которым я стараюсь следовать в личной жизни, взаимоотношениях с другими, работе и которыми хочу поделиться с вами.
 
1. Всегда будь открытым к новому, уважай чужую точку зрения и признавай свои ошибки.
2. Отдавай, не требуя ничего взамен.
3. Полюби дискомфорт.
4. Работай без привязки к результату. Получай удовольствие от процесса и это станет твоим источником удовлетворения.
5. Бери на себя ответственность за свои достижения, свое будущее и счастье своих близких. Не перекладывай ее на других.
6. Все, что тебя окружает, находится либо в зоне твоего контроля, либо вне его. Фокусируйся на том, что в твоих силах изменить и не трать свою энергию на то, что тебе не подвластно.
7. Учись понимать себя, свои желания и амбиции, комплексы и неуверенности. Не бойся признавать их, не бойся быть уязвимым. Только сильные могут смотреть в глаза всем своим проблемам, недостаткам и внутренним демонам.
8. Не пытайся быть кем-то другим, оставайся верным своей аутентичности. Не копируй чужой путь, создавай собственный.
9. Вместо развлечений и дистракций приоретизируй изучение и созидание.
10. Твои самые важные инвестиции - в собственное развитие, здоровье, крепкую дружбу и глубокие отношения с правильными людьми.
11. Фокусируйся на долгосрочном, стремление к быстрым результатам токсично.
12. Научись говорить "нет".
13. Не бойся экспериментировать. Попробовать что-то новое и зафакапить намного лучше чем сожалеть о том, что ты так и никогда не сделал этого.
14. Будь благодарным, учись во всем замечать позитив и новые возможности.
15. Осуждение и критика деструктивны. Направляй свою энергию на вещи созидательные.
16. Будь скромным, никогда не зазнавайся.
17. Сравнение - похититель удовольствия. Не сравнивай себя ни с кем, сравнивай себя лишь с собою вчерашним.
18. Будь внимателен к своему окружению, к вещам на которые ты тратишь свою энергию. Не бойся прощаться с людьми, с которыми вам не по пути.
19. Потребляй осознано. 
20. Твое счастье зависит не от внешних факторов, а от внутреннего восприятия.
21. Чаще улыбайся, делай комплименты и дари позитив другим. Это кайфово

И еще.

Спасибо что вы со мной.
Я это очень ценю, обнял. Відкрити / Коментувати