Что мы ждем от работы с Junior Backend Developer

Что мы ждем от твоего уровня знаний и умений

Нет промышленного опыта - это нормально. Но есть желание разбираться в чем-то новом, обучаться для того, чтобы потом использовать свои знания в промышленной разработке. День потерять, потом за 5 минут долететь
Получать опыт на своих ошибках или разбираясь в коде на проекте с целью не повторять ошибки, быть более эффективным/ результативным. Пойми, мы простим тебе что ты медлителен при условии, что ты ускоряешься!
Работа над устранением ошибок в своем коде. Перечитать свой код - неплохая идея. Хорошие писатели перечитывают свои романы несколько раз до публикации. Есть чему поучиться?
Стремление сделать вклад в проект. Представь, что ты футболист, который держится подальше от мяча, думая, что другие умеют играть лучше и затащат победу. Старайся вносить свою лепту, не проходи мимо неустройств, не надейся, что ревьюеры найдут все твои косяки в коде, а тестирование - в логике, проверяй и перечитывай сам. Актуализируй базу знаний/Confluence, указывай аналитику на ошибки в требованиях, помогай тестированию проверить свою фичу и т.п. Твоя зарплата и тайтл определяются твоей ценностью для компании. А твоя ценность определяется тем, приносят твои усилия пользу проекту или проблемы
Ответственность за результат. Представь, что ты ставишь клеймо качества со своим именем под все, что ты делаешь. Видя это клеймо, невольно должно появляться чувство уважения
Знание языка программирования и его конструкций. Знай свои инструменты! Не бойся инвестировать в “банальные” темы вроде синтаксиса языка или возможности IDE - если они помогут тебе работать эффективнее в долгосрочной перспективе. Считай, что ты инвестируешь свое время аналогично как ты инвестируешь деньги - выглядит ли это достаточно “прибыльно”? Не бойся спросить совета у ресурсного или, особенно ценно, - проектного девлида
Умение писать логику (if/else and/or). Рисуй таблички, алгоритмы, пиши в блокнотике, пиши юнит-тесты - как угодно, важно, чтобы кусочек твоего кода работал корректно на всех возможных входных параметрах

Как мы к тебе относимся

Мы, как правило, готовы вкладывать время в твое развитие. Научишь один раз, а помогать будешь несколько лет. Отличная инвестиция времени, если она приводит к тому, что вопросов становится меньше, а твой код стает более качественным и занимает у тебя маньше времени на написание и проверку
Мы нормально относимся к твоим ошибкам при условии, что их со временем становится меньше. Если тебе указали на ошибки, постарайся выжать все из этой ситуации! Не повторяй не только конкретно эту ошибку, но и аналогичные ошибки - тоже
Мы объясняем многие вещи на пальцах. Это не отменяет того, что ты что-то загуглишь и поймешь это объяснение лучше. Задашь встречные вопросы. Не воспринимай это объяснение как исчерпывающее, а как некий шорткат, который тебе позволит не идти в неправильную сторону, петлять и, в итоге, заблудиться в лесу инструментов, фреймворков и подходов
Ждем, что ты будешь учиться, а не зарабатывать лычки. Научиться - означать меньше тратить времени в будущем и получать более качественные решения. Если ты чему-то учишься, что тебя не приводит к этой цели, обсуди, может быть ты учишься не тому. Твоя цель похвастаться на тусовке за кружечкой пива, что ты вчера Spring дебажил нам не по сердцу!
Мы иногда заняты. Если тебе не ответили сразу в чатике, повод спросить кого-то еще? Может быть еще взять время погуглить? Если ты разобрался в вопросе, сообщи об этом нам вслед за вопросом, чтобы мы не пытались решать уже решенную проблему. Сообщи заодно свое решение. Лучше сообщить о тривиальном решении, не вызывающем вопросы, чем не сообщить о решении, которое окажется неправильным
Часто мы решаем задачи первыми, набиваем шишки, протаптываем лыжню. Решение аналогичных задач в последствии разумно поручить тебе, чтобы ты мог работать на основе какого-то примера. Иными словами, если для меня задача стала рутиной, для тебя она может быть вызовом и поводом многому научиться
Мы рассчитываем, что ты со временем, когда наберешься опыта, возьмешь на себя часть наших задач. А в перспективе - встанешь на наше место, позволив нашим опытным разработчикам выходить с проекта и брать новые проекты, учить других новичков. А тебе - развиваться, повышать свою ценность для компанию, а следовательно - выходить на новые тайтлы и получать большую зарплату.

