Що означає бути джуніор-розробником?

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

Вимоги

Важливо зрозуміти, що в позиції джуніор-розробника визначним є поняття розробник, а джуніор — це другорядна ознака. В Binary Studio ми визначили рівні розробників наступним чином:

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

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

Сіньйор — досвідчений розробник, гарний комунікатор. Йому можна довірити вирішення критичних завдань. Може бути лідером розробки частин або цілих систем, менторити інших членів команди.

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

Отже, за нашим визначенням джуніор — це не безпорадний студент, а спеціаліст, що вже володіє достатнім набором знань. Що означає достатній? Тестове завдання на джуніора, яке ми просимо виконати кандидатів, це туду-ліст. Для прикладу, JS-розробник має створити і бекенд на Node.js з роботою з базою даних, і фронтенд на React або Angular. Так, це найбанальніше завдання, яке може спасти на думку, проте воно дає нам змогу побачити, наскільки добре людина розуміє концепції веб-програмування та може їх реалізовувати, доклавши мінімальних зусиль.

Врешті, головна різниця між джуніором та іншими позиціями — це досвід, що не має багато спільного зі знаннями як такими. Досвід впливає на швидкість і якість прийняття рішень: щодо чого радитись з командою, а що робити самому; про які рішення питати в замовника, а які приймати самостійно; що потребує негайного вирішення, а що може почекати. З цього випливає і неавтономність джуніора — реалізовувати завдання він вміє непогано, але ще не навчився добре оцінювати їх складність, бачити ризики і розставляти пріоритети. Коли навчиться, стане мідлом. Зазвичай у випускників Академії на це йде близько 2 років.

Становлення

Як можна отримати досвід програмування, якщо роботодавці відмовляють в працевлаштуванні через брак досвіду? Напевно, це є найпоширеніший приклад пастки-22 — правила, яке містить в собі протиріччя.

Певний час після закінчення навчання я вважав, що це мала б бути функція університету — підготувати студентів до вимог ринку, але згодом змінив свою думку. Знання, що затребувані на ринку праці саме сьогодні, мінливі — за 5 років навчання вони можуть втратити свою актуальність. Якби на 2 курсі університету викладали ASP.NET MVC, то до моменту випуску студентів Майкрософт вже зарелізив би 3 версію ASP.NET Core з суттєво зміненими парадигмами (я вже не кажу про фронтенд фреймворки). Університет як довгострокова освіта, на мою думку, має давати фундаментальні технічні знання, що не змінюватимуться десятиліттями, формувати критичне мислення та світогляд.

Натомість Binary Studio Academy покликана закрити саме цю прогалину між фундаментальними теоретичними знаннями і актуальними потребами ринку. Місія нашої Академії — трансформувати найталановитіших студентів у найталановитіших веб-інженерів. Академія дає сучасний досвід з веб-розробки: використання останніх версій мови та платформ, уміле володіння фреймворками, досвід роботи з базами даних та хмарними сервісами. Інвестиція 2.5 місяців в отримання цього досвіду видається мені абсолютно доцільною, адже після закінчення Академії ви легко можете отримати позицію джуніор-інженера та застосувати щойно отримані знання (потрапити в Академію і успішно пройти всі етапи зовсім не так легко, але цілком реально. Все в руках самого студента).

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

Проект

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

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

Для ілюстрації моїх слів хочу навести приклад мого поточного проекту. Ми розробляємо інструмент для моделювання NoSQL даних, яким користуються великі технологічні компанії, як-от IBM, Atlassian чи Microsoft (ви можете детальніше ознайомитися з ним за посиланням). У моїй команді чотири розробники, двоє з них — джуніори. Вони працюють над завданнями будь-якої складності — наприклад, розробка нових плагінів баз даних, що вимагає швидкого ознайомлення з абсолютно незнайомим DB API та реалізації ефективного обходу дерев, в яких зберігаються дані додатка. Їхня робота йде в реліз поряд із роботою інших членів команди, інакше позиція джуніора на проекті не була б виправдана.

Детально про очікування клієнта від джуніор-розробників йдеться в статті мого колеги Едварда (англійською).

Компанія

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

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

Не в останню чергу таке ставлення зумовлено тим, що 60% працівників компанії — це випускники Академії (звичайно, що велика частина з них випустилася достатньо давно і вже встигла попрацювати на декількох проектах на різних позиціях. Наприклад, я закінчив Академію 2012 року). Це породжує порозуміння, адже ми йшли цим самим шляхом кілька років тому, а також довіру, адже ми знаємо, що випускники Академії — це обов’язково талановиті розробники.