work&dev fun(damentals) #1. Я был благодарен, за то что меня научили этому, когда я был джуном

Это цикл статей. Предыдущую можно прочесть тут ^[1]

Мне офигенно повезло. Когда я устроился на работу trainee, я не знал совершенно ничего. Вокруг сидели люди, разговоры которых меня пугали. Любой, сейчас примитивный, термин оставлял пустоту в глазах, а люди, которые ходили на митинги — вызывали восхищение.

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

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

Этот и 3 последующих проекта оказались ключевыми в моей карьере, я потратил на них около 3.5 лет. Но всех их объединяло несколько неотъемлемых частей.

И первая важная часть. Я считал себя частью проекта.

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

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

Пример: Если вы делаете что-то для бухгалтеров и выбираете между "ячейками по типу excel" и какими-то новыми, но слегка неудобными "fancy selectors", выбирайте первое, если у вас есть возможность. Плевать, что fancy selectors кажутся вам удобными и красивыми. Вы же их сутки на пролет тестируете, вы просто к ним привыкли. А вот ваш пользователь привык к ячейкам. Вы можете чего-то не знать, но если ни клиент, ни дизайнер не могут объяснить почему усложняющие систему элементы буду game changers, то этот вопрос стоит хотяб озвучить.

1. Чтобы сделать то, что действительно полезное, нужно понять пользователя. А для этого, нужно понять проект

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

На одном из проектов я попал к людям, которые не особо парились о том, чтобы казаться "нетоксичными" в том понимании, которое теперь вкладывают в это слово, то есть быть доброжелательным, даже там, где это нахер не надо, вот вам отличная статья про лицемерие Нетоксичное лицемерие / Хабр ^[2]. И я им за это благодарен. Я закрывал пуллреквесты по несколько недель и получал по 100-200 комментариев. Когда один уходил в отпуск и к ревью подключался кто-то другой мне приходилось переписывать решение под хотелки нового человека. Мне комментировали код, который просто попадал в область видимости в дифе. Кто-то опытный сейчас подумает, что это афигенно деструктивная атмосфера. А я скажу "нет". Потому что все объясняли, каждое решение, каждый + к однотипной ошибке. И это привело меня к тому, что отправляя код на пул реквест, я следовал правилу "убери за собой и немного вокруг". А также к более важной вещи, которая, по факту, является следующим уровнем к выработанному правилу — "рефакторинг — это ежедневный процесс" ^[3].
Такой подход быстро научил меня разбираться в чужом коде, я освоил несколько техник рефакторинга, сформировал свой подход к написанию тестов.

2. Убирай за собой и немного вокруг

Третья важная часть. Твоя задача завершена только тогда, когда ее принял клиент.

Тут, казалось бы, нечего писать, но десятки знакомых мне людей забывали про свои задачи сразу после открытия пулл рекваста. Часть из них даже не меняла статус в таск трекере. И дело тут не в дисциплине, а в подходе к работе. Будь у тебя отдел тестирования, продакт который делает UAT, автоматизация и вся эта прочая радость, твоя работа — довести дело до конца. Ответить на комментарии, проанализировать изменения требований и вынести в отдельную фичу/доработать, объяснить поведение, подсказать и описать как протестировать. Код не должен и не может быть единственным артефактом твоей работы. Писать код может кто угодно, это простейшие смысловые конструкции. Ты же не хочешь быть кем угодно, а хочешь быть профи. А профи за свою работу несут ответственность и доводят ее до конца.

3. Твоя задача завершена только тогда, когда ее принял клиент.

Четвертая важная часть. Стоимость бага можно снизить и это то, что ДОЛЖНО тебя беспокоить.

Этот пункт вытекает из предыдущего. Где-то спустя пол года работы мне рассказали про стоимость бага.
Ниже график, цифры утрированы, но суть тут не в этом.

