ZHASHKEVYCH
1.61K subscribers
59 links
Привет, меня зовут Максим Жашкевич👋
Профессионально занимаюсь разработкой с 16 лет. Пишу про IT индустрию, разработку продуктов и личностный рост

https://www.youtube.com/c/MaksimZhashkevych
https://www.instagram.com/zhashkevych
https://zhashkevych.com
Download Telegram
to view and join the conversation
80/20

20% усилий приносят 80% результатов. И наоборот.

Это известный закон Парето или "принцип 80/20", который можно проследить во многих сферах жизни.

20% клиентов приносит 80% доходов.
20% населения владеют 80% ресурсов.
20% видео на YouTube собирают 80% просмотров.
20% продуктов в магазине приносят 80% продаж.
20% фич в приложении используется 80% времени.

Продолжать можно до бесконечности.

Конечно не обязательно, чтобы соотношение было именно 80/20, это может быть как 70/30 так и 99/1. Главная идея заключается в непропорциональном соотношении усилий и результатов.

Что все это значит?

Больше работы != больше результатов.
4 часа сфокусированного труда принесет больше отдачи чем неделя имитации бурной деятельности.

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

Что с этим делать?

Понимая данный принцип, стоит постоянно проводить анализ 80/20. Находить те действия, которые приносят наибольшую отдачу. И фокусироваться на них, отсекая лишниее 80%.

При изучении нового навыка, какие 20% ваших усилий принесли 80% прогресса? Если это программирование, что принесло больше пользы: 10 часов кодинга или 50 часов просмотра сомнительных уроков на YouTube?

При разработке программного продукта, какие 20% трудозатрат принесут 80% результатов?
Действительно ли нужно добавлять 10 новых фич? Или лучше сфокусироваться на 2-х существующих и реализовать их безупречно?

Я часто слышу что "нужно делать больше".
Нет. Нужно делать меньше. Но лучше.
Программирование и разработка

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

Еще в раннем возрасте я начал учить программирование, потому что хотел создавать свои игры и программы. Чуть позже у нас в школе начались уроки информатики, на которых учитель предложил мне заниматься с ним дополнительно после уроков. Тогда я познакомился с С++ и начал решать олимпиадные задачи.

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

С другой стороны есть разработка ПО. Это может быть создание собственных программных продуктов, заказная разработка или работа в организации. В любом случае, продукт создается для решения бизнес-задач и создания ценности (материальной, социальной и тд.). У бизнеса есть ограниченные сроки и бюджет, а само программное обеспечение может существовать и видоизменятся на протяжении многих лет.

Разработка программного обеспечения требует гораздо большего, чем просто навыков программирования. За этим процессом стоит продуктовый дизайн, управление проектом, customer development, архитектура ПО, настройка и масштабирование инфраструктуры, построение процессов и много чего другого.

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

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

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

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

На этих выходных решил структурировать основные темы бекенд разработки и собрать набор полезных ресурсов по каждой из них.

Надеюсь что многим пригодиться. Список лежит у меня на Github, если хотите его дополнить и поделиться своими ссылками - feel free to contribute.
Софт скиллы
 
Много инженеров не уделяют должного внимания развитию софт скиллов. А зря.
 
Софт скиллы - это широкий спектр личностных и профессиональных качеств, от грамотной коммуникации, ответственности и делегирования до открытости к новому, контроля эмоций и возможности быстро изучать новое (в том числе хард скиллы).
 
Софт скиллы становятся актуальнее чем когда либо. Мы живем в динамично развивающемся мире.
Вы знаете, как будет выглядеть рынок труда в 2050-ом и какие профессии будут актуальны? И я нет.
 
Буквально 10-15 лет назад никто не слышал про Data Science и Machine Learning инженеров и никто не знал зачем нужно учить поведенческую психологию для разработки программных продуктов.
 
Приведу еще один пример. В прошлом десятилетии появилась профессия, которая называется Attention Engineer. Эти специалисты работают на стыке психологии и технологий, чтобы создавать программные продукты, которые в прямом смысле вызывают зависимость.
 
