Вхід і реєстрація
Про роботу · 6 травня, 9:54 13482
Pavlo Trepytion, Technical Community Manager в DOU.ua

Чому компанії найчастіше звільняють Senior’ів?

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

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

Як думаєте, це тимчасове явище чи до цього пора вже звикнути? Чому саме Senior-фахівці стали першими, кого скорочують, а не Middle чи Junior-спеціалісти?

Теми: middle, senior, аналітика, звільнення, обговорення, робота
👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

дмитрий аношенко 06.05.2025 16:44

Не давно побачив на стовпі обʼяву — шукають збірника вікон на виробництво. Вимоги до кандидата — студент до 25, жінка або чоловік за 60. Здається, навіть на виробництвах ніхто вже не шукає «сіньойра» у віці 25-45 ¯\_(ツ)_/¯

Перейти до дискусії
Beaver Green 06.05.2025 19:11

Я гадаю причини очевидні:
1) Ринок перекинувся і тепер усі хочуть наймати на −500. Тобто можна звільнити «зажершегося» синьора і знайти з вулиці голодного, який погодиться на −500 ще й буде вислужуватись на новій роботі.
2) В Україну бояться віддавати важливу роботу. А для тупого сапорта легасі (яке просто шкода викнути) може вистачити і мідлів.
3) Як правило клієнти погано дивляться на те, що синьйор, як важлива людина, може у будь-який день зникнути в Україні. Тому синьйорів намагаються наймати в інших країнах.
4) Синьйор може дозволити собі «гупнути дверима» якщо йому не дали підвищення — а тим більше якщо запропонували робити більше роботи за ті самі гроші або навіть менші (усі хочуть −500).
5) Усі сподівання хоч би на зупинку п#здеца закінчуються. Отже бізнес чекає що буде ще більша гепа. І через пів-року навіть якщо якась ІТ робота ще буде — то буде і черга голодних девелоперів, які вже згодні будуть працювати і за їжу.
6) Банально багато компаній або помирають — або виїжджають з України. Відповідно — звільняють усіх.
7) Це лише моє сподівання. Але хочеться вірити що деякі синьйори якось знаходять якийсь вихід з «резервації» і переїздять на більші зарплати у Європі.

Перейти до дискусії
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Bot Bot 24.05.2025 22:12

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

ІМХО але церез декілька років повернеться знову тренд на найм, коли отакі «оптимізації» чи «аі агенти», доведуть що банально софт та інфра падають, а її відновлюють дуже довго, чи делівері падає настільки що вже нічого без розвалу існуючого не зробиш.

Відповісти
Підтримати
Чорний Список Юджина 19.05.2025 20:27

З AI зараз усі мідли — сіньори, тож навіщо платити більше.

Відповісти
Підтримати
Pavlo Trepytion Technical Community Manager в DOU.ua 20.05.2025 13:51

Only with Vibedebuging 😃

Відповісти
Підтримати
yvs2014
yvs2014 20.05.2025 19:51

Hmm... i.e. ’web+bug’ gave birth to ’vibedebug’

Відповісти
Підтримати
Pavlo Trepytion
Vic Programmer 20.05.2025 11:04

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

Відповісти
Підтримати
Чорний Список Юджина
Andrii Sevastianov 20.05.2025 11:47

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

Відповісти
Підтримати
Чорний Список Юджина
Oleksandr Nazararenko 21.05.2025 14:32

Ну форми клепати то да, щось більш меньш серйозне то вже важкувато з AI

Відповісти
Підтримати
Чорний Список Юджина
Сергій Цимбалюк 09.05.2025 16:03

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

Відповісти
Підтримати
Alex Fogol Software Developer, C/C++ Expert 10.05.2025 19:21
Краще зберегти, в такому випадку, більш лояльнішого та завзятішого джуна.

брали лояльных а теперь спрашивают как с умных (к) (тм)

Відповісти
Підтримати
Сергій Цимбалюк
Олександр Шпак Oarsman в Self Employed 08.05.2025 16:59

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

Відповісти
Підтримати
Олександр Шпак Oarsman в Self Employed 09.05.2025 14:36

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

Відповісти
Підтримати
Emma Orlova
Vic Programmer 15.05.2025 13:36
Ви не чіпляйтеся за цифру.

О ну це же классика Ильф та Петров, www.youtube.com/watch?v=XKO-hpVGgMk
Ну і вцілому, 100 років пройшло але сенс ні www.youtube.com/watch?v=Xt2v0GTNj5g

Відповісти
Підтримати
Олександр Шпак
Alex Prokopenko Engineer 09.05.2025 20:19

У себе на банківському рахунку

Відповісти
Підтримати
Emma Orlova
Просто Анон 11.05.2025 20:39
8k+ це де ви таке бачили?

В кінці 2021...

Відповісти
Підтримати
Emma Orlova
Amigoo Rui 11.05.2025 22:01

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

Відповісти
Підтримати
Emma Orlova
Oleksii Nedashkivskyi AI/ML Tech Lead 15.05.2025 14:32

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

Відповісти
Підтримати
Emma Orlova
Emma Orlova SDE 15.05.2025 21:11

суттєво це не для простих смертних

Відповісти
Підтримати
Oleksii Nedashkivskyi
Oleksii Nedashkivskyi AI/ML Tech Lead 16.05.2025 12:05

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

Відповісти
Підтримати
Emma Orlova
Andrii Sevastianov 15.05.2025 13:17
Типова проблема сіньйорів — їхня мотивація. Вони не хочуть напружувати дупцю та показувати високу продуктивність. Грошима їх не звабиш, ...

По-перше звабиш, але тільки це не +500. По-друге, сидіти лайкати котиків у Facebook така собі альтернатива, тому, по-третє інші шляхи мотивації.

Часто я бачив, коли беруть людину зі знанням тонкощів нових стандартів C++, а по факту треба фіксити сі-подібний код. А на спроби переписувати частково на C++, відповідь, что поки що немає ресурсу. Або Java розробник, на співбесіді багато розмовляли про важливість тестування, а по факту половина unit-тестів не працюють, та це не в пріоритеті, фічі важливіше. Тут є фактор демотивації — не прислуховуються. І виникає ситуація, коли й звільнятися та шукати роботу це активний крок, який не хочеться робити. Але й працювати та робити те, що ти вважаєш неправильним, теж не дуже. І так ситуація підвисає.

Тому ніякі знання чи навіть ключова роль

Це як раз мотиваційний фактор, часто означає що ти вклав у систему багато свого ресурсу.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 15.05.2025 14:29
По-перше звабиш, але тільки це не +500.

Це дуже короткостроково. Тому що там буде боротьба між «я хочу бабла» та «я більше не хочу напружуватися», баланс буде знайдено доволі швидко.

по-третє інші шляхи мотивації

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

Тут є фактор демотивації — не прислуховуються

А я задам зустрічне запитання, чому бізнес мусить прислуховуватися до працівника, але працівник не мусить прислуховуватися до бізнесу? Бізнес інколи чітко каже — нам треба швидко зробити фічу. Це примітивна задача. Що каже розробник? Швидко не буде, бо це вплине на якість коду, технічний борг, та купа інших псевдопричин, які дуже важливі для розробника, але для бізнесу це звучить як відмова робити роботу або не бажання напружуватися. То може треба прокачувати знання заробляння грошей та підвищення ефективності роботи, а не тільки хард скілами перейматися?

Це як раз мотиваційний фактор, часто означає що ти вклав у систему багато свого ресурсу.

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

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 15.05.2025 19:20
Тому що там буде боротьба між «я хочу бабла» та «я більше не хочу напружуватися», баланс буде знайдено доволі швидко.

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

Зовнішня мотивація — завжди погана річ. Це примус, вимога,

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

А я задам зустрічне запитання, чому бізнес мусить прислуховуватися до працівника, але працівник не мусить прислуховуватися до бізнесу?

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

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

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 15.05.2025 20:12
Ну... якщо у тебе з/п більше за ринкову, ти розумієш, що пошук нової роботи це зменшення власного доходу, а у тебе вже кредити в розрахунку на поточний дохід... Це мотивація для багатьох...

Це невідворотньо. Працівники з найменшою маржинальністю йдуть під ніж першими. У сіньйора, який сидить на проекті 10 років та має вищу за ринок ЗП, буде найнижча маржинальність.

Навпаки, примус та мотивація це протилежні речі.

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

Там де є проблемне питання пошуку кадрів, там більше прислуховуються.

Я б сказав, терплять вибрикеньки. Прислуховуватися до людини, яка погано розбирається в бізнесі — ну таке...

Ніхто нікому нічого не винен.

Якщо це так, то чому працівник тоді вимагає, щоб до його думки дослухалися та ображається, якщо це не так? Або труси одягайте, або хрестик знімайте. ;)

Розробників цікавить не бізнес, а власне задоволення.

Це не монетизується. Його задоволення він може оплачувати самостійно в такому разі.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 16.05.2025 00:17
У сіньйора, який сидить на проекті 10 років та має вищу за ринок ЗП, буде найнижча маржинальність.

Знаю схожу історію, коли одного такого сіньйора звільнили, а оскільки це було у США, то йому виплатили річну зарплатню компенсації. Ну і він полетів відпочивати, а через півроку з’ясувалося, що без нього ніяк. Давай йому пропонувати повертатися, а він вже не хоче... Прийшлося ще збільшувати з/п, домовилися...

А проблема у тому, що внесок кожного важко оцінити.

Для людини будь-яка зовнішня мотивація — примус.

Ще раз, у всіх тварин, людина не виключення, схожа біохімія. І діяти без мотивації будуть лише ШІ та роботи.

Прислуховуватися до людини, яка погано розбирається в бізнесі

Спочатку треба розібратися в поведінці людей.

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

Ще раз, ніхто нікому не винен. Працівник може озвучити, що його не влаштовує, та піти шукати нову роботу. Роботодавець аналогічно може озвучити, що його не влаштовує, та звільнити. Причому озвучувати не обов’язково.

Це не монетизується.

Ок, це ваш бізнес. Не хочете видавати свою доньку заміж? Кохайтеся з нею самі. Але звідки тоді претензії до розробників, на кшталт «Типова проблема сіньйорів — їхня мотивація». Це проблема для вас, у них власне життя та власне бачення. Наймайте людей з правильною мотивацією та не переймайтеся. От на співбесіді одразу чесно попереджайте: «Про перегляд зарплати забудьте — це зменшить важу маржинальність. Нові технології? Не смішіть, це не монетизується. Ідей не генеруйте — у нас для цього начальство. І взагалі, ви тут ресурс, а не особистість. З 9:00 до 18:00 ми вас купили, а отже — посміхайтеся і тикайте в клавіатуру. Мотивацію приносити з дому, креативність лишити на парковці. Якщо вас щось не влаштовує — ось двері, а за ними черга з менш вибагливих».

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 16.05.2025 01:59
а через півроку з’ясувалося, що без нього ніяк

Їм просто було ліньки шукати відповідну заміну.

А проблема у тому, що внесок кожного важко оцінити.

