Яку шапку не повинен носити програміст? [зачинено]

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

Якщо головна роль полягає в написанні програмного забезпечення / коду, то які ролі розробник не повинен брати на себе? Чи є?

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

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

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

Ви носите те, що вимагає ваш роботодавець. Саме це робить вас гравцем команди. Саме це робить вас вирішенням проблем .

Люди занадто захоплюються ідеєю бути "розробником", "архітектором" чи "аналітиком". Викрутіть це. Ви повинні вирішити проблему. Код - це лише інструмент у вашому поясі.

Вирішення проблем ніколи не виходить зі стилю.

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

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

Тестер!

Будь ласка, надішліть нам тестерів прямо з школи тестера, якщо це потрібно!

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

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

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

Програміст не повинен бути єдиним тестером для власного коду .

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

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

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

Двоє, що я можу подумати, як раз з кажана.

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

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

Написання запитів добре, тестування Q / A чудово (і IMO має бути завданням програміста, маючи зовнішній відділ. Це потрібно знайти, але спочатку слід перевірити його). Адміністрація сервера - трохи сіра зона. Залежно від того, наскільки великий проект або якщо у вас є виділений адміністратор сервера, він може бути, а може і не знадобитися.

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

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

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

Технічна підтримка

Так багато мого дня витрачається на дзвінки з технічної підтримки ...

Деякі популярні:

• "Мій обліковий запис заблоковано" або "Я забув пароль"
• "Мій [телефон | клавіатура | миша | комп'ютер] не працює"
• "Мій комп'ютер повільний, чи можете ви перевірити це на щось незвичне?"
• "Чому X відбувається, коли натискаю цю кнопку? Це має робити Y"
• "Я постійно отримую ці спливаючі вікна ...." або "Я думаю, що у мене є вірус"
• "Цієї людини вже немає тут. Ви можете відключити всі їх речі?"
• "У нас є новий співробітник, чи можете ви налаштувати їх за допомогою логіна, картки безпеки, телефону, електронної пошти тощо?"

Будь-яка роль, яка змушує його керувати собою. У невеликих командах часто спостерігається тенденція зробити одного зі старших розробників керівником проекту, але також тримати його в команді як програміста. Це призводить до всіляких проблем, оскільки цей хлопець, як програміст, в основному некерований. Замість того, щоб делегувати всі завдання іншим членам команди, він часто буде спокушатися призначити багато з них собі, особливо найскладніші завдання. Тож найскладніші завдання, ті, хто, швидше за все, спричинить проблеми, покладаються на людину, яка лише 50% доступна як програміст і як такі звітує нікому. Коли інші члени команди не в змозі доставити, замість того, щоб бити в попку, він спробує виконати свої завдання, тому що, як керівник проекту, він відповідає за успіх і найбезпечніший спосіб досягти цього - це зробити сам чи не так?

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

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

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

Продажі .

Деякі погані помилки повинні це робити, але розробники, звичайно, не повинні.

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

Дизайнер інтерфейсу виконавця та користувача .

Більшість програмістів дуже бідні на твори мистецтва, але компанії не намагаються платити художнику, щоб малювати зображення та іконки для своїх виробів, а просто використовують «мистецтво програміста» - із жахливими результатами. (До Windows Vista це був найбільш очевидний диференціюючий фактор між Macs і PC - Macs виглядав красиво та привітно, ПК - це очі)

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

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

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

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

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

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

Крім того, насправді немає «капелюхів», які розробник не повинен носити, якщо у них є навички досягти найкращої ролі.

Я схильний брати будь-яку роботу, яка кидається на мене, якщо і тільки якщо:

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

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

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

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

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

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

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

редагувати:

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

Винна капелюх.