Они проектируют приложения таким образом, чтобы пользователи тратили на них все больше своего времени и внимания. Именно поэтому так легко залипнуть в YouTube, Facebook или Instagram и не заметить как быстро пролетело время - это заложено в дизайн этих платформ.
 
Возможно, вы даже не догадывались о такой профессии, как и множестве других, которые сейчас становятся актуальными на рынке.
 
Еще 50-100 лет назад мир выглядел иначе. Изучив какой-нибудь навык, люди могли всю жизнь проработать на одном рабочем месте.
 
А что сейчас?
 
Вспомните про сис. админов, или крутых "веб-мастеров" со знанием HTML/CSS и jQuery. Кому они сейчас нужны?  Только на старых проектах, где платят небольшие зарплаты.
 
Те кто смог адаптироваться под изменения в индустрии и переквалифицировался в DevOps и Frontend инженера живут хорошо, а те кто не смог сейчас жалуются на политиков и свою жизнь.
 
Выучив некий набор хард скиллов сегодня, у вас нету никаких гарантий, что через 10-15 лет вы будете востребованы на рынке труда.
 
Даже если вы сейчас умеете эффективно разрабатывать высоконагруженные системы на Go и у вас все замечательно, не факт что в обозримом будущем эти навыки все еще будут актуальными и хорошо оплачиваться.
 
Звучит не очень оптимистично, согласен. Однако тут как раз таки и становится очевидным, что нужно прокачивать свои личностные качества: способность к быстрому изучению нового, самоорганизацию, эмоциональный интеллект, грамотное письмо и коммуникацию.
 
Это то, что позволит успешно адаптироваться к новым условиям, новым рабочим местам, новым профессиям, новым коллективам. Это навыки, которые являются фундаментом личностного и профессионального развития.
​​Неэффективность больших команд и ошибка преждевременного роста
 
В начале 2019-го я устроился инженером в достаточно крупный B2C стартап. Большая компания, огромный коллектив, эффектные корпоративы раз в полгода, собственный ресторан, тренажерный зал и занятия йогой прямо в офисе, который в свое время победил в международном конкурсе дизайна.
 
Концепция продукта - предоставить возможность пользователям обезопасить себя в сети с помощью широкого спектра фич, от проверки своих паролей на факт утечки до онлайн-покупок с помощью виртуальных кредитных карт.
 
На момент моего прихода в компанию команда состояла из +- 70 людей, на бекенде нас было четверо. Спустя полгода количество людей в организации удвоилось, в одном лишь отделе разработки работало порядка 50 специалистов.
 
Казалось бы, у бизнеса должно быть все просто замечательно. Компания растет, следовательно продукт стремительно развивается и приносит много прибыли. А чтобы его масштабировать и улучшать, топ-менеджмент решил набирать в команду все больше специалистов.
 
На деле же все выглядело совсем по-другому. Продукту не хватало самого главного - покупателей, которые хотят решать проблему личной безопасности в сети за ту стоимость, которую мы предлагали. В управлении продуктами есть такое понятие как product/market fit - именно он у нас отсутствовал.
 
Не смотря на это, организация тратила огромную часть бюджета на маркетинг и разработку, нанимала все больше специалистов. Это привело к тому, что в определенный момент половину сотрудников уволили. Еще через месяц проект закрыли.
 
Из этой истории и моего опыта работы в такой организации можно сделать несколько интересных выводов.
 
Первый и самый главный - при запуске продукта необходимо найти свое место на рынке, понять своего клиента и решать его проблему так, чтобы он был готов за это заплатить. Без этого все остальные действия не имеют смысла и ведут к провалу.
 
Не нужно заботиться о запуске дорогих маркетинговых кампаний. Не нужно думать про масштабирование на миллион пользователей. Не нужно раздувать штат персонала. Все это должно следовать уже после валидации продуктовой гипотезы и первой волны продаж.
 
Второй интересный вывод - большие команды контрпродуктивны. Основная причина этому - возрастающая сложность коммуникации. Это можно легко объяснить с помощью закона Меткалфа. Он гласит что эффективность сети пропорциональна примерно половине квадрата количества подключенных устройств к этой сети.
 
