От началото на моята софтуерна кариера ме научиха на слоган: TEAM означава Tзаедно Eвсеки Aпостига M руда.

Дълго време обаче идеята ми да бъда екипен играч не стигна далеч, освен да кажа „Да“ на въпроса „Вие отборен играч ли сте?“.

По-късно в кариерата си смятах, че интервюиращите ми заслужават по-реалистичен отговор. Реших да опитам с по-дълбока истина. И ме заболя.

По време на пандемии минах през „най-изтощителната фаза на серийно отхвърляне“ в кариерата си. Първото отхвърляне, с което се сблъсках в самото начало на този период, беше свързано с така наречените умения за отборен играч.

Как ме отхвърлиха, защото бях лош отборен играч?

Интервюто беше техно-поведенческо. Попитаха ме за CV-то ми. След това те напреднаха към въпроси като проекти, с които се гордея, език за програмиране/библиотеки/рамки, които харесвах, и моите причини за тях, моите мнения относно дизайна на софтуера и SDLC.

Всичко вървеше доста гладко, докато не ме попитаха: „В екип ли работите или обичате да работите самостоятелно?“

Приех въпроса направо и му отговорих честно: „Както можете да видите в автобиографията ми, аз бях индивидуален сътрудник. Имам нужда от малко помощ при програмиране на задачи. Разбира се, аз си сътруднича с други съотборници за входове като функционалност, UX и UI дизайн. Но след като ги имам, обичам да работя в силоз и да доставя това, което се очаква.“

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

Когато попитах какво се е объркало, той отговори:

„Вашите екипни умения не са в съответствие с ценностите на нашата компания. Ние се съгласуваме повече с програмисти, които си сътрудничат непрекъснато със съотборници и създават най-доброто, което е възможно. Както споменахте, вие работите в собствен силоз, това е НЕ за нашия екип, съжалявам 😞”

Четох и препрочитах отговора му. За мен изглеждаше лишен от всякаква субстанция. Какъв беше най-малкият период от време, през който трябваше да посетите своя съотборник, за да се квалифицирате като отборен играч? И какво беше това съвместна работа за предоставяне на възможно най-добрия продукт глупости? Не трябва ли да предоставяте най-доброто, независимо дали си сътрудничите или не?

Освен това отговорът ми не казваше, че съм напълно настрана. Просто казах, че се оставям на мира, докато не свърша с функцията.

След като първоначалният гняв се охлади, когато го прочетох отново, ми просветна: това бяха формулировките. Моята част „работа в силоз“ предизвика някой в ​​групата за интервю. Може би този някой не е бил добър слушател или е избрал да игнорира всичко останало, което имах да предложа.

Страхотният програмист не е отборен играч:

Освен ако злите сили в софтуерната индустрия не го/я оформят в такъв — тогава той/тя се превръща в добър програмист или напуска компанията.

Не ме разбирайте погрешно Нямам нищо против отборните играчи. Но кои черти на екипния играч са истинските квалификации на колаборативния програмист? Когато попитате някого дали е отборен играч, какво точно очаквате в замяна?

Самата природа, която ви тегли към неромантична професия като програмирането, е способността ви да влизате в пещера с часове

Ако програмистът не е екипен играч, той умишлено би забавил доставките си, за да остави работата на колегите му да се забави. Още по-лошо, той ще направи бързи поправки, които неговите съотборници ще трябва да прекарат безсънни нощи в коригиране и преработване, което вероятно също ще допринесе за лошите баланси. Програмист, който не сътрудничи, не би актуализирал статуса си на работа навреме, не би говорил, когато е блокиран, и не би комуникирал, когато нещо бъде поискано от него.

Нито една от тези черти не е част от стандартните въпроси за интервю, освен ако кандидатът по някакъв начин не успее да ги спомене проактивно.

Напротив: Отборният играч не е някой, който се страхува да влезе в силоз. Всъщност самата природа, която ви влече към неромантична професия като програмирането, е способността ви да влизате в пещера с часове и да излизате победители, след като сте заковали проблема и/или сте проектирали страхотното решение. Този победен резултат отнема месеци, понякога години, да. Но това е в основата на естеството на работата на програмистите. И освен ако не преминат през тази фаза, техните пътувания не са завършени.

