Ох, вже ті новачки з шилом в дупі!

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

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

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

По-перше, в команді має бути нормальний онбординг. Я не говорю зараз про те, коли вам видають ноутбук, пароль до корпоративної пошти і роблять один дзвінок з HR на пів години на тему "шо ти голова".

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

По-друге, ніхто не забороняє вам вносити пропозиції. Саме так — вносити пропозиції. Не вриватися з бойовим криком "Міша, всьо хуйня, по новой давай!", а аргументовано запропонувати зміни. Так, я знаю, це набагато складніше, ніж плодити купу ПР, які розходяться з командними правилами бо "мені так зручніше". Ну і це не так захопливо, як сваритися на дейліках з тімлідом, визнаю.

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

Команда теж має бути відкрита до таких пропозицій. Не варто будувати робочі процеси за принципом "мій дід надвір ходив, то й ми будем". Якщо ви не хочете бути завалені "законодавчим спамом", визначте чіткі правила для таких випадків: який формат пропозала, яка аргументація, за і проти. І розглядайте не для галочки, а дійсно сприймайте це як потенційні покращення.

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

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

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

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

@babichdev