Этот закон можно легко применить и к группе людей. Чем больше в команде людей, тем больше количество потенциальных взаимосвязей, тем сложнее становиться организация и коммуникация внутри такой группы. Из-за этого много времени терялось на бесполезные митинги, обсуждения и передачу знаний другим коллегам / новым сотрудникам.
 
Ко всему этому, большая организация теряет гибкость и медленно реагирует на изменения, что крайне необходимо в условиях стартапа.
 
После того проекта я принял участие в разработке B2B стартапа в другой компании. За полгода мы разработали более сложный продукт с точки зрения технической реализации. Наша команда состояла из менее чем 10-ти человек, все работали удаленно.
 
Меня вдохновляют много разных компаний, одна из них - Basecamp и ее учредители Джейсон Фрайд и Дэвид Хейнемейер. Их главному продукту уже 15 лет, за это время они выросли до 20 миллионов активных пользователей. На данный момент в их компании работает 52 или 53 сотрудника, и это вместе со службой поддержки. Они осознанно отказываются от большого штата сотрудников, поскольку считают что это только навредит компании, о чем рассказывают в интервью и пишут в своих книгах Getting Real и Rework.
 
Больше не значит лучше и эффективнее. Часто даже наоборот. Раздутый штат не решит проблему отсутствия спроса на твой продукт. А с определенного количества специалистов, команда начинает терять свою эффективность.
Баланс качества
 
При разработке программного продукта хороший инженер стремится заложить идеальную архитектуру, написать безупречный код, достичь 100%-ое покрытие тестами, создать масштабируемое и отказоустойчивое решение. Это благие цели. Однако такой подход не всегда может позитивно сказыватся на конечном результате.
 
Сразу уточню, что все зависит от контекста. Следующие наблюдения применимы к молодым стартапам и заказной разработке с ограниченными сроками и бюджетом, но будут плохим советом для крупных Enterprise продуктов. 
 
При разработке больших энтерпрайз решений компания имеет много денег и времени. В таких условиях на первое место выходит качество разрабатываемого продукта. В стартапах и некоторых заказных проектах дела обстоят иначе. Там бизнес хочет быстро запуститься, валидировать идею и начать зарабатывать деньги.
 
Данный контекст непосредственно влияет на разработку. На начальном этапе имеет смысл отказаться от сложной архитектуры с кучей микросервисов, 100%-го покрытия тестами и пожертвовать лучшими практиками по написанию кода, что поможет сократить время выпуска продукта в продакшн. 
 
Главная цель на начальном этапе - сделать рабочую версию продукта, на который можно пустить трафик и получить первые результаты.
 
Будет ли это качественное решение? Нет.
Будет ли это масштабируемое и отказоустойчивое решение? Нет.
Будет ли этого достаточно на начале? Да.
 
Нужно держать в голове то, что клиент не заплатит вам за высокое покрытие тестами или красивый код. Он заплатит за рабочий продукт, который решает его проблемы, пусть даже он не будет идеальным на старте.
 
Много продуктов в начале создают из говна и палок. Когда идею провалидировали, появились первые клиенты и денежный поток, есть 2 варианта: все выбросить и сделать заново или привести до ума уже существующее решение. Какой вариант выбрать зависит от контекста и ресурсов.
 
Прелесть современной разработки в том, что так называемый Time to Market сейчас намного ниже чем 20-30 лет назад. 
 
Раньше разработчики создавали программный продукт несколько лет, после чего он записывался на дискеты или CD-диски (да, и такое было). Далее эти тиражи распространялись по всему миру, и если вдруг на этапе тестирования пропустили серьезный баг, исправить это было очень сложно.
 
Сейчас мы можем обновлять приложения хоть по 100 раз на день, поскольку запускаются они на наших серверах. Такой подход позволяет постоянно, итеративно улучшать продукт, параллельно обслуживая первых пользователей. 
 
Разработчики Basecamp запустили первую версию в продакшн без возможности приема платежей. Они знали, что после запуска у них есть 30 дней на решение этого вопроса. Первый год их приложение было развернуто на одном едином сервере. На данный момент этому приложению 15 лет и у них более 20 миллионов активных пользователей.
 
