Один таск схожий на інший. Проєкти йдуть майже під одну копірку. Відчуття нудьги наростає. Так і до професійного «вигорання» недовго. Але не впадайте у відчай. Навіть з однотипними завданнями девелоперу є куди рости і розвиватися.
Монотонна робота? Не поспішайте з висновками
Початківці часто стикаються з простими повторюваними тасками на кшталт написання подібних тестів або API-викликів із валідацією. З одного боку, це дозволяє вивчити проєкт від «А» до «Я», всю його архітектуру. З іншого — це монотонні задачі. Хіба що відрізняються в незначних деталях.
Нудно може стати і досвідченим девелоперам. Для них однотипними бувають і задачі, і проєкти. До прикладу, розробка шаблонних інтернет-магазинів на CMS типу Drupal. Відмінності можуть бути в кастомізації під запит клієнта. Підхід і реалізація схожі. Звісно, не без винятків. Одного разу моя команда створювала магазин на Sylius. Це стандартизована eCommerce платформа, але нам тоді була незнайома. Тож розбиралися і здобували нову експертизу. Тепер маємо класний досвід.
Як на мене, все залежить від ставлення до однотипності в роботі. Раджу спробувати змінити погляд на ситуацію. Це можуть бути задачі заради нових навичок чи щоб отримати бенефіти від клієнта, компанії тощо. Тоді ця на перший погляд монотонність вже не проблема, а необхідні дії для досягнення бажаного результату.
До того ж кожен таск не вимагає від вас креативності. Дедлайн близько? Не гайте час, придумуючи нове. Це як у кухаря, якому треба посмажити картоплю: він може експериментувати з рецептом щоразу при новому замовленні. Але в більшості випадків клієнт просто хоче смажену картоплю, не більше. Так і в розробці. Зробіть нехай і стандартно, але швидко, якісним і перевіреним способом. Щойно з’явиться час — беріться за рефакторинг і технічний борг. Повірте, там завжди є, над чим подумати.
Зрозумійте, яку користь отримуєте від задач
Реальне життя далеке від ідеального. Можливо, ваші задачі певний час будуть подібними чи робота врешті зведеться до сапорту. Здається, це вже «стеля». Та розберімось, що ви з цього отримуєте. Передусім, знайомитеся з розробкою як такою: процесами, ролями на проєкті, командами, Agile-підходом, методологіями Scrum або Kanban. В аутсорсі можете спілкуватися з клієнтами і прокачувати англійську, заглибитись в ту чи іншу сферу бізнесу, щоби краще розуміти замовника. Так потреби клієнта вдасться перетворювати у потрібні технічні рішення.
Як допоможуть Open Source та pet-проєкти
Шукайте нові професійні виклики в опенсорсних чи пет-проєктах. Можна робити те, що цікаво і найбільше подобається. Але подумайте: які знання та навички звідти ви перенесете в поточний проєкт?
Поділіться ідеями з керівником. Можливо, ваш інтерес до певної мови програмування чи технології лід спрямує у взаємовигідному напрямку: і для вас, і для команди. Працюєте на бекенді? Пошукайте опенсорс, де попрактикуєте Vue.js або React. Це гарний шлях до Full Stack розробки. Універсальному девелоперу знайдеться місце в багатьох проєктах.
Над pet-проєктом раджу подумати комплексно. Наведу особистий приклад. Одного разу вирішив побудувати пет-проєкт на фреймворці Laravel (використовував його на основному проєкті). Затестив кілька цікавих рішень, які переніс у робочий проєкт. Але як згодом пояснили досвідченіші колеги, це було не найкраще виконання. Проте вони порадили, як цю технологію обіграти інакше. Це додало мені нових, дійсно корисних знань.
Тож не бійтеся дискутувати з колегами. Головне — майте аргументи. Скажімо, використали в опенсорсі незнайому бібліотеку та хочете додати її в робочий проєкт. Проаналізуйте метрики цієї технології, щоб показати переваги, підготуйте кодову базу. Навіть якщо команда відмовиться від ідеї (може, у фреймворку є аналогічне рішення, про яке ви не знали), обговорення все одно піде вам на користь. Технічним фахівцям теж важливо вміти пояснювати свої ідеї.
Завжди є варіанти для всебічного розвитку
Окрім технологій, можете вивчати домени. Дізнайтеся, як працюють аналоги вашого продукту, подивіться код Open Source-конкурентів, почитайте про юридичні аспекти регулювання галузі. Це дозволить поступово перейти до складніших тасків, на рівні архітектури. А ще такі знання підвищать вашу фаховість в очах замовника.
Джуну буде складно зрозуміти особливості коду конкурентів. Тому початківцям я раджу передусім добре знати, що і чому ви робите на проєкті. Зрозумійте відмінності у підходах до виконання задач. Тоді вхід до типових проєктів буде впевненим. А з позитивним фідбеком від колег, керівників, замовників — беріться за складніші технічні завдання. Без них ніяк для подальшого розвитку.
Маючи технічну базу, ви відкриваєте для себе ще один цікавий напрям — менторство. Але зважайте, що тут треба любити доносити людям інформацію. Інколи одну й ту саму, інколи дуже часто. А також слідкувати за прогресом підопічного, надавати фідбеки. Готові ділитися досвідом і допомагати зростати іншим? Поцікавтеся в ліда можливістю стати ментором для когось у команді. Можливо, вже є учень, може, і не один. Не обов’язково у вашому проєкті, але який працює з аналогічними технологіями.
Якщо ж в команді немає новачків, спрямуйте шерінг знань за межі колективу. Пишіть статті для блогу компанії, записуйте подкасти, читайте лекції на внутрішніх конференціях чи подавайтесь як спікер на сторонні івенти. Якщо боязно виступати публічно, потренуйтеся в ближньому колі колег. Вивчіть технологію, підготуйте презентацію та поділіться інсайтами. Це плюс до розвитку ораторських навичок. Окрім того, так можна підсвітити прогалини у знаннях. Раптом слухачі поставлять питання, на які у вас не буде відповіді. От вам і привід повернутися до теми і дослідити її глибше.
Менеджмент як ще одна можливість урізноманітнити роботу
З сильним технічним бекграундом і досвідом менторства, спробуйте вийти на вищий рівень — менеджерський. І тут варіантів розвитку безліч: від побудови комунікації із замовником до розробки архітектурних рішень. Звісно, управління командою підходить далеко не всім. Щоб зрозуміти, наскільки це «ваше», почніть з малого — менеджменту окремої частини команди на проєкті.
Колись у мене на проєкті на трьох спеціалістів були однотипні завдання. Я б міг копати вглиб, займатися чимось суто технічним. Але захотілося поменеджерити. Пішов до РМа, і виявилося, мій запит дуже своєчасний. Наша менеджерка стикнулася з новими викликами і запропонувала мені поетапну передачу справ та сапорт. Задачі прості: сетап мітингів і комунікація з клієнтом. Та я все одно відчув новизну і велику відповідальність. А головне — зрозумів, що мені це подобається навіть більше, ніж програмування. Відтоді я працюю в цьому напрямку. Водночас коли спробував піти в бік техліда, для мене це стало надто складною задачею. Проблеми визнав і я, і колеги, і ліди. Порадившись із керівництвом, повернувся до менторства.
Як бачите, все вирішила відверта комунікація. Тому не соромтеся говорити про свої амбіції так само як і про труднощі. Це може стати початком вашого розвитку в будь-яких завданнях і напрямках.