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

Нещодавно до мене звернулося місцеве рекламне агентство з можливістю роботи. Вони залучають усі веб-сайти / інтерактивні розробки до власних служб та додають до своєї команди розробників.

Мені стає боляче від моєї легкої, але нудної корпоративної роботи, і мене заінтригує ця посада.

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

Чи може хто-небудь із досвідом порівняти / порівняти роботу в програмній компанії з роботою в компанії, яка, як правило, має власну команду або відділ розробки програмного забезпечення?

Це буде залежати від компанії. Але зазвичай, якщо це не їх головна увага, програмне забезпечення буде меншої якості. Процес, якщо вони є, буде менш суворим. Тестування не існує. А робота в цілому менш технічна.

Вони захочуть, щоб це працювало і працювало зараз, і це буде досить добре.

Але деякі місця стосуються розробки програмного забезпечення, навіть якщо вони мами та поп-магазини, які роблять щось інше цілком. Це залежить від того, чи є бізнес-лідерство відкритим для хороших ідей, технологічне керівництво знає достатньо, щоб зробити це правильно, і мати людей, які можуть пояснити гарну ідею. Який ти можеш бути.

Інтерв'ю компанії. Запитайте їх, чи знають / дотримуються тесту Джоеля. Більшість із них - хороші бали. Подивіться, чи розуміють вони технічну заборгованість і міфічний чоловік-місяць. Хто ваш керівник проектів, який процес він використовує та наскільки вигадливий він?

ВЕЛИЧЕЗНА різниця. У першому ти є частиною центру прибутку. В останньому ви є частиною центру витрат. Здогадайтесь, хто з них отримує краще лікування?

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

Програмісти все ще є програмістами. Тільки тому, що основний продукт компанії - це не програмне забезпечення, не означає, що програмісту не потрібні ті самі зручності.

Я працював у ІТ-відділі великих компаній, що розробляє програмне забезпечення для внутрішнього використання; Я працював у компаніях, що розробляють програмне забезпечення для ринку; і я працював в агентствах, які займаються веб-розробкою для клієнтів.

І я б не сказав, що між цими різними компаніями була різниця в важливості підвищення продуктивності.

Підвищення продуктивності програмістів є життєво важливим незалежно від того, яким розвитком займаються ці програмісти. І я б сказав , що підтримка програмістів щасливих і тримати їх працювати для вас ще більш важливо , коли вони є програмістами обслуговування в ІТ - відділі , не програмне забезпечення компанії.

Різниця багато в чому залежить від самої компанії; Я працював у хороших непрограмних компаніях та жахливих програмних компаніях. Однак у середньому ось що я знайшов:

Непрограмне забезпечення компанії

Акцент робиться на швидкому виконанні речей, при цьому мало або зовсім не задумується про якість або довготривалість ремонту. Зазвичай розробники технічно не знають, що вони робили в минулому або за час роботи з компанією, і часто намагаються запровадити нові концепції (ORM, принципи SOLID, TDD тощо). Люди, як правило, більше зосереджуються на «буксируванні лінії компанії».

Програмне забезпечення компанії

Наголос на виконанні речей без шкоди для якості. Співробітники частіше йдуть в ногу з технологіями (чи можуть вони використовувати її на роботі чи ні) і часто дивляться, як вони можуть інтегрувати нові ідеї чи рамки в розпорядок дня, щоб покращити програмне забезпечення. Якщо вони ще не знайомі і використовують такі поняття, як TDD, ORM, SOLID тощо, вони, напевно, чули про це і готові їх оцінити.

Зрештою, це врешті-решт залежить від компанії. Я працював у непрограмній компанії з надзвичайно Agile командою, яка охопила TDD та ORM і навчила мене багато чого з належної інженерії програмного забезпечення, і я працювала в невеликій програмі, яка написала код спагетті VBScript найгіршого виду і має 50+ розробників що кожен повинен був працювати на різних сторінках, щоб уникнути зламування речей, і тонни тяганини навіть для незначних змін. Однак, чим менше компанія покладається на програмне забезпечення, тим більше шансів, що навколишнє середовище буде дуже поганим для розробки програмного забезпечення.

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

Однією з різниць напевно буде менше акценту на накладні витрати та червоні стрічки, які вам доведеться пройти у магазині корпоративного програмного забезпечення. Ви побачите, що зможете мати набагато більш детальний контроль над усіма аспектами своїх проектів.

Один із профі: це може бути освіжаючим ...

Це особисто для мене вийшло жахливо, але це може бути, тому що я вибрав погано. ОГРАНИЧНА конфесія полягає в тому, що ви більше не прив’язані до хліба та масла, і натомість ви адміністративні витрати. Контролери бюджету ставилися до мене так, як я особисто брав гроші з власних гаманців і продовжував "бити мене, як орендований мул", так би мовити. Для мене це було гнітюче і виснажливе випробування, тому вам слід ретельно шукати ознаки подібного ставлення під час співбесіди.

