Получил работу по разработке программного обеспечения, которая с точки зрения эксплуатации представляет собой беспорядок и не имеет большого потенциала для карьерного роста. Что я могу извлечь из этого?

1

Ведущий разработчик (не мой начальник) открыто считает, что отсутствие документации — это гарантия занятости. В результате ничего не записывается.

2

Менеджер (мой начальник, технический специалист) кажется немотивированным и незаинтересованным в работе. Каждую пятницу он берет выходной, а остальное время проводит в своем офисе. Когда я спросил, должен ли я что-то делать, он обещает вернуться ко мне и не отвечает. В результате мне часто нечем заняться, кроме курсов Udemy.

Да, вы делаете. См. 1 )

Если больше никто не будет документировать, то можно/нужно.

3

Мы используем Agile/Scrum, который, по-видимому, дает разработчикам одно предложение для работы в спринтах.

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

Вам предстоит принять важное решение . У вас есть варианты: «отшлифовать свое резюме и начать искать» или остаться, смириться и попытаться что-то изменить.

Всего за 6 недель вы могли бы просто уйти и даже не упомянуть работу в своем резюме.

Или , вы можете остаться и попытаться сделать это. Если вы останетесь, вы, вероятно, не получите большой помощи (от ведущего разработчика или его босса); большой вопрос в том, встретите ли вы препятствия. Если вы ожидаете, что вы это сделаете, указан карьерный шаг.

Вы можете начать документировать вещи. Запустите код через DoxyGen, если он поддерживает ваш язык, или поищите что-то подобное. Запустите вики. Когда вы поймете, что делает какой-то код, добавьте комментарии. Добавьте модульные тесты, если можете.

Подойдите к товарищам по команде. Похоже, они сдались. Спросите их, не хотят ли они внести свой вклад в вики. Может быть, кто-то уже пробовал и встретил сопротивление — они узнают, и это может помочь вам принять решение.

4

Ведущий разработчик (а не мой начальник) открыто считает, что отсутствие документации является формой гарантии занятости.

Почитайте про автобусный фактор . Возможно, сказать об этом боссу/PM? Если ведущий разработчик пройдет под автобусом/женится и уедет/уедет, чтобы заботиться о родственнике/и т. д., что произойдет? Я видел это, и это некрасиво. В самом деле, если он так незаменим, что происходит, когда он берет отпуск?

5

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

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

Это не то , как вы хотите провести следующие 40 или 50 лет. Если вы выдержите это за двоих, сможете ли вы потом найти работу в другом месте?

Tl;dr - меняй или убирайся. Отношение ваших товарищей по команде должно быть индикатором. Отношение вашего начальника и PM - это уже показатель.

Начните искать работу прямо сейчас.

Я был в похожей ситуации на своей первой ИТ-работе после окончания университета.

Там, где с самого начала было очевидно, что это не очень хорошая работа, я убедил себя «по крайней мере, остаться на год, потому что было бы нехорошо уйти раньше».

Проблема с таким мышлением заключается в том, что:

1. Поиск новой работы может занять больше времени, чем вы думаете.
2. Вы можете уйти сейчас, пока у вас есть этот "новый запах выпускника". В моем случае через год, когда я начал искать новую работу - у меня теперь был годовой опыт работы с малоизвестной техникой. Иметь годовой опыт работы с неактуальной технологией, вероятно, сложнее, чем быть новичком без опыта. Если вы беспокоитесь об ответе «почему вы уходите с работы» — не волнуйтесь слишком сильно, фраза «я хочу работать где-нибудь с хорошей практикой» будет привлекательна для людей, у которых есть хорошая практика.
3. Есть альтернативная стоимость того, что вы могли бы узнать в противном случае. Если бы вы работали в другом месте, вы могли бы получить гораздо лучшие навыки.
4. Работа в месте с плохой практикой может плохо сказаться на вашем психическом состоянии. Если вы работаете с недокументированным кодом, это разочаровывает, вызывает стресс и может привести к выгоранию.

Ищите другую работу. Пока вы не найдете человека с юридически обязывающим предложением о работе, вы остаетесь на месте, потому что это кладет деньги в ваш карман.

Параллельно можно попробовать улучшить вещи у себя дома. Даже если это ни к чему не приведет, это хороший опыт обучения. Запишите, что происходит, почему это неправильно и каковы риски для компании.

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

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