Примеры

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

Чем это хорошо для тебя:

Ты научишься разбираться, гуглить, читать документацию, самостоятельности, но какой ценой

Чем это плохо для тебя:

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

Ожидаемое поведение:

Ты можешь попросить объяснить непонятные моменты, желательно предоставив свои варианты. Далее, прикидываешь план решения, показываешь старшему разработчику “ок или что-то не так, а может все не так?”. Этот процесс называется Review Before Code. Иногда это сделать тяжело - в силу твоего характера или в силу характера задачи. Вполне можно прикинуть первую версию в коде, получить первые шишки и потом уже приступать к описанию решения или доведения его до промышленного уровня. Почему бы не спросить совета “я хочу накидать прототипчик за полдня, норм?”?
Ты получаешь задачу, но не понимаешь, зачем ее делать, и какие проблемы на проекте этим решаются

Чем это хорошо для тебя:

Ничем, разве что хочется пострадать

Чем это плохо для тебя:

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

Ожидаемое поведение:

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

Чем это хорошо для тебя:

Ничем. Честно, поверь

Чем это плохо для тебя:

Если ты не генерируешь решений из головы, ты не научишься это делать в принципе. Сложнее тривиальных задач ты ничего сделать не сможешь. Застрянешь на тайтле Junior Software Developer до самой пенсии Твои решения никогда не будут достаточно хорошими

Ожидаемое поведение:

Учись придумывать решение задач, как бы тяжело это не было. Это как закрыть микрокредит под 10000% годовых. Ничего разумнее ты сделать не сможешь. Можно начать с обычных алгоритмических задач на codingbat, codewars или из учебника для программистов. Поверь, сделать это прямо сейчас не стыдно Иногда так бывает, что ты что-то прикинул, попросил помочь. Пока ждал, 10 раз все переделал и в самый неподходящий момент появляюсь я. Почему бы не сказать об этом? Скажи подойти попозже. А лучше заначь решение, вызывающее вопросы в Shelve и быстренько все верни как нужно, когда я подойду Если ты не слишком далеко зашел, генерируешь идеи сам, но пишешь слишком много всего, настолько, что оно начинает обваливаться под своим весом, не беда. Трать чуть больше времени на то, чтобы код был качественным, даже первая версия. Ты ведь первую, плохую версию, перепишешь в более красивый, production-ready вариант, да?
Ты не любишь проверять работоспособность своего кода - надо же инфраструктуру настроить, приложение запустить, а оно 5 минут компилится. Ревьюверы найдут косяки, а те, что не найдут, найдут тестировщики. Я ж мелкий баг закрыл, ну как тут можно было ошибиться…

Чем это хорошо для тебя:

Ничем, честно

Чем это плохо для тебя:

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

Ожидаемое поведение:

Учись ответственности за свой код, стремись доказать всем, и в первую очередь себе, что твой код работает. Пиши тесты. Возьми и прогони тест-кейсы коллег-тестировщиков. Импровизируй, советуйся
Встретив конфликт в Git у тебя и мысли не возникает его решить. Зато возникают панические настроения и желание попросить кого-то сделать эту работу. В задаче указаны какие-то компоненты, релизы и какие-то связи с задачами, которые не трогают ни единой струны твоей души - ты их полностью игнорируешь, а иногда, под настроение, воспринимаешь удобным тебе образом, в задаче по ссылке в cloned by указан исполнитель из другой команды, я подумал не надо делать эту задачу. Тебе приходят письма с какого-то странного адреса ci-jenkins@myproject.com, которые написаны моноширинным шрифтом, не вызывающим у тебя доверия - ты их игнорируешь даже если ты указан в TO и тема содержит фразу “Build failed”

Чем это хорошо для тебя:

Крепче спишь, наверное. Лид к тебе настолько охладел, что не грузит своими дурацкими задачами. Серьезно, это ничем для тебя не хорошо

Чем это плохо для тебя:

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

Ожидаемое поведение:

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

Чем это хорошо для тебя:

Может быть в краткосрочной перспективе ты выиграешь немного времени

Чем это плохо для тебя:

В долгосрочной перспективе ты медленнее учишься

Ожидаемое поведение:

Похоже тебе тяжело дается понимание основ твоей деятельности. В какой-то момент времени ты начнешь все записывать, но это не выход. Выход – понимать, что ты делаешь на таком уровне абстракции, ниже которого можно не проваливаться. Например, где-то можно притормозить на основах языка Java, а в какой-то момент придется провалиться и почитать байт-код. Так вот, ты, похоже, решил не напрягать свой измученный мозг и остановиться сильно выше по уровням абстракций. Приведем аналогию - ты хочешь что-то построить из лего, но у тебя нет кирпичиков, а есть 9 элементов, намертво соединенных друг с другом. Можно приложить усилия и разъединить, а можно и так взять. Настоящий прагматичный разработчик разберет эту конструкцию ради того, чтобы не пытаться запоминать такую сложную конструкцию и мучаться с ее подгонкой под то, что нужно получить

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

Чем это хорошо для тебя:

К тебе тяжело придраться

Чем это плохо для тебя:

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

Ожидаемое поведение:

Самое главное - соизмеряй свою активность с целями проекта и ценностями EPAM. При принятии решений каждый раз думай какой из вариантов ближе к целям проекта и нашим ценностям. Это называется конструктивность. Когда сбудется твой кошмар и тебя спросят, а почему-это ты так сделал? Ты весьма убедительно объяснишь почему. Обычно сложно возражать. Но это теория, предлагаю поглядеть пару примеров. Тебе интересно поглядеть, что там и как написано в смежной системе. Твой баг уводит корнями в ту систему. Ты тратишь полчасика попробовать ее развернуть, и она вдруг развертывается и работает. Ты тратишь еще часик подебажить и найти проблему. И получается. На вопрос не фигней ли ты страдал ты вполне убедительно доказываешь, что такие некрупные вложения времени были оправданы и ты скоро пофиксишь дефект и создашь Merge Request. Даже если ты не успеешь, всегда можно сказать - я попытался так как считаю, что для проекта в долгосрочной перспективе было бы полезно, если бы я знал смежную кодовую базу - я оттуда всяких интересных вещей натаскаю, плюс смогу быстро исправлять дефекты, которые мешают нашей системе. Другой пример - ты можешь прийти к лиду и сказать - задача оценена в 3 дня, но я бы взял 5, т.к. нет опыта в Кафке, хочется чуть подробнее глянуть. Ну кто откажет? Отношение к статусу тоже лучше спроецировать на цели проекта и ценности. Лучше всего сказать то, что поможет процессу в целом. Что делаешь, какие есть блокеры, какие прогнозы и следующий крупный шаг Посвятить команду в свой статус в целом хорошая идея, т.к. поможет понимать ситуацию на проекте. Если есть что-то полезное для всей команды - тоже можно обсудить
У тебя есть проектная задача, но ты решил поделать менторинг

Чем это хорошо для тебя:

Ты экономишь личное время за счет рабочего

Чем это плохо для тебя:

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

Ожидаемое поведение:

Запомни основной принцип EPAM: Project first. Если проект требует внимания, ты ОБЯЗАН отложить все - менторинг, прохождение корпоративных курсов на adaptation-портале, занятия по английскому, one-to-one с руководителем, HR-специалистом и т.п. Проекты - это то, как EPAM зарабатывает деньги. Единственно, стоит уведомить пострадавшую сторону, что ты не можешь сделать то, что обещал из-за внезапных проектных задач. Это ожидаемое поведение. Его нарушение - катастрофически снижает твою ценность, следовательно может заблокировать изменение тайтла и зарплаты. Были случаи, когда D3 становился D2. Серьезно Таким образом, сообщи проектному руководству о своем конфликте интересов. Иногда, очень редко, проектные задачи только кажутся срочными. Также бывает, что есть кто-то другой, кто может ее сделать Ну и учиться следует в свое личное время, которое может появляться в рабочие часы, в том числе, когда ты вкладываешься в свое умение быстро и качественно решать задачи и получаешь дивиденды в виде времени, которое ты тратишь на непроектные активности
Мы в запарке даем тебе задачу на голову выше твоих возможностей. Потребуется взаимодействовать с аналитиками, другими разработчиками, договариваться, писать письма, утверждать или уточнять требования. В задаче нет детального плана действий

Чем это хорошо для тебя:

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

Чем это плохо для тебя:

Тебе может быть сложно

Ожидаемое поведение:

Самое важное. Если задачу поручают неопытному человеку, это определенный знак. Обычно задача не очень срочная. На тебя большие планы. Уровень доверия к тебе повысился. Обычно у твоего лида в голове план вида “пусть попробует. Если облажается, я как раз разгребусь с задачей А и сам сделаю”. Таким образом, для тебя это повод показать себя. Не нужно бояться таких задач. Помедитируй, задай главные вопросы и начинай работать. Не бойся ходить к другим членам команды - они, конечно, заняты, но мы делаем общее дело. Руководствуйся целями проекта и нашими ценностями, ведя разговор. Ожидается, что ты согласуешь основные этапы своей работы прежде чем фиксировать их в ~гранит~ Git
Ты просишь помощи, но не прикладываешь достаточно информации

