Помогает ли специальное техническое обслуживание карьере программиста? [закрыто]

52

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

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

Но, как я оцениваю свой текущий карьерный рост и смотрю на своих сверстников подрядчики и корпоративные разработчики; Я чувствую, как будто я сильно отстаю, так как я приобрел большую широту в плане областей, к которым я прикоснулся, но не так много глубины. Я начал заниматься этим, начав блог, работая над своими собственными маленькими проектами git-hub и планируя свою жизнь так, чтобы у меня было время заниматься личным кодированием после работы на регулярной основе.

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

Но это приводит меня к моим основным вопросам, извинениям, если это кажется слишком сосредоточенным на моей личной дилемме:

В конечном итоге роли в области технического обслуживания оказываются вредными для ранней карьеры? Правильно ли другие программисты избегать подобных ролей? Занимается ли выполнение этой линии работы подобными заданиями, если вы не готовы начать все сначала?

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

Ответы:

70

В конечном итоге роли в области технического обслуживания оказываются вредными для ранней карьеры? Правильно ли другие программисты избегать подобных ролей? Занимается ли выполнение этой линии работы подобными заданиями, если вы не готовы начать все сначала?

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

Во-вторых, если я нанимаю кого-то с опытом работы от 2 до 4 лет, мне все равно, была ли его работа чисто обслуживающей. Если вы потратили 10 лет на техобслуживание, а я нанимаю проект «с нуля», у меня могут возникнуть вопросы, но в первые несколько лет я, честно говоря, ожидал этого.

С другой стороны, если я найму кого-то, кто НИКОГДА не работал в обслуживании, я буду более подозрительным. У меня было много кандидатов на рабочие места, которые в течение первых четырех лет переходили с одной «хорошей» работы на другую, и каждый из них ничего не узнал о том, что делает для поддерживаемого кода. И, не заблуждайтесь, если я нанимаю проект «зеленых полей», который собираюсь придерживаться, мне все равно, собираетесь ли вы поддерживать код, мне важно, чтобы вы знали, как оставить его обслуживаемым для будущих разработчиков.

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

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

Итак, чтобы прорезать все это и ответить на ваш вопрос: нет, я не думаю, что это будет мешать вашей карьере. Если вы не останетесь там слишком долго. Общее эмпирическое правило гласит: «Как только вы начинаете чувствовать, что каждый год получаете один и тот же опыт, пора уходить». Если вы чувствуете, каждый год, что вы лучший разработчик, чем в прошлом году, у вас все в порядке (и это касается меня, 20 лет моей карьеры, столько же, сколько и вас).

прецизионный самописец
источник
25
+1 Ведение делает кого-то лучше развития.
8
+1 Выполнение технического обслуживания по собственному или чужому проекту заставляет вас ценить и учиться на последствиях решений, которые были приняты ранее в рамках проекта.
Офидиан
Хотя опыт работы с техническим обслуживанием идеален, мое мнение таково, что вы узнаете, разрабатывая успешный проект,> что вы можете узнать, поддерживая чужой проект. Техническое обслуживание может научить вас, что не следует делать, но, как лучше всего сказал Джейсон Фрид: учиться на ошибках может сказать вам, что не следует делать в следующий раз, но это не говорит вам, что делать в следующий раз .
Корей Хинтон
@KoreyHinton: Я уверен, что Джейсон Фрид, успешный предприниматель, верит в то, что он говорит, с точки зрения предпринимателя. Я бы сказал, что а) он на самом деле не знает, что он может делать лучше, потому что для него все шло очень хорошо, б) поддержка DHH и Rails была 90% успеха 37signals, и это азартная игра, которая не окупится в 90% случаев, и в) даже Джейсон, вероятно, не станет утверждать, что совет о том, чтобы быть предпринимателем, обязательно означает обучение от необходимости собирать плохо написанное программное обеспечение.
фунтовые
@pdr Вы правы, две вещи точно не переводятся. Поскольку я все еще студент, я говорил с мнением, а не опытом. Я думаю, лично я предпочитаю писать новый код, а не поддерживать код, написанный другими, но похоже, что обслуживание - это то, чем я буду заниматься в этой области.
Корей Хинтон
13

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

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

Впрочем, я бы не слишком волновался. Одна вещь, которую вы говорите:

Я приобрел большую широту в плане областей, к которым я прикоснулся, но не так много.

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

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

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


источник
+1 По большому опыту . Пройдя 15 лет разработки и последний год обслуживания, я могу по собственному опыту сказать, что я затронул гораздо больше языков и платформ, чем оставался бы в процессе разработки. Будучи фрилансером, широкая широта (универсальность) дает мне утешительное чувство, что я вряд ли скоро уйду с работы. Возможно, это за счет возможности заработать больше денег при специализации (специалист), но я бы предпочел снизить риск.
Ливен Керсмакерс
2

В конечном итоге роли в области технического обслуживания оказываются вредными для ранней карьеры?