Плохой инженер делает как-нибудь, лишь бы работало.
Хороший инженер стремится сделать идеально, не вникая в бизнес.
Отличный инженер задает вопросы, пытается понять контекст и соблюдает баланс качества, исходя из ограниченности ресурсов.
Знания в голове и в мире
 
Один из важнейших аспектов работы над проектом - коммуникация. От нее напрямую зависят скорость и качество конечных результатов. Выстроить правильные процессы общения крайне важно на старте любого проекта.
 
Сложность коммуникации коррелирует с количеством участников. Когда на проекте один человек, все достаточно просто. Он знаешь все о проекте, а его единственный возможный канал связи - это клиенты. Как только в команде появляются новые люди - сразу все становится сложнее.
 
К сожалению, пока еще нет технологии, которая бы позволила нам транслировать свои мысли и знания в голову другого человека. Поэтому все особенности и нюансы проекта, все идеи и гипотезы необходимо коммуницировать с членами команды.
 
Возникает вопрос, как эффективно организовать передачу информации? Умные люди уже давным давно придумали вести базу знаний: документацию, диаграммы, flow чарты и тд. К сожалению, далеко не все этим пользуются.
 
У меня был опыт прихода в компанию, где мне показали репозиторий с сотнями тысяч строк кода и сказали “разбирайся”. Никакой документации, никаких схем или диаграмм, ничего. Даже комментариев в коде не хватало. Знания по проекту находились у каждого из членов команды в голове, и передавались они из уст в уста.
 
Человеческий мозг - самое ненадежное хранилище. Знания могут теряться или искажаться. Человек может банально что-то перепутать или недоговорить. Передача знаний в устной форме неэффективна, плохо масштабируется и занимает много времени.
 
Когда я стартую проект, все начинается с концепт-документа. В нем я излагаю абсолютно все детали: высокоуровневую идею, проблематику, бизнес ценность, технические особенности, функциональные требования и тд.
 
В процессе работы я стремлюсь постоянно оставлять артефакты: комментарии в коде, небольшие документы с описанием архитектуры, flow чарты с демонстрацией основных пользовательских сценариев. Все это образовывает базу знаний по проекту.
 
Как только у меня появляется необходимость подключить нового человека, в первую очередь я делюсь базой знаний. Такой подход значительно упрощает коммуникацию и позволяет быстро провести onboarding новых участников команды.
Как я уже сказал, полагаться на свою память дело неблагодарное. Даже если я веду проект самостоятельно, все идеи и знания я описываю в документах, веду доску в Trello, рисую диаграммы и тому подобное. 
 
Это особенно полезно когда ты возвращаешься к работе спустя некое время. Подобные артефакты позволяют быстро вернуться в контекст и не упустить важных деталей.
Грамотная коммуникация
 
Недавно я писал о софт скиллах и их важности для личностного и профессионального роста. В этот раз я хочу заострить внимание на одном из ключевых навыков - грамотном письме. 
 
Грамотность, в данном контексте, означает способность ясно и четко доносить свои мысли с помощью текста - будь-то неформальное общение в мессенджере, деловая переписка по Email, сопроводительное письмо при отзыве на вакансию, документация проекта или комментарий на YouTube. 
 
Сильные текста продают товары, продукты, услуги и идеи. Четкие и лаконичные сообщения помогают экономить кучу времени при деловых переписках. Правильно подобранные слова дают возможность делиться сложными знаниями в простой и понятной форме.
 
Я уверен что культивация этого навыка принесет свои плоды любому, будь вы студентом, программистом, дизайнером, менеджером или предпринимателем. 
 
Умение грамотно доносить свои мысли с помощью текста становится еще более актуальным навыком при работе на ремоуте, поскольку большинство коммуникаций происходят асинхронно в формате переписки.
 
Я уже не раз приводил примеры компании Basecamp и тема этого поста не станет исключением. При приеме на работу они дают тестовое задание, процесс выполнения которого нужно описать в документе. Не важно кого они нанимают - программиста, дизайнера или оператора в службу поддержки - этот этап собеседования является обязательным для любой позиции. 

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