Чем это хорошо для тебя:

Может быть чуть-чуть экономишь свое время

Чем это плохо для тебя:

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

Ожидаемое поведение:

Ты собираешь важную информацию о своей проблеме. Ищешь возможные варианты решения. Может быть пишешь мини-прототипы, чтобы получить больше информации, вытаскиваешь ее в режиме дебага. Твоя изобретательность, проактивность достойны кисти мастера в этот момент. Но ты также знаешь меру и не отправляешь 38-страничный отчет потратив 2 дня Также было бы отлично, если бы ты немного повременил нажимать кнопку Send, а потратил буквально 8 минут пробежать глазами что ты собрался отправлять и привел в порядок заголовок письма. Все важное вынес бы в начало письма. Может быть на каких-то нюансах сделал акцент - есть такая возможность в большинстве редакторов Далее, если у тебя есть безумная идея, что виновато магнитное поле Венеры, но у тебя нет доказательств, может быть взять минут 15 на проверку, или оставить это мнение при себе? Особенно это уместно, когда хочется обвинить своего коллегу, например, аналитика. Проверить факт от не-факта помогает вопрос “В чем это выражается”. Если ответ звучит по-идиотски, можно остановиться и еще раз переосмыслить/перефразировать факты, изложенные в письме. Например, “виновато разгильдяйство со стороны Заказчика” нас не убедит и вызовет лишние вопросы. А “IP-адрес, данный нам как адрес сервера, ведет на рабочую станцию какого-то сотрудника” - убедит
Проходишь менторинг ради самого факта прохождения, не получая практического навыка и опыта. Считаешь, что копипаста со StackOverflow ускорит процесс

Чем это хорошо для тебя:

Получаешь бейджик

Чем это плохо для тебя:

Во время работы на проекте ты не сможешь применить многое из того, чему учился. Можно продолжать эту порочную практику Stackoverflow-разработки и на проекте, но об этом мы уже говорили

Ожидаемое поведение:

Ты ставишь своей целью будущее применение того, что изучается. Имея эту цель, можно сознательно что-то пропустить, а в чем-то по-настоящему разобраться. Если есть сомнения, можно занести шоколадку ментору и попросить прокомментировать ваши идеи. Все настройки, весь код до последней переменной лучше написать самому или изучить возможности IDE, которые это сделают за тебя. Т.е., как бы не тривиально это звучало, нужно понимать свои инструменты. Заметь, не написать код Spring Boot-приложения на листочке, а понимать, что и как работает
1.Тебе нужно протестировать твой код и добиться желаемого покрытия. У тебя есть объект с данными, в котором 10 полей. Ты хочешь быстрее сделать задачу и проверяешь, что только первое поле имеет верное значение 2. Ты исправляешь баг или делаешь доработку. Прогоняешь тесты и видишь, что тест, связанный с твоим функционалом, упал. Ты удаляешь или отключаешь этот тест, либо убираешь из него те проверки, которые не проходят. После 1 или 2 ты делаешь реквест, его мержат, возможно, по невнимательности, или потому что не захотели или нет времени вникать в проблемы твоей задачи, и изменения попадают в репозиторий.

Чем это хорошо для тебя:

Ты быстрее сделал задачу и перевел ее в следующий статус (на тестирование и раскатывание на стенды)

Чем это плохо для тебя:

Ты не гарантировал правильность твоего кода . В нем может быть ошибка, о которой команда узнает намного позже, чем должна была бы узнать. Хорошо, если ее найдут тестировщики. Плохо, если ее найдут на проде Ты осознанно сломал функционал, не разобравшись в причинах, что проверял тот тест, который ты “исправил”

Ожидаемое поведение:

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

Чем это хорошо для тебя:

Ты сделал свою задачу быстро и без заморочек

Чем это плохо для тебя:

Через какое-то время проблемы в этом классе проявятся. Будут баги (1) или туда сложно будет вносить изменения (2). Ты боишься менять чужой код или не уверен в своих знаниях/ощущениях.

Ожидаемое поведение:

Ты подсвечиваешь проблему старшим разработчикам/своим коллегам. Это можно сделать и на статусе, чтобы донести до всей команды + ты расскажешь, что ты занимался активной деятельностью и тебе не все равно. Рефакторить код в одном классе можно и без особого разрешения, но это лучше обсудить и прикинуть варианты. Помни о правиле бойскаута - “Всегда оставляйте код чище, чем вы его застали”. (Но при этом нельзя скатываться в массовый рефакторинг многих файлов)
На статусе ты хочешь показаться особо продуктивным и говоришь, что “сегодня к концу дня, максимум завтра я закончу свою задачу”. Проблема в том, что ты так говоришь уже 2-3 дня

Чем это хорошо для тебя:

Ты себя успокаиваешь

Чем это плохо для тебя:

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

Ожидаемое поведение:

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

Диалектические примеры

Ситуация	Неправильно	Правильно
Есть вопрос	Бежать за ответом к лиду немедленно	Сидеть и пытаться его решить самостоятельно, несмотря на потраченное время. Разумно потратить полчаса-час. Если вопрос не сдвигается с места, идти с вопросом. Если все понятно, но есть варианты ответа на вопросы, то спросить лида предоставив свои варианты ответа
Нужно написать кусочек бизнес-логики	1. Искать место, откуда бы скопипастить похожий кусочек, чтобы адаптировать под свою задачу 2. Найти дебагером куда следует внести код. Поправить методы так, чтобы все заработало.	Есть два подхода 1.1. Сперва подумать, потом сделать Покрутить задачу в голове, сделать описание на бумажке. Задать вопросы до написания кода 1.2. Сделать Proof of Concept (PoC, прототип) - заговнякать первую версию как придет в голову с первого раза. А потом - улучшать Закодить первый вариант, прототип. Причесать, улучшить, сделать работающий промышленный код за пару итераций - написать тесты, правильно скомпоновать классы, методы. Грамотно назвать переменные Общая рекомендация - по возможности комбинировать подходы 1.1 и 1.2 или разумно выбирать что сделать в конкретной ситуации. Почему бы не спросить совета? 2. Понять устройство кода, реализующего бизнес-логику. Найти классы, методы, которые должны быть изменены. Пересмотреть контракты классов, методов так, чтобы они соответствовали SOLID и изначальной задумке разделения кода на классы/методы/интерфейсы/пакеты... Только потом вносить правку на уровне исходного кода. Если возникают сложности, можно согласовать с лидом или коллегами изменения на уровне сигнатур до написания кода. Не бойся спрашивать. Не бойся ошибиться - всегда можно исправить\|
Лид указал на ошибку в коде	Исправить ошибку	Понять, почему это ошибка. Понять как не допускать эту ошибку в будущем. Исправить ошибку. Сказать спасибо =)
Лид рассказал как сделать задачу	Садиться писать задачу в IDE	Разобрать рекомендацию лида. Погуглить ключевые технологии, идеи, подходы, понять логику этого решения. Еще раз прикинуть решение в голове или на бумажке. Для того, чтобы не потратить слишком много времени, завести таймер на полчаса-час или иной разумный промежуток времени Когда все вопросы загуглены или отвечены, садись за код Аналогично, разумно сделать первую версию как получится, максимально быстро для проверки работоспособности подхода, идеи. Далее уже можно взять время все причесать, оформить, переписать более правильно и оптимально, продумать структуру классов и методов, продумать и задокументировать интерфейсы, написать тесты - поставить свое клеймо качества
Задача сделана, но на глаза попался явный косяк	Оставить все как есть. Мой код отлит в граните	Все переделать до идеального состояния. Посоветоваться с лидом. По возможности переделать хорошо. Задача D1 - учиться и работать раз от раза более эффективно - получать качественный код за меньшее количество времени. В этом смысле исправить свой код - отличная возможность поучиться.Опять же не надо забывать о сроках и давлению со стороны бизнеса. Иногда явный косяк может оказаться разумным компромиссом и будет достаточно завести задачу в Jira на уменьшение техдолга, а то и написать TODO в коде
Нужно изучить вопрос. Нагуглились материалы только на английском	Включить автоперевод страницы. Читать и догадываться об истинных замыслах автора. Особенно радоваться переводу исходного кода	Читать на английском. Если не получается, инвестировать в свои умения именно чтения на английском. Материалы на русском обычно хуже по качеству. Чем реже и новее технология, тем меньше информации не то что на русском, но и на английском. Разработчик обречен уметь читать на английском. Писать и говорить - следующий этап развития. Английским сам по себе не прокачается. Нужно инвестировать свое время, работать систематично и усердно. Смирись и действуй...