Комментарии 14
А если я джуниор (Чуть больше года как работаю разработчиком), который пришел на средний по размеру проект, без документации, путем мучений разобрался в проекте, дописал много нового функционала, интегрировал несколько сервисов со стороними сервисами, сам веду переговоры с заказчиками, куда себя относить? Я вроде как и не джуниор уже но и миддл разработчиком назвать себя язык не поворачивается, потому что декомпозировать проект на мелкие задачи я умею, но вот понимаю что мой код и мои решения хоть и работают но оставляют желать лучшего. При этом я уже не боюсь старых и неизвестных ппоектов, я наоборот радуюсь когда решение задачи неизвестно, но не оставляет чувство что я какой то неполноценный разработчик. Извините если оффтоп
Важно понимать, что линейка junior-middle-senior — очень относительная. Часто она имеет смысл только в рамках одной компании (да и то не всегда). Лучше всего этот вопрос задать напрямую Вашему лиду/менеджеру. Скорее всего у него свой взгляд на эту градацию и он должен его объяснить.
Касательно недовольства качеством своей работы — это нормально. Было бы гораздо хуже если бы этого не было. Почитайте про синдром самозванца. Важно научиться оценивать свои ошибки, как-то их измерять следить за прогрессом. В этом Вам как раз тоже должен помочь Ваш лид/ментор.
Касательно недовольства качеством своей работы — это нормально. Было бы гораздо хуже если бы этого не было. Почитайте про синдром самозванца. Важно научиться оценивать свои ошибки, как-то их измерять следить за прогрессом. В этом Вам как раз тоже должен помочь Ваш лид/ментор.
В том то и дело, что нет никакого лида, есть менеджер который просто передает задания от руководства и все. Я единственный разработчик на проекте, я вижу лишь одно решение на данный момент, найти хорошую компанию где есть полноценная команда разработчиков и учится у них, а то на своем проекте да я уже как рыба в воде, но вот переживаю что перейдя на другой все будет уже не так радужно.
Если у вас единственный разработчик на проекте это вы, то есть джуниор с опытом работы около года, то мой вам совет — если можете, то ищите другую работу.
То есть я как бы не знаю что у вас там за проект, но если фирма сваливает целый проект на джуна, да ещё и даёт ему общаться с заказчиками и принимать решения какие сторонние сервисы интегрировать… В общем как-то попахивает всё это на мой взгляд.
Ну и опять же если всё как вы описываете, тo на мой взгляд на нормальную фирму вас спокойно миддлом возьмут. То есть возьмут может и джуниором, но если так будете и там работать, то скоро станете миддлом. А потом относительно быстро и сениором. Моё мнение.
То есть я как бы не знаю что у вас там за проект, но если фирма сваливает целый проект на джуна, да ещё и даёт ему общаться с заказчиками и принимать решения какие сторонние сервисы интегрировать… В общем как-то попахивает всё это на мой взгляд.
Ну и опять же если всё как вы описываете, тo на мой взгляд на нормальную фирму вас спокойно миддлом возьмут. То есть возьмут может и джуниором, но если так будете и там работать, то скоро станете миддлом. А потом относительно быстро и сениором. Моё мнение.
Соглашусь с Kanut. Если Вы там один и технический рост Вас заботит больше чем номинальная должность, то лучше поискать более подходящее место.
Ну так вы лид команды разработки. Или даже почти CTO. Оцените шансы увеличения команды в принципе (растёт ли список задач, отпускают ли вас в отпуск и т. п.) и свои шансы занять место её дид
Legacy проект это в первую очередь, по моему опыту, это очень много баг фикса. Причём баг фикса преимущественно без рефакторинга, потому что как раз на него бизнес не очень хочет выделять время (тема отдельных долгих обсуждений). Отсюда вытекает, как Вы написали, много анализа кода — это действительно присутствует. Среди советов можно добавить: 1) фикс бага только с добавлением теста на данный сценарий (исключение тест добавить невозможно или очень дорого) 2) ведение базы знаний по решенным проблемам: что случилось? почему? как решили? что сделали чтобы снизить вероятность повторения?
Зависит от того, в какой фазе жизненного цикла находится продукт. Если планируется активное развитие с новым фичами — будет и новый код, и рефакторинг, и бюджет времени на это.
Если нужна поддержка без особого развития по фичам — то бизнес заинтересован снизить общую стоимость и риски. Отсюда общий подход «работает — не трогай» с понятными следствиями
Если нужна поддержка без особого развития по фичам — то бизнес заинтересован снизить общую стоимость и риски. Отсюда общий подход «работает — не трогай» с понятными следствиями
Часто слышу "легаси" как синоним "устаревший", но для меня "легаси" это, прежде всего, код непонятно как и что делающий. Вплоть до того, что люди, которые его писали вот они, но в лучшем случае не помнят.
читать книги — это здорово, но на практике опыт наработанный командой иногда значительно больше чем то, что в книгах… практика всегда отличается от теории…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какие навыки можно прокачать на проекте c большой кодовой базой