Я очень хочу прогать

Привет, меня зовут Макс и я автор канала zxCrypto, где я просто оставляю свои истории кодинга в крипто-сфере, учусь новому и делюсь знаниями с подписчиками. На написание статьи меня вдохновило большое количество просьб, отправленных моими подписчиками. Просьбы направить на путь истинный, дать наставление, рассказать что посмотреть или почитать чтобы стать [хорошим] разработчиком. Попробую высказать свое мнение на этот счет. Мнение читателя может не совпадать с автором (и это здорово).

Глава 1. А оно мне надо?

Итак, дружок, для начала спроси себя - "Зачем мне это?", ведь процесс программирования достаточно неприятный сам по себе для большинства людей.

Цитата из статьи Почему твоя мама всё ещё не прогает:

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

Я выявил 4 основных мотиватора:

• Поддержка в иной сфере (крипта, наука, железо и т.д)
• Бабки
• Процесс
• Продукт

Разберем каждый по отдельности:

Поддержка

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

Бабки

Возможно, тебя тошнит от компьютеров, но тебе сказали что программистам хорошо платят и ты решил "аа пойду учиться, сложна что-ли кнопки нажимать". Вся моя группа в шараге, где я учился решила именно так (за исключением 3-4 человек). Тем не менее, давай посмотрим как обстоят дела и на что ты можешь расчитывать, рассматривать будем с позиции веб-разработки и различных грейдов:

Джун. Совсем базовые знания. Означает примерно "Читал разную документацию, примерно понимаю как что работает, сделал пару простых pet-проектов, но никогда не работал в команде и не представляю как может выглядеть реальный проект. Скорее всего смогу делать простые задачи, но наверняка их прийдется переделывать". Вилка 50-90к рублей.

Мидл - Мидл+. Примерно 2-3 года опыта. Означает примерно "Работал в паре компаний, знаком с процессами, хорошо ориентируюсь в %framework_name%. Могу пилить целые фичи не сильно напрягая окружающих, но только если задача хорошо проработана и мне более менее понятно как её решать. Знания не сильно глубокие и не сильно широкие. Решения самостоятельно принимаю редко.". Таких ребят большинство. Хорошо работающий винтик в системе где есть контроль и менеджеры целыми днями прорабатывающие задачи. Худшее что может случиться с разработчиком (имхо) - застрять на этом грейде на 5+ лет. Вилка 100-250к разнится в зависимости от кучи факторов. В крипте в среднем $3000. Спрос высокий, конкуренция тоже, на собеседованиях могут задрочить вопросами или попросить написать тестовое задание.

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

Техлид / Сеньор / Архитектор. Объединил в кучу по общим признакам: во первых это супер самостоятельные единицы, а во вторых они "поели" нереально много говна, т.е их знания очень широкие, очень глубокие и приправлены большим количеством опыта, который помогает решать сложные задачи интуитивно. Два этих фактора делают из таких чуваков чудовищ способных в одного затащить целый проект. Их ничто не может остановить. Считаю что надо в детстве заложить какие-то нейронные связи и иметь особый склад ума, чтобы добраться до этого уровня, плюс постоянное саморазвитие. Опыт 6-10 лет в разных задачах/проектах. Т.е 6 лет тупо верстать однотипные сайтики или админки и после назваться сеньором не получится, прийдётся постоянно бросать себе вызов чтобы оказаться тут. Спрос намного выше предложения. На собеседованиях обычно сразу выкупают твой уровень в ходе т.н дружеского диалога и просто с ходу кидают оффер. Вилка поинтереснее, обычный маркет предложит вам 180-350к, до 500к зарубеж удаленно, $5000-10 000 в валюте в крипте или в случае релокации в Европу. Будучи узко-специализированным Solidity-developer можно дорасти до уровня 12-18к.

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