Це автотренінг. Внесок доволі просто оцінити, а от ризики — тут трохи важче.

І діяти без мотивації будуть лише ШІ та роботи.

Люди так теж вміють. Але цьому треба вчитися. Цього треба хотіти. Так, таких людей меншість. На жаль.

Спочатку треба розібратися в поведінці людей.

Кому?

Це проблема для вас, у них власне життя та власне бачення.

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

Наймайте людей з правильною мотивацією та не переймайтеся.

Виключно так й роблю :)

От на співбесіді одразу чесно попереджайте: "Про перегляд зарплати забудьте — це зменшить важу маржинальність.

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

І взагалі, ви тут ресурс, а не особистість

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

Мотивацію приносити з дому

Були хоч раз лідом серед людей, яких ви не обирали в команду?

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 16.05.2025 15:33
Їм просто було ліньки шукати відповідну заміну.

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

Внесок доволі просто оцінити,

Як оцінити внесок від servicebility задач? Жодного прибутку від них, відмовляємося, так? Я бачив багато помилок в таких оцінках.

Спочатку треба розібратися в поведінці людей.
Кому?

Тому хто керує людьми.

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

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

збільшувати цінність, яку створює розробник для компанії

От це неможливо виміряти у процесі, трохи складнішим та копання ям.

Особистість не монетизується. Тільки ресурси.

Це тільки при умові, що люди легкозамінні. Я бачу, що ви впевнені, що так воно і є.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 16.05.2025 16:32
Це також гроші на пошук.

В будь-якому разі.

Потім три місяці онбордінгу

Навіщо брати таких слабких кандидатів?

Як оцінити внесок від servicebility задач?

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

Тому хто керує людьми.

Повірте, немає в поведінці людей нічого складного.

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

Тому що лінь. Лінь розвиватися, лінь шукати роботу, лінь щось змінювати у власному житті, лінь вчитися, лінь, лінь, лінь...
Ніякий зовнішній мотиватор не зможе це виправити. Тимчасово дупцю напружити можна, але постійно вже не вийде.

От це неможливо виміряти у процесі, трохи складнішим та копання ям.

Ще й як можливо. Тому що це не вибір виконавця, це вибір бізнесу. А він точно знає, як утилізувати ресурс з найбільшою користю. Є купа практик, як прямих так й непрямих. Один з прикладів — давайте людині ті задачі, які він виконає найкраще та не давайте таких, від яких в нього буде вигорання, депресія та суїцидальні нахили. Або змінюйте процес таким чином, щоб мінімізувати час виходу оновлень продукту на ринок. Або поміняйте модель розробки з класичної на альтернативну. Приберіть в решті решт зайві процеси, які не приносять достатньої користі, наприклад тестування чи код ревʼю. Не треба тільки казати, що якість продукту впаде, зазвичай вона тільки зростає після такого. В решті решт відправте розробників на курси з економтеорії, щоб вони хоч трохи розумілися на тому, що від них очікують в компанії.

Це тільки при умові, що люди легкозамінні. Я бачу, що ви впевнені, що так воно і є.

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

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 16.05.2025 18:30
Навіщо брати таких слабких кандидатів?

Не всі проекти настільки елементарні, що можна отак відразу війти. Часто щоб людина повноцінно освоїлась, треба близько року.

Те, що ви не знаєте як, не значить що це неможливо зробити.

Я просто ніде не бачив, щоб це працювало, а от помилок бачив багато.

то оцінюйте два стани між собою, коли ця річ працює та коли не працює.

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

Тому що лінь. Лінь розвиватися, лінь шукати роботу, лінь щось змінювати у власному житті, лінь вчитися, лінь, лінь, лінь...

Так, люди вони такі.

Один з прикладів — давайте людині ті задачі, які він виконає найкраще

Це є підлаштовування під працівника, а ви ніби-то проти цього. Бо задачу він виконає найкраще, коли вона буде покрита unit-тестами, коли вона буде написана з використанням певних технологій, ...

Весь корпоративний світ працює за таким принципом.

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 16.05.2025 18:44
Не всі проекти настільки елементарні, що можна отак відразу війти. Часто щоб людина повноцінно освоїлась, треба близько року.

Назвіть мені приклади таких проектів.

Я просто ніде не бачив, щоб це працювало, а от помилок бачив багато.

А в скількох компаніях ви працювали? А якого вони розміру були? Тип бізнесу?

У тому й проблема, щоб річ переслала працювати, її треба зламати.

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

Це є підлаштовування під працівника, а ви ніби-то проти цього.

Це оптимальне використання наявних ресурсів. Я саме за це.

Бо задачу він виконає найкраще, коли вона буде покрита unit-тестами, коли вона буде написана з використанням певних технологій, ...

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

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

Це коли досвіду нуль? Але задайтеся запитанням, чому для вас в корпорації знайшлося місце та чому ви не працюєте на неї?

Відповісти
Підтримати
Andrii Sevastianov
Просто Анон 16.05.2025 19:07
Назвіть мені приклади таких проектів.

Та будь який ентерпрайз на 200+ девів, де є кілька вендорів (підрядників), кілька кор тімок, зоопарк з технологій і методологій.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 18.05.2025 11:47

Там все сегментовано та фрагментовано. Наврядчи ви знайдете там хоч одну людину, яка знає про систему геть все.

Відповісти
Підтримати
Просто Анон
Andrii Sevastianov 16.05.2025 21:06
Назвіть мені приклади таких проектів.

Наприклад, AMD, розробка відеодрайверів.

А в скількох компаніях ви працювали?

Біля 20

А якого вони розміру були?

Від проектів на себе, де я був один, до 90 000.

Тип бізнесу?

Самий різний, думаю майже усе с розробкою.

A-B тестування

A-B тестування це добре, але якщо питання скоротити відділ? Бізнес не буде розробляти софт двома різними способами щоб з’ясувати, який краще.

Це коли досвіду нуль?

Ну, це навіть коли у тебе 20+ років досвіду.

Але задайтеся запитанням, чому для вас в корпорації знайшлося місце та чому ви не працюєте на неї?

Не зрозумів питання, особисто мене все влаштовує, а щодо поточної роботи — NDA.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 17.05.2025 00:29
Наприклад, AMD, розробка відеодрайверів.

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

Бізнес не буде розробляти софт двома різними способами щоб з’ясувати, який краще.

Буде, тому що задача бізнесу — оптимізація. Неможливо перевірити гіпотезу без тесту.

Ну, це навіть коли у тебе 20+ років досвіду.

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

Не зрозумів питання

Вас корпорація наймає на роботу. Є дві причини, чому це відбувається. 1) Ви приходите на місце іншої людини. 2) Ви приходите на новий проект. Зазвичай це перше. Чому людина пішла з такої гарної роботи, або її пішли? За вашою логікою корпорація мусить до останньго триматися за такого цінного працівника, який щось там знає, робить, його не треба вводити в курс справ. Але середній рівень плинності кадрів складає 10-15 відсотків на рік. Десь більше, десь менше, залежить від моделі керування та бізнес-моделі, але це доволі великий показник, чи не так? Отже, можна висунути гіпотезу, що такий рівень плинності обов’язково вбиє компанії, але цього чомусь не відбувається в реальному житті. Уходять C-level, середній рівень так само часто, як й низові працівники. І нічого не відбувається. Все як працювало, так й працює. Подумайте чому.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 17.05.2025 15:46
Так, знайти розробника з необхідними знаннями буде не легко, але його онбоардінг не буде тривалістю в рік.

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

Просто якщо у стартапі написано 10 000 рядків коду, а усе решта це моднявий фреймворк, то так, замінити досить просто. А якщо є пропрієтерний фреймфорк, який використовується внутріщньо, то спеціалісти це лише звільнені раніше. А якщо уявити, що і замість Python буде проприєтарна мова, ...

Буде, тому що задача бізнесу — оптимізація. Неможливо перевірити гіпотезу без тесту.

Інколи ціна перевірки гіпотези занадта. Як перевірити, що буде краще, Python чи C#? Ну.. написати два проекта, один на Python, інший на C#. А ще краще десяток, щоб результат був статистично значущим. Хто це буде робити?

Вас корпорація наймає на роботу. Є дві причини, чому це відбувається.

Насправді, корпорація наймає на роботу, бо витрачає бюджет. Не витратити погано, бо наступного року його скоротять.

1) Ви приходите на місце іншої людини. 2) Ви приходите на новий проект. Зазвичай це перше. Чому людина пішла з такої гарної роботи, або її пішли?

Таке вращення, що роботу ФОП-а у якого працює Петро, Василь та Галя ви переносите на корпорацію.

Але середній рівень плинності кадрів складає 10-15 відсотків на рік. Десь більше, десь менше, залежить від моделі керування та бізнес-моделі, але це доволі великий показник, чи не так?

Великий це емоційна оцінка. Чому він має вбивати компапнії? Який відсоток припадає на тих, хто прийшов, попрацював рік, стало видно що не зміг, та пішов далі.

Відповісти
Підтримати
Олександр Шпак
Valentin Nechayev уповноважений по милицях в Дарницькі печери 18.05.2025 09:26
Ну... якщо володієте цим секретом, то зможете легко робити декілька мільйонів доларів на рік.

Міліарди, а не міліони. Або навіть тріліони.

Бо секрет не в тому, як організувати процеси — це вже давно відомо — а як зробити, щоб на керівні посади, включаючи суто IT фірми, попадали люди, які дійсно зацікавлені в тому, щоб робота йшла, а не щоб робити красиву картинку для інвесторів, які не розуміють іншої мови, крім $$ (€€, whatever).

Спостерігаючи такі місця, я починаю розуміти тих, хто каже про неефективність капіталізму.

Відповісти
Підтримати
Andrii Sevastianov
Олександр Шпак Oarsman в Self Employed 18.05.2025 09:59
Ну... якщо володієте цим секретом,

Немає ніякого секрету. Базові знання ще ніхто не відміняв.

А якщо є пропрієтерний фреймфорк,

В мене використовуються пропрієтарні фреймворки. Онбоардінг — не більше двох місяців. Що я роблю не так?

Інколи ціна перевірки гіпотези занадта. Як перевірити, що буде краще, Python чи C#?

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

Насправді, корпорація наймає на роботу, бо витрачає бюджет. Не витратити погано, бо наступного року його скоротять.

Що за совкове бачення?

Таке вращення, що роботу ФОП-а у якого працює Петро, Василь та Галя ви переносите на корпорацію.

Це лише враження. Читайте книжки по менеджменту, тоді вам стане набагато зрозуміліше, про що йде мова.

Чому він має вбивати компапнії?

Тому що деградація знань відбувалася б швидко. Уявімо собі колектив, в якому працюють 10 людей. Їх рівень знань не 1/10 на кожного, вони володіють десь в середньому від третини до двох третин від загального об’єму знань. При чому їх частки не перетинаються. Якщо я володію третиною знань, то це може бути унікальна третина, ви володієте іншою часткою.

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

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

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 11:15
Що за совкове бачення?

Великі корпорації мають багато спільного за совком.