"We only hire good writers"
Jason Fried, CEO в Basecamp
 
Лаконичный и структурированный текст демонстрирует ясность мышления и порядок в голове. Это крайне важно для принятия важных, творческих решений и генерации новых идей.
 
Я всегда обращаю внимание на манеру письма своих коллег. За время работы в разных командах разработки я увидел достаточно интересную корреляцию: специалисты со слабо развитым навыком письменной коммуникации чаще пишут запутанный код с непонятными неймингами, плохой декомпозицией и неинформативными комментариями. 
 
Это и неудивительно. Язык программирования, как и обычный язык, это инструмент для рассказа истории. С помощью кода мы излагаем свое видение алгоритмов и бизнес-процессов. Как и текст, мы делим код на логические блоки с помощью функций и классов. 
 
Представьте что этот текст был бы написан одним абзацем, без переносов строк, запятых и с длинными предложениями. Уловить суть было бы намного сложнее. Та же логика применима к программированию на высокоуровневых языках, которые максимально абстрагируются от инструкций железу.
 
Чтобы лучше писать текста, следует практиковаться и читать литературу. Регулярное чтение позволяет расширять словарный запас и тренировать чувство грамотного письма.
 
Раз уж речь зашла за книги, рекомендую “Пиши, сокращай” от Ильяхова, которая разложит по полочкам то, что такое сильный текст и как его написать.
Концентрация

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

Речь идет о концентрации - способности сохранять фокус внимания на одном занятии без переключения контекста. 

Умеете ли вы быть сфокусированным на протяжении 4-6 часов?

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

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

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

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

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

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

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

Для высокого уровня концентрации также важно создать правильную обстановку и окружение. Для меня это:

- Режим "не беспокоить" на ноутбуке. Авиарежим на телефоне в первой половине дня.
- Качественный сон. Ни о какой концентрации не может идти речь если вы не выспались.
- Правильная музыка. Я люблю ритмичную электронику: ambient, deep house, dub techno и тд.
- Каждые 50-70 минут я делаю перерыв на 10-15 минут. Во время перерыва никаких соц. сетей и посторонних дел. В основном я растягиваюсь, делаю себе чай / кофе или выхожу на улицу подышать воздухом.

Также я уверен, что регулярный кодинг и написание текстов помогло мне развить способность удерживать внимание на одном деле по 5-6 часов без переключений контекста.

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

Иногда я туплю 1-2 часа над пустым документом и не могу ничего написать. Если я пересилил себя и не начал прокрастинировать, в результате получается новый пост или сценарий для YouTube видео.

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

Два года назад я прочитал книгу “Deep Work” от Кэла Ньюпорта. Уверен она есть в русском переводе. Крайне рекомендую для большего погружения в тему.

Учитесь сохранять концентрацию и быть сфокусированным. Ваша жизнь от этого станет только лучше.
Я middle разработчик, что дальше?
 
Если ты самостоятельно решаешь поставленные задачи, предлагаешь варианты реализации новых фич, умеешь оптимизировать и рефакторить код и уверенно владеешь своим техническим стеком - тебя с уверенностью можно назвать мидлом. 
 
Скорее всего у тебя несколько лет опыта работы в индустрии и пару проектов за спиной. На этом этапе многие задумываются о том, куда двигаться дальше и в какую сторону стоит развиваться. 
 
Вопрос построения карьеры достаточно интересный. Каждый обладает собственными взглядами, целями, амбициями, жизненными ценностями и областью интересов. У обычного разработчика есть много вариантов для дальнейшего развития, а выбор конкретного пути сугубо индивидуален.
 
Сейчас мне 20, скоро будет 21. В 16 лет я работал веб-разработчиком на небольшой веб-студии во время летних каникул. В 17 переехал в Киев и устроился фулстеком. После этого было еще две компании, где я получил бесценный практический опыт в backend разработке.
 
Помимо основной работы я немного фрилансил, делал “леваки” с друзьями и небольшие пет-проекты.

