Ого, прошло 6 месяцев! До сих пор не верится, что мой план сработал, ведь я уже больше полугода работаю Frontend Developer! Хотя с 24 февраля мне и миллионам других казалось, что время остановилось, на самом деле оно пролетело довольно быстро, может быть, даже быстрее, чем когда-либо.

Говорят, что на работе ты учишься намного быстрее, и за первый месяц работы ты узнаешь больше, чем за время учебы. Что ж, они не врали. Честно говоря, я понятия не имел, что такое настоящий проект, не простое Fullstack-приложение с примитивным REST API и пользовательским интерфейсом, а что-то большое и серьезное. С настройками, инструментами, тестами, различными средами и так далее. Довольно редко и не ожидается, что новичок сделает что-то подобное для домашнего проекта или создаст несколько сложных API со сложными структурами данных. Работа над довольно большим проектом — это, пожалуй, один из самых важных опытов, которые я когда-либо получал от своей первой работы в качестве разработчика программного обеспечения.

Итак, что изменилось и чему я научился за последние 6 месяцев?

Что я узнал

Что такое управление командой и проектом? 🧐

В вещах нет порядка по важности, но я все же предпочел расположить их именно так, как они есть.

У меня есть опыт работы в команде — иногда люди пренебрегают тем, насколько важен этот опыт. Кроме того, поскольку я работаю удаленно, у меня появилась замечательная возможность научиться работать в таких условиях, что в современном мире является весьма необходимым навыком. Конечно, я не могу игнорировать тот факт, что получить идею и опыт работы с менеджером проекта — это здорово. Не секрет, что новички толком не знают, что такое Agile, Waterfall или __enter_any_management_word_here__ и почему/что/кто такой Scrum Master. Да, мы все смотрели эти видео и, возможно, даже купили курс, но одно дело — узнать, что это такое, а другое — на самом деле научиться управлять своим кораблем в » историях, заданиях, билетах и ​​бла-бла-бла. воды. Говоря об этом, я НАСТОЯТЕЛЬНО рекомендую вам завести себе бесплатную учетную запись на GitHub (да ладно, я не могу представить, что у вас ее нет), продукты Atlassian (BitBucket, Jira и т. , и еще кое-что, и попробуйте создать свой собственный проект, чтобы увидеть, что к чему. Поверьте мне, даже умение ориентироваться в приложении и знание терминологии сделают вас на шаг впереди других.

Все еще о коде 🧑‍💻

Как я уже говорил ранее, когда вы начинаете работать, ваш прогресс в обучении мгновенно летит на Луну 🚀🌕

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

О….TypeScript….

Ну…..что я могу сказать…мне…нравится?! Да, мне все еще тяжело, особенно когда я получаю какие-то странные ошибки, которые не могу понять, особенно когда Google не очень помогает, хотя я неплохо гуглю 🥲 Честно говоря, я использую TypeScript с самого первого дня на работе, и становится трудно представить, что я использую чистый JavaScript, хотя должен признать, что иногда я сначала пишу vanilla JS, а потом добавляю типы 🌝

Поскольку большинство из нас, недавних новичков, начинали с React, основанного на функциональности, мне пришлось довольно быстро освоить компоненты, основанные на классах, потому что в проекте использовались оба из них. Это было здорово, узнал новые подходы и шаблоны. Видел как отличные техники, так и очень плохие — к счастью, мы довольно быстро от них избавились 😏

Еще одним убийцей стал D3.js — отличная библиотека! Я потратил чертовски много времени, работая с ним, и я являюсь своего рода «человеком» для любых вещей, связанных с D3.js в компании, потому что у меня больше всего опыта с ним, и я работал исключительно над этим. часть приложения, поэтому я хорошо разбираюсь в кодовой базе. Честно говоря, какое произведение искусства эта библиотека 🥰

Лично я очень интересуюсь всем, что касается разработки, поэтому я начал медленно изучать как Backend, так и DevOps. Это медленно, но верно. Тссс… наш бэкэнд на PHP, и я не очень хочу его трогать 🤫 Так что я сейчас использую Node и хочу добавить немного Python в свой стек.

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

Пожалуйста, поймите, что советы, которые я даю ниже, хорошо сработали для меня, в моей компании и в моей среде. Это не какие-то «окончательные» советы, которые работают всегда, но я считаю, что они работают в 90% случаев.

Карьерный совет для младших разработчиков

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

Быть младшим разработчиком не означает, что вы ребенок.
Я не говорю, что вы должны носить все черное и серое, не шутите и не дурачьтесь. вокруг немного — нет. Дело в том, что вы взрослый человек, получивший работу в реальной компании в реальном мире. Да, есть период адаптации. Да, они знают, что ты младший, и им нужно следить за тобой. Но, черт возьми, это же не детский сад, верно? Вы полностью ответственный человек, который должен серьезно относиться к работе и показывать, что вы способны ее выполнять. Способен нести ответственность за код, который вы пишете, и за ту часть приложения, над которой вы работаете. Чем быстрее они это увидят, тем быстрее к вам будут относиться как к важной части команды, а не как к сотруднику "стажер+".

Вы являетесь неотъемлемой частью команды, сообщите им об этом.

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

Не бойтесь открыть рот и выплюнуть факс.

Будем реалистами, все (по крайней мере, адекватные люди) хотят сделать отличный продукт, которым пользователи будут пользоваться с удовольствием. Если во время обсуждения новой фичи вы слышите, что происходит какое-то коллективное безумие, и предлагаются какие-то странные вещи — не бойтесь ГОВОРИТЬ. Действительно! Все устают и заняты своей работой, и они могут просто думать и упускать некоторые вещи из разговора. И если вы заметили, что эта идея плоха, реализация будет сложной, UX пострадает, и это может привести к невозможности масштабирования — ГОВОРИТЕ! Они это оценят — вернейший я. Делайте это по-умному. Пожалуйста, попросите прервать их и объяснить, почему вы считаете, что идея того не стоит. Приведите примеры, почему вы считаете, что это плохо.

Не бойтесь предлагать.

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

Проверяйте код.

В разных организациях это может быть по-разному, но если у вас есть возможность ознакомиться с кодом Senior — сделайте это. Посмотрите, как опытные люди пишут код, посмотрите, как они комментируют и как оформляют код. Вы можете МНОГОЕ узнать, просто читая чей-то код. И не бойтесь давать им комментарии о том, что что-то не так или что код — это ерунда….плохо. Как я уже сказал, в конечном итоге от плохого кода пострадают пользователи и разработчики. Если вы можете это предотвратить — сделайте это.

Балансируйте, когда обращаться за помощью.

Этот достаточно индивидуален. У каждого своя оценка того, что слишком рано, а что слишком поздно, хотя в данном случае никогда не поздно, потому что в конце концов вы застрянете и попросите о помощи. Давайте определимся, что на мой взгляд слишком рано, а что слишком поздно.

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

Несколько моментов означают, что еще слишком рано:
 — вы вообще не гуглили проблему;
 – вы гуглили ее, но это был только поиск сообщений об ошибках с копированием и вставкой, и вы не получили никаких результатов. ;
- Вы не смотрели похожий код/компонент в других местах;
- Вы проверяли только StackOverflow, но не проверяли проблемы GitHub и не пролистывали всю ветку;
- Вы не нагуглил по крайней мере 4-5 разных описаний проблемы.

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

Просить helo слишком поздно не так уж плохо для младшего разработчика, это даже ожидаемо, так же как и спрашивать «слишком рано». Но имейте в виду, что позже, когда вы спросите, это означает, что вы потратили больше денег на компанию.
Как я уже сказал, я пытаюсь уложиться в 2 часа, так или иначе, это предел, который я установил для себя, и до сих пор никто не жаловался и даже не оценил это.

Только один момент:
- Если прошло уже 2 часа и вы понятия не имеете почему, где, как и так далее — обратитесь за помощью, вы можете попасть в «слишком поздно» землю.

Не будь придурком и прими свои ошибки

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

БОГ, ПОЖАЛУЙСТА, НЕ БУДЬ уткой!

Это ваша работа, а не жизнь

Хороший разработчик — хорошо отдохнувший разработчик. Иногда я могу остаться немного дольше, просто чтобы закончить последнюю вещь, потому что я знаю, что утром мне потребуется некоторое время, чтобы вспомнить, о чем код. Иногда я могу понять, как что-то исправить в час ночи, и я могу сидеть и кодить 15–20 минут. Это прекрасно, я думаю. Но кроме этого.

17:00. ФИНИТО. ТИК-ТОК АМА ЧАСЫ……закрой ноутбук и расслабься.

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

Давайте назовем это днем

Фууууууу, это было большое событие. Думаю, я могу продолжить давать советы, поэтому давайте однажды сделаем это Twitter Space, потому что я могу говорить, говорить и говорить об этом. Не забудьте подписаться на меня в соцсетях, если вам это интересно @SergiiKirianov и Instagram js_messiah_live

Первые 6 месяцев были отличными. У меня не было ни дня, чтобы я пожалела, что сменила профессию и что я не в море. Есть несколько подводных камней, но ничего особенного. Что сказать, я люблю то, чем занимаюсь 🥰

Спасибо за чтение и надеюсь, вам понравилось, и надеюсь, что еще больше, что это будет полезно для вас. Желаю вам удачи в вашей карьере разработчика. Вы должны знать одно, вы можете это сделать! Это непросто, это может занять некоторое время, но вы справитесь! Я знаю!