Я джуниор. Мне приходилось работать в команде (одной и той же) над разными проектами. Один из проектов обнищал, не смог больше кормить команду. И там теперь всего один разработчик. Всего один разработчик в проекте с непростой архитектурой, с C++, JavaScript, Node.js и Lua. И он джуниор. И он - я.
Возможно вы только числитесь джуном, а на деле уже мид.
Возможно этот проект нахрен никому не нужен, и чисто поддерживается абы как-то шевелился, ибо если бы проект был критичен, на него нашлись бы деньги и люди.
Все проекты, с которыми мы работали, это форки, или мы вообще подрядчики. То есть код не наш. Соответственно главная (по мне) проблема это изучить код. И от сеньора и лида здесь пользы не бывает. Потому что отвечают они на твои вопросы по коду не быстро, не всегда, и вообще не обязаны отвечать.
А изучать код сам я вполне могу и без сеньора и лида.
Так вы один или у вас есть сеньоры и лиды?
У лида должна быть команда, у него не может быть всего лишь один джун. Возможно все-таки вас несколько и у вас не проект, а конкретный один компонент?
Сами сеньор и лид почти не пишут кода. Стараются не писать. Если пишут, то якобы самое сложное. А потом в этом самом сложном надо что-то доработать и джуниору приходится это изучить. Проще тогда уж сразу самому писать. В итоге джуниор (а он единственный джуниор в проекте!) должен ориентироваться во всех частях проекта, да еще и изучать их на ходу, кидаясь то туда, то туда.
Без сеньора и лида я тоже должен знать всё, но нет левого чувака, который пишет новый код и приходится его тоже изучать.
Если все, что написали сеньор и лид вы могли бы сами сразу написать без консультации, то меняйте работы и ищите сразу позицию сеньора.
Теперь про стресс от просроченных сроков. Стрессоустойчивость это наверно такая штука, что сильный в этом уменьшает стресс в коллективе, а слабый увеличивает, добавляя еще и от себя. Так вот, сеньор и лид как только видят, что я не успеваю, ругают и даже увольняют меня (но потом берут обратно).
Если все происходит именно так, меняйте работу.
Без сеньора и лида я рискую сорвать лишь более-менее глобальный дедлайн. И тогда меня пошлет заказчик и придется умолять заказчика вернуться. Всего 1 раз! А сеньор и лид за это время раз 5 успели бы меня отругать.
Сеньор и лид это локальные ребята. Заказчик если пошлет, он просто наймет другую команду и никакие мольбы уже не вернуться. А деньги идут именно от заказчика, а не от сеньора, лида или джуна. Поэтому если заказчик удовлетворен - это самое-самое главное. На все остальное (качество кода, работоспособность продукта, наличие джунов/лидов/сеньоров) - плевать. Главное убедить заказчика что все хорошо, и чтобы он продолжал давать денег.
Теперь про качество кода. Джуниор с сеньором и лидом все время боится, ждет замечаний по качеству, ждет задержек из-за этого. При этом свои собственные задержки он не может оправдать шлифованием кода. Двойные стандарты. Им можно, а мне нет.
Стоит почитать про технологический долг. Отсутствие багов - это хорошо. Но если продукт продолжает разрабатываться и меняться, в вашем коде придется кому-то ковыряться и модернизировать. Если он написан не в соответствии со стандартами, его изменить будет гораздо сложнее, дольше и следовательно дороже.
Много-много велосипедов приводят к такому легаси, что переписать все с нуля выходит дешевле, чем его править. Возможно требуют не шлифовать а работать согласно стандартам, но пояснить это не могут.
А может и просто придираются. Никто ж не знает кроме вас.
Без сеньора и лида я так же делаю упор на сдачу в срок и на безбажность. На качество иногда подзабиваю. Зато всегда спокоен и уверен, что если что-то сдаю, то это навсегда. И соответствующим образом проверяю код на баги. Делаю саморевью, а от него куда больше пользы, чем от ревью сеньора и лида, которое ищет где поэстетствовать, а не где баг. Число багов после ухода команды резко упало.
Если навсегда, то почему в принципе вы еще пишете код? Разве он не должен был быть уже давным давно написан навсегда?
Баги могут быть технические и логические. Если вы хорошо знаете бизнес заказчика - это одно.
Число багов после ухода команды может упасть потому что разработка упала. Гораздо меньше багов, если никто ничего не пишет, это же Л - Логика.
Единственное, что стало хуже - это то, что в коде иногда стали появляться решения, которые откровенно были не оптимальны и тормозили. Ведь я не просто джуниор, но еще и имею некоторые проблемы с алгоритмами. Но я их откатывал и фиксил, и это не так часто. И тормоза все же не баги.
Есть требования к продукту. В требованиях могут быть указаны метрики для перфоманс тесты. Если программа тормозит больше, чем это указано в требованиях к разработке - это баг.
И вообще, почитайте про основы тестирования, чтобы четко понимать что такое баг (грубо говоря, баг это несоответствие документации или ТЗ, а не ошибки компиляции)
Сорри за много букв и у меня вопрос, это везде так или от сеньора и лида бывает и польза?
Все что вы написали выглядит очень странно.
Я не припоминаю ситуации, что если увольняют джуна то потом его просят вернуться. Это вообще нонсенс. Видимо у вас какой-то уникальный случай, и возможно имеет смысл либо недоверять вашим словам, либо приняв их за чистую монету посоветовать просто сменить работу.
Простой
Сложный