Взгляните на пункт, который идет ПОСЛЕ разработки. Селф-тестинг. Это что должен делать каждый и привыкать с детского сада. Задеплоил на стейджинг, не торопись двигать задачу в колонку тестирования. Проверь сам, хотя бы happy path. Убедить, что все учел.

Тут есть несколько моментов.

1. Первый — меркантильный. Тестировщик потратит время на заведомо не работающую фичу, потратит время на описание реджекта или создание новой задачи, разберется все ли он учел.
2. Второй — этический. Тестировщик меняет контекст, вчитывается в задачу, создает себе представление о том, что конкретно нужно проверить и на что еще это может повлиять, готовит данные, которые ему понадобятся для проверки, и… бах… ничего не работает. Просто, банально, кнопка должна быть зеленой, а она красная. Такая задача, кмк — плевок в лицо тому, кто ее проверяет.
3. Третий — эгоистичный. То что ты делаешь, формирует твой бренд и авторитет внутри команды. Если ты деливеришь чепуху, не ожидай к себе серьезного отношения.
   Про стоимость бага можно говорить много, но не здесь. Здесь важно запомнить

4. Стоимость бага можно снизить и это то, что ты ДОЛЖЕН делать после того, как твой код попал в любой рабочий энв, отличный от development

Пятая важная часть. Попробуй, прежде чем спросить.

Нас всех этому учили в школе, дома и везде. Но мало, кто урок усвоил.
Via est gressibile steps, как говорится. Уважайте время своих коллег, не приходите к ним с вопросами, даже не попробовав самостоятельно. Я с самого начала задавал максимально глупые запросы в гугл и в большинстве своем я находил там ответы, хотя бы близкие к тому, что мне надо. Я не всегда знал как их применить. Не всегда они работали. Но я эти ответы искал сам. А уже потом, с ответами, шел к "старшим".
Это позволяло мне формировать контекст и добавлять конкретики.

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

5. Приходи только с вопросами, на которые у тебя уже есть неверные ответы

Шестая важная часть. Я читал код всего, что использовал, если он был доступен.

Как узнать про нюансы? Как найти примеры не выходя из IDE? Как не отвлекаясь найти решения для своих проблем, которые, кажется этот метод должен решать? Верно! Читать код. RubyMine / WebStorm / VSCode — все они умеют прыгать в код. Не все, но многие умеют прыгать в код библиотек. Я открою тайну, но большинство документации генерируется по комментариям к методам. Это значит, что вам не обязательно документацию гуглить, если вы можете сделать jump to defenition и просто прочесть ее в своем редакторе. Вы откроете для себя МИР НОВОГО СИНТАКСИСА, СИНТАКСИСА библиотек. Это первая плюшка. Вы откроете для себя нюансы работы методов и функций — вторая. Вы поймете не потеряете фокус и не отвлечетесь, потому что остаетесь в редакторе кода — третья. Разве этого мало?

6. Ковыряйте исходный код того, с чем работаете

Этого хватит, правда. Да, я не читал книг, я за 5 лет прочел всего полторы технические книги, посмотрел миллионы видео на youtube, прочитал кучу статей. Но все это я начал понимать и оценивать влияние на мою работу сильно позже.
А когда я был джуном, я просто работал работу на совесть, остальному меня научили опытные товарищи.

Если хотите пообщаться пишите на @_golubev ^[4].

Я дал этой рубрике название work&dev fun(damentals). Потому что работа и разработка — это весело. Но надо учиться фундаментальным вещам. Не важно софт скилы это или хард скилы.
Все, далее описанное, это тот опыт который я приобрел. Он ограничен моим пониманием вещей, происходящих в IT. Процессов, которые тут происходят. Решений, которые принимаются. Это понимание позволило мне из Trainee в в одного их лидов Full-stack направления. Параллельно создать отдел, который специализируется на техническом развитии и мониторинге эмоционального состояния сотрудников, для того, чтобы сделать их работу комфортной и обеспечить их конкретным пониманием того, что именно от них ожидают в компании и проекте.

Автор: Голубев Алексей

Источник ^[5]