Я второкурсник (по крайней мере первый год я уже отучился) направления 11.03.04 (электроника и наноэлектроника), с зимы первого курса работаю в небольшой компании программистом на пол ставки (ну или что-то вроде того), предпочитаю esp32. Мои проекты не то чтобы впечатляющие, впрочем для кого-то это такое же чудо, как для меня - художники, поэтому я буду делиться с вами, а нужно вам это, или нет - решать вам.
Для всех желающих, можно подписаться на канал и следить за моими лапками, такие крупные посты будут супер редко.
Ахтунг!
Пост будет про распыление (с выпуском затянул из-за него кстати, ну и выгорел чутка), однако собран он из моего опыта и мнения, в его основе не лежат никакие статьи, поэтому выводы делайте сами.
Ваши замечания, опыт и предложения в комменты.
Будем говорить в контексте программиста фулстака (держать в голове, особенно если это вы), поскольку именно таким был мой опыт, но постараюсь пояснять моменты, чтобы было полезно всем.
Полезно будет в основном начинающим вроде меня, но может кого зацепят мои мысли.
Контекст.
И так, знакомлю вас с моим профилем деятельности. Ну который на работе.
Чтож, его нет!.. Я программист, а свой первый проект по работе начал с esp32, однако так вышло, что нужен фулстак...
Фулстак - понятие сильно зависящее от контекста, в том плане, что понимать его можно по разному, в основном говорят об этом в контексте конкретного проекта или области. Я руководствуюсь описанием: «человек, способный покрыть все аспекты проекта, аспектов должно быть не менее двух и содержать они должны разные технологии».
Вашему вниманию стек одного из самых жирных проектов, которым занимаюсь я:
C++ под esp32,
веб (html, css, js),
сервак (flask, postgres, объектное хранилище),
развёртывание (docker).
Во время ведения проектов доков ведём супер мало.
Распыление? Не, не слышали!
Прошу убрать пульверизаторы от экранов, здесь не распыляемся, котики не оценят.
И так... Что такое распыление и почему это такая проблема?
Я думаю вам всем знакомы ситуации, когда необходимо переключаться между задачами.
Те же эксперементы по физике (в особенности термодинамика), когда необходимо делать периодические измерения и проводить большое количество расчётов. Обычно чтобы ускорить процесс в команде есть эксперементатор и счетовод, однако если вы решите это делать самостоятельно, то скорее всего запутаетесь, поскольку держать в голове число, которое вы не успели записать, потому что пришло время измерений, порой бывает непросто.
Думаю это можно считать неплохим примером распыления.
Что именно произошло?
Да, вы определённо хороши, потому что работаете за двоих, но сил у вас ушло много.
Когда вы переключаетесь между задачами, вы тратите силы и время, от этого ваш кпд ниже, чем у команды.
Даже если вы с таким не сталкивались, то скорее всего столкнётесь, особенно если вы фулстак, особенно если вы работаете в небольшой компании.
Почему такое происходит?
На самом деле распыление — вполне естественная ситуация, просто вас одного недостаточно.
Большие проекты, затрагивающие множество разных технологий даются соло‑проггерам тяжелее именно потому, что в них много разных технологий.
Допустим выпишите под устройство, которое связывается с сервером.
Зачастую реализацию сервера и устройства берут на себя два разных человека, работающих параллельно: таким образом api сервера сразу пишется и тестируется.
Однако, в такой команде нужно писать документацию, чтобы не пришлось мусолить чужой код.
И тут на сцену выходит фулстак. Ему не нужно писать подробный мануал, потому что код он напишет сам: сначала он сделает сервер, оттестит его тестовыми запросами, затем напишет клиент, оттестит его тестовыми запросами, сделает связку и оттестит в сборе.
На одного человека ложится достаточно много задач, к счастью зачастую тесты можно сделать параллельно, или забить на них (а потом смотреть на этот стул с пиками точёными с другого аппарата, если вдруг не повезло).
Но где же здесь распыление? Правильно, его не было! В этот раз мы поступили по умному и сделали части отдельно, поэтому переключений по стеку (смена технологий) произошло минимальное количество раз. Однако в реальности такое бывает редко, часто вам приходиться писать всё это разом, из‑за чего по стеку вас метает чуть ли не каждые 5–10 минут.
Вот тут собака и зарыта.
Каждое ваше переключение — это своеобразная смена обстановки. Разные технологии, а тем более языки, могут требовать разного подхода (особенно это ощущается, когда пишешь низкоуровневый производительный код под микроконтроллеры на С++, а потом резко начинаешь писать сервак и верстать веб). На это уходит не только ваше время, но и силы, особенно если это первый таклй опыт.
Это плохо?
Безусловно, такого стоит избегать, есть даже элемент выгорания с этого, однако ничего смертельного в этом нет, особенно как знаешь с этим бороться.
В мелких компаниях, одиночных проектах, или когда ведёшь курсы для группы, распыление вам будет встречаться, поэтому бороться с ним нужно.
Вот вам ваши ред флаги, ребят.
Если компания не даёт вам ТЗ, доки вы вести не обязаны, а каждый вокруг фулстак, то что‑то возможно не так.
Такое часто происходит в небольших компаниях, особенно когда проектов много, а сотрудников мало.
Это абсолютно нормально, для кого‑то даже хорошо, просто заранее решите для себя, готовы ли вы к этому и хотите ли с таким работать.
Как бороться?
По своему опыту скажу, что способов борьбы уйма, для всех это индивидуально, буду рад, если поделитесь своими фишками.
Вот как в своей работе лавирую я:
1) Ведите документацию.
Документация вам не враг, зватит от неё бегать. Я вас умоляю, делайте пометки хотябы к api и сьруктурам данных, чем больше у вас этого добра, тем лучше! Комменты по коду тоже хороши, но листать их иногда долго, поэтому делайте из них файлы‑выжимки, где собираете инфу, которую можно будет потом почитать или загнать в ИИ для контекста. Эти файлы также можно попросить написать ИИ, если там ничего сложного, но так как пишутся они проще по ходу работы, то потребности в помощи обычно нет.
2) Пишите и тестируйте!
Тесты написанного блока — своего рода микровывод, а ещё это способ и время отдохнуть, так ваши переключения будут проходить легче, а отладка будет не такой страшной, поскольку у вас есть контрольные точки.
3) Делайте контрольные точки!
Что‑то заработало? Засейвите всё прямо сейчас! Даже если это будет zip архив, а не коммит с git. Откат бывает нужен часто, пусть лучше это будет мусорка из бекапов, чем лишняя работа для вас.
4) Пишите крупными блоками.
Постарайтесь уменьшить частоту переключений и писать на одной технологии подольше.
5) Освежайте в памяти.
Обязательно практикуйте использование технологий, достаточно фоном смотреть видосы с ними, возможно вы даже узнаете новые фичи и прокачаетесь.
6) Не копипастите!
Не делайте это втупую, особенно с ИИ, обязательно тестируйте всё полученное. Зачастую готовые решения под вашу область будут лучше ваших, особенно в начале, однако чтобы добиться идеала нужно написать своё, особенно если вы правда хотите расти. Если вы будете принебрегать тестами, то можете сильно пожалеть, когда всплывёт проблема.
7) Используйте шаблоны!
Максимально автоматизируйте свою рутину, особенно если планируете долгий проект.
Недавно работал над софтом под ПК, работал очень долго, поэтому в первые недели сделал скрипт‑сборщик, чтобы делать бекапы с отчётами по одной кнопке. Скрипт написал по моему запросу ИИ, один промт сэкономил мне по 20 минут каждый день, которые я потратил на более важные задачи.
8) Управляйте временем!
Обязательно делайте перерывы, вы незаменимый винтик в механизме прогресса, отдыхайте, чтобы не подвести машину. Планируйте свою работу и берите запас времени, потому что ничего с первого раза не бывает.
9) Не бросайте!
Технология не подошла? Отдохните и попробуйте другую, ваш стек будет расти. Распыление сделает вас сильнее, правда будет больно.
Про другие области.
Сам я в других областях с таким не сталкивался, однако когда был помощником на курсах, узнал, что преподаватели, ведущие занятия не как лекцию, а отвечающие на каждый вопрос и разбирающие всё индивидуально, сталкиваются с распылением лоб в лоб. Вели этим летом недельные интенсивы, а на них нужно каждого индивидуально подтягивать. К сожалению тот, кто даёт основной материал не может вести это и объяснять всем, когда каждому нужно своё. Чтобы главный преподаватель не распылялся ему выдали несколько помощников, что в корне изменило ситуацию. Не знаю как тут можно было поступить иначе, не потеряв при этом темп и формат.
Уже смешарик?
Если вы уже распылились, то отдохните: почитайте доки, займитесь своими доками, поизучайте технологии, займитесь менее важными задачами...
Понять, что это уже произошло достаточно легко, вы почувствуете, что резко ваша продуктивность упала, а неудачи приследуют вас. На самом деле это сугубо поверхностно, но думаю вы сможете понять это на опыте.
У меня в таких ситуациях начинает болеть голова и пропадает концентрация.
В заключение хотелось бы сказать, что распыление доказывает ваши невероятные способности и рвение, однако себя беречь надо... Не думайте, что роботодатьль — деспод, если вас не уволили, то вы должны работать над собой, а не выробатывать себя.
А плюсы?
Не, не те, которые С++, а которые у фулстака
Чтож, будучи фулстаком вы полностью контролируете архитектуру и быстро принимаете решения, не дожидаясь согласования.
Пусть вы и медленнее, а знания возможно поверхностные, но вы швейцарский нож! Вам не нужно ломать засовы, с этим справиться болторез, ваша задача — открыть консервную банку, постричь ногти, отрезать горящий фетиль или открутить сервисную панель.
На этом я считаю можно заканчивать. Не бойтесь распыления, вы сильнее его. Просто сделайте перерыв и соберитесь с силами.
Удачи!
Пост оформлен в рамках самобичевания и самокопания одного енота на основе прошлой демоверсии этой статьи.
Если вам понравилось, то подписывайтесь на меня и ждите, пока мои лапки сделают «бяк‑бяк‑бяк».
Я не стал сильно расширять её, однако за время моих размышлений я немного изменил повествование, теперь эту работу можно считать законченной.
P. S. Кажется я зависим от программирования, памагите.