Чаще всего - ДА, предполагая:

  • эта карьера здесь означает опыт в различных технических навыках.
  • что вы проводите больше X лет там, где X достаточно, чтобы «установить» ваши способы мышления.
  • что ты ничего не делаешь в стороне.
  • «выделенный сопровождающий» (см. «РЕДАКТИРОВАТЬ» ниже) означает, что вы не пишете код для сопровождения, а кодируете новые вещи, но вы почти всегда пишете код для сопровождения или даже работаете над проектом в режиме сопровождения - никаких новых функций, по крайней мере, не требуется изменения в коде, чтобы исправить ошибку.

Это не значит, что это всегда так.

Людям, обслуживающим программное обеспечение, редко рекомендуется (см. РЕДАКТИРОВАТЬ ниже) проводить исследования, редко можно подключить новую библиотеку или БД и потратить несколько дней, чтобы выяснить, как оно работает. Это (обычно) стабильная работа, которая требует минимальных изменений в существующей кодовой базе и, таким образом, "формирует" способ, которым вы подходите к проблемам позже. Я могу назвать несколько компаний, которые придерживаются политики поддержки программного обеспечения, в которой прямо говорится: «меньше изменений в коде - лучше», несмотря на то, что это может принести неприятности.

Правильно ли другие программисты избегать подобных ролей?

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

Занимается ли выполнение этой линии работы подобными заданиями, если вы не готовы начать все сначала?

Чаще всего - ДА. Потому что у вас уже есть опыт в этом деле, потому что вы уже «знаете верёвки» и т. Д. Но смена определенно возможна и может произойти без подачи заявки на младшую должность. Вы уже начали делать вещи в стороне, продолжайте в том же духе! Это на самом деле очень полезно и может уменьшить «пробел в навыках», который вы заметили.


РЕДАКТИРОВАТЬ: Дэн указал (очень правильно), что задачи обслуживания часто могут быть выполнены с исследованиями. Это правда. Я изменил ответ выше в двух местах, чтобы лучше решить эту проблему.

Такие задачи наверняка МОГУТ быть выполнены таким образом, и если они есть - отлично! Тем не менее, AFAIK большинство преданных сопровождающих систем LEGACY имеют политики или ожидания и сроки управления, которые - опять же, чаще всего, - вынуждают их решать проблему с наименьшими возможными изменениями. Часто давление достаточно высокое, поэтому, даже если вы можете сделать это таким образом, вы можете не захотеть. Особенно, если это не ВАШ код: без теории (согласно Райлу и Науру) вы рискуете повредить больше, чем исправите.

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

LAFK говорит восстановить Монику
источник
@ dan1111, какие части нет? Несмотря на то, что это дубликат, я с удовольствием сделаю свой ответ лучше.
LAFK говорит восстановить Монику
Спасибо Дэн. Я несколько расширю свой ответ, чтобы выделить те части, которые, по моему мнению, содержат ответ на ваш комментарий.
LAFK говорит восстановить Монику
+1 за дополнительную работу над ответом. В частности, объяснение степени вашего собственного опыта полезно для установления достоверности ответа.
«Люди, обслуживающие программное обеспечение ... редко могут подключить новую библиотеку или БД и потратить несколько дней, чтобы узнать, как оно работает». Это не совсем мой опыт. Программисты по обслуживанию должны хорошо разбираться в чем-то незнакомом и быстро понимать его суть (будь то программа или библиотека). По крайней мере, это так, если вы поддерживаете разные вещи; если вы поддерживаете одно и то же постоянно, годами, то негативы, которые приходят с вами, не вызваны «обслуживанием», а вызваны слишком долгой работой над одной и той же вещью (независимо от того, где она находится жизненный цикл).
user1172763
Привет @ user1172763. Я должен сказать, ваше определение обслуживания довольно необычно. Я полагаю, что часть, которую я добавил для Дэна, касается более интересных случаев обслуживания, таких как ваш. Однако я не верю, что это стандартное обслуживание. Просто чтобы проверить - причина отрицательного голосования в том, что ваш опыт не соответствует моему ответу? Затем, пожалуйста, укажите ваши источники, как я уже говорил, чтобы другие могли читать и решать.
LAFK говорит восстановить Монику
1

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

Верный. Вы не могли бы сказать , «3 - летний опыт проектирования систем с нуля , используя X, Y и Z», вы должны сказать «3 -х лет опыт ПОДДЕРЖАНИЕ системы с нуля , используя X, Y и Z» , если вы не хотите прямо лежат на вашем резюме.

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

Если вы хотите сказать: «Я проектирую и строю системы с нуля», тогда да, вы должны были бы классифицировать себя как младшего.

Что характерно для ИТ (и я не говорю, что это то, что вы делаете), так это чтобы люди полагали, что, поскольку они работают в течение X лет, у них есть опыт X лет, и после {неопределенного количества лет} они должен считаться старшим разработчиком {Widget}.

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

В идеале вам нужно сочетание «новой» системной работы и устаревшей работы.

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

Удачи!

Ozz
источник
0

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

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

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

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

Коста Контос
источник