P.S. Написанные выше цифры были актуальны на момент написания статьи. В процессе написания бакс вырос в 2 раза и я думаю рублевый рынок быстро скорректируется вверх или вниз (скорее вверх, но может наоборот т.к многие сейчас пытаются найти работу с оплатой в долларах. Так же со многими ребятами из России разрывают контракты и они будут искать работу. Так что предложение станет выше и зарплаты в долларах могут ненадолго упасть)

Процесс

Этот мотиватор мне нравится. Есть люди которые просто кайфуют писать код. Не важно какой, рабочий, не рабочий, быстрый или медленный, им просто доставляет процесс. Но чаще всего нам нравится получать кайф от результата. Бился над каким то функционалом битый час и вот оно заработало - прилив дофамина обеспечен. Или долго пытался понять некую сущность или въехать в какую то тему, и наконец понял, и теперь гордишься собой. А есть ещё просто психи с ОКР которым просто нравится раскладывать все по местам, такие люди могут часами рефакторить код переписывая одни и те же методы по 20 раз или заботливо расставлять какие-нибудь скобочки часами напролет. Я кстати один из них.

Продукт

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

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

Разработчики сейчас очень дорогие для бизнеса и весь мир движется к no-code / low-code решениям повсюду. Посмотрите на развитие сервисов типа конструкторов сайтов. Для нас это значит что компаниям разрабатывающим такие решения, будут требоваться всё больше реально сильных разработчиков, малый бизнес обойдется без разработчиков вовсе или сможет ограничиться разработчиками уровня "скрипт кидди". А вот конкуренция среди мидл-разрабов может начать нарастать. Это значит - целимся в сеньоры.

Если мотивация еще не иссякла, то продолжаем 🤟

Глава 2. Рост

Как же мне вырасти и стать из ничего не умеющего балбеса крутым сеньором, за которым будут бегать все рекрутеры мира?

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

Не целься во фриланс пока у тебя нет опыта, так он никогда не появится.

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

Тебе нужна маленькая компания, какой нибудь интересный стартап, делающий прикольный продукт и состоящий из 1-2 команд, в которой все члены команды делят роли поровну между собой. Именно в таком коллективе ты сможешь стать заметным, именно такая компания сможет научить тебя всем процессам и даст понять как тут все устроено, как и почему принимаются те или иные решения на разных уровнях. Проявляй инициативу, общайся с людьми, участвуй в процессах, живи продуктом который ты делаешь. Не ной и не жди что тебе обязаны все рассказать и всему научить, считай что не компания наняла тебя делать работу, а ты пришел помочь этой компании. Остерегайся шаражек типа студий однодневнок (но честно говоря возможно с нулевым опытом тебя только туда и возьмут). Не бойся менять проект если чувствуешь себя не комфортно или кажется что тут не будет развития, окружай себя более умными/успешными людьми чем ты сам, и запомни:

Если ты понимаешь что ты самый умный в комнате, значит ты не в той комнате.

Но у меня совсем нет опыта, кому я такой нужен? Как научиться всему? Где взять портфолио?

Тебе понадобится портфолио. Для начала заведи GitHub и сделай парочку пет-проектов (и всегда, всегда используй гит или др. систему контроля версий, когда пишешь код). Желательно разных в реализации (т.е три одинаковых Todo-List на React собранных по офф. гайдам не подойдут). Придумать себе задачу может быть сложно, но кто мешает изобрести велосипед просто что-бы попрактиковаться? Можешь поискать примеры тестовых заданий в сети и попробовать выполнить их, если совсем нет идей. Можешь выйти за рамки, и например попытаться написать свою реализацию MVC / MVP/ MVVM вместо бездумного использования готовых решений, просто чтобы на своей шкуре прочувствовать эти паттерны. На настоящей работе тебя вряд ли похвалят за подобные "велосипеды", но опыт для себя получишь бесценный. Не вижу ничего страшного в работе в обмен на опыт, например бесплатно друзьям заверстать сайт. Такие проекты можешь показывать на интервью, как правило 2-3 небольших работ достаточно что-бы тебя взяли на позицию младшего разработчика (но будь готов к тестовому заданию). Можешь попробовать набить себе цену, можешь хитрить и сделать вид что ты умнее чем есть, главное сумей потом отстоять это и пройти испытательный срок (я например не гнушался показывать "сделанные мной" сайты, на которых я доделал только подвал (например), потому что знал что и остальное смог бы).

