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

Розробниця Кейрстен Фей у своєму блозі на Medium поділилася, як будувалася її кар’єра у сфері програмного забезпечення у 2022 році. Передаємо їй слово.

Подорож джуніора

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

1. Її робочі будні виглядають так: цілими днями вона сидить за робочим столом, штампуючи тисячі рядків коду у місяць.
2. Але якщо дівчина якісно виконує свою роботу, то поступово завойовує довіру команди. З часом вона отримує додаткові запрошення на зустрічі від стейкхолдерів проєкту. Її керівник пропонує їй працювати над більш масштабними проблемами.
3. Її робочі задачі змінюються: замість того, щоб виконувати вузькі та чітко визначені завдання, вона починає працювати над проєктними документами, де окреслює проблемні області та описує можливі рішення. І от вже вона витрачає на кодинг не 90% свого часу, а, скажімо, 80% чи навіть 70%.
4. Дівчина здобуває новий досвід. Вона вже може жонглювати кількома власними проєктами одночасно та більш активно долучатись до командних. Завдяки практиці, вона описує нові функції та ідеї щодо вдосконалення швидше, але уже не встигає їх всі реалізовувати.
5. І коли менеджер бачить це, він пропонує, щоб хтось з команди допомагав їй. Але ставить умову: усе проєктування та планування має бути виконано заздалегідь. Дівчина погоджується, записує та передає перший десяток завдань колезі.

Если вы задумываетесь над тем чтобы начать изучение программирования, то идеальным вариантом для старта будет Python. Он имеет простой синтаксис по сравнению с теми же Java и C++. Качественными курсами, после которых можно трудоустроится, считаются занятия в Mate Academy и Powercode Академии.

А як же кодування?

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

Чим досвідченішою я стаю, тим більше змінюються мої завдання: продуктивність вимірюється уже не тим, стільки рядків коду я написала, а тим, як я можу керувати проєктами та бути ментором для інших.

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

Що з цим робити?

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

Мій шлях

У перший робочий день 2022 року я приєдналась до нової команди Meta. Я озвучила менеджеру свою мету — розвивати навички за межами моєї сфери знань (UX). Я хотіла глибше зануритися у бекенд, щоб розвинути свої Т-подібні навичкиT-shape спеціаліст — це людина, що поєднує глибокі експертні знання у своїй сфері з широкими знаннями в суміжних галузях. Зізнаюся, я також хотіла приборкати синдром самозванця, що розвинувся під час роботи на такій високій посаді в технологічній сфері.

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

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

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

Мій менеджер пропонував мені очолити виправлення проблеми з продуктивністю UI. Але я була не в захваті.

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

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

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

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

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

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

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

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

Але все ж, варто визнати, що вміння вчасно сказати «ні» — це важлива навичка, яка потребує практики, і що ніхто не повинен шкодувати про те, що став на захист власного психічного здоров’я.

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

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

Причини, чому ви можете не писати код

Кодинг ніколи не займе 100% вашого часу. Навіть джуніори мусять відвідувати зустрічі та виконувати завдання, не пов’язані з кодуванням. І у процесі вашого професійного розвитку буде все більше роботи, що не пов’язана з кодуванням. Окрім відвідування зустрічей, я виділила ще кілька важливих обов’язків.

1Написання або оновлення документації

Почніть робити це в будь-який час і ніколи не зупиняйтеся. Не буває «недостатнього досвіду» — навіть нові працівники можуть почати із заповнення будь-яких концептуальних прогалин або «неполадок», з якими вони зіткнулися.

2Написання дизайн-документу

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

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

3Вдягання «іншого капелюха»

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

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

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

4Наставництво інших розробників у вашій команді

Коли у вас з’явиться достатньо досвіду, вас будуть просити допомагати з онбордінгом новачків-розробників. І це покращить не лише ваші комунікативні навички, а й promotion packet.

Поділюсь декількома порадами, як стати уважним наставником:

• Дайте новачкам зробити свій внесок у спільну справу (під вашим керівництвом). Спочатку давайте чітки і зрозумілі завдання з мінімальним рівнем неоднозначності. З часом підвищуйте складність.

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

• Зустрічайтеся регулярно 1:1 — це може бути 15-30-хвилин щотижня або раз на два тижні протягом перших кількох місяців. Зверніть увагу на будь-які проблеми, які виникають у новачка та ознайомте з ними менеджера чи техліда.

Висновок

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

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

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

Авторка: Кейрстен Фей

Текст адаптувала Євгенія Козловська