Про фейкових інженерів, або Чому я недолюблюю Stack Overflow Driven Development
Розкажу вам одну історію, яка трапилась не так давно та змусила мене шукати відповіді на питання «Що не так зі Stack Overflow?» та «WTF?»
Все почалося з того, що на одному з проектів компанії Erbis, над яким я працюю вже понад три роки, почали розширювати команду інженерів Java. Мене, як тім ліда, запросили проводити інтерв’ю з кандидатами. Знаю, що зараз ситуація на ринку IT неординарна і у більшості випадків останнє слово саме за розробниками. Але коли Java-інженер з досвідом 5+ років претендує мінімум на 5 штук баксів і не може вирішити на співбесіді просту задачку (і мова тут не про тестове завдання), яка передбачає нескладну логіку і знання базових алгоритмів... варіант з закиданням оферами відпадає.
Сорян, та далі буде швидше про закидання віртуальними помідорами.
Обережно, сеньори, полетять помідори
Було б не так сумно, якби не ситуація, що сталася декілька днів потому, коли зелений «джун» вирішив ту ж саму задачку, не зіпрівши, за 10 хвилин. Може, ще свіжими лишилися принципи й методології з універа чи з курсів, та було дивно, як Junior Java Developer зміг переплюнути Senior Java Engineer?
Відповідь можна вмістити у два слова: Stack Overflow.
Річ у тому, що наш «Mature Senior» настільки звик гуглити й копіпастити, що підзабув основи мови, на якій кодить і самостійно будувати рішення. Але в такому разі постає питання чи доречно називати такого спеціаліста інженером?
Згідно Вікіпедії, «інженер — це особа, яка на основі поєднання прикладних наукових знань, математики та винахідництва знаходить нові рішення технічних проблем». Нові рішення. А не відстежує відповіді на вищезгаданому ресурсі.
Працюєш з JakartaEE? З мене пиво!
Аналізуючи ситуацію далі, я дійшов висновку, що більшість «інженерів» працюють з технологією Spring/Spring Boot. Одразу скажу: так, мій проект на JakartaEE, але я не маю на меті докинути на вентилятор субстанції кольору #964B00, підігріваючи холіварну тему, що краще Jakarta EE чи Spring.
Насправді, написати REST сервіс, що отримує дані з бази даних, можна однаково добре, як на Spring, так і на Jakarta EE. З першим, звісно, буде швидше, бо на те, щоб знайти до компонента А компонент B на Stack Overflow і змусити їх працювати разом, піде небагато часу. Але фішка у тому, що коли потрібна кастомізація, заготовки для Spring часто не спрацьовують.
У випадку з Jakarta EE ви, зазвичай, теж підете спочатку пошукаєте чи не виклав хто готове рішення? Але вже за півтори години зрозумієте, що вихід один: закотити рукава і кодити.
Jakarta EE — це як вивчити польську
При цьому я не маю жодних претензій до Spring чи Stack Overflow, бо річ не в тім, що збільшується кількість конфігурацій і інтерфейсів, а у тому, що збільшується кількість розробників, які виконують типові задачі, і зменшується число тих, хто може запропонувати нестандартні рішення.
Не дивлячиь на те, що проект з Кремнієвої долини, над яким я працюю, побудований за допомогою Jakarta EE, ми розглядали у тому числі і Java-інженерів з досвідом Spring. Бо, за великим рахунком, перейти (особливо сеньйору) зі Spring на Jakarta EE — це як перейти з української школи до польської. Тобто розуміти мову ти будеш від самого початку, з арифметикою також все буде ок, читання і письмо треба буде підучити, ну ще танці будуть без бубна.
На жаль, у багатьох досі жива асоціація Java з EJB і іншими страшними речами
З мого досвіду, наразі реально крутих проєктів, побудованих на Jakarta EE, у Штатах та Європі вистачає. Тож списувати цю технологію з рахунків зарано. Більш того, на відміну від Spring, вона стимулює рости і розвиватися.
Якщо ви вирішите спробувати сучасну Jakarta EE і впевнитися у її потенціалі, запрошую до співпраці.
Найкращі коментарі пропустити