Тут вже є чудові відповіді, але я хотів би посилатися на посилання на стенограму 2-ї частини бесіди, яку Йоел Спольський виголосив в Єльському університеті:

Джоель Спольський - Розмова на Єлі, частина 2 з 3

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

Його три основні моменти:

• Коли ви власний програміст, вам ніколи не вдається робити справи правильно. Ви завжди повинні робити справи доцільно.

• Як власний програміст, після того, як якесь програмне забезпечення є «досить хорошим», ви перестаєте працювати над ним. Коли ви розробляєте програмні "продукти", ви отримуєте можливість зробити їх красивими.

• Коли ви програміст в програмній компанії, робота, яку ви виконуєте, безпосередньо пов'язана з тим, як компанія заробляє гроші. Це означає, що, з одного боку, керівництво піклується про вас.

Особисто я працював як у програмних компаніях, так і в непрограмних компаніях впродовж своєї кар’єри, і хоча завжди є винятки з кожного правила, я погоджуюся з пунктами Джоеля, оскільки переважна більшість компаній, здається, відповідає їм.

Одна з головних відмінностей полягає в тому, що працюючи в магазині програмного забезпечення, ви, ймовірно, допомагаєте створювати робочі місця в компанії. Робота в кафедрі програмування В іншому випадку компанія, як правило, означає, що ви пишете програмне забезпечення для заміни людей. Це гнітюча реальність. При цьому, рекламне агентство цілком може бути зовсім іншим звіром. Я б більше не схожий на веб-розробник в іншій компанії.

Щодо моїх спостережень, є щонайменше два випадки, коли дотримуються меж програмної компанії з питаннями професійного виживання .

Перший випадок - якщо хтось повністю зашифровується - дайте мені 80 ... 90 ... 100% часу на кодування або я помру . У магазинах програмного забезпечення це майже не можна, ніби всі знають, як туди потрапити, бо, адже всі роблять саме так. Але назовні є дуже високий ризик не змогти потрапити туди. Можливо, цей показник може становити 50, 40, 30% (моє особисте завантаження коду знизилося до 20% - не жартую, я вимірював в JIRA !) Це не тому, що "вони" не хочуть, щоб ви кодували - не хочуть, але , але ... вони просто не вміють.

Другий "смертельний ризик" - це якщо у когось є серйозні проблеми в спілкуванні. Це може бути клопітним навіть у магазинах програмного забезпечення, правда, але принаймні є хороші шанси вижити і прожити гарне продуктивне життя, не порушуючи взаємодії. :) Однак у непрограмних компаній такі шанси значно нижчі - навпаки, майже неминуче, з часом, доведеться витратити багато зусиль, щоб навчити когось із аутсайдерів з ІТ-основ лише тому, що в іншому випадку це зробити неможливо.

Ну за винятком двох згаданих вище випадків, я не знаю жодної іншої вагомої причини суворо зафіксувати себе в програмних компаніях. Тепер, якій стороні віддати перевагу? наскільки я можу сказати, це більше питання смаку, того, яка забава клацає більше на вас.

Обидві сторони пропонують свої, виразні форми веселощів. Це не просто описати.

Я б сказав, що програмні компанії цікавіше тим, хто прагне до «високих оцінок», тоді як зовнішні викликають захоплення тих, хто прагне до «великої різниці». Я думаю про це , як це приблизно (примітка числа нижче придумані тільки для спрощення створення точки) ...

• У фірми, що займається програмним забезпеченням, є шанс поставляти 100 функцій на рік - найвищий бал, якого ніхто ще не досяг. Це буде важко, це буде важко, це буде найкращим - зробити круте 50% покращення в середньому за 70 функцій на рік. Справді, великий виклик.
• Водночас у зовнішньої фірми є шанс пропонувати 50 можливостей на рік - найвищий приріст, який ніхто ніколи не досяг. Це буде важко, це буде важко, це буде великим - зробити колосальний 500% прискорення в середньому за 10 функцій на рік. Великий виклик, повірте мені.

Зауважте, що шанси отримати 500% приріст у програмній компанії незначно невеликі порівняно - і, відповідно, шанси на досягнення 100 функцій зовні незначні .

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

Тепер, якщо у вас є чітка перевага того чи іншого, ви знаєте, яку сторону взяти. Або, якщо ви нерішучі, просто не соромтесь гойдатися між ними, як хочете. :)

Кудос на відповідь центру витрат на прибуток.

Я був у обох і набагато віддав перевагу компанії програмного забезпечення. Оскільки ваше співвідношення з прибутком є ​​більш очевидним, ви більше шансів отримати належну компенсацію на основі продуктивності та загальну культуру корпорації, яка охоплює особистість розробників програмного забезпечення. Часто це означає, що це менш офісна політика, докерам не потрібні, очевидні шляхи кар'єри та менше BS. Але якщо ваш більше на стабільний 9-5, можливо, менш складний, не найрізноманітніший концерт типу, ніж іноді корпоративні ІТ, - це вигідніше - не бути тут цинічним, я розумію, що деякі люди люблять більш типовий баланс роботи / життя за рахунок інші речі. На мій досвід, загальна якість розробника набагато, набагато краща для програмної компанії; на противагу посередності, яка часто пронизує корпоративні ІТ. Я знаю, що є винятки,

