Як погано може бути брак роботи в команді, коли ви програміст? [зачинено]

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

Я не сердитий, не сором’язливий чи інший, я просто люблю працювати по-своєму і зі своєю думкою, поважаючи інших, у мене велика цікавість і голод до знань, але мені бракує практики, і я думаю, люди не хочуть працювати зі мною, бо вони можуть побоюватися, що я б говорив про якийсь мораль. (Наприклад, я почав вивчати програмування за допомогою Linux, а не Windows, навіть якщо я багато використовую Windows. І у мене є Mac).

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

Ваша поведінка досить поширена у вашому віці. Я був такий, як ти.

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

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

Найпоширеніший стиль управління у Франції заснований на страху та покаранні. Це не гарна новина для вас, оскільки це сприятиме вашому індивідуалізму. Так це заохотить вашу поведінку.

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

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

Крім того, наявність команди справді допомагає нагадувати вам час від часу про те, що ви пишете лайний код. :

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

А це означає, що наявність команди допоможе швидше вивчити речі! Бути самотнім зробить тебе відлюдником;)

Що відбувається з програмістами, яким не вистачає командної роботи?

Тоді стає важко працювати над надто великими проектами для одного програміста. Складний для сольного програміста і складний для решти команди.

З чого починаються проблеми?

Всілякі місця. Наразі у нас є єдиний програміст, який погано працює у складі команди. Він прагне робити короткі скорочення, які негативно впливають на решту програми, оскільки він занадто вузько зосереджений на виправлення помилки перед собою. Або записати нову функцію таким чином, щоб вона не була сумісною з рештою програми. Ми повинні переставити речі так, щоб кожну реєстрацію його коду переглядала решта команди. Але щоб не виділити його, ми також перевіряємо реєстрацію коду всіх інших, тому поряд із ранковою зустріччю зі статусом ми не отримуємо жодної роботи до обіду. Тож у нас в офісі це означає, що 4 людини щодня втрачають 1/2 дня роботи, оскільки один хлопець невдалий у командній роботі. Я не можу сказати, що це поліпшення порівняно з попередніми пригодами, тому що ми могли випадковим чином втратити день на тиждень (як правило, переслідуючи нових помилок) від його реєстрацій, які ламають речі (ми називаємо їх "розбійними крадами"). Деякі виправлення його коду в кінцевому підсумку очистять півдюжини помилок через те, наскільки заплутаною та безладною є програма (моя рекомендаціязапустити його з орбіти і почати заново, оскільки це єдиний спосіб бути впевненим, що його не прийняли).

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

Чи хороший програміст компенсує хоча б трохи?

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

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

У розробці програмного забезпечення для бізнесу компанія буде довгий час після того, як ви поїдете. Програми, швидше за все, були написані до початку роботи, і вони підтримуватимуться довго після того, як ви підете. Якщо ви пишете речі, які є настільки особливими та дивовижними, що ніхто більше не може їх зрозуміти, то ви опинитесь у ситуації, в якій Naughty Dog - їхній провідний розробник кинеться, ніхто більше не розуміє власну мову програмування, яку написав хлопець (і написав речі в), тому їм зараз доводиться перемикати все на C ++.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Це, однак, сказало, як зазначають інші, це вміння (до певної міри), яке можна засвоїти, і якщо ви докладете зусиль для цього. Як правило, є кілька курсів, які ви можете пройти тут, у Сполучених Штатах, у великих містах для розвитку навичок лідерства; Однак, бути хорошим лідером - це також бути добрим послідовником, тому ці навички розвиваються також. Крім того, вміння ефективно спілкуватися на публіці - це часом навик, з яким люди потребують практики, і пов'язаний з навичками роботи в команді, але іноді затьмарюється - когось, хто не в змозі ефективно спілкуватися, можна вважати, що він не є «гравцем команди», хоча просто потрібно трохи попрацювати над їхніми навичками спілкування.

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

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

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

• Всі люди різні, і всі вони цінні.

Часи бути незалежними, є й часи, коли можна зблизитися. Вони обоє важливі.

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

Працюючи з командою програмного забезпечення, ви можете внести свої добрі ідеї. Деякі будуть прийняті. Деякі не будуть. Тоді ви всі «покладете плече на колесо» і приступайте до роботи. Це теж гарна річ.

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

Я можу подумати про багатьох відмінних програмістів, які вважаються (багатьма) "досить важкими для роботи":

• Ульріх Дреппер - утримувач бібліотеки GNU C (Посилання одна з багатьох )
• Тео Де Раддт - ведучий OpenBSD

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

У якийсь момент свого життя ви зрозумієте одну з двох речей:

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

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

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

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

Якщо ви ще цього не бачили, перегляньте фільм « Справжній геній ». Зверніть особливу увагу на Lazlo Hollyfeld . Стривайте в команду з відкритим розумом і сміливо позичайте мою піжаму.

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

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

Мати бачення - це добре. Але це дійсно має значення лише в тому випадку, якщо ви можете переконати інших людей поділитися своїм баченням. Гейтс, Джобс і Торвальдс всім вдалося реалізувати своє бачення, виготовивши продукти, які служили багатьом людям, і змусивши їх купувати їхні бачення. Працювати виключно ваш спосіб є більш чистим і задовольняючим, але це коштує дорого. Ви можете, як сказав Вольтер, дозволити досконалим бути ворогом добра ("Le mieux est l'ennemi du bien").

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

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

Оскільки ви тільки готуєтесь вступити в робочу групу, я хочу зазначити щось інше.

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

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

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

Ви закінчите працювати в самоті.
Переваги роботи в команді:
1- Інтерактивна допомога: ви не будете застрягати в проблемі годинами / днями.
2- Ви дізнаєтесь речі, яких ви не знайдете в книгах / інтернет-підручниках, форумах.
3- Конкуренція: буде стимулювати вашу мотивацію подолання чайок.
4- Обговорення: що краще, ніж години читання книг та блогів.