Чи перешкоджають роботи з технічного обслуговування перешкоджати кар'єрі програміста? [зачинено]

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

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

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

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

Але це призводить мене до моїх головних питань, вибачень, якщо це відчувається занадто зосередженим навколо моєї особистої дилеми:

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

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

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

По-друге, якщо я наймаю когось із досвідом 2-4 років, мені зовсім не байдуже, чи їх робота була лише технічним обслуговуванням. Якщо ви витратили 10 років на технічне обслуговування, і я приймаю на роботу за проектом «зелені поля», у мене можуть виникнути запитання, але, протягом перших кількох років, я чесно його очікую.

З іншого боку, якщо я найму когось, хто НІКОЛИ не працював у технічному обслуговуванні, я стану більш підозрілим. У мене було багато кандидатів на роботу, які провели свої перші 4 роки, переходячи з однієї "хорошої" роботи на іншу, і кожен з них нічого не дізнався про те, що робить ремонтом коду. І, не помиляйтесь, якщо я беру на роботу для проекту «зелені поля», якого я маю намір дотримуватися, мені все одно, чи Ви збираєтесь підтримувати код, мені байдуже, що ви знаєте, як залишити його доступним для майбутніх розробників.

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

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

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

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

• Наскільки широко поширені конкретні технології, з якими ви працюєте? Якщо ви підтримуєте щось, що застаріло і рідко використовується в іншому місці, то це обмежило б ваші майбутні можливості кар’єри (але так би розробити нове програмне забезпечення для системи / платформи / технології, яка не використовується широко).
• Як ваша нинішня робота підготує вас до роботи, яку ви хочете зробити в майбутньому? Роботи з технічного обслуговування, як ви вказали, важливі і завжди будуть навколо. Немає нічого поганого в тому, щоб кар’єра була орієнтована на цей тип програмування; завжди буде багато можливостей для системних систем. Але, можливо, це не те, що ти хочеш робити. Викликає занепокоєння, якщо ваша нинішня робота не готує вас до того, що вас цікавить.

Однак я б не надто хвилювався. Ви можете сказати одне:

Я набув великої широти з точки зору районів, до яких я торкнувся, але не надто глибоких.

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

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

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

Чи шкідливі для ранньої кар'єри шкоди присвяченого програмуванню технічного обслуговування?

Найчастіше - ТАК, якщо вважати:

• що кар'єра тут означає досвід багатьох технічних навичок.
• що ви проводите там більше X років, де Х достатньо, щоб "встановити" свої способи мислення.
• що ти нічого не робиш осторонь.
• що "виділений сервіс" (див. EDIT, нижче) означає, що ви не кодуєте для підтримки , а також кодуєте нові речі, але майже завжди кодуєте, щоб підтримувати або навіть працювати над проектом у режимі обслуговування - жодних нових функцій, найменш, не потрібно зміни коду, щоб виправити помилку.

Це не означає, що це завжди так.

Людям, що підтримують програмне забезпечення, рідко рекомендується (див. EDIT, нижче) робити дослідження, рідко можуть підключити нову бібліотеку або БД і витратити кілька днів, щоб дізнатися, як це працює. Це (як правило) стабільна робота, яка вимагає мінімальних змін до існуючої бази коду і, таким чином, «формує» спосіб, як ви згодом вирішите проблеми. Я можу назвати досить багато компаній, які мають політику щодо забезпечення програмного забезпечення, яка прямо говорить про "менші зміни коду = краще", незважаючи на погані речі, які це може принести.

Чи праві інші програмісти уникати таких ролей?

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

Чи заважає ця лінія роботи заважати виконувати подібні завдання, якщо ви не готові починати спочатку як молодший?

Найчастіше - ТАК. Тому що ви вже маєте досвід робити це, тому що ви вже «знаєте мотузки» і т. Д. Але зміна, безумовно, можлива і може статися без подачі заявки на посаду молодшого віку. Ви вже почали робити справи в сторону, продовжуйте це робити! Це насправді дуже варте і може скоротити «прогалину кваліфікації», яку ви помітили.

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

Такі завдання, безумовно, МОЖНА робити так, і якщо вони є - чудовими! Однак більшість ВІДДАЛЕНОГО обслуговуючого персоналу систем LEGACY мають політику чи очікування керівництва та строки, які - знову ж таки, частіше за все - змушують їх вирішувати проблему з найменшими можливими змінами. Часто тиск досить високий, що навіть якщо ви зможете зробити це таким чином, ви можете не захотіти. Особливо, якщо це не ВАШ код: без теорії (відповідно до Райла та Наура) за ним ви ризикуєте пошкодити більше, ніж ви виправите.

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

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

Правильно. Ви не зможете сказати "3-річний досвід проектування систем з нуля, використовуючи X, Y і Z", ви повинні сказати "3-річний досвід ОСНОВНІ системи з нуля, використовуючи X, Y і Z", якщо ви не хочете правильно лежати на вашому резюме.

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

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

Що є звичайним для ІТ (і я не кажу, що це ви робите) - це люди припускати, що оскільки вони працюють протягом X років, вони мають X-річний стаж і після {невизначеної кількості років} вони слід вважати старшим {Widget} розробником.

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

В ідеалі ви хочете поєднати "нову" роботу системи та застарілу роботу.

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

Удачі!

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

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

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

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