Що визначає роль "розробника програмного забезпечення"

Я молодший розробник програмного забезпечення і працюю в компанії менше року.

Хоча я завжди думав, що розробник програмного забезпечення означає щось розробляти програмне забезпечення та КОДУВАТИ, мої завдання в більшій мірі полягають у адміністративному типі роботи, такі як налаштування Дженкінса, реплікація SQL тощо.

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

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

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

Це прикро, адже це ставить вас і вашого начальника в хитрі позиції.

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

Але з цього виникає кілька проблем.

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

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

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

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

Якщо ви не можете, то, можливо, захочете шукати деінде.

Я вважаю, що термін «Розробник ПЗ» є синонімом «Програміст». Таким чином, розробник програмного забезпечення - це людина, основним обов'язком якої є написання коду. На моїй першій роботі моя назва була "Розробник", і моя основна відповідальність полягала в розробці та кодовому програмному забезпеченні. Але я думаю, що точного визначення терміна немає. Він використовується по-різному у різних людей, тому значення стає нечітким.

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

Ці завдання займуть велику кількість часу на початковій фазі проекту, але займуть менший проміжок часу після того, як ви виконаєте гарне налаштування.

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

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

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

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

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

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

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

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

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

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

Досить часто для розробника в невеликій та середній компанії слід взяти на себе деякі завдання адміністратора сервера / DBA / загальних налаштувань.

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

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

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