Кстати, к курсам в ИТ очень предвзятое отношение, так уж сложилось что толпы бездарей прошедших курсы ломанулись к работодателям и те в какой то момент начали воспринимать пункт о прохождении курсов скорее как некую черную метку. Это может быть хорошим подспорьем чтобы преодолеть порог входа, но если ты прошел курс, даже если он был полезен - лучше особо не заикайся об этом и не думай что этого будет достаточно. Среди программистов ценится умение находить информацию и решения проблем самостоятельно, а курсы противоречат этому навыку, т.к тебя за ручку ведут по шагам, решая типичные задачки и не выходя за рамки. Так же я напрягаюсь когда ко мне приходят разрабы у которых в портфолио только примеры практических работ с каких нибудь курсов (нет ощущения что человек это действительно сделал сам, т.к на курсе очевидно был предусмотрен какой то ревью кода, а значит возможно я смотрю не код и мысли кандидата, а его наставника. К тому же эти работы очень уж типовые). Хотя опыт бывает разный.

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

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

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

Книги это хорошо и было бы здорово если бы я дочитал до половины хотя бы одну из них. Из хороших примеров могу посоветовать "чистый код" ("идеальный код", "идеальный программист", они все об одном) и "джедайские техники", и наверное всё, остальные общепризнанные шедевры я не читал. Но есть такой потрясающий сайт refactoring.guru, его рекомендую изучить целиком, можно вместо чистого / идеального кода. Еще порекомендую "Пиши, сокращай", но это к теме сабжа не имеет отношения, скорее для некой фильтрации мыслей от шума и более явного изложения мыслей в речи и на бумаге.

Интернет. Вот место где тебя научат. Бесконечные статьи на Хабре, Медиуме и прочих, и конечно же Stackoverflow, мне гугл постоянно подсовывает интересные статьи в списке рекомендаций (там где у нормальных людей какой то треш и содомия с пу...). Бесконечные статьи, вопросы и ответы, репозитории с кодом, вот где самый сок, самая кладезь знаний, которые ты по кусочкам будешь годами складывать в огромный пазл в твоей голове.

Наставник. Хорошо если у тебя окажется сильный ментор, он может направить тебя и спасти от ошибок и заблуждений (а ещё может привить тебе парочку карго-культов, куда без этого, подробнее ниже). Но старайся не злоупотреблять им, решай проблемы сам, не бойся брать ответственность и принимать решения. Если возникает проблема - иди к наставнику не с вопросом, а с потенциальным решением вопроса.

Но я хочу быть Super Star

Чтобы вырасти и стать реально классным тебе придётся научиться браться за невыполнимые задачи и успешно решать их. Тем круче разработчик, чем больше говна он в своей жизни поел. Берись за нетипичные задачи, предпочитай сложные простым, изучай новые темы, лезь куда не просят и проявляй животный интерес ко всему неизведанному. Не сдавайся если что-то не получается, ищи альтернативные решения, никогда не говори "это невозможно сделать", только если не уверен на 146% что никто в мире этого не сделает (ну или если очень не рентабельно, например ценность фичи сильно меньше трудозатрат). Стремись к максимальной простоте и старайся уменьшать хаос:

Никогда не оставляй после себя грязнее чем до тебя

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

Тяжелые времена порождают сильных программистов. Сильные программисты создают фреймворки. Фреймворки порождают слабых программистов. Слабые программисты порождают тяжелые времена.

Изучай исходники библиотек и пытайся понять как они реализованы, это очень сильно прокачает тебя. Задумайся, авторы библиотеки написали её на том же языке что и ты, но как они это сделали? Например web3.js, ты вызываешь метод, предположим estimateGas и получаешь результат, но смог бы ты этого добиться без web3.js и как? Понимание внутренней работы системы очень сильно помогает эффективнее использовать эту систему.

