Недавно ко мне обратилось местное рекламное агентство с возможностью трудоустройства. Они приносят всю веб / интерактивную разработку на себя и добавляют в свою команду разработчиков.
Меня тошнит от моей легкой, но скучной корпоративной работы, и я заинтригован этой позицией.
Работая только в магазинах программного обеспечения, где основной деятельностью было создание программного обеспечения, я беспокоюсь, что они могут не придавать значения качественным программным практикам, поскольку разработка не является целью их бизнеса.
Может ли кто-нибудь с опытом сравнивать / сопоставлять работу в компании-разработчике с работой в компании, в которой, как оказалось, есть собственная команда разработчиков или отдел разработки программного обеспечения?
источник
Ответы:
Это будет зависеть от компании. Но обычно, если это не их основное внимание, программное обеспечение будет иметь меньшее качество. Процесс, если они есть, будет менее строгим. Тестирование несуществующее. И работа в целом менее технически сложна.
Они захотят, чтобы это работало, и работало сейчас, и этого будет достаточно.
Но в некоторых местах дело доходит до разработки программного обеспечения, даже если они просто занимаются чем-то другим. Это зависит от того, насколько деловое руководство открыто для хороших идей, техническое руководство знает достаточно, чтобы сделать это правильно, и иметь людей, которые могут объяснить хорошую идею. Который может быть ты.
Интервью компании. Спросите их, знают ли они о тесте Джоэла. Большинство из них хорошие моменты. Посмотрите, понимают ли они технический долг и мифический человеко-месяц. Кто ваш менеджер проектов, каким процессом он пользуется и насколько он отвратителен?
источник
Там огромная разница. В первом случае вы являетесь частью центра прибыли. В последнем случае вы являетесь частью МВЗ. Угадайте, какой из них получает лучшее лечение?
Сейчас я работаю в софтверной компании, и я НАСТОЛЬКО намного счастливее, чем на своей прошлой работе, когда все это были временные увольнения и аутсорсинг, а разработчики считались легко заменяемыми виджетами (а не сердцем компании).
источник
Программисты все еще программисты. Тот факт, что основной продукт компании не является программным обеспечением, не означает, что программисту не нужны такие же удобства.
источник
Я работал в отделе ИТ крупных компаний, разрабатывая программное обеспечение для внутреннего использования; Я работал в компаниях, разрабатывающих программное обеспечение для рынка; и я работал в агентствах, занимающихся веб-разработкой для клиентов.
И я бы не сказал, что между этими разными компаниями есть какая-то разница с точки зрения важности повышения производительности.
Поддержание продуктивности программистов жизненно важно независимо от того, какую разработку делают эти программисты. И я бы сказал , что поддержание программистов счастливых и держать их работать для вас еще более важно , когда они являются программистами обслуживания в ИТ - отделе , не программное обеспечение компании.
источник
Разница во многом зависит от самой компании; Я работал в хороших компаниях, не занимающихся программным обеспечением, и в ужасных компаниях, выпускающих программное обеспечение. В среднем, вот что я нашел:
Компания без программного обеспечения
Акцент делается на том, чтобы все было сделано быстро, практически не задумываясь о качестве или долговременной ремонтопригодности. Разработчики, как правило, технически неосведомлены за пределами того, что они делали в прошлом или во время их работы в компании, и часто пытаясь внедрить новые концепции (ORM, принципы SOLID, TDD и т. Д.), Встречают путаницу или немедленное увольнение. Люди склонны больше фокусироваться на «буксировке линии компании».
Компания-разработчик
Акцент на том, чтобы делать вещи без ущерба для качества. Сотрудники с большей вероятностью идут в ногу с технологиями (независимо от того, могут ли они использовать их на работе) и часто смотрят, как они могут интегрировать новые идеи или структуры в повседневную рутину, чтобы улучшить программное обеспечение. Если они еще не знакомы и не используют такие понятия, как TDD, ORM, SOLID и т. Д., Они, вероятно, слышали об этом и более охотно их оценивают.
Опять же, это в конечном итоге зависит от компании. Я работал в непрограммной компании с чрезвычайно гибкой командой, которая охватывала TDD и ORM, и многому научил меня в правильной разработке программного обеспечения, и я работал в небольшой компании по разработке программного обеспечения, которая написала спагетти-код VBScript наихудшего типа и имеет более 50 разработчиков. что каждый должен был работать на разных страницах, чтобы избежать поломок, и тонны бюрократизма даже для незначительных изменений. Однако чем меньше компания внешне полагается на программное обеспечение, тем больше вероятность того, что среда будет очень плохой для разработки программного обеспечения.
источник
Я работал единственным разработчиком программного обеспечения на уровне людей, не занимающихся программным обеспечением, и я думаю, что в этом случае независимость еще важнее. Когда у вас нет десятков людей, использующих одни и те же инструменты, вам приходится принимать гораздо больше решений - какой язык вы будете использовать, какой компилятор, какие серверы и т. Д. Одиноким разработчикам требуется больше свободы для установки, оценки и администрирования программного обеспечения. это считается само собой разумеющимся в групповой обстановке.
источник
Одно различие наверняка будет меньше внимания на накладные расходы и redtape, которые вы должны пройти в корпоративном магазине программного обеспечения. Вы обнаружите, что сможете гораздо более детально контролировать все аспекты своих проектов.
Один профессионал в том, что это может быть освежающим ...
Лично для меня это оказалось ужасно, но это может быть потому, что я выбрал плохо. Один ОГРОМНЫЙ недостаток заключается в том, что вы больше не связаны с бизнесом, а вместо этого у вас административные накладные расходы. Бюджетные контролеры относились ко мне так, будто я лично брал деньги с их собственных кошельков, и продолжали, так сказать, «избивать меня, как арендованного мула». Для меня это было невыносимое и изнурительное испытание, поэтому вы должны внимательно искать признаки такого отношения во время интервью.
источник
Здесь уже есть несколько хороших ответов, но я просто хотел бы сослаться на стенограмму 2-й части доклада, который Джоэл Спольски дал в Йельском университете:
Джоэл Спольски - Talk At Yale Часть 2 из 3
Там он рассказывает о разнице между «штатными» программистами и программистами, которые работают в компаниях, занимающихся разработкой программного обеспечения.
Его три основных момента:
Когда вы программист, вы никогда не сможете делать все правильно. Вы всегда должны делать вещи целесообразным способом.
Как внутренний программист, если какое-то программное обеспечение «достаточно хорошо», вы перестаете над ним работать. Когда вы разрабатываете программные «продукты», вы делаете их красивыми.
Когда вы программист в компании-разработчике, работа, которую вы выполняете, напрямую связана с тем, как компания зарабатывает деньги. Это означает, с одной стороны, что руководство заботится о вас.
Лично я всю свою карьеру работал как в софтверных, так и в софтверных компаниях, и, хотя всегда есть исключения из каждого правила, я согласен с мнением Джоэла, поскольку подавляющее большинство компаний, похоже, согласны с ними.
источник
Одно из главных отличий заключается в том, что работая в магазине программного обеспечения, вы, вероятно, помогаете создавать рабочие места в компании. Работая в отделе программирования В целом, для компании другого типа это означает, что вы пишете программное обеспечение для замены людей. Это удручающая реальность, с которой приходится иметь дело. При этом рекламное агентство вполне может быть совершенно другим зверем. Думаю, это больше похоже на интернет-магазин в другой компании.
источник
По моим наблюдениям, есть как минимум два случая, когда мы придерживаемся границ софтверной компании в вопросах профессионального выживания .
Первый случай, если кто-то полностью занимается кодированием - дайте мне 80 ... 90 ... 100% времени на кодирование или я умру . В магазинах программного обеспечения это почти само собой разумеющееся, как будто все знают, как туда добраться, потому что, ну, все делают именно это. Но снаружи существует очень высокий риск не попасть туда. Можно получить всего лишь 50, 40, 30% (однажды моя личная нагрузка на кодирование упала до 20% - без шуток, я измерил в JIRA !) Это не потому, что «они» не хотят, чтобы вы кодировали - нет, они хотят, но , но ... они могут просто не знать как.
Второй «смертельный риск» - это если у кого-то возникают серьезные проблемы в общении Это может быть проблематично даже в магазинах программного обеспечения, верно, но, по крайней мере, есть хорошие шансы выжить и жить хорошей продуктивной жизнью, не нарушая взаимодействия. :) Однако в компаниях, не занимающихся разработкой программного обеспечения, такие шансы намного ниже - скорее наоборот, почти неизбежно, что в конечном итоге придется приложить немало усилий, чтобы научить кого-то из аутсайдеров основам ИТ, потому что в противном случае это будет невозможно сделать.
Ну, за исключением двух случаев, упомянутых выше, я не знаю другой веской причины строго привязываться к программным компаниям. Теперь, какую сторону предпочесть? насколько я могу судить, это больше зависит от вкуса, от того, какое удовольствие вас больше интересует.
Обе стороны предлагают свои собственные, отличные формы получения удовольствия. Это не легко описать.
Я бы сказал, что компании-разработчики более интересны тем, кто стремится к «высоким оценкам», в то время как сторонние компании дают острые ощущения тем, кто стремится к «большой разнице». Я думаю об этом , как это примерно (примечание числа ниже придуманы только для упрощения создания точки) ...
Обратите внимание на то, что шансы получить 500% прирост в компании-разработчике ничтожно малы по сравнению - и соответственно, шансы получить 100 функций ничтожно малы за пределами .
Высшие оценки с одной стороны расширяют наше понимание профессиональных ограничений, улучшая наши знания о том, как делать вещи лучше. Большая разница с другой стороны оказывает глубокое влияние на культуру компании, улучшая знания посторонних о том, как сделать это правильно.
Теперь, если у вас есть явное предпочтение тому или иному, вы знаете, какую сторону выбрать. Или, если вы нерешительны, просто смело качайтесь между ними, как хотите. :)
источник
Престижность затрат против ответа МВП.
Я был в обоих и очень предпочел бы компанию по разработке программного обеспечения. Поскольку ваша корреляция с прибылью более очевидна, у вас больше шансов получить надлежащую компенсацию, основанную на производительности, и общую корпоративную культуру, охватывающую личность разработчиков программного обеспечения. Зачастую это приводит к уменьшению офисной политики, докерам не требуется, очевидных карьерных путей и меньшего количества BS. Но если вам больше нравится стабильный 9-5, возможно, менее сложный, не ультрасовременный концерт, чем то, что иногда ИТ-корпорации лучше, не будучи циничным, я понимаю, что некоторым людям нравится более типичный баланс работы / жизни за счет другие вещи. По моему опыту, общее качество разработчика намного, намного лучше в компании-разработчике; в отличие от посредственности, которая часто пронизывает корпорацию ИТ. Я знаю, что есть исключения,
источник
ИТ является частью группы поддержки в компаниях, не занимающихся разработкой программного обеспечения. Программисты программного обеспечения разработали приложения, которые помогут компании значительно повысить производительность, ускорить выполнение транзакций, провести техническую поддержку и т. Д. вещи для их программистов, но многие нет, поэтому они использовали для аутсорсинга программистов в других компаниях.
источник
Я предпочел бы противопоставить работу в отделе ИБ работе в отделе разработки продуктов компании, которая продает программное обеспечение. Просто чтобы уточнить каждую сторону и дать некоторые из них, с некоторыми исправлениями форматирования:
Отдел информационных технологий
Компания может производить оборудование, программное обеспечение, автомобили или что-то еще, но ключом здесь является то, что существует внутренний отдел, который отвечает за системы, которые компания использует изо дня в день. Здесь могут быть такие структуры, как ITIL, которые могут попытаться привнести некоторую зрелость в процессы, которые отдел выполняет в рамках этого отдела, - это ребята из инфраструктуры, которые поддерживают свет, а другая часть - это ребята из разработчиков и аналитиков, которые вносят улучшения , улучшения и новые системы. Здесь проекты могут различаться по продолжительности, хотя в некоторых случаях может потребоваться годы, чтобы полностью внедрить систему из-за этапов развертывания при замене какой-либо большой системы, такой как CMS, CRM или ERP.
Временами у меня возникало ощущение, что в машине есть винтик, а в других - довольно опрятно быть частью костяка компании из-за взлетов и падений такого положения. Я не хвастаюсь людям за пределами компании слишком много, потому что большая часть моей работы посвящена внутренним системам, которые не предназначены для публичного доступа или просмотра. Здесь могут быть билеты поддержки, когда кто-то может иметь дело с поставщиками программного обеспечения, поскольку у кого-то есть проблема, которая не обязательно является чем-то, где легко узнать, что вызвало ошибку, и поэтому отдел IS должен проконсультироваться с кем-то еще чтобы помочь решить проблему. В других случаях может случиться так, что некоторые настройки должны быть изменены в связи с изменением требований или бизнес-правил.
Компания-разработчик
Здесь это работает над тем, что компания продает напрямую, и поэтому есть некоторые большие различия в правилах. Во-первых, клиент здесь не может быть упакован так же, как корпус отдела IS. В отделе ИБ может быть всего несколько пользователей системы, так что руководство может позаботиться о многих странных случаях, когда, если кто-то намеренно решает неправильно использовать инструмент, это не всегда может быть предотвращено. В софтверной компании нет такой сети безопасности. Если кто-то загрузит ваше программное обеспечение и ему удастся найти способ сделать что-то довольно разрушительное, у компании может появиться большой черный взгляд на это. В этом случае может быть некоторая демонстрация того, что я сделал, так как может быть какая-то классная возможность показать друзьям или родственникам, если они хотят узнать немного больше о том, что я делаю.
Здесь следует отметить, что могут быть компании, привлеченные в качестве системных интеграторов, для внедрения большого настраиваемого корпоративного программного обеспечения, которое работает с сотрудниками отделов ИС над реализацией решений на миллион долларов, а также с теми, которые работают непосредственно для компании, которая делает большое программное обеспечение само по себе. Могут также быть поставщики сервисов приложений, которые я бы включил сюда, поскольку они продают сервис, который обычно состоит из программного обеспечения. Например, у Google может быть отдел информационных технологий, а также ряд разработчиков программного обеспечения, хотя никто не пошел бы в магазин, чтобы купить DVD с программным обеспечением Google, по крайней мере, я не думаю, что видел это, хотя я и делаю знаю о многих продуктах Google, которые можно использовать довольно легко. Это может позволить некоторую специализацию, поскольку это не
источник
Недавно я работал в крупной американской компании, не занимающейся разработкой программного обеспечения, где коллега услышал, как генеральный директор сказал: «Я не даю чертову информацию о программном обеспечении, которое я запускаю * *». По моему опыту это нормально для курса. Почти неизбежно возникнут проблемы, которые кажутся очевидными для команды разработчиков программного обеспечения, но менеджеры, не являющиеся разработчиками, откажутся даже думать об этом.
источник