Один таск схожий на інший. Проєкти йдуть майже під одну копірку. Відчуття нудьги наростає. Так і до професійного «‎вигорання» недовго. Але не впадайте у відчай. Навіть з однотипними завданнями девелоперу є куди рости. Про такі можливості професійного розвитку розповідає Ігор Казубек, Head of PHP Department в ІТ-команді NIX.

Монотонна робота? Не поспішайте з висновками

Початківці часто стикаються з простими повторюваними тасками на кшталт написання подібних тестів або API-викликів із валідацією. З одного боку, це дозволяє вивчити проєкт від «‎А» до «‎Я», всю його архітектуру. З іншого — це монотонні задачі. Хіба що відрізняються в незначних деталях.

Нудно може стати і досвідченим девелоперам. Для них однотипними бувають і задачі, і проєкти. До прикладу, розробка шаблонних інтернет-магазинів на CMS типу Drupal. Відмінності можуть бути в кастомізації під запит клієнта. Підхід і реалізація схожі. Звісно, не без винятків. Одного разу моя команда створювала магазин на Sylius. Це стандартизована eCommerce платформа, але нам тоді була незнайома. Тож розбиралися і здобували нову експертизу. Тепер маємо класний досвід.

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

До того ж, кожен таск не вимагає від вас креативності. Дедлайн близько? Не гайте час, придумуючи нове. Це як у кухаря, якому треба посмажити картоплю: він може експериментувати з рецептом щоразу при новому замовленні. Але в більшості випадків клієнт просто хоче смажену картоплю, не більше. Так і в розробці. Зробіть нехай і стандартно, але швидко, якісним і перевіреним способом. Щойно з’явиться час — беріться за рефакторинг і технічний борг. Повірте, там завжди є, над чим подумати.

Зрозумійте, яку користь отримуєте від задач

Реальне життя далеке від ідеального. Можливо, ваші задачі певний час будуть подібними чи робота врешті зведеться до сапорту. Здається, це вже «‎стеля». Та давайте розберемося, що ви з цього отримуєте. Передусім, знайомитеся з розробкою як такою: процесами, ролями на проєкті, командами, Agile-підходом, методологіями Scrum або Kanban. В аутсорсі можете спілкуватися з клієнтами і прокачувати англійську, заглибитись в ту чи іншу сферу бізнесу, щоби краще розуміти замовника. Так потреби клієнта вдасться перетворювати у потрібні технічні рішення.

Як допоможуть Open Source та pet-проєкти

Шукайте нові професійні виклики в опенсорсних чи пет-проєктах. Можна робити те, що цікаво і найбільше подобається. Але подумайте: які знання та навички звідти ви перенесете в поточний проєкт?

Поділіться ідеями з керівником. Можливо, ваш інтерес до певної мови програмування чи технології лід спрямує у взаємовигідному напрямку: і для вас, і для команди. Працюєте на бекенді? Пошукайте опенсорс, де попрактикуєте Vue.js або React. Це гарний шлях до Full Stack розробки. Універсальному девелоперу знайдеться місце в багатьох проєктах.

Над pet-проєктом раджу подумати комплексно. Наведу особистий приклад. Одного разу вирішив побудувати пет-проєкт на фреймворці Laravel (використовував його на основному проєкті). Затестив кілька цікавих рішень, які переніс у робочий проєкт. Але як згодом пояснили досвідченіші колеги, це було не найкраще виконання. Проте вони порадили, як цю технологію обіграти інакше. Це додало мені нових, дійсно корисних знань.

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

Про інші шляхи всебічного розвитку для ІТ-спеціалістів читайте у повній версії блогу.