Реально крутые чуваки разбираются в новых сферах очень быстро просто за счёт знания основ и большого опыта. Имея хороший опыт и насмотренность они быстро находят решения проблем в стороннем софте просто предположив что за алгоритм выполняется под капотом и поняв что может вызвать баг. Я знаю людей, способных разобраться в новом языке или технологии и выдать результат быстрее или качественнее, чем это сделает средний мидл с опытом 3+ лет в этой сфере, если задача хоть чуток выходит за рамки типичной. Такие люди в прочем любые проблемы решают увереннее других, будь то ремонт авто, строительство, бизнес и т.д, но самое приятное - этот навык можно натренировать.

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

Учись отлаживать код. Страшный секрет этого мира в том что кроме printf / console.log есть куча других инструментов для более эффективной отладки кода. Займись этим и выясни что предлагает тебе твой язык / окружение. Крайне важно нарабатывать опыт отладки чужого кода, этакое умение выполнять код задом наперед.

Не поддавайся карго культам

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

Примеры таких утверждений:

• Фреймворк / Язык X хороший, его надо использовать
• Фреймворк / Язык Y плохой, не надо его использовать
• Технология X лучше технологии Y (IOS лучше чем Android)
• Надо делать так, потому что так делает "какой-то уважаемый чел с горы"
• Мутабельные данные - зло
• ООП - добро, ФП - говно, или наоборот
• "Нужно 100% покрытие тестами", либо "Тесты не нужны"
• Бесплатные / Свободные решения лучше Платных

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

Пройди лишнюю милю

Если тебя просят сделать X, сделай X+1. Когда делаешь что угодно, не забывай что это твое творение и если делаешь что-то, делай это так чтобы не было стыдно. Универсальное правило и при создании крупной архитектуры банковского приложения, и при верстке маленького сайтика, где хотелось бы не забыть состояния при наведении на кликабельные элементы. Главное не уходи в совсем уж нездоровый перфекционизм.

Учись декомпозировать задачи

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

Какие навыки важны?

Разделяют 2 вида навыков, гибкие навыки (soft-skills) и проф. навыки (hard-skills)

Soft-skills

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

Я считаю что 50% успеха зависит от них. Не стоит думать что хорошие программисты это асоциальные задроты пишущие идеальный код. Реальность такова что что бы стать хорошим программистом, тебе прийдется так же стать просто приятным парнем.

Наиболее критичные навыки на мой взгляд:

• Эффективная коммуникация (умение слышать/воспринимать информацию и формулировать мысли / доносить информацию, навыки убеждения, развитая речь)
• Работа в команде (распределение обязанностей, чувство эмпатии, отсутствие эгоизма и пр.)
• Критическое мышление
• Способность находить информацию и ответы, правильно формулировать вопросы, рассматривать вещи с разных точек зрения
• Чувство ответственности
• Самостоятельность, усидчивость и самодисциплина
• Любопытство
• Внимание к деталям и чувство стиля

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

Hard skills

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

Фактически это чистый опыт с конкретным языком/технологией, количество изученных алгоритмов и практик и т.д

Важные моменты на которые стоит сделать упор для более лёгкого обучения:

