Хабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть