Чим старше дев — тим він краще

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

Наприклад, для молодого девелопера новий фреймворк або генеративний ШІ — це виклик, трохи азарту і багато «а раптом щось піде не так». А старший розробник дивиться на те саме і просто думає: «Окей, тут будуть підводні камені», і вже має уявлення, як їх обійти. Він розуміє, де реально можна експериментувати, а де краще тримати під контролем.

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

То як думаєте: досвід завжди робить старшого девелопера кращим? Чи іноді швидкість і свіжий погляд молодшого можуть дати перевагу?

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Є розуміння не суб’єктивне, а об’єктивне в числах якихось, що таке хороший і що таке поганий? Крім того акі числа цікавлять конкретно взяту компанію, конкретно взятий відділок, проект та менеджера. Бо те що важливо для одної людини і типу бізнесу і іншої і іншого типу бізнесу це радикально протилежні речі можуть бути. Для одних важлива висока структурна та алгоритмічнга якість коду — щоби програмний продукт був високо надійним і добре підтримуваним, не вимагав мільйонів долларів на обладнання та електрику тощо.
Для інших висока швидкість впровадження в бізнес функціональних вимог, щоби намацувати попит та збільшувати виторги і прибутки. Третім взагалі найкращім програмістом буде технічний консультант — торговець, який зможе переконати клієнта, що йому треба прибрати з проекта усіх інших вендорів, та негайно винайняти 50 джуніорів саме з вашого акаунта і випускників саме вашої лаби і не важливо яким само методом це буде досягнуто і який на виході буде софт — бо від цього прибутки безпосередньо не залежать. Подробиці у Адізеса.
А так от той же Стів Джобс звільнив колись головного іженера команди Lisa — бо той будував компьютер для NASA як його вчили по американский космічній программі і як він вважав правильним.
В той же час Джобс будував компьютер для середнього бізнесу і конфлікт стався просто на базі кількості шрифтів. Джобс чудово знав, що без шрифтів той компьютер покупцеві — нафіг не здався. www.youtube.com/watch?v=x9xPX3WiK3E Конфлікт вважається еталоном IT конфліктів і проблеми із нерозумінням бізнесу і інженерів.

Скорее тем вероятнее, что она сольется в ближайшие год два...

Різниця між юним та досвідченим розробником у тому, що коли бізнес-інтереси та best practices написання коду конфліктують між собою, то юний розробник приносить в жертву бізнес-інтереси заради коду, а досвідчений жертвує якістю коду заради бізнесу.

это галерный булшит, на самом деле почти всегда можно ничем не жертвовать

Це якраз частина мислення яке відрізняється. Ви як досвідчений спеціаліст від початку знаєте, що : Clean Code, Clean Architecture, Design Principle and Patterns, CI/CD тощо це в кінцевому обійдеться дешевше. Бізнесмен думає абсолютно не так, йому треба — щоби було більше прибутку маржі, якщо він не може збільшити виторг і середню суму по чеку — тоді він прагне зниження собівартості, міняє сініорів на джуніорів, дає на одну людину 3+ профільних обов’язків чи проєктів, урізає обладнання сервери, офіси бініфіти, страхування, відпустки тощо або просто краде рейт — виставляє команди на безкоштовні овертайми без оплати.
І часто він йде просто найпростішим шляхом — влаштовує внутрішню конкуренцію, щоби збити ціну на послугу з розробки софту яку купляє на ринку.
Коли програміст боїться — що в нього впаде продакшн чи вийде продукт із купою багів повільний і при цьому використовуючи забагато апаратних ресурсів тобто топить за якість, то бізнесмен боїться що він прогорить або витратить час не рентабельно, тобто замало заробить і конкуренти його обійдуть. Якість при цьому звісно йому теж треба, але не за рахунок власного прибутку. І лаятись він буде тільки коли стануться проблеми із бізнесом через низьку якість — що насправді не така вже і рідкість, коли потім перероблюється софт за індусами та комсомольськими командами з поганою підготовкоюю, та за якими погано слідкували і менторили.
Отримати тут Win-Win доволі складно, сучасна виробничість праці, швидкість і якість підготовки спеціалістів, стани ринків тощо не відповідають ситуації на ринку, бо на ньому червоний океан конкуренції. По 70 людей на робоче місце і по 5+ компаній на один прожект. Вихід з ситуації — виключно в інноваціях. Велике американське вміння як відомо полягає не в задоволенні потреб — а в створенні цих потреб.

это все «за скобками» мы ведь про сам подход, делать хорошо, или делать плохо оправдывая что так лучше бизнесу, нет так не лучше. нужно делать быстро и качественно

Що ж це за best practices, які йдуть у розріз з бізнес-інтересами? Але як на мене це більше культурне явище. Не так давно панувала думка, що молоді розробники погані, бо не знають best practices та пишуть гівнокод. Зараз навпаки, що знають best practices і надто фанатично до них підходять.
По факту це скоріше людські якості. Є догматики в 20 років і в 50, і є прагматики в будь-якому віці. Досвід не гарантує мудрості, а молодість не означає фанатизм. Є клінічні випадки серед досвідчених також, але більшість все ж таки досить раціонально підходить, тому не можу сказати що це питання віку чи досвіду.

І той в інший кейс це BS. Правильних підходів в розробці які б існували у відриві від бізнес цілей немає. Не може бути правельний код або дизайн якщо він шкодить бізнес цілям. Може бути тільки не розуміння бізнес цілей і/або не відповідність інструментів що використовується до цих цілей.

Чим старше дев, тим він більше вигорівший

Можу авторитетно порівняти — бо був і молодим ентузіастом і досвідченим динозавром.
Я прийшов у компанію вигравши олімпіаду, яку компанія влаштовувала на увесь Харків. Тоді я вже закінчував ВУЗ з червоним дипломом. І був наймолодшим джуном у компанії (тоді ще брати 16-річних не було меінстрімом)
Основною мовою програмування я тоді вважав C++, хоча більшість курсачей та шабашок робили на Делфі (або С++ Builder — але він був дуже вередливий). Але більшість балів на олімпіаді я отримав по Java — бо вона тоді тільки нещодавно з’явилася і мені було цікаво її вивчати як майбутню «мову Інтернета».
Але перша моя справжня вакансія на реальному проєкті була ... DBA! Бо тоді майже уся складна логіка по збору і обробці даних робилася у базі. І перфоманс бази був найбільшою проблемою: бо аплікейшини переважно були GUI і працювали у клієнтів на компах — але база була одна на усю компанію і усіх юзерів. На той момент я знав SQL на відмінно — вмів будувати і оптимізувати будь-які запити бо прочитав багато книг і награвся з базами у ВУЗі.
Отже: перевагою молодого девелопера можуть бути свіжі теоретичні знання, яких може бракувати досвідченим девелоперам які працюють постійно з одним стеком. Так у команді, де я став ДБА, були переважно досвідчені VB девелопери, а от SQL глибоко ніхто не знав.
Так само я активно долучався до оцінки та архітектури нових Web проєктів. Знову тому що девелопери з досвідом переважно робити десктоп, а Web тоді був чимось новим і мало хто знав HTML, CSS та такі технології як XML — XSLT, SOAP сервіси, а ще аплети, сервлети, ActiveX в браузері і усі інші модні тоді штуки. У ВУЗі і на стажуванні у мене було багато часу для само-навчання і отримання Бреінбенч сертифікатів. Отже на роботу я прийщов з невеликим досвідом — але з великим і різноманітним теоретичним знанням передових технологій.
Не може сказати що деякі архітектурні рішення молодої команді були ідеальні. Але як мінімум вони були інноваційні та креативні. Наприклад був проєкт, який ми називали 1-tier архітектура: була тільки база, де процедури приймали та віддавали XML, і при цьому вони були відкриті як HTTP ендпоїнти (MS SQL таке дозволяв зробити легко). Отже на сервері була тільки база — а UI формувався шляхом XSLT трансформації прямо в браузері! Це дозволяло швидку і гнучку модифікацію, простий деплоймент та можливість робити різні UI «скіни» для різних юзерів. Усе це було не тільки до початку фронтенду а навіть до ASP.Net.
А от досвід перетворює синьйора на Шерлок Холмса! Пам’ятаєте як він пояснював свій «дедуктивний метод»:

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

Досвід дозволяє помічати деталі, бачити закономірності, будувати ланцюжок висновків та будувати і перевіряти гіпотези. Саме це необхідно коли приходиш працювати на проєкт, де сотні девелоперів за десять років написали сотні тисяч файлів коду. І де ніхто вже не пам’ятає що де і як працює. Досвід — це єдине що допомагає зорієнтуватися. Так само як досвід пошуку і виправлення помилок іноді дає можливість просто побачивши колстек помилки зрозуміти у якому випадку вона виникає.
А ще досвід значно полегшує розуміня нових технологій. Наприклад що там зараз у моді — мікросервіси? А раніше це називалося Service Oriented Arhitecture, а ще раніше були COM компоненти, Java Beans і усяке таке. Тому що інженерна думка іде по-спиралі і кожен виток повторює попередні ідеї з деякими варіаціями. І досвід дає можливість побачити недоліки свіжих модних фреймвоків. Наприклад у ASP.Net давно вирішені проблеми глобалізації, різних таймзон і навіть підтримки користувачів з обмеженими можливостями. А візьмете модний фронтенд фреймвок — і там про такі речі навіть ніхто не думав. Будьте готові шукати якісь сторонні рішення чи імплементувати усе самим. Є 100500 речей про які досвідчений девелопер подумає на старті нового поєкту. А от молодий відразу кидається у бій — а про такі речі ак перфоманс чи скалабіліті думають вже перед релізом.
Я завжди мріяв розробляти нові інноваційні проєкти «з нуля» на передових технологіях. Декілька разів навіть вдавалося — але це були переважно невеликі «стартапи». Сумно визнавати — але найбільшу користь я приносив як раз на величезних легасі ентерпрайз проєктах це досвід розбиратися у хаосі ніщо не може замінити.

На той момент я знав SQL на відмінно — вмів будувати і оптимізувати будь-які запити бо прочитав багато книг і награвся з базами у ВУЗі.

Я до сих пор не знаю SQL на відмінно и оптимизировать будь-які запити не могу, хотя занимаюсь всю жизнь. Наверное вуз не тот LOL

Знати SQL на відмінно за вузівськими вимогами — не так вже й складно. Але є суттєва різниця між абстрактними навчальними базами та базами IRL.

Я вважаю, що, як і в будь-якій іншій справі, в ДБА працює правило «10000 годин/5 років». Спочатку 5 років інтенсивної праці за напрямком, і дуже бажано — на різних реальних проектах, і лиш потім — статус гуру.

То был сарказм. SQL не так прост как многие считают. ВУЗовский уровень, это не уровень вовсе -,да простят меня выпускники.

Наприклад, для молодого девелопера новий фреймворк або генеративний ШІ — це виклик, трохи азарту і багато «а раптом щось піде не так». А старший розробник дивиться на те саме і просто думає: «Окей, тут будуть підводні камені», і вже має уявлення, як їх обійти. Він розуміє, де реально можна експериментувати, а де краще тримати під контролем.

Не совсем так.
У нас стафф, вроде не молодой, за 40, а купился на это в середине проекта. Вышел с инициативой напилять агента и закончить проект за недели а не за месяцы. Прошло две недели и на митингах звучит апдей ‘в нештатный режимах лучше контролировать процесс инженерам’ сколько таких нештатных режимов — оказалось достаточно.

Вторая инициатива, а давай те напиляем агента который будет оптимизировать запросы ! От того жк стафа.
Ну чтож, начал агент оптимизировать — сжег кучу ресурсов (читай бабла) изза выполнения — проверки, напилял код который наполовину говно, так еще и оптимизация мизерная.

Ну такое

Ах да молодешь просто видит в этом решение всех проблем.
Синьоры тупо генерируют проекты в которых никто дупля не вяжет что оно такое.

Это проблема большого масштаба, и не только изза энтузиазма

там де добре спрацював ШІ це репортінг DWH, додали RAG по dsl, апі навчили його і замість складних запитів можна розмовляти по-людськи, типу покажи мені дані у розрізі такому-то, фільтрані по країнам ЄС та додай ще Африку але не Єгипет. Як раз 40+ сіньорами задумано і зроблено, усі щасливі. Але добре що 50+ дядьки трохи контролюють ентузіазм і не все ШІзують

Мы наверное «разрешили» инициативу ибо было очевидно что то провалится. Простые вещи пусть ши делает. Но есть critical участки, куда рано еще.

ибо было очевидно что то провалится

Угу, і ніхто не міг об’яснити. Чи ви об’ясняли а він не слухав?

Тоді:
1. Як так сталося що він вами руководить а не ви ним
2. А вам не пофіг? Зайва можливість в робочий час прокачати ШІ скіли і набратися досвіду, ще й платять за це. Це краще ніж фомрольопати.

1.Разрешили в ковычках, чтобы было понятно кто чем руководит.
2. Это проект и ресурсы ограничены, в том числе людские. Риск был согласован ибо стафф писчал и рисовал радужные картины будущего.
Нет нам не пофиг.

Я бачу що у команди або не було компетенції зробити все правильно, або не було компетенції і довісвіду об’яснити що конкретно в цій задачі не вийде.

Лол. Да, местные эксперты все знают и все видят.

Найсмішніше те, що це пише той трамп, у якого АІ весь код пише і скоро всіх замінить

Да, там опилки останутся у таких в башках.
И так уровень хромает, а с приходом ши вообще потеряем поколение.

Зы -+ местных экспердов знаю ;)

Джунів вже чимало втратили за 3 роки, тому молодь не прагне до вступу на комп’ютерні науки

Не поступают те кто не видят там перспектив.
Разве это значит что не будет выпускников — отнюдь. Среди них будет меньше мотивированных баблом и больше тех кто идет по призванию.

у якого АІ весь код пише і скоро всіх замінить

давай конкретні посилання на цитати

використовує АІ тулзи, вайб кодить != АІ весь код пише
виставить більшість на мороз, особливо джунів, мідлів != всіх замінить

ну ви ж читати не вмієте, бачите те щ хочете бачити, додумуєте своє, щоб потім можна було накидати не вентилятор

давай конкретні посилання на цитати
У мене в залежності від проекту, до 90% АІ коду

Ще пам‘ятаю був коментар «я вже більше року не пишу код», але не можу його знайти, може видалив, а може то коментар іншого трампа.

виставить більшість на мороз, особливо джунів, мідлів != всіх замінить

Саме так, залишиться один трамп, який буде власноручно за допомогою Ші писати весь код у світі, тож технічно ви праві, завжди можна сказати, що півтори каліки ще кодять, значить ші всіх не замінив.

ну ви ж читати не вмієте, бачите те щ хочете бачити, додумуєте своє, щоб потім можна було накидати не вентилятор

Хто без гріха хай перший кине в мене камінь

Ще пам‘ятаю був коментар «я вже більше року не пишу код», але не можу його знайти, може видалив, а може то коментар іншого трампа.

Те що деякі проекти 90% це не значить що всі проекти на 100%. А так да, у деяких відсоток АІ коду 90%, у деяких 50%, у деяких 10%.

І це у мене ще слабенький воркфлоу. Якщо зробити все по феншую, то відсоток АІ коду буде більший, просто часу немає агентів і промти тюнити, дедлайни не чекають.

завжди можна сказати, що півтори каліки ще кодять, значить ші всіх не замінив.

Це будуть ваші аргументи. Половину замінить, а ви будете казати: «а всіх то не замінив!».

По факту, уже 10-15% звільнив, може не був основною причиною но точно посприяв. Це через layoffs останні 2 роки і через недобраний персонал (зазвичай набирали по 10-20% в рік а тут не те що не набирали а звільняли.

Це будуть ваші аргументи. Половину замінить, а ви будете казати: «а всіх то не замінив!».
виставить більшість на мороз, особливо джунів, мідлів != всіх замінить
ну ви ж читати не вмієте, бачите те щ хочете бачити, додумуєте своє, щоб потім можна було накидати не вентилятор

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

«а всіх то не замінив!».

я хз

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

Ось вам темпоральна цікавинка:
Якщо мозок щось «бачить» у майбутньому, як він це розпізнає? Правільно, потрібно дуже багато досвіду, потрібно мати накопичену базу подібних "картинок«/образів, щоб порівняти і визначити, яка саме халепа чекає на розробника там, у майбутньому.
Тому відповідь: досвід рулить.
Але, скільки триває оте саме розпізнання? Чим більша ота накопичена база образів, чим її обсяг більший, тим довше триває процесс розпізнання:
Менеджер: Ну то як?
Джун: Отак!
Досвідчений: Чекай, зараз, ще не всі образи перебрав...
Менеджер: Та чого ти зволікаєш? Он джун вже готовий таску виконувати
Досвідчений: Та наче все ок, от тільки...
...
У цім сценарії, ми бачимо, що досвідчений розробник тягне час, тому що його мозок ще перебирає / опрацьовує можливі ситуації.
Тому — або швидко та з бледжеком і дівчатами
Або повільно проте якісно.
Втім можна трохи допомогти досвідченому:
Менеджер: А який би ти зробив перший крок? Якби ця таска була купкою соломин і треба було витягти таку, що інші б не зачепила, яку б ти потяг?
Бо є така казка про трьох братів що «яснобачили»
Перший брат — Воно кругле
Другий — Якщо кругле то жовте
Третій брат — Якщо кругле та ще й жовте це цітрус

Звідки у казці про цитрус — хто зна, але розпізнання уточнює крок за кроком що там у коробці.

це називається ейджизм

досвід робить будь кого кращим
свіжий погляд завжди корисний

Досвід релевантніше міряти кількістю проектів середньої-високої складності з якимось там емпіричним коефіцієнтом плюс стаж у роках з якимось іншим коефіцієнтом.
Але є Гвідо і Лінус , у яких 1-2 проекти , і що тут сказати ;-)