Недавно я начал работать на своем 5-ом рабочем месте как senior инженер, а параллельно занимаюсь развитием собственного SaaS-продукта, о котором расскажу чуть позже. 
 
Я достаточно молод и мне еще много чего предстоит повидать. Несмотря на это, последний год я много задумываюсь о построении собственной карьеры и жизни в целом. Столкнувшись с вопросом “куда можно развиваться из позиции middle?” я проанализировал все доступные опции, а результатами размышлений хочу поделиться с вами.
 
Для меня работа - это инструмент, который дает возможность хорошо зарабатывать, содержать себя и своих близких, изучать практики разработки современных приложений на реальных проектах и развивать свои навыки работы в команде. Ну и помимо всего прочего, я кайфую от решения сложных задач и состояние потока во время кодинга.
 
Я не привязываюсь к рабочему месту. Когда я чувствую что мне стало скучно, прекратился мой профессиональный рост или у меня есть варианты поинтересней - я ухожу.
 
Поэтому я считаю, первое, что стоит сделать при планировании своей карьеры - определиться зачем ты вообще занимаешься разработкой и к чему стремишься. 
 
Возможно на этом этапе окажется что для тебя это просто способ заработать, но ты не кайфуешь от своей работы, или у тебя есть другие интересы, которые ты игнорируешь из-за уже протоптанного пути. Возможно ты поймешь что хочешь чего-то совсем другого. И это отлично. Я уверен что нужно экспериментировать и не привязываться к чему-то одному.
 
Также важно держать в голове, что твоя карьера - это не воля случая. Ты в состоянии строить свою жизнь и выбирать путь развития. Твои решения непосредственно влияют на твой путь.
 
Когда ты поймешь себя и чего ты вообще хочешь от жизни, выбрать дальнейшее направление будет гораздо легче.
 