Уявімо собі колектив, в якому працюють 10 людей

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 19.05.2025 11:21
Великі корпорації мають багато спільного за совком.

Ви ж розумієте, що в комерційній організації швидше можна отримати «медальку» за невитрачені гроші, ніж за бездарно поросраний бюджет?

то це означає, що їй подобається,

Далеко не так. Причин, чому людина залишається на посаді довго може бути купа різних. Наприклад, людина взяла іпотеку та тепер боїться втратити роботу, або людина не впевнена в собі та вважає, що не зможе знайти ніде краще місце, бо не пройде співбесіду. Або боїться засудження оточення за втрату такої «гарної» посади/ЗП та таке іншошого. Люди дуже любдять так звану «стабільність».

Також є варіанти, що коли ніхто не розуміє чорний ящик

Рано чи пізно це буде переписано або повністю викинуто.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 11:37
Ви ж розумієте, що в комерційній організації швидше можна отримати «медальку» за невитрачені гроші, ніж за бездарно поросраний бюджет?

Не розумію, головне правильно відзвітуватися.

Наприклад, людина взяла іпотеку та тепер боїться втратити роботу

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 19.05.2025 12:00
головне правильно відзвітуватися.

Якщо в звіті буде написане, що завдяки оптимізації процесів було зменшено витрати на X $K, це буде сприйматися як зрада чи перемога?

Зазвичай в IT тобі пропонують вакансії, навіть коли ти працевлаштований.

Це до певного рівня. Потім тобі нічого не пропонують, бо overqualified, в нас немає задач для вас, ви не зможете влитися в молодий колектив.

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

Так, але для бізнесу це дуже рідко має вирішальний характер.

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

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

Відповісти
Підтримати
Andrii Sevastianov
Valentin Nechayev уповноважений по милицях в Дарницькі печери 19.05.2025 23:05
Великі корпорації мають багато спільного за совком.

Совок як раз і був великою корпорацією, тільки без можливости звільнитись. Тому повністю звісно, що шаблони управління в совку і в типовій великій компанії — 1:1.

Відповісти
Підтримати
Andrii Sevastianov
Valentin Nechayev уповноважений по милицях в Дарницькі печери 18.05.2025 09:23
Так, знайти розробника з необхідними знаннями буде не легко, але його онбоардінг не буде тривалістю в рік.

Це при нормально організованих процесах. Нормальні менеджери 1-го рівня, є документація (актуальна!), код нормально структурований, (майже) все покрито тестами, і так далі.

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

Дякую, надивився такого жаху. Ось наприклад на одному проєкті: кожний новак має зробити на власному лаптопі віртуальну інфраструктуру для простих тестів (ці тести нічого не покривають крім одного-єдиного happy path в найпростішому варіанті). Є документація, застаріла на рік-два. Попередник іде «криголамом» передо мною, розбираючи всі деталі і спотикаючись на них, іноді чекаючи відповіді по 4 дня. Я доєднався, пішов за ним, оформлюючи в приватному confluence (там він був дозволений! вже щастя) поправки до того документу (наші зміни одразу відкинув великий «спец», що писав його, навіть не намагаючись зрозуміти, що він написав повну маячню). І вже по комбінації початкового документу з поправками далі всі колеги робили собі такі ж стенди.

Що при цьому все рівно щось було не так і стенд іноді запускався через 2 рази на третій (десь невиправлений обгін, на який було всім начхати) — окрема розповідь.

А шефи, які пропрацювали в цьому багато років, вже знали всі ці проблеми і, головне, кого і як спитати! — їм відповідали швидко, а не як нам ;(

І це ± типова картина.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 19.05.2025 11:24

Тепер запитання, чи стане краще компанії, якщо з неї звільнити отих всіх дурогонів?

Відповісти
Підтримати
Valentin Nechayev
Олександр Шпак Oarsman в Self Employed 19.05.2025 12:03

Там будь-хто з нормальним менеджерським підходом буде кращим. Тому що проблема не в рівні спеціалістів як програмістів, а в тих процесах, які вони побудували.

Відповісти
Підтримати
Andrii Sevastianov
Олександр Шпак Oarsman в Self Employed 19.05.2025 19:14

Та щось у вас одні проблеми... :D Я сам люблю ідентифікувати проблеми, але тільки для того, щоб їх висвітлювати та вирішувати. Ігнорування проблем ніколи не було робочим способом їх вирішення.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 19:31

Бо якби не було проблем, то кожен міг би піти працювати, давно не було би проблем з багами, строками, і всі тільки б так і робити. А програмісти заробляли на рівні кур’єрів.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 19.05.2025 20:21

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

Тому очікування не співпадають з реальністю та все погане...

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 23:05
Замість того, щоб задати запитання, що я роблю не так та в чому причина постійних фейлів, всі намагаються знайти просте рішення, хоча воно криється в тому, як людина мислить та підходить до вирішення задач.

Мої 30 років в ІТ показали одну просту річ: проблеми в плануванні, строках та повторюваних помилках — вічні. Якщо вірити книжкам, то з самого початку дедлайни зривалися з втратами у десятки мільйонів доларів. Найрозумніші люди планети намагалися це вирішити. З’явилися waterfall, agile, scrum, kanban, TDD, CI/CD, DevOps, Gantt, burn-down charts — список можна продовжувати довго. І всі вони відповідали на питання на мільярд: чому ми знову проекти виходять за строки а то і взагалі провалюються?

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

Я — людина маленька. Я більше думаю про те, як бути успішним в умовах, які я змінити не можу.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 20.05.2025 02:20
З’явилися waterfall, agile, scrum, kanban, TDD, CI/CD, DevOps, Gantt, burn-down charts

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

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 20.05.2025 10:55

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 20.05.2025 11:24

Тоді вам треба починати задавати правильні запитання.

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

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

Упередженість та карго культ заважають дивитися на світ не однобоко.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 20.05.2025 13:56
Тоді вам треба починати задавати правильні запитання.

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

Десь відсотків під 95 людей на цьому форумі свято вірять в силу цього методу.

Нагадує анекдот:
— Будь обережним, там один дурень їде по зустрічній!
— Який один, тут їх тисячі!!!

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

Ок, верифікація, математичне доведення потрібних властивостей кода. Чи трійки Хоара, чи ізоморфізм Карі Говарда. Але відразу виникає питання де знайти спеціалістів, строки розробки, ...

Хоча рішення лежить під носом.

Компанії по всьому світу витрачають мільярди доларів на тестування. Відкрийте їм очі, як треба вести бізнес. Заробляйте на консалтінгу сотні мільйонів! Чому ви тут витрачаєте свій час?

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 20.05.2025 15:58

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

Компанії по всьому світу витрачають мільярди доларів на тестування.

Так прийнято. Діди тестували...

Відкрийте їм очі, як треба вести бізнес.

Ви плутаєте розробку та бізнес. Це не тотожні речі.

Заробляйте на консалтінгу сотні мільйонів! Чому ви тут витрачаєте свій час?

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

А нові проекти не так вже й часто запускаються, як хочеться.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 20.05.2025 17:22
Так прийнято. Діди тестували...

Як на мене, саме процеси розробки п/о змінюються швидко. Нещодавно набули популярності devops, unit-тести стали обов’язковими, а до цього часто можна було чути що у нас немає ресурсу на це, CI, ...

Та головна причина, чому ніхто не захоче відмовитися від тестування — бо це треба інвестувати в зміни, на що немає часу та грошей.

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

Ну чесно, інвестувати у те, щоб створити команду CI є кошти, а щоб позбутися тестувальників — немає? Питання що непереконливо виглядає.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 20.05.2025 17:49

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

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

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

Але саме головне тут не це. Мені банально не цікаво заробляти гроші на такому.

Відповісти
Підтримати
Andrii Sevastianov
Yuri Glushko 20.05.2025 18:48
Інколи ваша архітектура просто не здатна втілити потрібні методики

Так які саме, for god’s sake?!

Відповісти
Підтримати
Олександр Шпак
Witness 20.05.2025 20:02

«у нас есть такие приборы, но мы вам про них не расскажем»

Відповісти
Підтримати
Yuri Glushko
Олександр Шпак Oarsman в Self Employed 21.05.2025 02:39

Та їх безліч. Основна задача — мінімізувати шанси на помилку. Приведу простий приклад. У вас є два модуля, які спілкуються між собою. Зазвичай це робиться в імперативний спосіб, коли ви просто в одному модулі робите виклик метода іншого модуля, передаєте певні параметри. Це сильнопов’язана архітектура. Тобто, ви не зможете змінити код в одному місці та не поламати в іншому.

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

Приклад — парсер HTML. Він побудований таким чином, щоб все лайно, що йому упхали на вхід, якось обробити. В нього немає виключень чи особливих випадків, при яких він працює або не працює. Він гарантовано видасть DOM структуру, навіть якщо на вхід прилетіло «сміття». Тому його стан завджи однаковий — він видасть результат. Чи потрібно таку поведінку покривати тестами? Звісно що можна, але напоркуа?

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

Відповісти
Підтримати
Yuri Glushko
Yuri Glushko 21.05.2025 06:01
Який підхід більш стійкий до змін? Вам треба стандартизувати протокол обміну даними між модулями
...
Приклад — парсер HTML. Він побудований таким чином, щоб все лайно, що йому упхали на вхід, якось
...

LOL
Ясно, корочє.
Ще один distiguished інженер-теоретик, сертифікейт оф екселенс.

Чи потрібно таку поведінку покривати тестами? Звісно що можна, але напоркуа?

*витираючі сльози*
Дякую за стендап, пишіть ще, не зупиняйтесь.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 21.05.2025 09:23
Ще один distiguished інженер-теоретик, сертифікейт оф екселенс.

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

Дякую за стендап, пишіть ще, не зупиняйтесь.

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

Відповісти
Підтримати
Yuri Glushko
Олександр Шпак Oarsman в Self Employed 21.05.2025 09:37

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

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

Відповісти
Підтримати
Yuri Glushko
Andrii Sevastianov 21.05.2025 12:09
Одна з головних ознак упередженості, це коли перша реакція людини — альтернативна думка неправильна, треба її відкинути, а не альтернативна думка цікава, треба розглянути.

Ну... ок, я аналізую приблизно так:

1. Рівень думки? В принципі висловити таку ідею може навіть початківець, тобто це рівень нижче за джуна. От як дійшов до того, що в Python можна методи об’являти def some_job(*args, **kwargs):, так от перша думка, чому б так й не робити з усіма методами? Універсальна структура, жодних помилок при виклику.

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

3. А далі просто невеличкий аналіз, що більшість проблем лишається. Бо це не падіння при виклику, (які виключені у мовах зі статичної типізацією), а це помилкові результати. Більшість тестів падають на перевірках на рівність, а не необроблених виключеннях.

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 21.05.2025 13:30
def some_job(*args, **kwargs)

Це саме примітивне рішення, але воно не буде працювати в довгостроковій перспективі.

а це помилкові результати

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

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

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

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

Це як третьорозрядник каже, «чому б не піти так», гросмейстер «це не має сенсу», третьорозрядник — «ви упереджені...»

Так, це ще одна спроба переконати себе в першу чергу, що щось не має сенсу. Але є продукти, які так працюють, та працюють доволі успішно. Це значить, що ви не гросмейстер (без образ). ;)

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 21.05.2025 16:24
Я впевнений, що в вашій голові миттєво знайдуться контр-аргументи та приклади, що це неможливо бо це неможливо. Відкиньте їх.

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

Люди жось впроваджують лише тоді, коли вони бачать переваги та недоліки, та як воно буде працювати. А так ніхто не підпишеться повірити на слово, а потім «не шмогла».

Тому повний приклад, як було, як буде, які помилки виключаються, які переваги, які недоліки. А так, «відкиньте аргументи проти, перепишість квартиру на Аум-сенріко...» Дуже наївно.

Відповісти
Підтримати
Олександр Шпак
yvs2014 21.05.2025 17:05
Закон Фермі: якщо якась неприємність може трапитися — вона трапиться

Фермі?

ніхто не підпишеться повірити на слово

fersure

Відповісти
Підтримати
Andrii Sevastianov
Yuri Glushko 24.05.2025 01:59
def some_job(*args, **kwargs):

Універсальна структура, жодних помилок при виклику.

Gosh, that’s BRUTAL

Відповісти
Підтримати
Andrii Sevastianov
Yuri Glushko 24.05.2025 01:58

Та не переживайте так.

Все було розглянуто.
Ретельно.

І визнано сміховинним глупством.

Данінгу з Крюгером вітання передавайте.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 24.05.2025 21:59

Так, вони мені сказали, що ви в них були вельми цікавим піддослідним... Передали, що ваші показники самовпевненості були найвищими з усіх.

Відповісти
Підтримати
Yuri Glushko
Andrii Sevastianov 21.05.2025 11:45
А коли структура даних довільна, то вам за замовчуванням прийдеться переконуватися, що модуль зможе обробити дані, а не впасти.

Впасти може все що завгодно. Але от що робити, коли недостатньо даних? Треба розпарсити HTML файл, а його не передали? Через друкарську помилку у формуванні цієї довільної структури. Користувач увів посилання на сайт, код його зберіг на диск та помилково викликав парсер. Той не впав, але повернув помилку: файл не знайдено.

Чи потрібно таку поведінку покривати тестами? Звісно що можна, але напоркуа?

Той факт, що HTML парсер поверне DOM структуру, не означає, що він поверне коректну DOM структуру. Як цього досягнути?

В принципі, якщо треба, щоб код не падав, то це total функції у ФП, це верифікація на трійках Хоара як в Ada, або безліч сторонніх тулзів, які можна інтегрувати у розробку.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 21.05.2025 14:22
Треба розпарсити HTML файл, а його не передали?

Треба виконати функцію, а її ніхто не виконує. То це помилка чи ні?

Через друкарську помилку у формуванні цієї довільної структури.

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

Користувач увів посилання на сайт, код його зберіг на диск та помилково викликав парсер. Той не впав, але повернув помилку: файл не знайдено.

Це взагалі що за юзкейс такий? Задача парсера — парсити, а не файли читати. Не натягуйте сову на глобус, будь ласка.

Той факт, що HTML парсер поверне DOM структуру, не означає, що він поверне коректну DOM структуру. Як цього досягнути?

Парсер браузера ЗАВЖДИ повертає коректну DOM структуру. Без виключень. Якщо результат парсингу не співпадає з очікуваннями розробника, то розробнику треба переконатися, що той текст, який він згодує парсеру, є коректним та валідним. Це не задача парсера доводити, що він зробив щось так чи не так.

В принципі, якщо треба, щоб код не падав,

То вам треба придумати методи, як це забезпечувати ;)
В реальному світі, коли ви порізали палець, то ви не вмираєте миттєво та не втрачаєте повністю роботоспроможність. Ви можете втратити мобільність та швидкість, але це впливає на вашу продуктивність в першу чергу. ;)

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 21.05.2025 16:18
Це взагалі що за юзкейс такий?

Наприклад, утіліта htmlgrep. Це виглядає як

def htmlgrep(file_path, *, seach_in_text=True, search_in_attribute=False):

Згідно з вашим стайлом замінити на

def htmlgrep(*args, **kwargs):

і тепер вона ніколи не впаде при виклику. От тільки ми викликали 

htmlgrep('/data/index.html', search_attribute=True)

а треба було 

hlmtgrep(file_path='/data/index.html', search_in_attribute=True)
.

Звісно що HTML парсер завжди повертає коректну DOM структуру, звісно що пошук по ній коректно повертає 0 результатів. Звісно ніякої помилки у цьому немає, ніякі тести не потрібні.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 21.05.2025 17:10

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

В такому випадку ваша функція (поки розглядаємо самий тупий варіант) мусить запитати в обʼєкта даних, чи є в ньому потрібні параметри, якщо ні, то ми або нічого не робимо, просто повертаємо обʼєкт як є. Інакше опрацьовуємо та повертаємо модифікований обʼєкт.

Звісно що HTML парсер завжди повертає коректну DOM структуру, звісно що пошук по ній коректно повертає 0 результатів. Звісно ніякої помилки у цьому немає, ніякі тести не потрібні.

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

Парсер дозволяє багато помилятися розробникам, виправляє помилки та структуру по своєму розумінню, закриває теги, атрибути, робить все, щоб вгадати щось. Хоча мусив просто впасти, все як ви любите. ;)

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 21.05.2025 18:16
Чому ви залишили два параметри замість одного?

Тому що це Python, формально це опис функції, яка приймає будь яку кількість параметрів, та не робить жодних перевірок.

Ви вперто продовжуєте доводити мені

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 21.05.2025 18:54
Тому що це Python, формально це опис функції, яка приймає будь яку кількість параметрів, та не робить жодних перевірок.

А мусить бути лише один параметр, й той бажано клас (map в крайньому випадку)

переводячи обговорення ближче до коду, так краще видно.

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

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 21.05.2025 20:56
А мусить бути лише один параметр, й той бажано клас (map в крайньому випадку)

Це нічого не змінює, вважайте що там один параметр, бо завжди можна всі параметри огорнути класом/структурою, чи навпаки.

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

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

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

Відповісти
Підтримати
Олександр Шпак
yvs2014 21.05.2025 21:24
є сенс розмовляти, коли є однакове розуміння про те, який код буде її втілювати

навіть такий?
[ ⊢ [⊥] C [Q] ] ⊃ [ Q ≡ ⊥ ]

Відповісти
Підтримати
Andrii Sevastianov
Олександр Шпак Oarsman в Self Employed 21.05.2025 22:18

Тут запитання, що вважати ⊥.

Відповісти
Підтримати
yvs2014
yvs2014 21.05.2025 22:32

precondition?

resulting in

Це нічого не змінює

Це дуже все змінює

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 22.05.2025 08:13

Без контексту це лише дві безглузді фрази.

Відповісти
Підтримати
yvs2014
Олександр Шпак Oarsman в Self Employed 21.05.2025 22:14
Це нічого не змінює

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

Просто рівень коду відразу демонструє ху із ху

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

Взагалі по взагалях всі спеціалісти триндіти, як тільки питання про код — усе видно.

Що саме ви збираєтеся побачити? Цей підхід називається «атака на особистість». Доволі примітивна маніпуляція, яка полягає в тому, що якщо ви не можете аргументовано вести суперечку, треба поставити під сумнів опонента, його рівень знань, обізнаності, досвід, щоб скомпрометувати все й одразу. Я не граю в такі ігри (хоча можу та інколи полюбляв, але недовго, бо це робить мене покидьком).

Про архітектуру є сенс розмовляти, коли є однакове розуміння про те, який код буде її втілювати.

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

Поки що такого розуміння немає.

Я не можу вам допомогти в цьому. На жаль.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 22.05.2025 10:25
Це дуже все змінює. Це порушення протоколу обміну даними.

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

Цей підхід називається «атака на особистість». Доволі примітивна маніпуляція, яка полягає в тому, що якщо ви не можете аргументовано вести суперечку, треба поставити під сумнів опонента, його рівень знань, обізнаності, досвід, щоб скомпрометувати все й одразу.

Де особистість? Я говорив про свій досвід співбесід джунів. На рівні архітектури всі розумні. На рівні коду...

Архітектура — вона про способи, методи, методології розробки. А реалізація — то вже другорядне.

Ви кажете, що тестування не потрібно, бо можна писати код без помилок. Я кажу: покажіть код, я покажу, де можна помилитися. А на архітектурному рівні завжди можна казати «все прораховано», «ви не розумієте», ...

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 22.05.2025 12:28
З точністю до ізоморфізму це нічого не змінить, будь яку функцію багатьох аргументів можна розглядати як функцію одного аргументу.

Ок, задам інше запитання, при якому підході вище шанси на помилку?

На рівні архітектури всі розумні. На рівні коду...

А як це стосується нашого обговорення? Я не джун.

Я кажу: покажіть код, я покажу, де можна помилитися.

Добре, що це нам дасть? Ви ототожнюєте помилку з тестом. Якщо можна помилитися, значить треба тестувати. Я приводив вже приклад з живих систем, біології. Ви можете тимчасово втрачати мобільність певних кінцівок, при цьому продовжите бути функціональним. Є «помилка», але важлива саме реакція живих організмів на неї. Від того, що ви визначите діагноз, є два варіанти розвитку подій — або обкластися аналізами, або почати лікування. Сучасна розробка каже, що треба обовʼязково обкладатися аналізами.

Відповісти
Підтримати
Andrii Sevastianov
Yuri Glushko 20.05.2025 18:31
Коли ти ставиш задачу, придумайте архітектуру, методику розробки, які б повністю виключали написання тестів

Наведіть приклад?

Відповісти
Підтримати
Олександр Шпак
Yuri Glushko 20.05.2025 18:26
Найрозумніші люди планети намагалися це вирішити.

Та ж не вирішити — а очолити.

Відповісти
Підтримати
Andrii Sevastianov
Alex Fogol Software Developer, C/C++ Expert 17.05.2025 06:53
Один з прикладів — давайте людині ті задачі, які він виконає найкраще
Це є підлаштовування під працівника

це єрунда

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

це залежить від рівня позиції тому зазвичай «процес» не передбачає надходження зовнішніх людей на високі позиції

бо просто бізнес ))

Відповісти
Підтримати
Andrii Sevastianov
Alex Fogol Software Developer, C/C++ Expert 17.05.2025 06:39
Навіщо брати таких слабких кандидатів?

потому шо у пана атамана нема золотого запасу )) ака «закладеного бюджету на проект»

бо так туди може увійти контрактор експерт по $200 за годину але «свого робочого» розраховано по $20

селяві просто бізнес

... тож вони би і взяли не таких слабких но от незадача вони до них не йдуть ))

Відповісти
Підтримати
Олександр Шпак
Alex Fogol Software Developer, C/C++ Expert 17.05.2025 06:50
Весь корпоративний світ працює за таким принципом.

то є не зовсім так а може радше зовсім не так

Там процеси грають визначну роль, не особистості.

тут така цікава історія що так вони би хотіли би щоби процеси грали но там не всьо так однозначно

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

Особистості можуть впливати

а тої «особистості тупої посередності» яка записує собі пароль у себе на столі прямо на стікері до монітора

... тож корпорація просто змушеня створювати процес у якому запроваджено «не записувати пароль на стікері до монітора на столі» саме як процес з відповіднімі «тренінгами» «екзаменами» тощо розрахованими саме на посередність

просто без цього сам бізнес вже на рівні корпорації просто не зможе масштабуватися

власне він просто не зможе масштабуватися вже до рівня корпорації як такої чистого масштабу

але без них все буде працювати без проблем.

але тут починається най цікавіше а хто же ж власне ті уже самі процеси власне створює ))

... тому корпорація має окремі процеси просування ті особистості які можуть

Особистості можуть впливати на ефективність окремих частин процесів

що так само процес але вже окремо орієнтований на підтримку роботи процесів інакше знову же ж таки ніяк

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 17.05.2025 10:22
то є не зовсім так а може радше зовсім не так

А як?

просто без цього сам бізнес вже на рівні корпорації просто не зможе масштабуватися

Не через опосердкованості в ньому. Ти не зможеш масштабуватися без універсальних процесів та залежності від особистостей. Бо особистості не масштабуються.

але тут починається най цікавіше а хто же ж власне ті уже самі процеси власне створює ))

Той, хто на них розуміється. Якщо розуміється добре, то процес вийде аналогічним. Якщо не розуміється — то буде класичне «Я — керівник, ти — дурак».

що так само процес

Так, але він не масштабується.

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 17.05.2025 06:37
Потім три місяці онбордінгу, потім ще три місяці, доки людина не почне приносити велью. Плюс ризики, що за цей час він не розбереться, ...

в американському кейзі це зазвичай покривають експертами контракторами «на короткий термін 3 + 3 місяці плюс передача знань»

... стосовно «ризики що не розбереться» то є загальний ризик навряд чи це щось нове чи особливе але я може ще подумаю над цим моментом окремо

Відповісти
Підтримати
Andrii Sevastianov
Alex Fogol Software Developer, C/C++ Expert 17.05.2025 06:34
а через півроку з’ясувалося, що без нього ніяк
Їм просто було ліньки шукати відповідну заміну.

там питання навіть не просто «шукати» но що само по собі така «відповідна заміна» суто технічно буде коштувати кратно

... бо хінт усім треба бо ж усі так і зробили а тепер «шукати відповідну заміну» але натомість таких щоби справді то є могли «стати відповідну заміну» їх навпаки дуже мало просто виходячи вже з того що не так багато хто отак просто погодиться копати чуже гівно )) селяві просто бізнес

ЗЫ: вони до речі могли спробувати і то реально пошукати слідуючи класичним no try not do or do not there is no try (к) (тм)

... і тут першим моїм власним питанням на такі пропозиції було буде «а старого куди діли?»

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

тож то є так само просто бізнес нічого особистого бо чого ти думаєш як він вже не хочу то я хочу бо я той хто може

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 17.05.2025 10:32
там питання навіть не просто «шукати» но що само по собі така «відповідна заміна» суто технічно буде коштувати кратно

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

Книжки з керування персоналом на кшталт «Як мотивувати працівника залишатися бути лояльним компанії» я щось не зустрічав. А от «Як мінімізувати вплив окремих особистостей на процеси компанії» — це будь-яка книжка з менеджменту. Всі практики там направлені на зменшення залежності від окремих працівників, а не збільшення її.

Відповісти
Підтримати
Alex Fogol
Andrii Sevastianov 17.05.2025 17:22
Якщо б це було правдою, то зараз би всі, а особливо корпорації, намагалися якомога довше зберегти склад компанії та максимально утримувати працівників на робочих місцях.

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

Книжки з керування персоналом на кшталт «Як мотивувати працівника залишатися бути лояльним компанії» я щось не зустрічав.

Досить популярна книжка, як на мене, це «Як пасти котів», одна із думок, як на мене, це те що програмісти — не «ресурси», їх важко змусити щось зробити — треба домовитись.

Всі практики там направлені на зменшення залежності від окремих працівників

Це гарна ціль, проте це також коштує вкладення.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 18.05.2025 10:06
Проблема у тому, що менеджмент зазвичай цього не розуміє.

Вам лише так здається. Як вчителю в школі все видно, так й менеджеру.

програмісти — не «ресурси», їх важко змусити щось зробити — треба домовитись.

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

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

Це гарна ціль, проте це також коштує вкладення.

Але ризики кратно менші.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 11:07
Ви мусите самі себе переконати, що вам потрібно працювати та показувати рівень продуктивності.

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

Особливо я скоріше оберу місце, де мені комфортніше працюється.

Але для бізнесу ви як були ресурсом, так й залишитеся

Я це прекрасно розумію, але навіть у тваринництві надої залежать від умов утримання корів. Будь яким ресурсом треба вміти користуватися. Я більше раджу ставати дефіцитним ресурсом.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 19.05.2025 11:26
Особливо я скоріше оберу місце, де мені комфортніше працюється.

Саме тому ви змінили 20 компаній за свою карʼєру?

Я більше раджу ставати дефіцитним ресурсом.

А я — трохи більш корисним для бізнесу. Всі не зможуть бути дефіцитним. А от корисним — всі.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 11:46
Саме тому ви змінили 20 компаній за свою карʼєру?

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 19.05.2025 12:04

:D Зрозуміло, більше грошей для вас дорівнює кращим умовам.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 19:03

Я просто не бачив останні роки поганих умов.

Відповісти
Підтримати
Олександр Шпак
Alex Fogol Software Developer, C/C++ Expert 17.05.2025 22:51
нижки з керування персоналом на кшталт “Як мотивувати працівника залишатися бути лояльним компанії” я щось не зустрічав.

The Mythical Man-Month: Essays on Software Engineering by Fred Brooks
The Deadline: A Novel About Project Management by Tom DeMarco

цю я не люблю але вона є

Herding Cats: A Primer for Programmers Who Lead Programmers by Hank Rainwater

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

Відповісти
Підтримати
Олександр Шпак
Denys Poltorak Embedded | C++ (opentowork) 18.05.2025 00:08
Книжки з керування персоналом на кшталт «Як мотивувати працівника залишатися бути лояльним компанії» я щось не зустрічав.

Peopleware
Organizational Patterns of Agile Software Development

Відповісти
Підтримати
Олександр Шпак
NoName 17.05.2025 23:00

я случай с увольнением слышал по другому — чел дружил с директором 10 лет семьями, директор ему предложил — давай я тебя золотой парашют счас дам а через год возьму тебя обратно на ту же должность или даже с повышением. Чел взял парашют и ушел, а через пол года директора повысили и он сразу позвал его назад, часть парашюта нада было вернуть и тут помогло повышение зарплаты.

Відповісти
Підтримати
Andrii Sevastianov
Witness 16.05.2025 15:29
Знаю схожу історію, коли одного такого сіньйора звільнили, а оскільки це було у США, то йому виплатили річну зарплатню компенсації. Ну і він полетів відпочивати, а через півроку з’ясувалося, що без нього ніяк. Давай йому пропонувати повертатися, а він вже не хоче... Прийшлося ще збільшувати з/п, домовилися...

что-то мне кажется, что тут речь про продуктовую компанию. И там речи о маржинальности не идет. В аутсорсе другие критерии «держать» гребцов.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 16.05.2025 16:34

Навіть в продуктовій компанії тримати неефективного працівника не будуть. Це бізнес, нічого особистого. Люди гроші заробляють, а не в задовільнення потреб розробників граються, бо вони такі цінні, такі цінні...

Відповісти
Підтримати
Witness
Просто Анон 16.05.2025 17:01
Навіть в продуктовій компанії тримати неефективного працівника не будуть

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

Відповісти
Підтримати
Олександр Шпак
Witness 16.05.2025 17:24

вот да. в продукте, который уже 10+ лет ситуации, как описано выше довольно часто. Хватает знаний, которые не задокументированы и только в голове.
у меня тоже в США коллега вышел из отпуска, а ему на дверь указали. Позвали обратно довольно быстро.

Відповісти
Підтримати
Просто Анон
Олександр Шпак Oarsman в Self Employed 16.05.2025 18:53

Ці знання настільки унікальні були, що решта колективу їх не змогла їх відтворити?

Відповісти
Підтримати
Witness
Witness 16.05.2025 18:54

прикинь )
и это не дев был, а по-современному продакт.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 16.05.2025 18:59

Шкода мені цю компанію. Процеси там не налагоджені від слова взагалі.

Відповісти
Підтримати
Witness
Олександр Шпак Oarsman в Self Employed 17.05.2025 00:30

Вам просто не пощастило. Або ви маєте хибне уявлення про те, як все мусить працювати.

Відповісти
Підтримати
Andrii Sevastianov
Alex Fogol Software Developer, C/C++ Expert 17.05.2025 07:07
Або ви маєте хибне уявлення про те, як все мусить працювати.

це не зовсім так питання лише

а) у ціні

... бо окремо «налагодити процеси» роботи у супермаркеті і окремо у проектній роботі як то інженерія майже будь яка

б) у людях

... як там вже написано «особистості які впливають» бо ж «процеси» не беруться ні з відки їх хтось має так само створювати налагоджувати і так далі на що відповідно потрібні відповідні люди які відповідно можуть

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

щось для ілюстрації

youtu.be/erw1mpwK8nY?t=126

або щось для ілюстрації

youtu.be/XuL-_yOOJck

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 17.05.2025 10:36

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

Відповісти
Підтримати
Alex Fogol
Andrii Sevastianov 17.05.2025 17:39
Питання не в ціні, а в ризиках. Ризик прив’язати бізнес процеси на одну людину, яку може вбити шахед, а значить бізнес гарантовано отримає проблеми, які можуть навіть вбити цей бізнес, кратно вищі за ризики постійного рекрутингу та плинності кадрів.

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

Усі ризики виключити неможливо.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 18.05.2025 10:12

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

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 10:57

Масштабування бізнесу в IT має іншу специфіку — це не франшиза типу McDonald’s, де ріст завжди означає розширення фізичної інфраструктури та найм персоналу. У цифрових продуктах копія майже безкоштовна, а автоматизація — нормальна практика.

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 19.05.2025 11:31

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

P.S. Франшиза теж не про масштабування.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 11:53

Не бачив жодної IT-компанії, яка б масштабувалася за рахунок «процесу виробництва» й автоматизувала саму розробку. У більшості випадків компанії спеціалізуються: або на певній вертикалі, або на типі продукту. Це не конвеєрне «клепання» різного ПЗ, а глибоке занурення в домен.

Відповісти
Підтримати
Олександр Шпак
Valentin Nechayev уповноважений по милицях в Дарницькі печери 18.05.2025 09:45

Ну чому... працював в місці, де налагоджені, щонайменше, в рази краще, ніж в середньому.

Але у нього є свої суттєві недоліки (зараз це вкрай застарілий стек).

Відповісти
Підтримати
Andrii Sevastianov
Alex Fogol Software Developer, C/C++ Expert 17.05.2025 06:58

гиги ))

ЗЫ: а от тут ти плутаєш процеси на кого вони налагоджені і яка їх ціль

Відповісти
Підтримати
Олександр Шпак
Просто Анон 16.05.2025 19:03
Ці знання настільки унікальні були, що решта колективу
їх не змогла їх відтворити?

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

А новій людині до цього всього ще місяць онбордитись.

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 18.05.2025 11:51

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

Задайтеся краще запитанням, скільки часу треба буде тій «тімі», щоб внести чергові правки до фічі. Це набагато цікавіше запитання.

Відповісти
Підтримати
Просто Анон
Олександр Шпак Oarsman в Self Employed 16.05.2025 18:52
Питання в тому як оцінити ефективність.

Є купа готових методик. У вас є чудові метрики — час та гроші. У вас є проекти, фічі, релізи, продукти. Це доволі чітко квантується. Ви що, не можете порахувати, скільки грошей вам принесла фіча чи реліз? А скільки часу ви витратили на це? Хто приймав участь? Який був бюджет розробки?

Далі справа лише за математикою.

Відповісти
Підтримати
Просто Анон
Просто Анон 16.05.2025 19:15
Ви що, не можете порахувати, скільки грошей вам принесла фіча чи реліз?

Звичайно що ні, це ж не стартап де А/Б тестуванням порахували конверсію за останній місяць.

Як порахувати вклад Васі-дева у міграцію з Оракла на Постгресс, який зайняв 3 роки, було задієно сотні людей, і результат буде (ключове слово) через 1-2 роки економити в 20кк$/рік?

Вася маленький гвинтик, він переписує репортінг сервіс про який нікому і так не потрібен буде, але переписати треба бо так вирішив Джон архітект 5 років тому

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 19.05.2025 10:42
Як порахувати вклад Васі-дева у міграцію з Оракла на Постгресс, який зайняв 3 роки, було задієно сотні людей, і результат буде (ключове слово) через 1-2 роки економити в 20кк$/рік?

Ви дійсно не можете придумати жодного варіанту, як це порахувати? Навіть приблизно гадки немає?

Відповісти
Підтримати
Просто Анон
Andrii Sevastianov 16.05.2025 21:10
Ви що, не можете порахувати, скільки грошей вам принесла фіча чи реліз?

В релізі декілька фічей, як зрозуміти що принесло, а що не принесло? Проблема що машини часу не існує. Ми не можемо повернутися в минуле то реалізувати по іншому.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 17.05.2025 00:36

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

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

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 17.05.2025 17:43
Проведіть опитування серед клієнтів, щоб вони склали перелік трьох фіч,

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

Інструментів для аналітики купа. Їх все об’єднує, що вони працюють не дуже добре.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 18.05.2025 10:14

Якщо вони працюють не дуже добре, то чому їх до сих пір використовують?

Ви одні й ті самі дані можете інтерпретувати в різні способи. Те, що хтось не навчився це робити ефективно не каже, що сам підхід неефективний.

Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov 19.05.2025 10:47

Я цього не бачу. Останній раз я заповнював опитник щодо вжитку досить давно.

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 19.05.2025 11:36

А я нещодавно проводив живу сесію з розробниками одного застосунку, щоб їм на прикладах показати мої патерни використання та проблеми, з якими я стикаюся під час користування.

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

Відповісти
Підтримати
Andrii Sevastianov
Alex Fogol Software Developer, C/C++ Expert 17.05.2025 06:09
Бізнес інколи чітко каже — нам треба швидко зробити фічу. Це примітивна задача. Що каже розробник? Швидко не буде, бо це вплине на якість коду, технічний борг, та купа інших псевдопричин, які дуже важливі для розробника

... е ніт ти пропустив «псевдопричин важливих для розробника» якіх конкретно вказано у кейзі і якіх конкретно покриває мінімум 80/20 реальних кейзів але я думаю дещо більше

коли беруть людину зі знанням тонкощів нових стандартів C++, а по факту треба фіксити сі-подібний код. А на спроби переписувати частково на C++

чхала «людина» і на код і на борг і на якість і вообще на «бізнес» даже бо основна і єдна

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

то є «а давайте все перепишемо на сі++»

всьо )) «так вєдь другіх нєт» (к) (тм)

ЗЫ: я провіряв ))

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 17.05.2025 10:38

Вибач, нічого не зрозумів... Можна формулювати думки трохи чіткіше?

Відповісти
Підтримати
Alex Fogol
Prairie Marksman 07.05.2025 16:53

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

Відповісти
Підтримати
nerevar indoril 07.05.2025 05:12

Бо український «сінйор» це чувак(есса) з трьома-чотирма роками досвіду. Звідси і меми про 23-річних сінйорів, хоча у переважній більшості західних компаній це рівень мідла. Хоча звичайно бувають вийнятки коли «стартап взлетів» і співзасновник може начепити собі личку хоч СТО.

Відповісти
Підтримати
IRD 07.05.2025 18:16

То ви ще європейських сеньорів не бачили))))

Відповісти
Підтримати
nerevar indoril
Anton Khristiansen Team Lead 15.05.2025 12:55

чисто для себе хотів прояснити — чувакесса чи чувесса? ))))

Відповісти
Підтримати
nerevar indoril
yvs2014 15.05.2025 14:48
чувак ... 23-річний

234 years old Chewie is approaching middle age

Відповісти
Підтримати
Олександр Шпак
Danylo Bilyk C++ Developer в Freelance 07.05.2025 00:49

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

Відповісти
Підтримати
Philip Pristupa 07.05.2025 04:15
колупає в носі на бенчі, вичикуючи від моря погоди

Де це зараз сеніорів не бенчі тримають?

Відповісти
Підтримати
Danylo Bilyk
Просто Анон 06.05.2025 23:09
Чому компанії найчастіше звільняють Senior’ів?

Бо їх зараз найбільше.
Сіньор в Україні це людина 3+ роки.
Останні 3 роки людей без досвіду майже не беруть, отже джунів і мідів мало.

Ну і на графіку там різниця в межах статистичної похибки, ті ± 2-3% нічого не показують

Відповісти
Підтримати
Andy K 06.05.2025 21:40

Сенйори часто облінились, зупинились у розвитку і займають синекуру експерта в певній області клієнтської системи. Толковий мідл отримує ту експертизу за квартал колупання в коді-доках, коштує дешевше, таски закриває швиденько і не придумує відмазки.

Ну і ще

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

Відповісти
Підтримати
Alex Fogol Software Developer, C/C++ Expert 07.05.2025 03:18
Толковий мідл отримує ту експертизу за квартал колупання в коді-доках

так і є тіко де ж його взять? )) усі давно в сіньори пішли

Сучасні джуни й мідли з тих хто вигризли собі офер в конкуренції з сотнею інших кандидатів.

це як дослівне майже «мільони лемінгів не можуть помилятися» (к) (тм)

Відповісти
Підтримати
Andy K
Vic Programmer 06.05.2025 19:37

Мені це пояснили сініори в 2008-9, усе просто — сініори це собівартість. Коли ви платите джуніорам наприклкад $800-1000, мідлам 1500-2400, а сініорам $4000-6000 — за одного сініора 5 джуніорів дають. Тобто усе елементарно як двері, особливо коли ваш прибуток — це різниця між тим що ви отримуєте і собівартістю — зарплатнею (в IT більше 80% собівартості), податками, електрикою і т.д.
На підйомі ринку компанії треба сініори, щоби клієнта взяти проти конкурентів — або створити якісний продукт. На спаді ринку — компанії ріжуть кости. Дуже часто сініорам просто нема чого робити на спаді, роботи такого рівня просто нема.

Відповісти
Підтримати
Nikita Podgorbunskyi Software Engineer в безмежних просторах цифрових технологій 06.05.2025 19:56

Так, коли нема розвитку починається занепад, а де занепад зазвичай нема задач для яких потрібена висока кваліфікація.

Відповісти
Підтримати
Vic
Sasha G 07.05.2025 17:07

дивлячись які задачі стоять.
якщо просто тягнути час і отримувати за це гроші — може і джунів прокатить.
На своєму прикладі наведу(я сінйор, бек).
Коли задача перелапатити весь проект(старе легасі) розібратись що як працює і імплементувати нову фічу яка затроне пів проекта і зробити відповідні зміни в десятки файлів( в які — сам розберись).
Так от, я зробив це за 3 дні, ще 1 день баги фіксив.
Причому зрпобив це круто, покращивши при цьому проект — зробив рефакторинг і виніс код який можна в сервісні функції, щоб уникнути дублювання коду і в майбутньому при потребі дуже легко робити зміни всього в одному місці а не лазити по всьому проекту.
Бо маю великий досвід колупання в лайні.
5 джунів зроблять це місяці за 3 і ще пів року фікситимуть баги якщо взагалі розберуться.
1 сінйор але не трушний а за вислугою років — так само буде довго возитись.
Але справжніх крутих сінйорів не звільняють(майже), хоч вони і не дешеві, бо вони того варті і джунами їх не заміниш.
А GPT взагалі обісреться на питаннях навіть на 50% складності від тих що я вирішую — перевіряв.

Відповісти
Підтримати
Vic
Vic Programmer 07.05.2025 17:53
якщо просто тягнути час і отримувати за це гроші — може і джунів прокатить.

Комрад ви дивитесь в сутність.

Так от, я зробив це за 3 дні, ще 1 день баги фіксив.

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

Відповісти
Підтримати
Sasha G
Beaver Green 06.05.2025 19:11

Я гадаю причини очевидні:
1) Ринок перекинувся і тепер усі хочуть наймати на −500. Тобто можна звільнити «зажершегося» синьора і знайти з вулиці голодного, який погодиться на −500 ще й буде вислужуватись на новій роботі.
2) В Україну бояться віддавати важливу роботу. А для тупого сапорта легасі (яке просто шкода викнути) може вистачити і мідлів.
3) Як правило клієнти погано дивляться на те, що синьйор, як важлива людина, може у будь-який день зникнути в Україні. Тому синьйорів намагаються наймати в інших країнах.
4) Синьйор може дозволити собі «гупнути дверима» якщо йому не дали підвищення — а тим більше якщо запропонували робити більше роботи за ті самі гроші або навіть менші (усі хочуть −500).
5) Усі сподівання хоч би на зупинку п#здеца закінчуються. Отже бізнес чекає що буде ще більша гепа. І через пів-року навіть якщо якась ІТ робота ще буде — то буде і черга голодних девелоперів, які вже згодні будуть працювати і за їжу.
6) Банально багато компаній або помирають — або виїжджають з України. Відповідно — звільняють усіх.
7) Це лише моє сподівання. Але хочеться вірити що деякі синьйори якось знаходять якийсь вихід з «резервації» і переїздять на більші зарплати у Європі.

Відповісти
Підтримати
Alex Fogol Software Developer, C/C++ Expert 06.05.2025 20:22
1) Ринок перекинувся і тепер усі хочуть наймати на —500. Тобто можна звільнити «зажершегося» синьора і знайти з вулиці голодного, який погодиться на —500 ще й буде вислужуватись на новій роботі.

для цього потрібно мати якусь аналітику по тим сіньорам хто вже кинутий на мороз і вже голодний на −500

... тут якраз доу міг би б допомогти (роботодавцям) з такою саме аналітикою )) ну а що?

Відповісти
Підтримати
Beaver Green
Іван Маляр 09.05.2025 00:59

Насправді ці дані є. І я думаю людина яку ми з вами коментуємо саме на них і посилається.

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 06.05.2025 20:27
Тому синьйорів намагаються наймати в інших країнах.

ніт на жаль з цім усе дуже складно (( інакше вони би все від початку не йшло би в Україну як то by design

Відповісти
Підтримати
Beaver Green
юнит тест 07.05.2025 09:59
може у будь-який день зникнути в Україні

это мнение тупых галер, я знаю фирмы, которые без проблем нанимают даже с Харькова, несмотря на то что на галерах он занесен в негласный блек-лист вместе с Херсоном, Запорожье и другими городами, которые сейчас очень сильно страдают

Відповісти
Підтримати
Beaver Green
Alex Prokopenko Engineer 09.05.2025 20:25

8) Соціально активни мідл з чатом GPT по продуктивності кращий сеньйора інтроверта.

Відповісти
Підтримати
Beaver Green
Oleksii 06.05.2025 19:06

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

Через півроку команда пролонгує контракт з 2 з 6 українських сінйорів, які показали себе як нормальні спеціалісти, а не джуно-мідли. Моралі немає.

Відповісти
Підтримати
Alex Fogol Software Developer, C/C++ Expert 06.05.2025 20:31
он-коли, активно приймають участь у розвитку продукту, про-активність і ось це все.

на погляді же ж якась ацька суміш імітації бурной дєятєльності з не менш ацьким же ж говнокодом простіті це не рахуючи ще «архітектурно бізнес ложік рішень» на яке воно усе «спирається» або ж навпаки не зовсім зрозуміло чи спирається бо ж провести прямі лінії між «архітектурою» та «(говно)кодом» не має ні якої технічної можливості

но активність наліцо як фак ))

Відповісти
Підтримати
Oleksii
Кратос 06.05.2025 20:48

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

Відповісти
Підтримати
Oleksii
Кратос 06.05.2025 20:50

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

Відповісти
Підтримати
Кратос
Alex Fogol Software Developer, C/C++ Expert 07.05.2025 03:20
Хард скіли нікому не потрібні

штучний інтелект всіх замінив уже у хард скіли

... гм чи то навпаки у софт скіли я вже заплутався ((

Відповісти
Підтримати
Кратос
Philip 07.05.2025 14:35

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

А от хард скіли — як реалізувати якусь фічу — для цього зараз вже команда з більшості сіньйорів не потрібна. Достатньо 60%+ з мідлів та джунів і їх вміння користуватись курсором та швидко робити задачі без прокрастинації :)

Відповісти
Підтримати
Alex Fogol
flyman 08.05.2025 22:32

а ще мідли з джунами добрі в дизайн і архітектуру

Відповісти
Підтримати
Philip
Philip 09.05.2025 09:25

Так дизайн і архітектура треба на початку розробки проекту чи нової великої фічі.
Для цього в команді достатньо одного ліда і хай одного сіньйора в команді з 4-5 людей.

А піляти звичайні фічі і фіксити баги набагато ефективніше будуть 2-3 перспективних джуна чи мідла (під невеликим супервіжном сіньйора/ліда), ніж один вигорівший сіньйор за ті самі гроші :)

Відповісти
Підтримати
flyman
flyman 09.05.2025 10:06

довідник стеля,
чому не на стадо з стопіцот баранів один пастух і дві вівчарки?
чому на початку розробки чи нової великої фічі дизайн і архітектура?
вам приходять задачі в стилі літкода?

Відповісти
Підтримати
Philip
Philip 09.05.2025 11:05

Бо на початку розробки — це як раз задача сіньйора / ліда / архітектора — закласти цю архітектуру, базу даних, налаштувати клауд, взаємодію сервісів і т.д.
Далі йде взаємодія з продакт менеджером, аналітиками і треба просто пилити фічі в рамках тієї архітектури, яку заклали. Сіньйори від таких задач часто вигорають, бо нудно, і роблять їх довго.
Як приходять задачі — по різному: зробити сторінку — ось дизайн, інтегрувати сервіс — має бути такий результат, зібрати датасет, проаналізувати дані, протестувати промпти LLM для купи різних кейсів, заімплементити фічу Х для клієнта B на основі того, як зробили для клієнта А.
В усіх цих кейсах для виконання 90% задачі не треба сіньйор. А треба його залучення тільки на початкове обговорення та ревʼю проміжних етапів та результатів.
В такому випадку і для сіньйора це може бути цікавіше — бо він зробить за два тижні не одну складну і дві простих задачі, а одну складну і прийме участь в імплементації чотирьох-шести простих

Відповісти
Підтримати
flyman
flyman 09.05.2025 11:22

лід, архітект і сенйор, це три різні людини,
і не плутайте HLD з (ре)дизайном модуля
як правило лід, архітект це поштучно на проект, а сенйори гуртом не западло

Відповісти
Підтримати
Philip
Philip 09.05.2025 12:08

Звісно три різні, хоча іноді на проектах може бути тільки одна чи дві.
Але концептуально, з точки зору компанії, що лід, що архітектор, що сіньйор, отримують майже одні й ті самі гроші.
(добре, архітектор може на 1-2k$ більше).
Але з точки зору складності, кількості задач і відповідальності зазвичай архітектор та лід роблять набагато більше...)
Тому й виходить, що багато сіньйорів не потрібно — їх має бути не сильно більше за лідів та архітектів )

Відповісти
Підтримати
flyman
Олександр Шпак Oarsman в Self Employed 09.05.2025 12:21

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

Відповісти
Підтримати
Philip
Philip 09.05.2025 12:42

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.05.2025 13:05

Тоді краще казати, що їхня функціональна роль набагато ширша.

Відповісти
Підтримати
Philip
flyman 09.05.2025 12:41

it depends, але якщо мова про клепання форм і написання крудів, то може і так як пишеш, достатнього одного пастуха для стада джунів з копілотами

Відповісти
Підтримати
Philip
Микола Сидоренко 09.05.2025 11:37

А може не варто за когось вирішувати коли йому буде нудно, а коли не буде?

Відповісти
Підтримати
Philip
Philip 09.05.2025 12:33

В мене є дві відповіді:
* по-перше я сам на власному досвіді, та досвіді друзів та колег знаю, які задачі нудні для сіньйорів, призводять до їх вигорання чи пошуку другого фулл-тайму чи парт-тайму :)
* по-друге з точки зору менеджменту продуктової компанії/стартапу — набагато краще кожній людині давати достатньо складні задачі, які людина зможе вирішити за оптимальне [кількість людина-годин * вартість]
Тобто якщо сіньйор вирішив задачу за день (хоча насправді вона зайняла дві-три години, а потім пішов займатись власними справами), то це менш оптимально, ніж джун вирішив задачу також за день (хай буде 7 годин) і потребував однієї години допомоги сіньйора :)

Відповісти
Підтримати
Микола Сидоренко
flyman 09.05.2025 12:44

у вас горизонт планування одна таска, і взагалі, «не потрібно щоб робота була зроблена, важливо щоб працівники замахалися»

Відповісти
Підтримати
Philip
Philip 09.05.2025 13:16

нууу... я не погоджуюсь
у нас є і заплановані OKR на квартал з розписаними ініціативами, і планування спрінтів
просто краще, коли всі члени команди кожен день завантажені і працюють як раз в сторону виконання цих OKR :)

плюс є справа в бюджеті — наприклад у компанії є бюджет ХХk$ на місяць на всю інженерну команду стартапу.
І за ці гроші або можна найняти ліда і 4 скілових сіньйора. Або трьох сіньйорів, трьох мідлів та трьох джунів.

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

Відповісти
Підтримати
flyman
flyman 09.05.2025 13:20

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

Відповісти
Підтримати
Philip
Олександр Шпак Oarsman в Self Employed 09.05.2025 13:27

Назвіть три основні причини вигоряння

Відповісти
Підтримати
flyman
flyman 09.05.2025 13:37

в кожно це індивідуально, а статистикою не володію, не моя спеціалізація «пасти стадо з вирішенням задачі лінійного програмування»

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.05.2025 14:37

Ви свої можете причини назвати, які вам здаються логічними.

Відповісти
Підтримати
flyman
Олександр Шпак Oarsman в Self Employed 09.05.2025 15:27

Не знайшов чомусь..

Відповісти
Підтримати
flyman
Олександр Шпак Oarsman в Self Employed 09.05.2025 18:11

Це лише запитання, не твердження.

Відповісти
Підтримати
flyman
Олександр Шпак Oarsman в Self Employed 09.05.2025 13:26

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

Відповісти
Підтримати
Philip
Микола Сидоренко 09.05.2025 19:52

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

Відповісти
Підтримати
Philip
Philip 10.05.2025 10:03

Я не про те, що сіньйори не потрібні. Потрібні, але їх не має бути більше за 30-50% від команди.
І так, вони мають вирішувати ті задачі, які вирішать краще за джунів.
Мідли також треба, бо більшість не архітектурних і не інфраструктурних задач вони можуть вирішити майже так швидко і майже з такою ж якістю, але коштувати в 1.5-2 рази дешевше. Та і ростуть часто швидко.
Джуни також треба, бо вони можуть вирішувати відносно рутинні, не цікаві задачі для інших (зібрати датасет, проскрапити якісь сайти, заімплементити якусь відносно просту задачу по аналогії), при цьому коштують в 5-10 разів менше за сіньйора.
Ну і для мідлів та сіньйорів менторінг і навчання джунів це також може бути професійне зростання.
Для всіх є свої задачі, і якщо у компанії є обмеження по бюджету (а так у більшості) — то треба мати баланс різних рівнів розробників, а не тільки всіх сіньйорів

Відповісти
Підтримати
Микола Сидоренко
Andrii Sevastianov 10.05.2025 10:37

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

Ну і для мідлів та сіньйорів менторінг і навчання джунів це також може бути професійне зростання.

Це значні ресурси, а от про зростання не впевнений.

Відповісти
Підтримати
Philip
Alex Fogol Software Developer, C/C++ Expert 10.05.2025 23:16
Так дизайн і архітектура треба на початку розробки проекту чи нової великої фічі.

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

шоб ніхто не здогадався шо так у коді є і шо там мало бути і яке взагалі було питання життя всесвіту і взагалі

Відповісти
Підтримати
Philip
Олександр Шпак Oarsman в Self Employed 09.05.2025 09:42

Думаєте сіньйори в неї вміють?

Відповісти
Підтримати
flyman
flyman 09.05.2025 10:06

ви працювали в тімі де одні сінйори? а задачі від клієнта приходять в стилі повного ажайла

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.05.2025 10:32

Так. Розпочати проект простіше з сіньйорами в команді. Менше часу витрачаєш на пояснення. Але це працює лише до певного моменту. Допоки не починає падати мотивація.

Відповісти
Підтримати
flyman
flyman 09.05.2025 10:36

І чому ж падає мотивація? Замотивовують спрінтами? Не піднімають рейт хоча б щоб покрити інфляцію? Порушують домовленості? Нема WLB? Чому вона падає опівнашосту? Лєвак укрєпляєт брак?

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 09.05.2025 11:46

Я вже писав основні причини вище.

Відповісти
Підтримати
flyman
Олександр Шпак Oarsman в Self Employed 09.05.2025 12:24

Я не зобовʼязаний нікого переконувати. ;)
Хочете довести зворотнє — доводьте. З моєї практики — все відбувається саме так, як я написав.

Відповісти
Підтримати
flyman
Philip 09.05.2025 10:48

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

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

Відповісти
Підтримати
flyman
Alex Prokopenko Engineer 09.05.2025 20:31

Для архітектури є архітектор. Чому я маю забирати чийсь 🍞

Відповісти
Підтримати
flyman
flyman 09.05.2025 21:57

ясно, ти тільки код кодити, ти точно сенйор?

Відповісти
Підтримати
Alex Prokopenko
Alex Prokopenko Engineer 09.05.2025 22:01

А вам шашички чи їхати? Я ще після себе чашки на кухню відношу.

Відповісти
Підтримати
flyman
Philip Pristupa 07.05.2025 03:25

Хард-скіли в українських сеніорів дуже низькі. Бо 2-3 фултайми.

Відповісти
Підтримати
Кратос
Alex Prokopenko Engineer 09.05.2025 20:29

Софт скіли, вміння бухати і підлизувати босу завжди були важливим елементом виживання в стаї. Під час ковіду то трохи підзабулося, але природа бере своє.

Відповісти
Підтримати
Кратос
Oleksii 07.05.2025 21:49

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

Відповісти
Підтримати
Кратос
Alex Prokopenko Engineer 09.05.2025 20:26

Бо в них акації фірми, кожен квартал падають дивіденди.

Відповісти
Підтримати
Кратос
flyman 08.05.2025 22:29

то якась не правильна європейська команда без поставленого по феншую WLB

Відповісти
Підтримати
Oleksii
Dmytro 06.05.2025 18:52

Бо нормальному сеньйору за 25 і ніхто особливо не вірить в кінець попи в найближчі роки, хіба що дядя Петя зробив його інвалідом.

Відповісти
Підтримати
anonymous
дмитрий аношенко DPM в lifecell 06.05.2025 16:44

Не давно побачив на стовпі обʼяву — шукають збірника вікон на виробництво. Вимоги до кандидата — студент до 25, жінка або чоловік за 60. Здається, навіть на виробництвах ніхто вже не шукає «сіньойра» у віці 25-45 ¯\_(ツ)_/¯

Відповісти
Підтримати
Donald Trump 07.05.2025 03:22

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

Відповісти
Підтримати
дмитрий аношенко
Микола Сидоренко 07.05.2025 08:28

Ні, все ще простіше: бо 25-45 річні можуть просто не дійти до роботи, в будь-який рандомний день. А часто і прямо з роботи може зникнути в будь-який рандомний день під час перевірки ТЦК. Так мого знайомого забрали, прямо з роботи, навіть машину не дали відігнати додому.

Відповісти
Підтримати
Donald Trump
Про різні речі 09.05.2025 20:30

Варіантів у цих людей не багато і вони всі складні:
https://aboutdifferentthings.com/dlya-bahatokh-dobre-vzhe-ne-bude-ale-ya-khotiv-by-pomylyatysya/

Відповісти
Підтримати
Микола Сидоренко
Vic Programmer 07.05.2025 08:35

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

Відповісти
Підтримати
Donald Trump
дмитрий аношенко DPM в lifecell 06.05.2025 16:42

Не давно побачив на стовпі обʼяву — шукають збірника вікон на виробництво. У вимогах до кандидата — студент, жінка, або ж чоловік старше 60 років. Здається «сеньйорів», у віці 25-45 навіть на виробництві вже ніхто не шукає ¯\_(ツ)_/¯

Відповісти
Підтримати
Євгенія Невська HR-manager 06.05.2025 16:24

Що частіше чула : оптимізація затрат, напевно, одна із найчастіших причин ( можуть як і своїми замінити, так і колегами з Азії/Індії/Пакистану) ; немає проекту; бенч може не оплачуватися; клієнт може дропнути всю тіму, бо в Польщі/ЄС безпечніше ітд; просто рішення зверху від менеджменту;

Відповісти
Підтримати
Andrey MK 06.05.2025 15:08

Недавно разговаривал со старым знакомым(сеньором) из Австралии.Спрашиваю как там у Вас? У него на работе более половины IT сотрудников сеньор уровня(и по знаниям и по возрасту) А он спрашивает а как мол у Вас? А у нас ж...па кругом

Відповісти
Підтримати
yvs2014 06.05.2025 10:53

якщо виходити з того що ділення на 4 страти junior/middle/senior/lead в багатьох випадках штучне, і «чому» фактор знаходиться в іншій площині, — то питання розвернеться в сторону що не так з самим тим розподілом

Відповісти
Підтримати
Donald Trump 06.05.2025 10:03

Тому що джун, який обложився АІ інструментами і написав кілька десятків правил в курсорі працює ефективніше за сінйора, який гордиться знаннями мютексів і постійно зітхає «як ви вже заіпали зі своїм АІ». А коштує при цьому в 5 раз дешевше. Не обов’язково АІ, замінити на будь-який тренд.

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

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

Відповісти
Підтримати
igor stepanushko Salesforce Developer 06.05.2025 15:06

м-да ... учить мат. часть ... и про АІ в том числе :)

Відповісти
Підтримати
Donald Trump
Rostyk Chuma Software developer в Haly Software 06.05.2025 15:23

орнув, вже маю стале відчуття що не 1 джун, а цілих 2 на проекті, перший людина, інший АІ

Відповісти
Підтримати
Donald Trump
Fenix 06.05.2025 15:28
АІ, замінити на будь-який тренд

трампа теж скоро замінить якийсь AI, при цьому набагато ефективніший для вирішення міжнародних конфліктів та досить дешевий для пратників податків ))

Відповісти
Підтримати
Donald Trump
Roman Petrovich 06.05.2025 15:32

джуни пиляють круди, сіньйори пиляють рішення. Джун з трьома AI не завжди дотягне до сіньора.

Відповісти
Підтримати
Donald Trump
Donald Trump 07.05.2025 03:17

Це нормальні сінйори пилять рішення, ті які розвиваються, вчать, пробують щось нове, сидять на технічних ресурсах, гіки в душі, не бояться складних задач. А половина робить роботу з якою б і нормальний джун справився, щоб сильно не напрягатися і в 17:00 піти до сім’ї і сісти за комп наступного дня в 8 ранку. Єдина перевага цих сінйорів що проект краще знають, але у джуна мозги краще і швидше працюють, тому по ефективності можна сказати урівновішують друг-друга, а через пів року-рік, коли джун вивчить проект, він буде рвати такого сінйора.

Відповісти
Підтримати
Roman Petrovich
Alex Fogol Software Developer, C/C++ Expert 07.05.2025 03:23
але у джуна мозги краще і швидше працюють

у спрощеному оцінкою парето відношенні 80/20 то є не так

а через пів року-рік, коли джун вивчить проект, він буде рвати такого сінйора.

канєшно )) просто перейде через дорогу на +500 )) сири самі себе не куплять

Відповісти
Підтримати
Donald Trump
Vic Programmer 15.05.2025 14:40
у спрощеному оцінкою парето відношенні 80/20 то є не так

Чисто фізично звісно в них нервові з’вязки там і т.д. звісно краще, як і у спортцменів там вік є вік біологію ще ніхто не відміняв. Та самі знаєте, може зовім не туди щось робити, не та застрягати на якихось простих речах і т.д. І тут просто усе кинути і забити болт там, чи якусь діч чудити і т.д. Там часто дісйно — «Сила є розуму не треба», не дивлячись на інтелектуальну працю — через брак вирпрацюваної системи мислення, ця праця з рештою безтолкова.
Звісно, як хтось типу Аристотеля навчить сисистемі мислення і системногому мисленню вазагалі — з того виходить Александр Македонський. А так усе власним шляхом пробами та помилками і вже виходить певний вік коли воно напрацьовано.

а через пів року-рік, коли джун вивчить проект, він буде рвати такого сінйора.

В 50% випадків в сучасному IT через пів року, буде зовсім інший проект, або інший стрім як це назвуть і т.д. «Проект» в термінах аустсорсніга, це торговий «проект» тобто надання персоналу чи послуг конкретному типу клієнту, що він там робить для чого і т.д. — взагалі третя справа яка особливо нікого не цікавить, окрім як це ще комусь треба на ринку, аби платили справно. Тобто це підміна понять, правильно це будо би називати відпрацювання замовлення по договору. Реально проектна організація праці рідко де є. Атсорс 100% взагалі не проектна орнанізація праці як така, це сервісна модель бізнесу — справді надання послуг, як не дивно.

Відповісти
Підтримати
Alex Fogol
Дмитро Московченко Java Developer в EPAM 07.05.2025 12:57
не завжди дотягне

А в яких випадках дотягне?

Відповісти
Підтримати
Roman Petrovich
Serhii 06.05.2025 15:34

Так-так, все вірно, продовжуй так робити далі.

Відповісти
Підтримати
Donald Trump
Oleksii Kliuiev Senior backend developer 06.05.2025 17:16

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

Відповісти
Підтримати
Donald Trump
Oleksandr Kradenkov iOS/macOS Software Engineer 07.05.2025 11:34

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

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

Все ж зрізання витрат на ЗП фахівцям через сповільнення розвитку виглядає реалістичніше.

Відповісти
Підтримати
Oleksii Kliuiev
Ювженко Денис System Architect в Intellias 06.05.2025 19:43

А виявляється в нашого форумного «Трампа» і в справжнього куди більше спільного ніж могло здатися!

Відповісти
Підтримати
Donald Trump
Андрій Сторожук python developer 07.05.2025 00:56
Тому що джун, який обложився АІ інструментами і написав кілька десятків правил в курсорі працює ефективніше за сінйора

ну ну

Відповісти
Підтримати
Donald Trump
Quintinus Quatruus 09.05.2025 19:36

АХАХАХХАХАХАХА
ти то сам цей курсор використовував? половина кода яку він дає — це антипатерни, які компілюються в кращому випадку через 3-4 ітерації вайбкодінгу.
короче нафіга фріку щось доводити. нехай пишуть такий вайдкоб, потім роботи сініорам буде більше

Відповісти
Підтримати
Donald Trump

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.