Ако тази способност отсъства, някой не си върши работата както трябва. Раздута кодова база? Хиляди ненужни зависимости за обикновени неща като форматиране на клеймо за време или проста анимация? Това е ясен знак, че екипът не отделя време за развитие. Кодерите не получават достатъчно време за проучване, кодиране и тестване. Вместо това те прекарват много повече време в срещи или ненужно сътрудничество, което фирмената култура им налага.

След като са загубили потока, те могат да направят много малко за времето, което остава след него. Забелязал съм, че го пилеят в едночасови бърборения на маса за кафе. Те губят часове в решаване на мястото за следващия петъчен излет, който ще продължи само час и ще присъстват само половината от съотборниците. Въпреки че от време на време подобна загуба на време е наистина ползотворна за изграждането на фирмената култура, в повечето случаи тя остава отметната кутия, без осезаем резултат.

Няколко интервюта:

Обратно към моя период на отхвърляне на интервюта, се сблъсках с още повече отхвърляне, защото казах: „Аз не съм човек, който излиза на бира в петък вечер. Понякога ги посещавам, за да се сближа, но истинското обвързване се случва на работа. ”

Фишът за отказ гласи: „Не съм отборен играч. Не и за нас, поне не сега. (Този панел за интервю включваше 6 души от един и същи екип и аз бях единственият, който говори през по-голямата част от времето)

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

„Аз съм нещо като и двете: Сътрудничам в обсъждането на спецификациите, което не би трябвало да отнеме повече време, ако сте направили достатъчно проучване предварително. И аз съм индивидуалист, след като спецификациите са в камък. Моята цел е да минимизирам времето на моите колеги, което бих загубил, ако се връщаме напред-назад.“

В крайна сметка постигнах успех с този отговор. Описах наученото в най-новата си електронна книга за интервюта за старши разработчици.

Но какво да кажем за програмирането по двойки?

„Писах много за програмирането по двойки“ — особено от гледна точка на GitHub CoPilot. Моят цитат за вкъщи от тази статия е:

„Програмирането много прилича на тези среднощни училищни задачи. Ако го правиш с приятели, изобщо не го правиш.”

Освен това програмирането по двойки е мода в индустрията. Някой е създал страхотен инструмент, за да научи децата как да кодират, след което е решил да го продаде на компании (защото имат по-дълбоки джобове от училищата и правителствата, плащащи за часовете по програмиране на децата). Вместо да продават само инструмента (който вероятно струва милиони за лицензиране всяка година), те днес измислят методология (Agile, някой?).

Следващия? Измислете инструмент за партньорска проверка на двойки, който позволява на още една двойка да наблюдава как кодира оригиналната двойка. По желание проверете дали наистина кодират или правят нещо по-интересно (IoT най-накрая навлиза в бюрата на разработчиците😋) Създайте повече метапозиции, които измерват и отчитат, като същевременно допринасят за културата на екипа.

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

Накратко:

Програмирането по двойки нарушава потока. Работи само когато и двамата програмисти имат еквивалентни компетенции, еднакъв темперамент и се познават достатъчно един друг, за да са готови да изложат своите въведени текстове един на друг.

Последното нещо, от което се нуждаем, е раздутите прегледи на кода - те се справят добре в текущия си формат.

Заключение:

Всяка компания процъфтява благодарение на двете най-важни съставки: бизнес цели и фирмена култура.

Цялата идея за работа в екип е да се внуши чувство за сигурност и да се култивира воля за принос. Тези цели са насочени към бизнес целта на организацията.

Фирмената култура е перфектен лубрикант, който допълва горивото, което е бизнес целта. Но това не е цел, която трябва да бъде преследвана толкова яростно от програмистите, колкото би трябвало да бъде от управленския персонал. Изграждането на екип и сътрудничеството попадат под чадъра на фирмената култура.

Постигането и демонстрирането на перфектна личност на екипен играч не е най-важното умение на програмиста. Избягването да бъдеш скапан отборен играч, реалистично, е.

Когато следващият ви мениджър по наемането на персонал ви попита за абстрактни умения за екипен играч, кажете му какво точно защитавате, какво не бихте и как работите. Ако вашият отговор не е приемлив за него, това е за по-доброто и на двама ви.

Pen Magnet е автор на популярната електронна книга за интервюта за старши разработчици, която разглежда въпросите за формата на интервюто на Amazon STAR:

Изчерпателен подход към интервю за старши програмист (40+ примерни въпроса)(За първите 100 средни читателиотстъпката е50%)