Самые большие затраты возникают из-за того, что лид ведет дела совершенно неэффективно. Если у джуниора есть вопросы, вы не забираете их работу как лид и делаете сами (если лид дал работу джуну, то это работа, которую лид никогда не должен трогать), вы помогаете им преодолеть проблему, если это что-то, что нужно задокументировать, скажите им, чтобы задокументировать это, а затем вы позволите им заняться этим.

Кажется, у вас есть один PM (и все знают, что он мало что делает), один лид (но никто не знает, что он делает) и три разработчика, которые не делают никакой полезной разработки. Это не ваша вина, очевидно, но вы можете попытаться сделать все возможное, чтобы изменить это.

PS Я вижу, как откроется вакансия ведущего разработчика, как только ваше руководство проснется. По общему признанию, вы должны быть очень хороши, чтобы получить это.

PS. Замена тимлида означала бы, что у компании внезапно появится один эффективный тимлид и три эффективных и мотивированных младших разработчика. Они могут многого добиться.

Каков наилучший способ иметь сильную рыночную стоимость, чтобы подскочить от 8 месяцев до одного года?

Учитывая информацию, ваш лучший результат — хороший справочник и все, что вам удастся обучить себя. Оба из которых являются довольно ценными активами.

Не ожидайте слишком многого, когда впервые присоединяетесь к рабочей силе.

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

Ни одна компания, в которой вы будете работать, не будет делать все правильно, а тем более правильно для вас. Стартапы работают быстро и ломают вещи, крупные устоявшиеся компании тонут в процессах и бумажной волоките. Не поймите меня неправильно, ваша текущая ситуация звучит довольно плохо, но, не видя ее, я не знаю, насколько это плохо и насколько эффект «новой работы», когда все либо прекрасно, либо пожар в мусорном баке.

Здесь нет правильного или неправильного. Вы можете остаться и научиться выживать в неблагополучной компании и даже улучшать ее (например, документируя, как говорили некоторые люди). Вы можете уйти, чтобы попытаться найти компанию получше, но трава всегда будет зеленее в другом месте. В любом случае вы станете сильнее и с большим опытом работы в реальной компании, даже в самой неблагополучной.

Вы должны уйти.

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

Если вы хотели уйти на грустной ноте и, по крайней мере, вызвать изменения, уйдя, вы могли подать уведомление и поговорить с руководством, объяснив им, почему внутренние методы разработки напрямую вредят бизнесу. Однако я бы не советовал этого делать, хотя сам так делал в свое время. Этому есть две причины:

1. Такие предприятия не меняются. Они продолжают как-то наскребли деньги или разоряются, обычно есть один человек, который является своего рода сердцевиной всего этого, и если он когда-либо уходил, компания разваливалась. В любом случае, к вашим словам, скорее всего, никогда не прислушаются, так что, по сути, все, что вы, вероятно, создадите, — это временные раздоры.
2. Кроме того, я смотрю на это с вашей точки зрения. У вас нет никакой выгоды ни от попытки помочь компании, когда вы уходите, ни от того, что вы пытаетесь разорвать ей новую, когда вы уходите, кроме, может быть, некоторого личного удовлетворения. В остальном просто никакой пользы. Скорее всего, вы сожжете мост, и какой бы совет вы ни придумали, он никогда не пригодится.

Я знаю, что это немного неудовлетворительно, но просто уходи. Будьте профессиональны, назовите профессиональную причину, по которой вы хотите уйти, а затем забудьте об этом проекте. В отличие от другого ответа, я не думаю, что ваша работа заключается в создании документации, если ваше руководство активно работает против этого, а руководству все равно. В конечном счете вы разработчик, а не руководитель проекта. Ваша работа заключается в создании кода. Если решения руководства и руководителя разработки катастрофичны, вы можете указать на это, но если они решат не прислушаться к вашему предупреждению, то здесь вы должны подвести черту. Особенно, если ваш лидер не хочет, чтобы вы документировали, я не понимаю, почему это вообще ваша работа. Это не.

Просто дополнение: лично я тоже буду продолжать там работать, пока вы не получите новый контракт. Не делайте проблемы этой компании своими проблемами.

Попросите запланировать встречу с вашим начальником по поводу обратной связи. Попросите его записать конкретное время, прежде чем вы покинете комнату, и если он этого не сделает, напишите ему несколько раз, пока он не назначит время (хотя, конечно, не спамьте его почтовый ящик).

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

Кроме того, попросите дать вашим Agile-задачам надлежащие критерии приемлемости, чтобы вы знали, что, черт возьми, вы должны делать. На данный момент Agile реализован только наполовину.