Март 21

Програмування без негативу: як виконувати поточну роботу й зберігати спокій

Чи давно ви почувалися зле від програмування? Ну, знаєте, щось не працює в Internet Explorer, код надто поганий, ви десь не попали в естімейт, не передбачили ризики чи не змогли зрозуміти, як щось працює, а самі двічі senior тощо. Мабуть, нещодавно.

Як часто це відбувається

Процес розробки ПО складається з повторюваних активностей в сталих умовах, тому недобрі відчуття, якщо вони виникають, теж повторюються. Умовно, ви розбиралися, як працює той «поганий» код, у минулому, робите це зараз і робитимете це надалі, якщо не зміните job function. Так само з Internet Explorer, естімейтами, ризиками й іншими аспектами програмування.

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

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

Як поліпшити ситуацію

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

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

Схематично цей процес можна представити так:

Або так:

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

Проаналізуйте будь-яку негативну ситуацію, пов’язану з індивідуальною діяльністю. Ви маєте незавидне А, і вам це не подобається. Чому? Бо десь є ліпше Б, у якому ви хотіли б опинитися.

Наведу кілька прикладів:

Код незрозумілий (А), а мав би бути зрозумілим (Б).
Завдання займає багато часу (А), а мало б уже завершитися (Б).
Оцінка виконання роботи мала б бути точною (А), а робота зайняла суттєво більше часу (Б).

Поставте собі запитання: чи є у вас підстави на ці очікування? Я маю на увазі факти, чому так повинно бути, а не ваші побажання.

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

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

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

Розрахунок відчуттів

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

Ситуація — це те, на що ви впливати, загалом, не можете.

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

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

Не очікуйте, що:

Код має бути обов’язково зрозумілим.
Ви виконуватимете завдання моментально.
Оцінки будуть виключно точні.

Дуже важливо розуміти, що зменшення очікувань не означає зменшення завдань чи потреб. Ви однаково можете:

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

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

Патерни узгодження

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

Добрим рішенням цієї проблеми, крім звернення на неї уваги й запровадження культури збереження спокою, був би загальноприйнятий перелік патернів боротьби зі стресовими ситуаціями, як-от всім відомі GoF або Head First Design Patterns. Я на таку поважну місію не претендую, але все ж спробую навести кілька прикладів зі свого досвіду. Сподіваюся, це допоможе комусь із читачів швидше знаходити рішення, а можливо, стане поштовхом для написання змістовніших робіт на цю тему.

Отже, що вас зазвичай дратує?

Нецензурно поганий код

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

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

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

Погано виконана кимось робота

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

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

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

Незрозуміло, як виконати завдання

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

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

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

Не вкладаюся в час

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

Завдання потребує більше часу, це факт.

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

Задовбався

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

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

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

Потрібно виконувати завдання не так, як ви хочете

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

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

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

Потрібно виконувати не те, що ви хочете

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

Розглянемо ситуацію:

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

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

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

З чого почати?

Пригадайте ситуацію, де ви в процесі програмування відчували негатив. Спробуйте розібратися, які у вас були очікування та яким був насправді стан речей. Чи були у вас підстави нервувати? Чи стала б у нагоді медитація тієї миті, як ви відчули щось неприємне? Якщо так, то наступного разу спробуйте скористатися цим інструментом. Сподіваюся, він стане в пригоді.

Також вам може бути цікава моя попередня стаття про труднощі взаємодії програмістів з колегами «Коли буде готово: як не зруйнувати взаємини в команді».

Бажаю гарного настрою та успіхів!