ІТ є частиною групи підтримки в непрограмних компаніях. Програмні програми програмного забезпечення розробили додатки, які допоможуть компанії значно покращити продуктивність, швидші транзакції, технічну підтримку тощо. Деякі компанії, що не пропонують програмне забезпечення (Виробництво / Промисловий етч), пропонують тренінги та інші речі для своїх програмістів, але багато хто ні, тому вони звикли передавати програмістів в інших компаніях.

Чи може хто-небудь із досвідом порівняти / порівняти роботу в програмній компанії з роботою в компанії, яка, як правило, має власну команду або відділ розробки програмного забезпечення?

Я швидше протиставляю роботу в відділі IS, ніж працювати в підрозділі з розробки продуктів компанії, яка продає програмне забезпечення. Просто для уточнення кожної сторони та надання деяких з кожної, з деякими виправленнями форматування:

Відділ ІС

Компанія може виготовляти обладнання, програмне забезпечення, автомобілі чи що завгодно, але ключовим тут є те, що є внутрішній відділ, який відповідає за системи, якими компанія користується щодня та вихідний день. Тут можуть бути такі структури, як ITIL, які можуть спробувати донести деяку зрілість до процесів, якими ведеться відділ, як частина цього відділу, - це інфраструктура, яка утримує світло, а інша частина - це хлопці з розробки та аналізу, які вдосконалюють , вдосконалення та нові системи. Тут проекти можуть відрізнятися за довжиною, хоча в деяких випадках може знадобитися років, щоб система повністю була впроваджена через фази впровадження, якщо якась велика система буде замінена на зразок CMS, CRM або ERP.

Часом у мене було відчуття того, що я гвинтик у машині, а в інших досить акуратно бути частиною основи компанії для мінімумів і максимумів такої посади. Я не надто сильно хвастаюся перед людьми, що знаходяться за межами компанії, оскільки більшість моєї роботи ведуться на внутрішніх системах, які не мають бути загальнодоступними або переглядатися. Тут можуть бути квитки на підтримку, коли, можливо, доведеться мати справу з постачальниками програмного забезпечення, оскільки у когось є проблема, яка не обов'язково є чимось, коли легко дізнатися, що спричинило помилку, і тому відділ ІС повинен здійснювати подальші дії з кимось іншим щоб вирішити проблему. В інших випадках може бути, що деякі налаштування повинні бути змінені через зміни вимог чи правил бізнесу.

Програмне забезпечення компанії

Тут працює над тим, що компанія продає безпосередньо, і, отже, є великі відмінності у правилах. По-перше, тут замовника не можна настільки багато, як у випадку з відділом IS. У відділі ІС може бути лише декілька користувачів системи, щоб управління могло піклуватися про багато випадкових випадків, коли, якщо хтось навмисно вирішив неправомірно використати інструмент, це не завжди можна запобігти. У програмній компанії немає такої мережі безпеки. Якщо хтось завантажує ваше програмне забезпечення, і їм вдасться знайти спосіб зробити з ним щось досить руйнівне, компанія може отримати великі чорні очі для цього. У цьому випадку може бути щось, що демонструє те, що я зробив, бо може бути якась цікава функція, щоб показати другові або родичу, якщо вони хочуть дізнатися трохи більше про те, що я роблю.

Щось тут слід зауважити, - це те, що можуть бути компанії, яких запроваджують як системних інтеграторів, щоб розмістити велике налагоджене корпоративне програмне забезпечення, яке працює з людьми у відділах ІС, на впровадження мільйонних доларів, а також ті, які працюють безпосередньо для компанії, яка робить саме велике програмне забезпечення. Тут також можуть бути постачальники послуг додатків, які я б тут розмістив, оскільки вони продають послугу, яка зазвичай побудована з програмного забезпечення. Наприклад, у Google може бути відділ ІС, а також ряд розробників програмного забезпечення, навіть якщо хтось не ходив би в магазин, щоб придбати DVD програмного забезпечення Google, принаймні, я не думаю, що цього я бачив, хоча знаю про багато продуктів Google в режимі он-лайн, якими можна користуватися досить легко. Це може дозволити певну спеціалізацію, як це є »

Нещодавно я працював у великій американській непрограмній компанії, де колега почула, як генеральний директор говорив: «Я не даю аф *** про програмне забезпечення, яке я запускаю * *». На мій досвід, це рівнозначно курсу. Майже неминуче з’являться проблеми, які здаються очевидними для програми програмного забезпечення, але керівництво, яке не розробляє розробники, відмовиться навіть думати про це.