Мне офигенно повезло. Когда я устроился на работу trainee, я не знал совершенно ничего. Вокруг сидели люди, разговоры которых меня пугали. Любой, сейчас примитивный, термин оставлял пустоту в глазах, а люди, которые ходили на митинги — вызывали восхищение. Я до сих пор помню свой первый митинг. Я созвонился с нашим американским партнером, который раньше жил в нашем городе и вообще, как оказалось, был давним другом и партнером. Мы обсудили проект, мокапы, мне сказали думать про UX и пользователя и что идея будет прорывная, но надо работать быстро. Я вышел оттуда гордый и довольный собой. Через 4 месяца проект закрыли, потому что Instagram поменял политику предоставления доступов к API, а меня перевели на другой проект. Все далее ниже описанное, мне, к сожалению, удалось пережить лишь раз, но именно в этот раз мои действия, как мне в итоге кажется, провели меня на определенный уровень осознанности и понимания того, как учить молодых разработчиков, чтобы в 24 тобой мама гордилась заслуженно :) Этот и 3 последующих проекта оказались ключевыми в моей карьере, я потратил на них около 3.5 лет. Но всех их объединяло несколько неотъемлемых частей.  Первое что стоит сделать джуну, да и вообще кому угодно — стать вовлеченным, но не в код, а в проект, как идею. В каждом проекте я искал что-то, что отвечало мне на вопрос "а зачем это?", "какую проблему пытается решить клиент этим проектом?". Но джуну это важнее всего, потому что полезные привычки надо вырабатывать с детства. Ответ на этот вопрос приводит к рассуждениям о целевой аудитории, об их шаблонах поведения и о том, что может быть реально НЕ ВАЖНО для клиента и пользователя, а что может быть ошибочным. Пример: Если вы делаете что-то для бухгалтеров и выбираете между "ячейками по типу excel" и какими-то новыми, но слегка неудобными "fancy selectors", выбирайте первое, если у вас есть возможность. Плевать, что fancy selectors кажутся вам удобными и красивыми. Вы же их сутки на пролет тестируете, вы просто к ним привыкли. А вот ваш пользователь привык к ячейкам. Вы можете чего-то не знать, но если ни клиент, ни дизайнер не могут объяснить почему усложняющие систему элементы буду game changers, то этот вопрос стоит хотяб озвучить. На одном из проектов я попал к людям, которые не особо парились о том, чтобы казаться "нетоксичными" в том понимании, которое теперь вкладывают в это слово, то есть быть доброжелательным, даже там, где это нахер не надо, вот вам отличная статья про лицемерие Нетоксичное лицемерие / Хабр. И я им за это благодарен. Я закрывал пуллреквесты по несколько недель и получал по 100-200 комментариев. Когда один уходил в отпуск и к ревью подключался кто-то другой мне приходилось переписывать решение под хотелки нового человека. Мне комментировали код, который просто попадал в область видимости в дифе. Кто-то опытный сейчас подумает, что это афигенно деструктивная атмосфера. А я скажу "нет". Потому что все объясняли, каждое решение, каждый + к однотипной ошибке. И это привело меня к тому, что отправляя код на пул реквест, я следовал правилу "убери за собой и немного вокруг". А также к более важной вещи, которая, по факту, является следующим уровнем к выработанному правилу — "рефакторинг — это ежедневный процесс".
Такой подход быстро научил меня разбираться в чужом коде, я освоил несколько техник рефакторинга, сформировал свой подход к написанию тестов.  Тут, казалось бы, нечего писать, но десятки знакомых мне людей забывали про свои задачи сразу после открытия пулл реквеста. Часть из них даже не меняла статус в таск трекере. И дело тут не в дисциплине, а в подходе к работе. Будь у тебя отдел тестирования, продакт который делает UAT, автоматизация и вся эта прочая радость, твоя работа — довести дело до конца. Ответить на комментарии, проанализировать изменения требований и вынести в отдельную фичу/доработать, объяснить поведение, подсказать и описать как протестировать. Код не должен и не может быть единственным артефактом твоей работы. Писать код может кто угодно, это простейшие смысловые конструкции. Ты же не хочешь быть кем угодно, а хочешь быть профи. А профи за свою работу несут ответственность и доводят ее до конца. Этот пункт вытекает из предыдущего. Где-то спустя полгода работы мне рассказали про стоимость бага. Ниже график, цифры утрированы, но суть тут не в этом.  Взгляните на пункт, который идет ПОСЛЕ разработки. Селф-тестинг. Это что должен делать каждый и привыкать с детского сада. Задеплоил на стейджинг, не торопись двигать задачу в колонку тестирования. Проверь сам, хотя бы happy path. Убедить, что все учел. Тут есть несколько моментов. Нас всех этому учили в школе, дома и везде. Но мало, кто урок усвоил. Via est gressibile steps, как говорится. Уважайте время своих коллег, не приходите к ним с вопросами, даже не попробовав самостоятельно. Я с самого начала задавал максимально глупые запросы в гугл и в большинстве своем я находил там ответы, хотя бы близкие к тому, что мне надо. Я не всегда знал как их применить. Не всегда они работали. Но я эти ответы искал сам. А уже потом, с ответами, шел к "старшим". Это позволяло мне формировать контекст и добавлять конкретики. Как узнать про нюансы? Как найти примеры не выходя из IDE? Как не отвлекаясь найти решения для своих проблем, которые, кажется этот метод должен решать? Верно! Читать код. RubyMine / WebStorm / VSCode — все они умеют прыгать в код. Не все, но многие умеют прыгать в код библиотек. Я открою тайну, но большинство документации генерируется по комментариям к методам. Это значит, что вам не обязательно документацию гуглить, если вы можете сделать jump to defenition и просто прочесть ее в своем редакторе. Вы откроете для себя МИР НОВОГО СИНТАКСИСА, СИНТАКСИСА библиотек. Это первая плюшка. Вы откроете для себя нюансы работы методов и функций — вторая. Вы поймете не потеряете фокус и не отвлечетесь, потому что остаетесь в редакторе кода — третья. Разве этого мало?  Этого хватит, правда. Да, я не читал книг, я за 5 лет прочел всего полторы технические книги, посмотрел миллионы видео на youtube, прочитал кучу статей. Но все это я начал понимать и оценивать влияние на мою работу сильно позже.  А когда я был джуном, я просто работал работу на совесть, остальному меня научили опытные товарищи. Я дал этой рубрике название work&dev fun(damentals). Потому что работа и разработка — это весело. Но надо учиться фундаментальным вещам. Не важно софт скилы это или хард скилы.
Все, далее описанное, это тот опыт который я приобрел. Он ограничен моим пониманием вещей, происходящих в IT. Процессов, которые тут происходят. Решений, которые принимаются. Это понимание позволило мне из Trainee в в одного их лидов Full-stack направления. Параллельно создать отдел, который специализируется на техническом развитии и мониторинге эмоционального состояния сотрудников, для того, чтобы сделать их работу комфортной и обеспечить их конкретным пониманием того, что именно от них ожидают в компании и проекте. Software Engineer