Програмирането е скучно, ако не го правите
Как да се справим със скуката на работното място - техническият директор на Enki startup Бруно Марнет мисли много по този въпрос. Докато работи като програмист, решава проблема със скуката с поредната смяна на работата, но когато основава собствена компания, той мисли как да накара подчинените си да не искат да напускат работа, така че работата да не се превърне в скучно ежедневие. Той изложи мислите си в колонка, предлагаме ви нейния превод.
Като програмист никога не съм успявал да остана на една работа повече от две години.
Всяка следваща работа беше добра стъпка напред в кариерната стълбица, а текучеството е нормално явление в нашия бранш. Но предишните ми работодатели не бяха особено щастливи, че напуснах. Някой се опита да ме задържи, но бях толкова отегчен, че просто не можах да остана.
(Корекция: Имам късмета да живея на места, където има повече свободни работни места за програмисти, отколкото самите програмисти! Разбирам, че такава смяна на работа не винаги е налична).
Сега съм съосновател и технически директор на Enki. В тази роля отговарям за работната среда на програмистите. Част от работата ми е да се уверя, че програмистите никога не са толкова отегчени, колкото аз бях в миналото.
С екипа ми разработихме стратегия за справяне със скуката и я приложихме върху себе си. Засега работи добре, затова реших да го споделя.
В нашата работа често има интересни продукти, които трябва да бъдат написани, забавни проблеми, които трябва да бъдат решени. Така че изглежда, че скуката не трябва да бъде основен проблем за нас. Но в началото винаги е така. Вместо това скуката се прокрадва в екипа постепенно и те връхлита в най-неподходящия момент.
Затова се опитваме да се борим с него предварително, изграждайки култура, коятоникога не ни позволявайте да скучаем на работа.
TL;DL* (ствърде дълго; нищо не научи)
Най-честата и очевидна причина за скуката на програмистите е проект, който отнема твърде много време.
Усетих го на собствената си кожа, още на първата работа. След това екипът работи върху това как да подготви и предостави финансови данни чрез удобен API. В началото това беше вълнуваща задача поради сложността и мащаба на данните. Изучавах високоефективни техники за анализ на данни и API дизайн. Но година по-късно все още работехме върху същия набор от данни, използвайки същите технологии. Станах професионалист в много тясна индустрия. Нямаше какво да уча.
Не можех да сменя екипа или проекта, защото беше изгодно за компанията да ме задържи там, където вече работех. Бях твърде добър в данните и технологиите, за да бъда разменен за някой друг. Не можах да накарам технологията да се промени само за да мога да науча нещо ново. Не се оплаквах от скуката и разочарованието си на никого конкретно, така че в крайна сметка просто напуснах работата си.
Как можете да избегнете тези чувства?
Опитваме се да гарантираме, че никой не работи с един и същ код, продукт или набор от данни повече от три месеца подред. Може да се спори за точния период, може би такъв период няма да е достатъчен за по-големите компании. Но като цяло вярваме в "бързата ротация".
За да постигнем това, ние насърчаваме култура на пълен стек, което означава, че всеки от нашите програмисти може да работи върху всяка част от нашия код (или да може бързо да го научи).
Друг начин да го предотвратите е да говорите за такива неща през цялото време. Имаме директни дискусии лице в лице всяка седмица. Ако програмистът се чувства твърде отпуснат или започнеспециализират в тесни теми, време за разбъркване на рамки.
Поддържането на стар код е скучно
Веднага можете да видите кога проектът вече е в етап на поддръжка - официално или не - когато разработчиците прекарват 90% от времето си в коригиране на грешки, вместо да разработват нови функции.
Някой ще забележи, че без подкрепа е невъзможно. Старият код се нуждае от него. Създаването на софтуер е като изграждането на къща. Древните къщи трябва да бъдат ремонтирани и обновявани от време на време. нали
Общият проблем тук е с уважението.
Веднъж имах ментор, който беше циничен по този въпрос. Той веднага прие за даденост, че нищо не може да се направи. Ето как работи разработката на софтуер, каза той. Животът е гаден, свиквай с него.
Но как да смекчим този ефект?
Режимът на поддръжка понякога е резултат от лоши технически решения и липса на смелост.
Огромният монолитен код със сложни зависимости се нуждае от повече поддръжка. Микроуслугите с добре проектирана инфраструктура са много по-гъвкави. Ако дадена микроуслуга започне да се обърка, тя може да бъде заменена. Можете да го пренапишете от нулата, като използвате различен език или технология. По този начин ще научите нещо ново, вместо да закърпвате стар код. И ако вашата архитектура все още не го позволява, можете да я подобрите и в същото време да придобиете някои DevOps умения.
Стратегията за микроуслуги е един от многото начини за справяне със скуката от поддръжка на код. Някои компании разработват специални инструменти, които правят поддръжката по-интересна и ефективна. Един пример за довеждане на този подход до крайност е това, което Facebook някога направи с масивната си PHP кодова база. Те създадоха свой собствен компилатор и свои собственивъведен Hack език върху PHP, така че в същото време базата данни да стане по-лесна за поддръжка и разработчиците да се забавляват повече. Подозирам, че това не реши напълно проблема, но определено разнообрази работата на разработчиците.
Копирането е скучно
Има програмиране и програмиране.
В някои предишни работни места създадох тонове не толкова готин код. Веднъж написах скриптове в Groovy и Python за интегриране на данни. Данните бяха сложни, с много непоследователни схеми, което правеше невъзможно автоматизирането на процеса. Така че трябваше да напиша много код и колегите ми смятаха, че научавам много.
Но не беше. Защо?
50% от кода ми (умишлено преувеличавам!) беше директно копиране и поставяне от Stack Overflow. А останалите 40% от други сценарии – колеги или мои. Работата започна да се повтаря. И няма място за творчество или учене.
Как да смекчим този ефект?
Като екип обръщаме внимание на типа код, който нашите програмисти пишат - по време на прегледи на кодове, срещи и срещи. Ако някой прекара седмица в писане на не съвсем креативен код, ние се опитваме да разберем как се е случило това.
Понякога проблемът се корени в технологиите. Може би прекарваме повече време в скриптове или настройки, отколкото ни е необходимо. В този случай ние се опитваме да автоматизираме процесите. Ако не можете без copy-paste, ние се опитваме да споделим тежестта на скучната работа между всички.
Вътрешните инструменти обикновено са скучни
Програмистите обичат да създават персонализирани вътрешни инструменти за решаване на конкретни проблеми. В крайна сметка създаването на нещо ново е толкова вълнуващо. Често създаването на персонализирани решения изглежда по-чисто от адаптирането на съществуващи. Но изучаване на патентован инструмент на десетпъти по-скучен от популярната технология с отворен код.
Защото не можете да ги обсъждате с приятелите си, не можете да се хвалите, че ги познавате, не четете за тях в Hacker News; не могат да се използват в хакатони, както и в техните тайни проекти в свободното им време.
Но много компании попадат в капана да създават неща, които не си струват скуката, която причиняват. С други думи: те помагат да се справят с краткотрайната меланхолия, причинявайки все повече и повече меланхолия в бъдеще със своето съществуване.
Видях с очите си как работи. За широкомащабна интеграция на данни ми беше позволено да използвам само DSL, създаден от компанията. Всичко, което научих, беше просто още един жаргон, подобен на SQL (умишлено преувеличавам). Бих искал да използвам и да науча технология с отворен код на ниско ниво като Spark. Щях да бъда десет пъти по-ангажиран и дори кодът ми да беше два пъти по-подробен, щях да бъда пет пъти по-продуктивен (аритметиката не работи по този начин, но схващате идеята).
Каква култура в компанията може да предотврати това?
Опитваме се да подхранваме силна привързаност към технологиите с отворен код. Ние не бягаме от модерните технологии и ако можем да използваме повторно нещо подходящо и интересно, го правим. Изхвърляме нашия собствен код веднага щом технологията с отворен код е достатъчно зряла, за да я замени. И когато собственият ни код стане достатъчно универсален, ние незабавно го превеждаме в отворен код.
Понякога правим грешки. Например използвахме библиотеката agenda.js, за да планираме задачи за бекенда, защото изглеждаше модерна и интересна. Но се оказа, че това прави всичко по-трудно, така че се върнахме към старата, по-надеждна технология (добрата стараcron!). Не съжаляваме за експеримента, беше ценен урок.
Да си "bydlokoder" е скучно
Друга популярна причина за скуката на програмистите е лошото управление на човешките ресурси. По-точно: еднопосочен диктаторски контрол на разработчиците.
Топ мениджърите понякога използват този стил, без дори да го осъзнават, с най-благородни намерения. Особено когато проектът не е нито клатещ се, нито когато крайният срок наближава. Под такъв натиск безусловният рефлекс е да вземате собствени решения, да сведете до минимум мозъчната атака и просто да казвате на хората директно какво да правят, без обсъждане или обяснение. Само за да спестите време и да получите резултати.
Разбиращият подчинен не е непременно разстроен от това. Всъщност някои хора (от време на време) оценяват тази простота на работа: просто правете това, което им се каже.
Но тук има известен риск.
Знаейки точно какво трябва да се напише, преди да започнете работа по кода, превръща интелектуалния и творчески процес в механичен. Разработчиците се превръщат в "bydlokoderov".
По-важното е, че страстните програмисти обичат да разбират защо правят нещата по начина, по който го правят. Програмист, който не се интересува от причините за вземане на решения, е програмист, който трябва да смени работата си.
Как да го избегнем?
На първо място, имате нужда от вътрешна култура, която насърчава откритата дискусия. Да има актуализиран форум за дискусии относно стратегията и планирането на това, което екипът трябва да направи. И всички в екипа трябва да са бдителни и активни.
Когато наближат трудни времена (или крайни срокове), подчинените трябва да говорят по-силно, а шефовете да слушат внимателно.
Рутина = скучно
Последен в списъка, но не на последно мястоточка: рутината в затворена среда е универсален убиец на интереса към работата.
Това не се отнася само за технологични компании или програмисти. Това характеризира всяка работа в офиса. Ден след ден, в една и съща стая, заобиколени от едни и същи хора, играещи една и съща роля... Дори в бързо развиваща се среда и дори ако всички тези компоненти са обективно добри, хората бързо свикват с доброто и се разстройват от не толкова добрите елементи на работната атмосфера.
Как да се борим с него?
Ключова съставка: разнообразие. Можете да наемете хора с много различен произход и опит (в момента имаме британец, французин, българин и грък в екипа). Да виждаш едни и същи хора всеки ден ще бъде много по-интересно, ако всеки от тях може да внесе нещо специално в културата.
Също така се опитваме често да излизаме от рутината.
Ходим заедно на хакатони и партита. Всички имаме свои собствени странични проекти, опитваме се да участваме в разработването на любимите ни инструменти с отворен код. Дори помагаме на останалата част от екипа с нетехническа работа (наемане, маркетинг, разпространение). Не защото сме професионалисти в това, а за да променим ситуацията.
Организираме срещи след работно време (като „тайни филми“), седмични „анкитони“ без предварително определен план. Понякога обмисляме някои идеи. Понякога просто излизаме заедно в League of Legends. Или отиваме в кръчмата. Хубавото е, че до последно не знаем какво ще правим и тогава решаваме заедно.
Малко хаос е последната съставка в нашата рецепта против скуката. Като всяка рецепта, тя никога няма да бъде перфектна. Променете дозите, съставките и опитайте отново.
*позоваването на популярния мем е твърде дълго; не четях, аналог на българския език „много букви, не я владеех“.