Чому ти не розвиваєшся як програміст: "Чотири вершники деградації" і як їх подолати
«Кожен повинен бути самомотивуючою біологічною машиною
Євген Черняк, бізнесмен, ведучий YouTube-каналу Big Money
Поговоримо про можливі причини стагнації програміста як професіонала. На власному досвіді я поясню, що вказує на відсутність розвитку, що до цього призводить, як відстежувати власний прогрес. Поділюся інсайтами, як запобігти деградації та жити в постійному русі. Ця стаття буде корисною як новачкам, так і досвідченим IT-фахівцям.
Після кількох років роботи на одній посаді в одній компанії настає затишшя. Ти повністю адаптувався, почуваєшся у своїй тарілці, а рутинні завдання виконуєш на «автопілоті». Але є одне «але». Разом з упевненістю приходить нудьга. І одного дня ти розумієш, що виріс зі своєї посади, став неактуальним і твою роботу складно продати. А нових кар’єрних викликів на горизонті поки що не видно.
Так, бути програмістом — складно. Тут не можна просто взяти й навчитися писати код, пройти базові курси, подивитись кілька відео на YouTube, прочитати кілька книжок — і на цьому зупинитися. Бути програмістом — це як брати участь у марафоні, треба постійно підтримувати «форму», вчитися і витягувати себе із зони комфорту. В іншому разі ти ризикуєш ̶з̶і̶й̶т̶и̶ ̶з̶ ̶р̶о̶з̶у̶м̶у̶ зійти з дистанції на самому початку.
Ілюстрація Аліни Самолюк
Причини стагнації
Зі свого досвіду назву «чотири вершники деградації». Якщо в тобі відгукнувся хоча б один, знай — час щось змінювати.
Однотипні проєкти, проєкти з низькою якістю коду
Буду «кепом»: можна багато працювати, зокрема інтелектуально, але якщо ти не розвиваєшся, то деградуєш. Скажімо, обираєш середнячковий проєкт, де немає простору для зростання: з одним доменом, архітектурою, однотипним скоупом завдань. Залипаєш на ньому роками, залишаючись експертом в одній вузькій ніші.
Ще бувають проєкти, які самі собою мають низьку якість коду. І ти рухаєшся второваною стежкою, пишеш і не задумуєшся, що і як. Це теж гальмує. У результаті навички перестають відповідати ринковим потребам. І людина навіть не замислюється про те, щоб відмовитися від такої роботи.
Робота на фрилансі без команди
Багато розробників працює на фрилансі з дому. Якщо IT-фахівець один на проєкті, без команди, то він ні з ким не спілкується, пропускає новини зі світу розробки, застряє в певному технологічному стеку і не пробує щось нове.
До того як прийти в OpenGeeksLab, я півтора року був фрилансером. Працював на проєкті, власником якого був житель Аляски. Золотий клієнт. Завжди вчасно розраховувався і ніколи не сперечався за відпрацьовані мною години. Проєкт був на популярному в ті часи MEAN-стеку із використанням бібліотечки Fabric.js. І якщо перший рік я ще пиляв фічі, грався з прототипним наслідуванням для побудови кастомних об’єктів у Fabric, розбирався, як під капотом працює AngularJS digest тощо, то останні пів року просто сидів і вигадував, що б то поліпшити.
Загалом я займався проєктом сам, комунікації особливо не було. Новини зі світу технологій надходили через вузьке горлечко потреб. За півтора року я переписав цей проєкт двічі або тричі. Зрештою настав момент, коли я зрозумів, що мій професійний розвиток зупинився.
Відсутність мотивації
Коли відчуваєш постійний тиск з боку тімліда, коли над тобою тяжіють фінансові питання, коли пообіцяв зробити завдання за три дні, а насправді потрібен щонайменше тиждень, то це рано чи пізно призведе до вигорання.
Якщо в тебе неадекватний менеджмент, то залишається тільки втікати. З власного досвіду скажу, що змінити в такій ситуації мало що можна, а навіть якщо й вийде, то воно того не варте. А щоб піти, потрібно сформувати фінансову подушку безпеки. Якщо ж ти сам пообіцяв зробити завдання за три дні, а це нереально, тут питання про вміння грамотно оцінити обсяг роботи. У такому разі раджу читати туторіали про методики оцінювання.
Коли в спеціаліста є мотивація, він краще виконує завдання і цим полегшує роботу собі й навколишнім.
Професійне вигорання
Найнеприємніше, що можна уявити — це робити те, що пригнічує. І жодні гроші світу не зможуть тоді втішити. Спеціаліст опиняється в замкненому колі: виконує завдання, які не відгукуються, не розвивається як фахівець, відповідно не зростає зарплата.
Що робити в такій ситуації? Не панікувати. І читати далі.
Поради щодо розвитку
Ф̶а̶к̶а̶п̶и̶ ̶с̶т̶а̶ю̶т̶ь̶с̶я̶. У житті буває по-різному. Але людині під силу все змінити й вийти на якісно новий рівень.
Йди в ІТ, якщо справді любиш технології та хочеш вчитися
Як зрозуміти, ІТ — твоє чи ні? Для мене це дивне питання. Я шукав відповідь, йдучи від зворотного. Закінчив фізматшколу, а ще в моєму класі велику увагу приділяли вивченню інформатики. Потім закінчив виш за технічною спеціальністю. Поки вчився, зарікся бути розробником. Але коли настав час дорослішати, то зрозумів, що нічого іншого не вмію, та й, власне, простору для творчості в цій професії багато.
Якщо ти йдеш в ІТ лише заради грошей, краще не йди. Скажімо, є розробник, фреймворкер-початківець. І ось він вивчив React. Вивчив — і молодець. Але в нього починаються проблеми, коли закінчується документація щодо фреймворку. Коли людина мислить вузько, то на нову технологію потрібно знову витрачати кілька років.
Тут стають у пригоді патерни, алгоритміка, архітектурні підходи. Все це добре допомагає у вивченні нового. А нове, своєю чергою, — це добре поліпшене старе.
Ініціюй ротацію чи зміни компанію
IT-компанія повинна будувати свою культуру так, щоб діалог між менеджерами та командою був відкритим. Найчастіше люди вигоряють, а тому звільняються. Щоб цього не сталося, співробітники мають розуміти, що не буває безвихідних ситуацій і рішення завжди можна знайти.
Якщо компанія працює над кількома проєктами чи вузькими доменами і спеціалісту не подобається проєкт або домен, то гарним рішенням стане попросити про ротацію на інший. У нашій компанії це нормальна практика.
Якщо твоя компанія ніяк не стимулює професійний розвиток, то час замислитися над тим, щоб її змінити.
Візьми тайм-аут
Якщо компанія стимулює зростання, але ти все одно відчуваєш, що щось не так, то вкрай важливо взяти тайм-аут і відпочити. Ба більше, у деяких фірмах практикують відпустку від вигорання, коли можна взяти кілька днів за рахунок компанії, щоб перезавантажитися.
Що робити, щоб видихнути? Тут у всіх свої способи. Повалятися тиждень тюленем в all-inclusive чи підкорити нову гірську вершину. Зробити у вихідні генеральне прибирання чи не вилазити з піжами, дивлячись Netflix. Влаштувати вдома вечірку в стилі хюґе чи зірватися на концерт улюбленого гурту в інше місто. Як каже гугл, відповідей — безліч.
Але буває й так, що людина просто не може що-небудь робити. Тоді є сенс відвідати психолога. І це нормально. Не чекай від себе швидких результатів. Дозволь собі «настоятися», щоб потім з новими силами рушити далі.
Зміни посаду
В якийсь момент ти можеш відчути, що як розробник впираєшся в стелю, коли вклалися всі основи й тобі однаково, з якою технологією працювати. Тоді варто змінити посаду. Розробнику є куди рости далі сеньйора, тімліда чи техліда.
Наприклад, девелопери переходять у бізнес-аналітику, щоб спілкуватися як з технічними, так і з нетехнічними фахівцями.
Я за освітою системний аналітик. І це допомогло мені стати програмістом, який вміє ставити гарні питання.
Розважайся
Є ще вихід із ситуації — розважатися. Тут я маю на увазі внести в проєкт щось своє, запропонувати нетипове рішення задачі, написане «людською» мовою. Наприклад, написати бібліотечку або врапер чи навіть опублікувати в npm і заопенсорсити. Або налаштувати процес збірки або делівері, спростивши життя собі та команді.
Розвивайся
Це неправильно — з дев’ятої до шостої займатися рутинними завданнями й виконувати лише чужі вказівки. Проходь курси, навіть якщо вони не стосуються твого основного техстеку. Корисними будуть мінімальні DIY-проєкти, щоб спробувати нову технологію або архітектурний підхід.
Я у вільний час колупаю сервер, граюся з технологіями. Ще, наприклад, пройшов курс з DevOps на Udemy. Він був про те, як працює Docker і оркестровка. На мітингу поділився здобутими знаннями з колегами. Наразі в нашій компанії всі проєкти йдуть по CI/CD pipelines. Такий рутинний процес, як деплой, автоматизований на всіх проєктах, і його може зробити будь-який розробник.
Важливо хотіти створювати нове, привносити в проєкт щось своє, кайфувати від того, що твій код працює, як треба, і ти бачиш результат.
Ділися своїми напрацюваннями, адже вони допоможуть колегам отримати базове розуміння, як налаштувати ті чи інші процеси для свого проєкту, і вплинути на зростання всієї компанії загалом.
Комунікуй
Важливу роль відіграє прокачування м’яких навичок. Виходь в офлайн, виїжджай в офіс, комунікуй з колегами як зі своєї команди, так і з інших, дізнавайся, чим вони займаються, які проблеми розв’язують.
Треба робити себе кращим, спостерігати, як працюють інші, шукати критичні точки й намагатися на них вплинути.
Обирай сильніших за себе
Щоб розвиватися, працюй з людьми, які сильніші за тебе. Вивчай софтверні рішення, які реалізували більш досвідчені колеги. Починаючи з місцевих мітапів і конференцій, листування в тематичних Telegram-каналах тощо і закінчуючи спілкуванням з техлідом великої ентерпрайз-компанії.
Бери складні проєкти, пробивайся в команду людей, які розумніші за тебе. У розробці не можна стояти на місці, бо, поки ти зупинився, ком’юніті пише нову версію твоєї улюбленої бібліотеки.
Так, це складніший шлях, але й живий досвід і якісно новий результат.
Спробуй менторство
В OpenGeeksLab регулярно проходить безкоштовна інтернатура. Ми з колегами виступаємо менторами. Менторство — дуже корисна штука. Коли ведеш новеньких, то прокачуєшся сам, адже навчання в цій сфері не закінчується ніколи. На попередній інтернатурі я бачив багато нестандартних рішень у коді учнів. Вони навчили мене дивитися на деякі питання ширше і більш нестандартно.
Кожна інтернатура — це щоразу новий і крутий досвід. Це класно, коли твої підопічні стають справжніми розробниками. І це так мотивує, коли бачиш, що хлопці та дівчата не здаються, навіть якщо в них щось не виходить з першого або п’ятого разу.
Проявляй ініціативу грамотно
Щоб зрости на посаді й у зарплаті, потрібно братися за складніші завдання, ухвалювати самостійні рішення, робити корисні речі для компанії, завойовувати авторитет серед колег. Але проявляти ініціативу варто грамотно.
Я пішов в OpenGeeksLab фронтенд-розробником. Писав на Angular і сів на великий проєкт. Якось колишній CTO компанії зібрав усіх нас на тімбілдинг і розповів про мікросервіси. Мене це зацікавило. За кілька тижнів зайшов проєкт з мікросервісами. Мені довелося дуже швидко опановувати, що це таке, як взаємодіють сервіси, як працює AWS, що таке оркестровка і Docker swarn. Після того, як з усім розібрався, справа пішла, і я потихеньку перекочував у серверну інфраструктуру.
Я довгий час підкидав ідеї щодо оптимізації процесів розробки, працював з будь-яким стеком, який траплявся. Зайти на PHP? Ок. Фронт на jQuery? Ок. З цього моменту розвиватися стало простіше. Наприклад, багато фронтенд-розробників знають бібліотеку Redux Saga, але мало хто знає, що є Saga Design Pattern, а ще менше — що його можна застосовувати на бекенді.
Висновок
Робота для програміста — дуже захоплива річ, але тільки якщо кодиш те, що до душі. У розробці легко випасти з темпу і залишитися поза справами, тож вивчай нове, практикуйся.
Ніхто не каже, що буде легко. Може здаватися: «це не моє», «це складно», «не цікаво», «я не можу, у мене лапки», але, погодься, програмування дає неймовірні можливості. І хай тобі в цьому щастить!