• Настрой IDE для комфортной работы. Настрой плагины, изучи или перенастрой комбинации клавиш, изучай возможности которые предоставляет IDE и активно их используй. Настройка займет десятки минут, но сэкономит часы в дальнейшем. Я кстати заметил что даже опытные разработчики часто не знают о возможностях редактора с которым работают и какие-то элементарные вещи делают очень долго из-за этого (например поиск файлов по маске/регулярному выражению).
• Строгость. Стайлгайды, Линтеры, типизация, эти вещи по началу могут раздражать и будет казаться что это отнимает время, но с ростом проекта это сэкономит уйму работы. При командной работе даже не обсуждается.
• Смотри примеры, спеки (тесты), изучай чужой код, ищи ответы в issues и на stackoverflow, не торопись спрашивать (у коллег, на стековерфлоу) пока не станет понятно что реально застрял надолго.
• База (языки, паттерны, стандарты) важнее. Фреймворки и абстракции не так важно.
• Изучай другие сферы, хотя бы поверхностно. Если ты фронтенд разработчик - постарайся вникнуть в то как работает бэкенд, с какими проблемами они сталкиваются, как решают. Это поможет при взаимодействии с людьми. Зачастую разработчики переусложняют решения не понимая что можно сделать проще если перенести логику на другую сторону, либо наоборот не желают брать на себя ответственность и реализовывать функционал на своей стороне т.к просто не понимают насколько сложнее или хуже будет реализация с другой стороны.
• Не ограничивайся одним языком / фреймворком. Расширяй кругозор. Не обязательно их использовать, просто поймите разницу, поймите какие проблемы они пытались решить, почему сделали именно так а не иначе. Возможно случайно обнаружится, что мобильная разработка интереснее веба, например.
• Пиши тесты. Начни хотя бы с юнит-тестов для чистых функций которые делают одну конкретную задачу. Тесты помогают найти ошибки на самом раннем этапе и помогут вам убедиться что новые изменения не сломали старую логику (отличный пример - метод sum принимающий числа как аргументы и возвращающий сумму этих чисел. Кажется простым, но что если передать в него числа разных типов (string, hex, number, BigInt, BigNumber, NaN, undefined и т.д, очень актуально в крипте))

Выгорание

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

Для себя я выявил причины появления выгорания:

1. Исчезает интерес к продукту или технологии, может быть в следствии отсутствия развития (не хочешь учиться или уже слишком хорошо знаешь то с чем работаешь). Решений масса, основное - брать всё в свои руки. Не нравится проект - меняй проект. Не нравится задача - проси другую или сделай так что бы понравилась. Надоел стек - подумай что с этим делать, протолкни идею команде перейти на другой фреймворк или язык и т.д. Короче решай свои проблемы сам, не жди что это решат за тебя.

2. Рутина. Следует избегать задач или проектов которые тянутся больше 3 месяцев. Очень важно декомпозировать задачи на мелкие части, которые можно полностью завершать по отдельности. Представь что перед тобой игра, в которой 20 уровней и на каждом уровне по 3 задания. Ты пройдешь такую игру радостно и непринужденно. Но если это будет один уровень с 60 заданиями, то ты просто рехнешься и бросишь играть на 10%.

3. Отсутствие отдыха и впечатлений. Особенно актуально сейчас, когда большинство работают из дома удаленно, а из-за ковида невозможно никуда нормально съездить отдохнуть. Тебе нужно почаще выходить из дома, гулять на свежем воздухе, общаться с людьми, переключаться с задач на что-то вообще не похожее на твою работу и заниматься физическими нагрузками (т.е пойти порубить дрова лучше чем поиграть в компьютерные игры). У программистов вся нагрузка на мозг и важно дать ему отдохнуть от мыслей и задач. Хороший сон так же важен, а вот время когда вы ложитесь и встаёте не имеет значения как по мне.

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

Если чувствуешь что тебе реально плохо, то сделай две вещи:

1. Немедленно перестань работать. Толку от тебя будет мало в любом случае.

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

Если чувствуешь что ничто не помогает и все повторяется из раза в раз - возможно стоит подумать а точно ли то чем ты занимаешься приносит тебе удовольствие? Может найти другую компанию или вообще заняться другой работой, уйти в DevOps например, или начать собирать мебель. Подумай об этом.

_____

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

Спасибо что добрались досюда ❤️

Присоединяйтесь в мой канал

Глава 3. Мой путь

Не обязательная глава (хотя наверняка самая интересная с точки зрения повествования). Многие интересуются как именно я пришел и вырос в IT, так что поделюсь своей историей. К сожалению телеграф имеет ограничение на длину статей, поэтому вынес на отдельную страницу:

Продолжить читать этот бред ...