Я работал как единственный разработчик в компании, которая знала определенную технологию, как единственный, кто занимался тем типом программирования, который я делал, и как подрядчик в подобных ситуациях. (Я также работал в командной среде с другими разработчиками, которые знали разные инструменты, и с другими разработчиками, которые сделали именно то, что я сделал.)
Плюсы того, чтобы быть единственным программистом
- Как вы упомянули, у вас часто есть свобода использовать любые инструменты или языки, которые вы можете выучить. Вам не всегда нужно доводить дело до того, как ваши коллеги получат разрешение на работу с New Technology X, в то время как все остальные используют Current Technology Y.
- У тебя больше обязанностей. По сути, вы выполняете функции руководителя проекта и разработчика в каждом из ваших проектов, и, обладая способностью выявлять и внедрять новые вещи, вы также эффективно становитесь руководителем отдела. (Не говорите об этом продавцам. Они любят общаться с лицами, принимающими решения, а у вас нет времени с ними разговаривать.)
- Нет сомнений в том, что за выполненную работу нужно отдать должное: очевидно, что только вы и только вы сами сделали все возможное.
- Вы можете тратить больше времени на работу над собственными проектами и меньше времени на собраниях, посвященных проектам, которые в основном принадлежат кому-то другому (но вы работаете в качестве сотрудника службы поддержки, возможного резервного копирования или чего-то еще).
Cons
- Как отмечает Дэвид в комментарии, вы - единственный разработчик, поэтому никакая разработка не может быть сделана без вас. Однажды я хвастался своему брату, что я «парень» в конкретном проекте на работе. Он точно описал мою ситуацию для меня: я попал в ловушку. Я не мог двигаться дальше в этой компании, потому что я никогда не смогу избавиться от этого проекта. (Он тоже был прав. Потребовалось несколько месяцев тренировок в течение продолжительного периода времени, прежде чем я смог передать его кому-то, кто был хоть в какой-то мере способен его поддержать.) Вам может быть трудно взять настоящий отпуск, когда ничто не может быть сделано без тебя.
- Как отмечает Пьер, на сайте нет никого, кто мог бы делать обзоры кода или делиться с вами передовым опытом. Вы можете связаться со сверстниками по-разному, но ничто не так эффективно, как постучать коллегой по плечу и попросить ее взглянуть на ваш код в течение 5-10 минут.
- В том же духе вы можете испытать трудности при получении новых инструментов. Выездное обучение может быть таким же редким, как и отпуск: кто-то будет жаловаться на то, что компания не может позволить себе не смотреть язык 3.0 в течение недели, когда некому поддерживать приложения Language 2.0.
- Карьерный рост может быть чрезвычайно сложным для управления. У вас может не быть позиции, к которой вы можете стремиться, даже изменение названия может быть затруднительным, а обзоры на конец года не имеют никакой системы отсчета, поэтому отличная работа может остаться в значительной степени незамеченной, если ни для кого другого Причина, по которой никто не понимает, что вы делаете.
Если вы решите переехать в компанию, в которой вы будете работать в команде программистов, я не думаю, что ваш сольный опыт, скорее всего, сильно повредит вам. Отсутствие у вас опыта работы с шаблонами проектирования не обязательно так важно, как ваша готовность изучать их. (Могут быть ситуации, когда вы проводите собеседование с кандидатом с аналогичным опытом, а также опытом в любых методах, которые использует компания, но это справедливо в основном для всех.)
В том же духе недостаток опыта в команде уравновешивается вашей способностью носить много шляп. Есть некоторые разработчики, которые являются хорошими командными игроками, но никогда не развивают способность управлять проектом; Вы уже показали, что вы можете сделать это.
Я бы порекомендовал, когда вы являетесь индивидуальным разработчиком, вам следует потратить некоторое время на чтение инструментов и методов, которые используют аналогичные разработчики, поэтому даже если вы не используете их самостоятельно, вы знаете, что они существуют, и вы можете обратиться к их во время интервью, даже если бы сказать: «Да, я немного читал об инфраструктурах MVC, но я сам не использовал их». Делайте все возможное, чтобы оставаться на связи с другими разработчиками: посещайте собрания местных групп пользователей, читайте и комментируйте блоги (или оставляйте свои собственные), старайтесь время от времени посещать семинары, смотреть вебинары и тому подобное. (Вы можете также рассмотреть такие сайты, как lynda.com, для внутреннего обучения: это не так хорошо, как недельная конференция где-то еще, но вы можете смотреть видео в свое время и не отправлять всех в режим паники, потому что вы из офиса.)