Джунам постоянно что-то советуют: учиться, задавать вопросы, разбираться в чужом коде (хотя бы в своем…), постоянно развиваться. В это время junior: когда уже просто получать зарплату, которую обещали на курсе?
Предлагаю альтернативный путь: никакого развития через дискомфорт, признания ошибок и прочих плюшек найма! Только уверенность в себе и шесть простых правил, которые помогут надолго сохранить статус начинающего специалиста.
Самообразование зло!
Всё уже есть в интернете. Документация, статьи, примеры, готовые решения. Нет смысла всё это запоминать, да и опыт не нужен, просто открой и посмотри. (ИИ: псс, теперь всё в одном чате).
Не нужно понимать, как работают transactions, почему возникает data race (что то из “Форсажа”) и что именно происходит при выполнении запроса (это магия). Особенно избегай базовых знаний, они подозрительно долго изучаются и не всегда попадают в резюме. Другое дело - посмотреть ролик “ты уже знаешь программирование”.
При этом обязательно сохраняй полезные материалы, создай список: “прочитать потом” - как на YouTube! Главное, не забывать обновлять.
Ничего не спрашивай!
Любой вопрос показывает, что ты чего-то не знаешь. А начинающий разработчик, который чего-то не знает - это же аномалия!
Не понял задачу? Сделай как понял.
Нашел противоречие в требованиях? Выбери вариант, который проще реализовать.
Не разобрался в бизнес-логике? Додумай!
Главное - никому ничего не говорить: пусть команда до последнего наслаждается твоей самостоятельностью.
Если застрял, тоже молчи. Да, коллега мог бы объяснить всё за десять минут, но тогда он узнает о пробеле в знаниях, а это недопустимо! Гораздо продуктивнее для компании и карьеры потратить неделю и показать результат, который придется переделывать полностью.
Нейронка напишет все за тебя!
Наконец-то появилась возможность заниматься разработкой, не отвлекаясь на мелочи вроде кода.
Твоя задача после получения ТЗ - передать условие агенту и “написать код”. Читать необязательно: ты же не знаешь, как работает сенсорный экран смартфона, хотя именно ты и пытаешься собрать этот экран… но это мелочи, продукт несомненно будет конкурентным.
Если решение выглядит сложным, значит оно профессиональное. Шесть новых интерфейсов, три обертки и универсальная фабрика ради одного запроса - отличный результат. И это чувство: “Я написал код как Senior”! Больше абстракций - качественнее код!
Пришли правки? Ты знаешь, что делать! ИИ - запрос - результат! Не помогло? Повторил!
Подстраиваться под компанию унизительно!
Ты пришёл в команду со своей индивидуальностью, ты личность, ты смог пробиться через заслон HR и по-своему уже победитель. Поэтому любые предложения учитывать существующие процессы нужно воспринимать максимально настороженно.
Просят соблюдать принятый стиль кода? Подавляют творческую свободу.
Просят предупреждать о задержке? Микроменеджмент.
Объясняют, почему решение не подходит проекту? Обесценивают.
Предлагают сначала разобраться в текущей архитектуре, а уже потом её переписывать? Боятся свежего взгляда.
Не допускай мысли, что у коллег могут быть причины работать именно так. Всё, чего ты пока не понимаешь, называй устаревшим подходом.
Главное не забудь: порекомендовать переписать весь легаси код на современную и очень популярную архитектуру/либку/фреймворк.
При первом конфликте уходи, ведь твоя задача - эксплуатировать бизнес!
Обсуждать разногласия долго, а объявить команду несовременной можно сразу. На следующем месте скажешь, что искал выстроенные процессы. Если история повторится, значит, процессы опять выстроили не верно.
И обязательно называй всё это защитой личных границ - это важно.
Будь одиночкой!
Коллеги, руководители, лид - это всё шум!
Помни:
Не участвуй в обсуждениях решений.
Не интересуйся, почему коллега выбрал именно такой подход.
Не смотри, как более опытный разработчик ищет ошибку.
Советы воспринимай как попытку продемонстрировать превосходство.
Когда тебе объясняют, как сделать проще, обязательно докажи, что твой вариант тоже имеет право на существование. Даже если для доказательства потребуется больше времени, чем для исправления.
Главное - не дать чужому опыту случайно нарушить твой вектор развития. На каждые грабли надо наступить публично - это уникальный профессиональный опыт, который покажет, что ты можешь!
Отдавай код без проверки!
“Написал код” - значит, закончил задачу. Всё остальное относится к следующим ”командным игрокам”.
Для поиска ошибок есть ревью. Для проверки поведения - тестировщик. Для обнаружения того, что никто не проверил - пользователи. Идеально…
Не запускай даже основной сценарий. Ты же только что написал код и прекрасно представляешь, как он должен работать. Проверять - это усомниться в своих силах, а это недопустимо!
Пустые значения, повторные запросы, отсутствие нужной записи - это мелочи. Если бы требовалась валидация, её бы указали в ТЗ. На нормальных данных код, вероятно, работает, осталось объяснить пользователям спецификацию.
Если тестировщика нет - проблема компании.
Если на ревью пропустили ошибку - проблема ревьюера.
Если задача отразилась на соседнем сервисе - значит, архитектура была недостаточно устойчивой. Псс… Не забудь предложить переписать легаси.
Статус “Готово” должен означать только одно: ты больше не собираешься этим заниматься.
Эпилог. Уже не до шуток...
У всех этих советов общий смысл: найти объяснение, почему за результат должен отвечать кто-то другой.
Знания - интернет
Понимание задачи - постановщик
Код - нейронка
Ошибки - ревьюер.
Себе остается только чувство выполненного долга, код ведь отдал.
Проблема не в том, что junior мало знает. Он и не обязан приходить с опытом человека, который имеет десятилетний опыт. Проблема начинается, когда человек не знает, не пытается разобраться и не считает это своей задачей.
Самообразование при этом не означает обязанность отдавать работе все вечера. Самостоятельность не запрещает обращаться за помощью. Нейронками можно пользоваться, но осознанно. А умение работать в команде не требует терпеть хамство, неоплачиваемые переработки и нарушение договоренностей.
От начинающего разработчика разумно ждать не полных знаний, а вовлеченности: попробовал разобраться, обозначил спорные моменты, задал вопросы, проверил решение, учёл обратную связь. Ошибся - понял почему и сделал выводы.
Несколько советов без инверсии:
Получить первую работу - победа, но не финальная.
Тебя взяли в команду - теперь приложи усилия, чтобы вырасти. Не изображай сеньора, уточни, каких результатов от тебя ждут по итогам испытательного срока: какие задачи нужно научиться решать, к кому обращаться за помощью, что будет считаться прогрессом. Не обещай знать всё. Показывай, что разбираешься и постепенно берёшь на себя больше.
Не бойся задавать вопросы и интересоваться технологиями.
Не понял ТЗ - уточни, что требуется до начала работы. Застрял в коде более чем на пару часов - спроси у коллеги. Проси помочь разобраться, а не выполнить задачу за тебя.
Не становись мостиком между ТЗ и нейронкой.
ИИ действительно заменит тебя, если не будешь понимать, что делаешь. Используй ИИ, но разбирайся в результате, валидируй код, консультируйся, т.е. ни в коем случае не отказывайся от инструмента - откажись от мысли, что нейроответ является твоим по умолчанию.
Самое лучшее решение для современного джуна - галера.
Рассматривай аутсорс и стажировки, пока ищешь работу, попытайся прорваться в галеру - только она будет действительно заинтересована в повышении грейда сотрудника, чем сам сотрудник. Но надо набраться терпения, галеры выматывают и могут привести к выгоранию. Но если ты молодой специалист - выгорание маловероятно, а вот провал реален.
Джун - это уровень опыта. "Я ни за что не отвечаю" - уже отношение к работе. И одно совсем не обязано сопровождать другое.