Как по мне, у мидла есть 3 основных варианта профессионального роста: 
1) Развивать техническую экспертизу вглубь, становиться senior`ом / архитектором / тех. лидом.
2) Развивать управленческие навыки, становиться тим лидом / PM / CTO и тд.
3) Развиваться в создании продуктов и бизнесе. Запускать собственные проекты, уходить в консалтинг или заказную разработку.
 
Когда ты понимаешь почему ты начал заниматься разработкой и что тебя больше интересует, выбор дальнейшего развития происходит на интуитивном уровне. 
 
Тебя прёт от работы с кодом и проектирования приложений?
Развивай техническую экспертизу. 

Тебе больше по душе общаться с людьми, управлять процессом разработки и быть ближе к бизнесу?
Развивайся как управленец. 

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

Главное не сидеть на месте. Иначе через 5-10 лет твои навыки уже не будут столь актуальными.
А возможно тебя вообще заменят алгоритмы машинного обучения.
​​Дизайн системы, технический долг и скорость разработки

Месяц назад я устроился разработчиком в стартап от крупной компании из США, которая создает программные продукты для большого Enterprise. Проект находиться на стадии MVP, старого legacy нет. В команде бэкенда только два программиста.
 
Зачастую на таких проектах приятно работать. Впереди тебя ждет разработка новых фич вместо поддержки старого функционала и постоянного фиксинга багов.
 
Первую неделю я изучал кодовую базу и закрыл скоуп задач по второстепенной логике. Откровенно говоря, я остался не в восторге от качества кода и архитектуры проекта. 
 
Бизнес-логика намешана внутри транспортного слоя и репозитория, из-за чего покрывать тестами подобное решение очень сложно. Подавляющая часть переменных, функций и методов имеют непонятные и неконсистентные именования. 
 
Архитектуре характерна сильная связанность. Изменение одного метода влечет за собой непредсказуемые последствия на корректность работы абсолютно разных компонентов.
 
Большинство методов имеют слабую декомпозицию, за счет чего они очень длинные и сложны к восприятию. По коду часто встречаются цепочки из условных операторов и циклов с несколькими уровнями вложенности. Можно встретить “не чистые” функции, которые по выполнению оставляют побочные эффекты, о которых ты даже не догадываешься.
 
Все вышеперечисленные проблемы несут за собой ряд последствий. Изучать логику проекта сложно, у новых разработчиков уходит на старте много времени. Поддерживать и расширять подобный код становиться трудно, из-за чего проект со временем начинает обрастать костылями. С каждой новой фичей тех. долг растет, а сложность кодовой базы возрастает экспоненциально. 
 
На вторую неделю я взял в работу задачу по интеграции со сторонним продуктом, который входит в экосистему решений компании. Потратив 2 дня на изучение бизнес требований, API спецификации, общение со специалистами со стороны заказчика и проектирования технического решения я приступил к разработке. 
 
Данная задача подразумевает расширение существующего функционала. Однако углубившись в уже реализованную логику, я не смог ничего добавлять, пока не отрефакторил 80% написанного кода.
 
На задачу, которую можно выполнить за 3-4 дня, у меня ушло полторы недели. Помимо реализации бизнес логики мне пришлось переписать огромное количество кода и убедиться, что вся остальная логика системы при этом не поломалась. Без надлежащего покрытия тестами это тоже не простая задача.
 
Многие программисты и менеджеры убеждены, что в условиях сжатых сроков, писать плохой код полный костылей экономит время.

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

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

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

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

Я уверен что от технического долга избавиться невозможно, он всегда будет присутствовать на любом проекте. Борьба с ним - процесс итеративный. 
 
Вместо того, чтобы остановить разработку и все переписывать, стоит закладывать в оценку сроков на выполнение каждой новой задачи дополнительных 2-3 дня на рефакторинг. 
 
Вместо того, чтобы тратить на таску 3 дня, на нее уйдет неделя, но в процессе можно оптимизировать логику, которую задевает эта задача. 
 
При работе с уже написанным кодом стоит придерживаться правила Бойскаута - оставлять код чище, чем он был до тебя.
 
Например, поступила новая задача расширить функционал создания пользователя. Это отличная возможность переписать слой работы с данными для сущности пользователя, вынести из нее бизнес-логику в сервис и отделить ее от транспортного уровня. 
 
В процессе можно задекомпозировать уже существующие методы, переименовать непонятные переменные и переписать участки кода с несколькими уровнями вложенности.

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

Дополнительно, если старый код еще не покрыт тестами, то у тебя появилась замечательная возможность это исправить.
 
Каждое такое изменение будет незначительно улучшать качество проекта, на 1% в единицу времени.

Да, выполнение бизнес задач будет отнимать немного больше времени, однако спустя уже несколько месяцев такой практики качество кодовой базы значительно вырастет, а архитектура системы будет “чище”, что позволит выиграть время в долгосрочной перспективе.
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. Чаще улыбайся, делай комплименты и дари позитив другим. Это кайфово🔥

И еще.

Спасибо что вы со мной.
Я это очень ценю, обнял.
Инженерная культура

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

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

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

Кстати, в этом курсе, помимо большого объема теории, я подробно разбираю техническую часть данной платформы: архитектуру, стек технологий, модель данных, инфраструктуру и тд.
 
На данный момент платформа еще в сыром виде. Впереди предстоит много работы и пространства для оптимизаций. Я буду очень признателен услышать от вас обратную связь по поводу вашего опыта прохождения курса, удобства интерфейса и возможных улучшений!
 
Без вашей поддержки и интереса ничего этого бы не было 🔥
Поэтому спасибо. Я это ценю.
Не усложняйте
 
Начинающие разработчики часто грешат высокой сложностью своего кода. В качестве решения простых проблем они любят изобретать велосипеды. 
 
Что скажете про следующий кусок кода?
 
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"
    }
}
 
Его я написал несколько лет назад на своей первой работе. Честно сказать, я не знаю как мои нейронные связи умудрились сгенерировать подобное решение. А еще я не понимаю как это прошло код ревью от команды. Ну да ладно, главное что работает.

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

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

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

Но это не так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стоит делать меньше, но лучше. Отсекать лишнее, фокусируясь на самом важном.
Ценность разработчика

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

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

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

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

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

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

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

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