Досвід релевантніше міряти кількістю проектів середньої-високої складності

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

Софт-скілли накопичуються. Як звалити роботу на другого, а відповідальність за зрив на третього...

Linux це фактично проектів 300 у одному флаконі.
Python схоже.

python та node нагадують чимось perl з хаосом, linux як флакон чогось не бачиться в такому ракурсі

Для мене такі пости свідчення того, що революційних змін в IT останні 30 років не відбувалося. Бо коли такі зміни були, то сеніорами ставали у 22, а після 30 вже не брали. Свою перевагу бачу в тому, що довелося працювати на більш низькому рівні, що дає розуміння як воно працює під капотом.

А LLM ігноруємо?

Я більше про розробку ПО. Так, наприклад, інтернет це революційна зміна. Але я не знаю жодного розробника, який не зміг опанувати пошук у Google. Так само і LLM, кожен може запитати на рідній мові та отримати відповідь. А як це вплине у майбутнєму — подивимося, рано робити висновнки.

От ситуація у 90-х була іншою, та була повʼязана з появою персоналок. До цього машинний час був в дефіциті. Це призводило до того, що достатньо розвинути скіли було важко. Взагалі, коли зʼявляються нові технології, то студенти отримують неабияку перевагу. Бо на роботі у тебе бізнес задачі, часу немає вчитися. Окрім як новий проєкт написати, але там теж є питання. Тому 30+ років були виключення, а сеніори були 22+.

Про вплив LLM мені зараз важко оцінити за браком даних. Покажіть мені хоча б 10 успішних production-проєктів, створених переважно за допомогою LLM (не з LLM як фічею, а де LLM створював код). Поки що я таких не бачу. У 90-х через 5 років після появи веб-браузерів ми мали Amazon, eBay, тисячі стартапів. Що ми маємо через 2+ роки після ChatGPT? Програмісти стали продуктивнішими? Напевно, хоча на цьому тижні я запитав якусь дрібницю у ChatGPT, він почав нести ахінею, решту робочого дня витратив щоб довести що він ідіот, на цій ноті завершив робочий день. Тому подивимося

Junior — я не знаю як зробити цю таску
Middle — я знаю як зробити цю таску
Senior — я знаю як не робити цю таску

Коли ще проводив співбесіди повністю переконався в справедливості виразу «20 років досвіду можуть насправді бути 2 роками, повтореними 10 разів». Досвід і кількість років в індустрії на мій погляд не варті нічого.

Мені 20 років досвіду відчуваються 7 роками, повтореними менше 3-х разів.

З того, що було більше 7 років тому, зараз валідне:
Java, бази даних, Спринг (які постійно розвиваються), архітектура корпоративного софта ERP\CRM, мікросервіси, навички тестування.
Багато чого стало формально не потрібне, але знання стають в нагоді коли треба підтримувати старий легасі софт, і там вже не дивуюсь, коли треба Swing, Struts чи щось таке.
Є технології, типу CORBA, які регулярно воскресають під іншим брендом, є патерни, які переходять на наступний технологічний рівень, типу, під капотом Спринг Бута крутиться Томкет.

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

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

Виглядає як пост камуніті манагера

Підписатись на коментарі