Трагедія ентерпрайзної розробки
Значну частину кар'єри я працював у великих, ентепрайзних компаніях які робили ентерпрайзний софт на ентерпрайзній технології Java Enterprise Edition.
Велика компанія, велика кількість людей, велика кількість клієнтів, великі клієнти.
Все велике.
Все, крім мого вкладу. Він мізерний, а то й від'ємний.
Головна проблема ентерпрайзу для мене — важливість не результату, а процесу. Байдуже чи добрий ви софт робите, чи поганий. Чи повільно, чи швидко. Поки крутяться шестерні well-oiled sales machine, контракти крутяться і лавеха мутиться, не має значення взагалі що ви робите.
Вперше я це усвідомив коли з подивом дізнався, як один з замовників відмовився від нашого рішення на користь іншого. Цей проєкт тривав декілька років, і в ньому були залучені значні людські ресурси. Але потім у клієнта змінився якийсь CIO, і він одним махом перекреслив всі зусилля.
Пізніше я побачив що великі продажі працюють зовсім не так, як умовні маленькі. Люди, які будуть вашими користувачами, часто не зацікавлені в змінах або чомусь новому та чинять пасивний опір. Особа, що приймає рішення про покупку або підписання контракту не є цільовою аудиторією даного проєкту. Команда продавців вдається до різноманітних трюків на грані хабарництва, щоб схилити клієнта на свій бік.
Якість стрімко летить у прірву, бо середовище виховує відповідний майндсет людей — робити якомога менше та уникати відповідальності. Хто працює понад норму — той, очевидно, дурень, бо зусилля його будуть все одно змарновані.
Звичайно, крім обговорення зарплат працівникам на таких проєктах більше нічого не цікаво. Бо їх робота порожня, результат не важливий, впливу на нього не має, а всім на все байдуже.
Втрачається мотивація робити щось, бо воно нікому не потрібне.
Люди, що можуть працювати так роками, викликають в мене деяку повагу. Як тільки бачу що те, що я роблю, нікому не треба, мій віртуальний прутень мотивації ловить пів на шосту, а мозок починає думати чим би нормальним зайнятися натомість, або впадає в апатію.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Значну частину кар'єри я працював у великих, ентепрайзних компаніях які робили ентерпрайзний софт на ентерпрайзній технології Java Enterprise Edition.
Велика компанія, велика кількість людей, велика кількість клієнтів, великі клієнти.
Все велике.
Все, крім мого вкладу. Він мізерний, а то й від'ємний.
Головна проблема ентерпрайзу для мене — важливість не результату, а процесу. Байдуже чи добрий ви софт робите, чи поганий. Чи повільно, чи швидко. Поки крутяться шестерні well-oiled sales machine, контракти крутяться і лавеха мутиться, не має значення взагалі що ви робите.
Вперше я це усвідомив коли з подивом дізнався, як один з замовників відмовився від нашого рішення на користь іншого. Цей проєкт тривав декілька років, і в ньому були залучені значні людські ресурси. Але потім у клієнта змінився якийсь CIO, і він одним махом перекреслив всі зусилля.
Пізніше я побачив що великі продажі працюють зовсім не так, як умовні маленькі. Люди, які будуть вашими користувачами, часто не зацікавлені в змінах або чомусь новому та чинять пасивний опір. Особа, що приймає рішення про покупку або підписання контракту не є цільовою аудиторією даного проєкту. Команда продавців вдається до різноманітних трюків на грані хабарництва, щоб схилити клієнта на свій бік.
Якість стрімко летить у прірву, бо середовище виховує відповідний майндсет людей — робити якомога менше та уникати відповідальності. Хто працює понад норму — той, очевидно, дурень, бо зусилля його будуть все одно змарновані.
Звичайно, крім обговорення зарплат працівникам на таких проєктах більше нічого не цікаво. Бо їх робота порожня, результат не важливий, впливу на нього не має, а всім на все байдуже.
Втрачається мотивація робити щось, бо воно нікому не потрібне.
Люди, що можуть працювати так роками, викликають в мене деяку повагу. Як тільки бачу що те, що я роблю, нікому не треба, мій віртуальний прутень мотивації ловить пів на шосту, а мозок починає думати чим би нормальним зайнятися натомість, або впадає в апатію.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Build vs buy
Колись працював в стартапі, що мав модель gig economy. Будь-яка людина могла стати робітником.
Щоб якимось чином провести відсіювання майбутніх гіг-воркерів потрібно було зробити щось типу системи навчання та тестування.
СТО зарядив мене на цю задачу.
Зробив круди для питань, відповідей, блоків тестів і тд.
В продакшен то все не пішло, та незабаром було викинуто на звалище нікому не потрібного коду, тому що бізнес-модель вирішили змінити, а від гіг-воркерів відмовилися.
Нещодавно я проходив лінійку корпоративних тестів, і згадав ті часи.
Задумався, чому CTO не взяв готову систему? Їх же мають бути сотні, курси це настільки типова задача що можна було просто підібрати будь-який продукт та зробити з ним мінімальну інтеграцію.
Натомість ми робили своє рішення, ще й на джаві та реакті (до реакту, щоправда, діло не дійшло, скасували раніше).
Тим більше ми були стартапом для якого це не було кор-компетенцією, а перших людей можна було б набрати буквально вручну та посадити робити тести на папірці.
Зараз би я звичайно запропонував взяти щось готове, але тоді ще не був таким розумним та змарнував свій час, час СТО та інших людей на порожню діяльність.
P.S.: Цікаво що той же CTO поставив задачу пошукати рішення для авторизації юзерів (типу auth0 і тд), тобто це не була системна похибка.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Колись працював в стартапі, що мав модель gig economy. Будь-яка людина могла стати робітником.
Щоб якимось чином провести відсіювання майбутніх гіг-воркерів потрібно було зробити щось типу системи навчання та тестування.
СТО зарядив мене на цю задачу.
Зробив круди для питань, відповідей, блоків тестів і тд.
В продакшен то все не пішло, та незабаром було викинуто на звалище нікому не потрібного коду, тому що бізнес-модель вирішили змінити, а від гіг-воркерів відмовилися.
Нещодавно я проходив лінійку корпоративних тестів, і згадав ті часи.
Задумався, чому CTO не взяв готову систему? Їх же мають бути сотні, курси це настільки типова задача що можна було просто підібрати будь-який продукт та зробити з ним мінімальну інтеграцію.
Натомість ми робили своє рішення, ще й на джаві та реакті (до реакту, щоправда, діло не дійшло, скасували раніше).
Тим більше ми були стартапом для якого це не було кор-компетенцією, а перших людей можна було б набрати буквально вручну та посадити робити тести на папірці.
Зараз би я звичайно запропонував взяти щось готове, але тоді ще не був таким розумним та змарнував свій час, час СТО та інших людей на порожню діяльність.
P.S.: Цікаво що той же CTO поставив задачу пошукати рішення для авторизації юзерів (типу auth0 і тд), тобто це не була системна похибка.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Ваша робота — робити боса щасливим
Кмітливий співробітник фаангу знає, що підвищення дають не за старанну роботу, а за добре зібраний promo package.
Це породжує викривлену систему мотивації, результати якої ми можемо спостерігати в безглуздих редизайнах гмейлу та депрекейті продуктів гугл клауду.
Здається що українські компанії ще не пройшли так далеко, принаймні я не чув про якісь формальні-формальні процедури з комітетами, документами і тд, частіше все зводиться до «дайте грошей або я йду» або зміни роботи на +500 (ах, які були безтурботні часи!). Втім я вже давно не працював в наших конторах тому буду радий новинам з лідерів ринку.
Менше з тим, уважний та старанний кар'єрист швидко усвідомлює, що грошова винагорода часто ніяк не корелює з успіхами компанії як юридичного організму, а швидше корелює з тим чи мотивовані люди які мають владу дати вам цю винагороду, це зробити.
Якщо немає ніякої можливості перестрибнути через голову боса, то так чи інакше вся ваша діяльність повинна буде зводитися до того, щоб робити того щасливим. Як і в фаангах, це може розходитися з декларованими або справжніми цілями компанії.
Це звичайно якщо ви хочете отримати те саме міфічне «підвищення», у вигляді плюс грошей або, частіше, плюс обов'язків та сумнівного тайтлу в корпоративному орг чарті.
А якщо не хочете, то можна просто займатися своїми справами та не відсвічувати на стендапах.
Не знаю як вас, а мене такий стан справ пригнічує надзвичайно.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Кмітливий співробітник фаангу знає, що підвищення дають не за старанну роботу, а за добре зібраний promo package.
Це породжує викривлену систему мотивації, результати якої ми можемо спостерігати в безглуздих редизайнах гмейлу та депрекейті продуктів гугл клауду.
Здається що українські компанії ще не пройшли так далеко, принаймні я не чув про якісь формальні-формальні процедури з комітетами, документами і тд, частіше все зводиться до «дайте грошей або я йду» або зміни роботи на +500 (ах, які були безтурботні часи!). Втім я вже давно не працював в наших конторах тому буду радий новинам з лідерів ринку.
Менше з тим, уважний та старанний кар'єрист швидко усвідомлює, що грошова винагорода часто ніяк не корелює з успіхами компанії як юридичного організму, а швидше корелює з тим чи мотивовані люди які мають владу дати вам цю винагороду, це зробити.
Якщо немає ніякої можливості перестрибнути через голову боса, то так чи інакше вся ваша діяльність повинна буде зводитися до того, щоб робити того щасливим. Як і в фаангах, це може розходитися з декларованими або справжніми цілями компанії.
Це звичайно якщо ви хочете отримати те саме міфічне «підвищення», у вигляді плюс грошей або, частіше, плюс обов'язків та сумнівного тайтлу в корпоративному орг чарті.
А якщо не хочете, то можна просто займатися своїми справами та не відсвічувати на стендапах.
Не знаю як вас, а мене такий стан справ пригнічує надзвичайно.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Морозні фрілансери
Розповсюджена тема серед різного штибу гіг-виконавців — зникати та не давати апдейтів по замовленню.
Спочатку людина готує сніданками (inb4 підлога країни за рискою зубожіння), а потім просто зникає.
Мені ото треба трохи патчів зробити, я побачив в метро піратську рекламу, там інстаграмний акаунт. Написав туди, відповів чоловік, скинув йому шаблон, той назвав ціну та запитав адресу, я все дав. Далі тіп зник. На повідомлення не реагував.
В чому проблема відповісти «вибачте не можу зараз зробити ваше замовлення» або «зараз не маю можливості, напишіть через місяць»?
Ті патчі я так і не отримав, але і гроші не витратив.
Нещодавно блукаючи твітером натрапив на акаунт пані що теж робить патчі. Вона активно веде соцмережі, має трохи підписоти, ну думаю ура, є найдійний виробник.
Пишу, кажу так і так треба патчі — «ок, з вас 3000 гривень», питаю карту, скидую гроші, питаю коли чекати — «на початок наступного тижня».
Як ви вже здогадалися, на «початок наступного тижня» мені ніхто не відписав. Я почекав ще два дні та ввічливо поцікавився як справи. «Чекаю від дизайнера в суботу має бути та зразу друкуємо». Ну ок.
В суботу мені ніхто не пише. Ну думаю ясно все з вами. В цей понеділок вже більш агресивно прошу назвати реальні терміни та не переоцінювати власні сили. Треба почекати — я почекаю, просто скажіть коли і як. «Сьогодні ввечері буду точно знати, дизайнер затримується».
Звичайно ж ввечері мені ніхто не відповів. І вчора теж.
Я сам був такою людиною двічі. Перший раз ми з моєю компанією реально продовбали дедлайн по одному з проєктів. Я не встигав і просто не знав що відповісти клієнту. А якщо не знаєш що відповісти, то починаєш прокрастинувати та морозитись. Бо не можеш обіцянку нову дати, тому що сам не знаєш коли воно буде зроблено.
Другий раз я просто не хотів робити якусь задачу та теж морозився і не відповідав керівнику, аж поки він не дістав мене через телефонний дзвінок.
Я розумію що мої 3000 гривнів то не бозна-які гроші, може в тої пані є замовлення на 30000, і моє їй нецікаве. Але чому б просто не сказати про це?
Навіщо брати роботу та повну оплату, а потім ігнорувати клієнта? Я б вже просто шукав іншого виконавця і всі були б задоволені.
☝️Як робити правильно? А правильно просто чесно розповісти про всю ситуацію та давати своєчасні апдейти, щоб у замовника була можливість спланувати ризики. «Дизайнер затримується, через тиждень буду знати. Якщо вам це не підходить, то ось ваші гроші».
А не падати на мороз та змушувати клієнта постійно пінгувати вас.
🤬
#робота #кулсторі
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Розповсюджена тема серед різного штибу гіг-виконавців — зникати та не давати апдейтів по замовленню.
Спочатку людина готує сніданками (inb4 підлога країни за рискою зубожіння), а потім просто зникає.
Мені ото треба трохи патчів зробити, я побачив в метро піратську рекламу, там інстаграмний акаунт. Написав туди, відповів чоловік, скинув йому шаблон, той назвав ціну та запитав адресу, я все дав. Далі тіп зник. На повідомлення не реагував.
В чому проблема відповісти «вибачте не можу зараз зробити ваше замовлення» або «зараз не маю можливості, напишіть через місяць»?
Ті патчі я так і не отримав, але і гроші не витратив.
Нещодавно блукаючи твітером натрапив на акаунт пані що теж робить патчі. Вона активно веде соцмережі, має трохи підписоти, ну думаю ура, є найдійний виробник.
Пишу, кажу так і так треба патчі — «ок, з вас 3000 гривень», питаю карту, скидую гроші, питаю коли чекати — «на початок наступного тижня».
Як ви вже здогадалися, на «початок наступного тижня» мені ніхто не відписав. Я почекав ще два дні та ввічливо поцікавився як справи. «Чекаю від дизайнера в суботу має бути та зразу друкуємо». Ну ок.
В суботу мені ніхто не пише. Ну думаю ясно все з вами. В цей понеділок вже більш агресивно прошу назвати реальні терміни та не переоцінювати власні сили. Треба почекати — я почекаю, просто скажіть коли і як. «Сьогодні ввечері буду точно знати, дизайнер затримується».
Звичайно ж ввечері мені ніхто не відповів. І вчора теж.
Я сам був такою людиною двічі. Перший раз ми з моєю компанією реально продовбали дедлайн по одному з проєктів. Я не встигав і просто не знав що відповісти клієнту. А якщо не знаєш що відповісти, то починаєш прокрастинувати та морозитись. Бо не можеш обіцянку нову дати, тому що сам не знаєш коли воно буде зроблено.
Другий раз я просто не хотів робити якусь задачу та теж морозився і не відповідав керівнику, аж поки він не дістав мене через телефонний дзвінок.
Я розумію що мої 3000 гривнів то не бозна-які гроші, може в тої пані є замовлення на 30000, і моє їй нецікаве. Але чому б просто не сказати про це?
Навіщо брати роботу та повну оплату, а потім ігнорувати клієнта? Я б вже просто шукав іншого виконавця і всі були б задоволені.
☝️Як робити правильно? А правильно просто чесно розповісти про всю ситуацію та давати своєчасні апдейти, щоб у замовника була можливість спланувати ризики. «Дизайнер затримується, через тиждень буду знати. Якщо вам це не підходить, то ось ваші гроші».
А не падати на мороз та змушувати клієнта постійно пінгувати вас.
🤬
#робота #кулсторі
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Овнершип
Знаєте найпростіший спосіб добитися того, щоб людина мотивовано педалила на вас денно і нощно? Дати ій овнершип.
Я неодноразово попадався на цей гачок, і ділюся з вами рецептом.
Берете звичайного наївного молодого програміста і даєте йому в розробку продукт. Причому даєте від початку до кінця, щоб всі технічні рішення приймав він. Це дуже важливо!
Запрошуєте на продуктові мітинги, вислуховуєте його думки щодо задач, цокаєте та вдаєте що берете це до уваги.
Даєте йому можливість працювати на будь-яких технологіях в рамках вашого бюджету та термінів.
Платите нормально грошей, не дуже багато, але й не мало.
Слідкуєте, щоб він мав повний контроль над рішенням та не міг звинуватити у своїх невдачах нікого, крім самого себе. Ні «архітектора від клієнта», ні «тупих девів з сусіднього відділу», ні «недолугого РМ», нікого. Вся відповідальність на ньому.
Робите так, щоб він виростив продукт сам та відчував що це його справа. Час від часу можна насипати трохи бонусів, але небагато.
Вітаю! Ви маєте майже-кофаундера, але на зарплаті та без частки в бізнесі. Лояльного, ефективного, готового покласти свої вихідні за фікс критичної баги. Ну бо юзери крутяться лавеха мутиться, а хто крім нього?
Згодом дати йому людей, щоб тіп вже точно вріс корінням у вашу контору, бо це тепер і його команда. Відправляйте на конференції, щоб розповідав який у вас крутий продукт та як добре працюється. Давайте йому відповідальність винаймати людей, бо він муситиме «продавати» компанію кандидату, таким чином поглиблюючи та укріплюючи віру у вашу справу.
Першого разу мене витримали на такому гачку 7 років. Я мав все своє — свій маленький продукт, відносну свободу його розвивати, команду, місце біля вікна та цискофон. Другий раз минуло 5 років. Там в мене взагалі була абсолютна свобода, фактично я був CTO-архітектором-девелопером, і діло вже йшло до частки в одному з бізнесів, але війна ці плани перекреслила. Інші рази навколо було забагато людей, мені не давали свободи, або я був розфокусований через інші обставини, тому ніякого овнершипу не мав.
Головне — пильнувати момент поки наш простак не зрозуміє що він насправді має неабияку цінність та не почне цим користуватися. Тут вже на ваш розсуд. Але до того часу ви будете мати надзвичайно ефективного та мотивованого працівника.
P.S.: Макс з Джині шукає якраз таку людину. Я не піду, бо там треба фултайм душити пітона за смішні гроші, але ви можете спробувати. Тільки обережно! Овнершип викликає залежність та може зашкодити вашому здоров'ю.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Знаєте найпростіший спосіб добитися того, щоб людина мотивовано педалила на вас денно і нощно? Дати ій овнершип.
Я неодноразово попадався на цей гачок, і ділюся з вами рецептом.
Берете звичайного наївного молодого програміста і даєте йому в розробку продукт. Причому даєте від початку до кінця, щоб всі технічні рішення приймав він. Це дуже важливо!
Запрошуєте на продуктові мітинги, вислуховуєте його думки щодо задач, цокаєте та вдаєте що берете це до уваги.
Даєте йому можливість працювати на будь-яких технологіях в рамках вашого бюджету та термінів.
Платите нормально грошей, не дуже багато, але й не мало.
Слідкуєте, щоб він мав повний контроль над рішенням та не міг звинуватити у своїх невдачах нікого, крім самого себе. Ні «архітектора від клієнта», ні «тупих девів з сусіднього відділу», ні «недолугого РМ», нікого. Вся відповідальність на ньому.
Робите так, щоб він виростив продукт сам та відчував що це його справа. Час від часу можна насипати трохи бонусів, але небагато.
Вітаю! Ви маєте майже-кофаундера, але на зарплаті та без частки в бізнесі. Лояльного, ефективного, готового покласти свої вихідні за фікс критичної баги. Ну бо юзери крутяться лавеха мутиться, а хто крім нього?
Згодом дати йому людей, щоб тіп вже точно вріс корінням у вашу контору, бо це тепер і його команда. Відправляйте на конференції, щоб розповідав який у вас крутий продукт та як добре працюється. Давайте йому відповідальність винаймати людей, бо він муситиме «продавати» компанію кандидату, таким чином поглиблюючи та укріплюючи віру у вашу справу.
Першого разу мене витримали на такому гачку 7 років. Я мав все своє — свій маленький продукт, відносну свободу його розвивати, команду, місце біля вікна та цискофон. Другий раз минуло 5 років. Там в мене взагалі була абсолютна свобода, фактично я був CTO-архітектором-девелопером, і діло вже йшло до частки в одному з бізнесів, але війна ці плани перекреслила. Інші рази навколо було забагато людей, мені не давали свободи, або я був розфокусований через інші обставини, тому ніякого овнершипу не мав.
Головне — пильнувати момент поки наш простак не зрозуміє що він насправді має неабияку цінність та не почне цим користуватися. Тут вже на ваш розсуд. Але до того часу ви будете мати надзвичайно ефективного та мотивованого працівника.
P.S.: Макс з Джині шукає якраз таку людину. Я не піду, бо там треба фултайм душити пітона за смішні гроші, але ви можете спробувати. Тільки обережно! Овнершип викликає залежність та може зашкодити вашому здоров'ю.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Парадокс сумлінного працівника
Чи ви помічали людину, яка якісно робить свою роботу і через це застрягає на одній посаді?
В нас був програміст, який гори міг звернути. Яку б задачу йому не давали — той копав до останнього та все виконував на найвищому рівні.
Звісно, керівництво цим користалося, і його постійно садили гасити пожежі без можливості зростання.
Коли керівник не має прямої стратегічної вигоди від росту такого працівника, то він буде експлуатувати його до останнього.
Поки наш боєць сумлінно виконує свою роботу, менш здібні колеги потроху просуваються у ліди, менеджери, та архітекти, і ось уже вони вирішують що той має робити. Парадоксально, чи не так? Ніхто не хоче втрачати кваліфікованого програміста та натомість отримувати посереднього менеджера. Хай краще копає.
Якщо ж людина своєї цінності не усвідомлює, то виходить зовсім дурня, коли зп такого потужного козака менша ніж новачка який прийшов на простішу посаду та працює гірше.
Часто такому працівнику не вистачає розуміння мета-гри, щоб вирватися з цього кола і він так і марнує свій час на здобутки для інших людей.
---
Я спостерігав за таким хлопцем, який дуже добре вмів готувати. Через те він постійно стояв на кухні, хоча не хотів цим займатися. Але замість того, щоб піднятися на рівень вище, та стати мета-кухарем, який не працює руками, а підбирає собі колектив, планує меню, роздає вказівки та контролює результат, він продовжував брати безпосередню участь у процесі, через що згодом вигорів та покинув нас.
Я декілька разів намагався донести йому цю ідею, але той відкидав будь-які пропозиції, натомість скаржився на життя🤷♂️
---
Розумний керівник який розуміє що можна піти далі аніж мати простого копача, буде намагатися виростити його та масштабувати. Але, як я казав раніше, часто це не збігається з тактичними задачами конкретної людини, тому і працівник і менеджер сидять роками та займаються фігнею.
☝️Практична порада
👉Зверніть увагу, чи не стали ви заручником власної компетентності та сумлінності. Ознаки — складність ваших задач не росте, професійний розвиток зупинився, грошей не досипають, але задач на вас накидують все більше і більше. Подумайте, чи влаштовує це вас, і якщо ні — в який бік хотілося б рухатися: обирати собі задачі самостійно (IC) чи йти на рівень вище та організовувати роботу інших так щоб вони робили роботу замість вас (Engineering Manager).
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Чи ви помічали людину, яка якісно робить свою роботу і через це застрягає на одній посаді?
В нас був програміст, який гори міг звернути. Яку б задачу йому не давали — той копав до останнього та все виконував на найвищому рівні.
Звісно, керівництво цим користалося, і його постійно садили гасити пожежі без можливості зростання.
Коли керівник не має прямої стратегічної вигоди від росту такого працівника, то він буде експлуатувати його до останнього.
Поки наш боєць сумлінно виконує свою роботу, менш здібні колеги потроху просуваються у ліди, менеджери, та архітекти, і ось уже вони вирішують що той має робити. Парадоксально, чи не так? Ніхто не хоче втрачати кваліфікованого програміста та натомість отримувати посереднього менеджера. Хай краще копає.
Якщо ж людина своєї цінності не усвідомлює, то виходить зовсім дурня, коли зп такого потужного козака менша ніж новачка який прийшов на простішу посаду та працює гірше.
Часто такому працівнику не вистачає розуміння мета-гри, щоб вирватися з цього кола і він так і марнує свій час на здобутки для інших людей.
---
Я спостерігав за таким хлопцем, який дуже добре вмів готувати. Через те він постійно стояв на кухні, хоча не хотів цим займатися. Але замість того, щоб піднятися на рівень вище, та стати мета-кухарем, який не працює руками, а підбирає собі колектив, планує меню, роздає вказівки та контролює результат, він продовжував брати безпосередню участь у процесі, через що згодом вигорів та покинув нас.
Я декілька разів намагався донести йому цю ідею, але той відкидав будь-які пропозиції, натомість скаржився на життя🤷♂️
---
Розумний керівник який розуміє що можна піти далі аніж мати простого копача, буде намагатися виростити його та масштабувати. Але, як я казав раніше, часто це не збігається з тактичними задачами конкретної людини, тому і працівник і менеджер сидять роками та займаються фігнею.
☝️Практична порада
👉Зверніть увагу, чи не стали ви заручником власної компетентності та сумлінності. Ознаки — складність ваших задач не росте, професійний розвиток зупинився, грошей не досипають, але задач на вас накидують все більше і більше. Подумайте, чи влаштовує це вас, і якщо ні — в який бік хотілося б рухатися: обирати собі задачі самостійно (IC) чи йти на рівень вище та організовувати роботу інших так щоб вони робили роботу замість вас (Engineering Manager).
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Мітинг без стейкхолдера — гроші на вітер
Організовував нещодавно одну зустріч щодо співпраці. Так вийшло що мій керівник не мав змоги потрапити на неї та відправив свого заступника, якому довіряє.
Я знав що то не дуже хороша ідея, але ніяк не зміг на це повпливати.
Зустріч пройшла чудово, далі ми з заступником прийшли до керівника, розповіли йому що до чого, але той, коли почув деталі, відмовився від співпраці.
Ні я, ні заступник не могли його переконати в необхідності цієї справи. А чому? Тому що він не був на тому мітингу, та не мав можливості поспілкуватися з майбутнім партнером, почути його аргументацію та досвід і поставити свої питання.
Горів я на цьому не один раз. Золоте правило — завжди розмовляти з людиною що приймає рішення або мати на зустрічі таку людину. Інакше то все коту під хвіст, марнування часу, посиденьки без задач.
☝️Практична порада
👉Перед тим як йти на зустріч переконайтеся що там буде присутня людина яка приймає рішення щодо неї (можливо це будете ви самі). Якщо така людина не буде присутня — подумайте чи варто вам бути там присутнім.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Організовував нещодавно одну зустріч щодо співпраці. Так вийшло що мій керівник не мав змоги потрапити на неї та відправив свого заступника, якому довіряє.
Я знав що то не дуже хороша ідея, але ніяк не зміг на це повпливати.
Зустріч пройшла чудово, далі ми з заступником прийшли до керівника, розповіли йому що до чого, але той, коли почув деталі, відмовився від співпраці.
Ні я, ні заступник не могли його переконати в необхідності цієї справи. А чому? Тому що він не був на тому мітингу, та не мав можливості поспілкуватися з майбутнім партнером, почути його аргументацію та досвід і поставити свої питання.
Горів я на цьому не один раз. Золоте правило — завжди розмовляти з людиною що приймає рішення або мати на зустрічі таку людину. Інакше то все коту під хвіст, марнування часу, посиденьки без задач.
☝️Практична порада
👉Перед тим як йти на зустріч переконайтеся що там буде присутня людина яка приймає рішення щодо неї (можливо це будете ви самі). Якщо така людина не буде присутня — подумайте чи варто вам бути там присутнім.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Будьте рішенням, а не проблемою
«Що робити, як це вирішити?» — в армії не можна ставити такі питання.
В будь-який момент часу ви повинні чітко розуміти яку задачу ви виконуєте та змогти пояснити це будь-кому старшому.
Якщо цього не зробите, то вашу долю вирішуватимуть за вас.
Наприклад є потреба розвантажити машину, ви собі йдете повз, і попадаєтесь на очі відповідальному за розвантаження який може вас долучити до цієї важливої місії. Якщо ви не поясните, що маєте важливішу задачу, то будете займатися позаплановою фізичною активністю.
Ідеально мати куточок, який знаходиться вдалині від місць пересування особового складу, де можна спокійно займатися своїми справами й не привертати зайвої уваги.
Те ж проблемами та задачами. Якщо сказати, наприклад, «я не можу зробити те-то і те-то через те що так і так», і не принести готове рішення, то рішення приймуть за вас, і будьте певні що воно буде не на вашу користь, а ви взагалі пошкодуєте що відкрили рота.
Ситуація: особовий склад розслабився і забив на ранкову зарядку. Старший питає в чому справа, хтось, на свою голову відповідає «не встигаємо, бо треба ще займатися прибиранням».
Як гадаєте, чи буде хтось розбиратися як так сталося що за місяць до цього всі все встигали, а зараз перестали?
Рішення просте та straightforward — тепер підйом на пів години раніше, щоб усі все встигали. Таким чином одна людина зрізала чималий шматок сну всім, без жодної на те потреби.
Правильно було б взагалі не підіймати цю тему, а рухати мештами швидше та всередині колективу вирішити коли як і що робити, щоб і поспати і зарядку зробити і прибрати.
В цивільному житті теж все так, просто в армії воно гіпертрофоване, через те що часто не стоїть мета робити щось ефективно, а стоїть мета зайняти особовий склад діяльністю.
☝️Практична порада
👉Зверніть увагу, чи не звертаєтесь ви до своєї менеджерки або ліда з проблемами, а не рішеннями. Коли злапаєте себе на питанні «як мені це зробити?», подумайте, а чи не могли б ви принести керівництву готовий план і наступного разу прийдіть вже з ним.
#армія #робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
«Що робити, як це вирішити?» — в армії не можна ставити такі питання.
В будь-який момент часу ви повинні чітко розуміти яку задачу ви виконуєте та змогти пояснити це будь-кому старшому.
Якщо цього не зробите, то вашу долю вирішуватимуть за вас.
Наприклад є потреба розвантажити машину, ви собі йдете повз, і попадаєтесь на очі відповідальному за розвантаження який може вас долучити до цієї важливої місії. Якщо ви не поясните, що маєте важливішу задачу, то будете займатися позаплановою фізичною активністю.
Ідеально мати куточок, який знаходиться вдалині від місць пересування особового складу, де можна спокійно займатися своїми справами й не привертати зайвої уваги.
Те ж проблемами та задачами. Якщо сказати, наприклад, «я не можу зробити те-то і те-то через те що так і так», і не принести готове рішення, то рішення приймуть за вас, і будьте певні що воно буде не на вашу користь, а ви взагалі пошкодуєте що відкрили рота.
Ситуація: особовий склад розслабився і забив на ранкову зарядку. Старший питає в чому справа, хтось, на свою голову відповідає «не встигаємо, бо треба ще займатися прибиранням».
Як гадаєте, чи буде хтось розбиратися як так сталося що за місяць до цього всі все встигали, а зараз перестали?
Рішення просте та straightforward — тепер підйом на пів години раніше, щоб усі все встигали. Таким чином одна людина зрізала чималий шматок сну всім, без жодної на те потреби.
Правильно було б взагалі не підіймати цю тему, а рухати мештами швидше та всередині колективу вирішити коли як і що робити, щоб і поспати і зарядку зробити і прибрати.
В цивільному житті теж все так, просто в армії воно гіпертрофоване, через те що часто не стоїть мета робити щось ефективно, а стоїть мета зайняти особовий склад діяльністю.
☝️Практична порада
👉Зверніть увагу, чи не звертаєтесь ви до своєї менеджерки або ліда з проблемами, а не рішеннями. Коли злапаєте себе на питанні «як мені це зробити?», подумайте, а чи не могли б ви принести керівництву готовий план і наступного разу прийдіть вже з ним.
#армія #робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Зроблено на 95% — значить не зроблено взагалі
Нещодавно потрапив у ситуацію. Команда мала набір задач, виконувала їх, але одну не вдалось зробити через технічні причини.
Начальник попросив звіт, після чого сказав — «так у вас нічого не вийшло зробити».
🤦♂️
Бомбануло в мене знатно, не допомогло навіть розуміння чому він так вважав.
Я багато разів був в ситуаціях, коли проєкт, зроблений на 95% клієнтом або начальником вважався таким що не зроблений. Тобі здається, «та тут вже все є, тільки задеплоїти лишилося та пару багів виправити», але очевидно, що в бінарній логіці «готово/не готово», це значить «не готово».
А щоб доробити останні 5%, зазвичай потрібно витратити ще стільки ж часу🥲
Тому треба відразу фокусуватися на критеріях «готовності», які виставляє той, хто приймає роботу, і рухатися в тому напрямку.
Чітко розуміти що поки ті критерії не досягнуті — значить фактично проєкт або задача не готові, не зроблені, відзвітувати нема про що.
Не тішитися ілюзіями про «готово на 95%» та не крінжувати або горіти, якщо хтось скаже «так ви нічого не зробили». По фактах так, нічого не зробили, для людини з бізнесу, воно виглядає так — або ми можемо запуститися або не можемо, проміжних варіантів не існує.
Якби я був босом, я б звичайно підбирав більш коректні слова для тієї ж ситуації, та намагався б спрямувати підлеглих у потрібному напрямку: або розділив би роботу на шматки які можна зарелізити окремо, або надав би чіткіші та зрозуміліші критерії успіху.
На жаль, знаходжуся в ситуації, де обирати не приходиться, потрібно вчитися стійко витримувати токсичність та не втрачати бойовий дух за будь-яких обставин.
☝️Практична порада
👉Якщо бачите що ви або команда раз у раз попадаєте в ситуації де вам кажуть «ви ніц не зробили», то потрібно самотужки пропрацювати визначення «завершеності» та узгодити це з особою якій ви звітуєте. Проблема часто знаходиться в непорозуміннях між виконавцями та замовниками. Якщо замовник сам не може сформулювати це визначення — ваша робота допомогти йому це зробити.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Нещодавно потрапив у ситуацію. Команда мала набір задач, виконувала їх, але одну не вдалось зробити через технічні причини.
Начальник попросив звіт, після чого сказав — «так у вас нічого не вийшло зробити».
🤦♂️
Бомбануло в мене знатно, не допомогло навіть розуміння чому він так вважав.
Я багато разів був в ситуаціях, коли проєкт, зроблений на 95% клієнтом або начальником вважався таким що не зроблений. Тобі здається, «та тут вже все є, тільки задеплоїти лишилося та пару багів виправити», але очевидно, що в бінарній логіці «готово/не готово», це значить «не готово».
А щоб доробити останні 5%, зазвичай потрібно витратити ще стільки ж часу🥲
Тому треба відразу фокусуватися на критеріях «готовності», які виставляє той, хто приймає роботу, і рухатися в тому напрямку.
Чітко розуміти що поки ті критерії не досягнуті — значить фактично проєкт або задача не готові, не зроблені, відзвітувати нема про що.
Не тішитися ілюзіями про «готово на 95%» та не крінжувати або горіти, якщо хтось скаже «так ви нічого не зробили». По фактах так, нічого не зробили, для людини з бізнесу, воно виглядає так — або ми можемо запуститися або не можемо, проміжних варіантів не існує.
Якби я був босом, я б звичайно підбирав більш коректні слова для тієї ж ситуації, та намагався б спрямувати підлеглих у потрібному напрямку: або розділив би роботу на шматки які можна зарелізити окремо, або надав би чіткіші та зрозуміліші критерії успіху.
На жаль, знаходжуся в ситуації, де обирати не приходиться, потрібно вчитися стійко витримувати токсичність та не втрачати бойовий дух за будь-яких обставин.
☝️Практична порада
👉Якщо бачите що ви або команда раз у раз попадаєте в ситуації де вам кажуть «ви ніц не зробили», то потрібно самотужки пропрацювати визначення «завершеності» та узгодити це з особою якій ви звітуєте. Проблема часто знаходиться в непорозуміннях між виконавцями та замовниками. Якщо замовник сам не може сформулювати це визначення — ваша робота допомогти йому це зробити.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
X Y problem
Один з методів мотивації людей, якому навчають майбутніх керівників це давати підлеглим відповідальність за рішення щодо виконання задачі.
Одразу наведу приклад.
Ситуація 1: приходить техлід каже — «зроби контролер
Ситуація 2: техлід каже — «нам треба, щоб користувачі мали персоналізовані сторінки на сайті, гадаю що треба робити авторизацію, що скажеш?».
У першому випадку у вас не так багато свободи в рішеннях, вам вже фактично його дали, залишилося тількипередати то в чатгпт та скопіпастити результат закодити. Простору для обговорення дуже мало — ось вам і ендпоїнти, ось вам і контролер. Неясно чи воно взагалі потрібне.
В другому випадку вийдете до чатгпт та просите, щоб той зробив авторизацію самі думаєте що там мають бути за контролери, чи мають вони бути взагалі, як його правильно спроєктувати. Ви маєте трішки бізнес контексту зверху, так, користувачі, сторінки, акаунти, а це точно потрібно? Може відразу OAuth2? А може якось без логіну можна обійтися🤔
В першому випадку ви просто сліпий виконавець який робить що сказали.
В другому ви вже дотичні до відповідальності за рішення та можете думати наперед про наслідки, які воно матиме в майбутньому. Навіть якщо варіантів зробити що просять небагато, або взагалі один, все одно підтримується ілюзія ніби ви щось вирішуєте. Це дозволяє не втрачати мотивацію від фактично усвідомлення свого рабського існування та виторгувати принаймні трішки уявної свободи.
Розумний керівник буде користуватися цією маніпуляцією та застосовувати її навіть там де вибору немає, а шлях очевидний.
Нерозумний керівник буде займатися мікроменеджментом, давати рішення, а не задачі, та не пояснювати логіки того що відбувається.
Прямі вказівки на рішення мене люто тригерять, бо обмежують свободу та розбивають ілюзію незалежного прийняття рішень. Я розумію чому так може відбуватися, але то не допомагає від підгоряння. Я розумний та відповідальний, дайте мені задачу і я її зроблю, а ще краще і задач не давайте, а дайте зону відповідальності, а я собі сам придумаю які задачі потрібно зробити, щоб все було як має бути. Дайте мені овнершип!
«Ріжок, ти йобу дав», скажете ви, «які ілюзії, який овнершип, копай що сказали, бери менше відповідальності за більше грошей, працюй на двох роботах на мінімумі продуктивності, щоб не вигнали, та живи жеття у вільний час!»
І будете по-своєму праві. Хтось так може жити, але не я. Мені треба знаходити сенс в діяльності на яку витрачаю третину життя, інакше здурію. Якщо я не спромігся зробити свій двіж та стати сам собі босом то треба хоч якось пояснювати собі чому працюю на когось.
☝️Практична порада
👉Якщо ви бос — зверніть увагу як роздаєте задачі підлеглим. Чи даєте їм достатньо відповідальності? Ясно що не всі до цього готові, наприклад джунам треба давати готові рішення, але можна спостерігати за прогресом.
👉Якщо ви підлеглий — поміркуйте над задачами які вам дають. Якщо це готові рішення — можливо вам вже варто піднятися на новий щабель та взяти відповідальність? Поставте це питання на наступному 1:1 зі своїм менеджером.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Один з методів мотивації людей, якому навчають майбутніх керівників це давати підлеглим відповідальність за рішення щодо виконання задачі.
Одразу наведу приклад.
Ситуація 1: приходить техлід каже — «зроби контролер
SessionsController з трьома методами: GET /login, POST /login, DELETE /signout».Ситуація 2: техлід каже — «нам треба, щоб користувачі мали персоналізовані сторінки на сайті, гадаю що треба робити авторизацію, що скажеш?».
У першому випадку у вас не так багато свободи в рішеннях, вам вже фактично його дали, залишилося тільки
В другому випадку ви
В першому випадку ви просто сліпий виконавець який робить що сказали.
В другому ви вже дотичні до відповідальності за рішення та можете думати наперед про наслідки, які воно матиме в майбутньому. Навіть якщо варіантів зробити що просять небагато, або взагалі один, все одно підтримується ілюзія ніби ви щось вирішуєте. Це дозволяє не втрачати мотивацію від фактично усвідомлення свого рабського існування та виторгувати принаймні трішки уявної свободи.
Розумний керівник буде користуватися цією маніпуляцією та застосовувати її навіть там де вибору немає, а шлях очевидний.
Нерозумний керівник буде займатися мікроменеджментом, давати рішення, а не задачі, та не пояснювати логіки того що відбувається.
Прямі вказівки на рішення мене люто тригерять, бо обмежують свободу та розбивають ілюзію незалежного прийняття рішень. Я розумію чому так може відбуватися, але то не допомагає від підгоряння. Я розумний та відповідальний, дайте мені задачу і я її зроблю, а ще краще і задач не давайте, а дайте зону відповідальності, а я собі сам придумаю які задачі потрібно зробити, щоб все було як має бути. Дайте мені овнершип!
«Ріжок, ти йобу дав», скажете ви, «які ілюзії, який овнершип, копай що сказали, бери менше відповідальності за більше грошей, працюй на двох роботах на мінімумі продуктивності, щоб не вигнали, та живи жеття у вільний час!»
І будете по-своєму праві. Хтось так може жити, але не я. Мені треба знаходити сенс в діяльності на яку витрачаю третину життя, інакше здурію. Якщо я не спромігся зробити свій двіж та стати сам собі босом то треба хоч якось пояснювати собі чому працюю на когось.
☝️Практична порада
👉Якщо ви бос — зверніть увагу як роздаєте задачі підлеглим. Чи даєте їм достатньо відповідальності? Ясно що не всі до цього готові, наприклад джунам треба давати готові рішення, але можна спостерігати за прогресом.
👉Якщо ви підлеглий — поміркуйте над задачами які вам дають. Якщо це готові рішення — можливо вам вже варто піднятися на новий щабель та взяти відповідальність? Поставте це питання на наступному 1:1 зі своїм менеджером.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Токсичні колеги
У благословенні офісні часи, коли не було великої війни та коронавірусу, люди значно більше спілкувались наживо. Найбільше звичайно під час обіду/чаювання/кавування на кухні та перекуру у курилці. Американський термін water cooler talk дуже влучний для опису цього явища.
На кухні можна було підслухати останні інсайди, розкладки та нахрюки, вклинитися в чужу розмову, або розпочати свою.
Я часто користувався цим і розводив непродуктивні та токсичні теревені про те як у нас на проєктах все погано, яка нездала робота, і як мені то все надоїло.
З часом ці балачки накопичилися достатньо щоб тригернути звільнення. На наступній роботі я був обачнішим, а далі розпочалась пандемія і майданчика для стендапів в мене більше не було.
Між тим, крім мене, токсичні срачі розводили й колеги. Дехто потім переніс це в чати. Ви точно знаєте негативний тип людей які постійно на все скаржаться і яким завжди все не так. Я не був такою людиною, але знаходився недалеко.
З часом я трішки порозумнішав і почав ставити питання: якщо все так погано, то чому ти досі тут? Що ти робиш, щоб перестати скиглити? Зміни боса, проєкт, контору, та що завгодно, але зроби хоч щось, а не просто отруюй себе та оточення.
Один з моїх життєвих принципів це те що слова не мають розходитися з діями, а шкура має бути в грі.
Коли б я мав це за принцип півтора десятка років тому, то не затримувався б на кухні, деморалізуючи моїх молодших колег, а спрямував би цю енергію на те, щоб вибити собі проєкт цікавіше або знайти нову роботу.
Натомість моїм вибором були дегенератські розмови про те як все погано. Час змарновано, висновки не зроблені.
Часи зараз вже не ті, токсики не мають звичної трибуни й можуть поскаржитися на життя хіба що в пабі. Коли я чую такі розмови то намагаюся від них дистанціюватися. Годі й питати людину, що вона зробила, щоб виправити ситуацію. Такі балачки непродуктивні, ні до чого не приводять.
☝️Практична порада
👉Помітив що скаржишся комусь на свою роботу? Змінюй її або перестань себе труїти👊
P.S.: то все також переноситься на інші сфери: сім'ю, державу, світ. Пропоную скаржитися на це своєму психотерапевту, а з друзями проводити час весело та продуктивно.
P.P.S.: впізнали себе? Ставте 💩 в реакцію👇
#робота #лайфстайл
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
У благословенні офісні часи, коли не було великої війни та коронавірусу, люди значно більше спілкувались наживо. Найбільше звичайно під час обіду/чаювання/кавування на кухні та перекуру у курилці. Американський термін water cooler talk дуже влучний для опису цього явища.
На кухні можна було підслухати останні інсайди, розкладки та нахрюки, вклинитися в чужу розмову, або розпочати свою.
Я часто користувався цим і розводив непродуктивні та токсичні теревені про те як у нас на проєктах все погано, яка нездала робота, і як мені то все надоїло.
З часом ці балачки накопичилися достатньо щоб тригернути звільнення. На наступній роботі я був обачнішим, а далі розпочалась пандемія і майданчика для стендапів в мене більше не було.
Між тим, крім мене, токсичні срачі розводили й колеги. Дехто потім переніс це в чати. Ви точно знаєте негативний тип людей які постійно на все скаржаться і яким завжди все не так. Я не був такою людиною, але знаходився недалеко.
З часом я трішки порозумнішав і почав ставити питання: якщо все так погано, то чому ти досі тут? Що ти робиш, щоб перестати скиглити? Зміни боса, проєкт, контору, та що завгодно, але зроби хоч щось, а не просто отруюй себе та оточення.
Один з моїх життєвих принципів це те що слова не мають розходитися з діями, а шкура має бути в грі.
Коли б я мав це за принцип півтора десятка років тому, то не затримувався б на кухні, деморалізуючи моїх молодших колег, а спрямував би цю енергію на те, щоб вибити собі проєкт цікавіше або знайти нову роботу.
Натомість моїм вибором були дегенератські розмови про те як все погано. Час змарновано, висновки не зроблені.
Часи зараз вже не ті, токсики не мають звичної трибуни й можуть поскаржитися на життя хіба що в пабі. Коли я чую такі розмови то намагаюся від них дистанціюватися. Годі й питати людину, що вона зробила, щоб виправити ситуацію. Такі балачки непродуктивні, ні до чого не приводять.
☝️Практична порада
👉Помітив що скаржишся комусь на свою роботу? Змінюй її або перестань себе труїти👊
P.S.: то все також переноситься на інші сфери: сім'ю, державу, світ. Пропоную скаржитися на це своєму психотерапевту, а з друзями проводити час весело та продуктивно.
P.P.S.: впізнали себе? Ставте 💩 в реакцію👇
#робота #лайфстайл
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Коли ненапряжна робота може бути корисною
Читачки та читачі знають що я людина яка декларує гру на перемогу, а не на процес, та постійний розвиток. На ділі мені не завжди вдавалось цього дотримуватися, але я стараюсь.
Одна з речей які мене ніколи не приваблювали це робота на чілових проєктах та умисне уникнення відповідальності (і відповідно зростання).
Таких проєктів, де можна почілити, було досить багато. Зараз не знаю як, але підозрюю що вони нікуди не ділися. Саппорт, легасі, кастомер який не пушить, стабільність, всі діла.
Я й сам було діло нудьгував, але то тривало недовго.
Зараз розумію що для таких проєктів є місце. Тільки місце це диктується не небажанням працювати, а зовнішніми обставинами — найчастіше сімейними, або іншою діяльністю яка займає значну частину вашого життя.
Народження дитини, догляд за близькими, участь у спортивних змаганнях або залученість в якесь хобі що вимагає багато часу, війна — коли робота ненапряжна, ніхто не пушить, а ви здатні видавати достатній результат, щоб залишатися в строю — це чудовий компромісний варіант.
Аби то було тимчасовим і ви повернулись до звичних щурячих перегонів.
☝️Практична порада
👉А не буде поради, зараз не час перебирати проєктами👊 Працюй, донать!
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Читачки та читачі знають що я людина яка декларує гру на перемогу, а не на процес, та постійний розвиток. На ділі мені не завжди вдавалось цього дотримуватися, але я стараюсь.
Одна з речей які мене ніколи не приваблювали це робота на чілових проєктах та умисне уникнення відповідальності (і відповідно зростання).
Таких проєктів, де можна почілити, було досить багато. Зараз не знаю як, але підозрюю що вони нікуди не ділися. Саппорт, легасі, кастомер який не пушить, стабільність, всі діла.
Я й сам було діло нудьгував, але то тривало недовго.
Зараз розумію що для таких проєктів є місце. Тільки місце це диктується не небажанням працювати, а зовнішніми обставинами — найчастіше сімейними, або іншою діяльністю яка займає значну частину вашого життя.
Народження дитини, догляд за близькими, участь у спортивних змаганнях або залученість в якесь хобі що вимагає багато часу, війна — коли робота ненапряжна, ніхто не пушить, а ви здатні видавати достатній результат, щоб залишатися в строю — це чудовий компромісний варіант.
Аби то було тимчасовим і ви повернулись до звичних щурячих перегонів.
☝️Практична порада
👉А не буде поради, зараз не час перебирати проєктами👊 Працюй, донать!
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Обачність на 1:1
Продовжую тему з токсичними колегами, цього разу говоримо про 1:1.
Такі мітинги з безпосереднім керівником вже досить давно стали ±стандартом в індустрії. Зазвичай ні менеджер, ні підлеглий не знають, як правильно використати цей час, і вони перетворюються на формальність, яку до того ж менеджер має звичку переносити й забивати на неї.
Менше з тим, 1:1 це асиметричні мітинги. Ваш бос володіє значно більшим обсягом інформації аніж ви, і потрібно це враховувати. Якщо ви чимось незадоволені, і особливо якщо нагостирили лижі геть з того місця, потрібно розважливо доносити це, аби не нашкодити собі.
Я зараз не говорю про те що потрібно брехати, або іншим чином поводитись непорядно, зовсім ні. Але потрібно розуміти що контора вам не друг, а партнер, і стосунки ці мають зміщений баланс. Коли ви станете баластом — вас тут же викинуть за борт, і краще не давати зайвих сигналів що щось не так, якщо це не в ваших інтересах.
---
Інша річ, це озвучування своїх побажань на таких зустрічах. Добре подумайте над тим, чого ви хочете, щоб не сказати абищо, а потім відмовитися від пропозиції. Наприклад, в мене неодноразово були ситуації, коли робота була нудною, але я не говорив про це, бо знав що не готовий зараз взятися за більш двіжовий проєкт. Мені потрібен був чіл та поступове зниження залученості, а не двіж та максимальний енгейжмент.
Інша проблема яку я мав то балабольство. Було таке що декілька разів я озвучував речі, які не робив, конкретно — казав що напишу пости в корпоративний блог і забивав на те. Ця активність не була обов'язковою і мені ніц не вартувало просто промовчати, але я, хвалько такий, не втримався. Не будьте як я, не будьте балаболом.
Це може пройти непоміченим, і ви не отримаєте ніяких санкцій, але люди запам'ятають що ви не берете відповідальність за свої слова.
Повертаюсь до «шукри в грі» — говорите — робіть. Не готові робити або знаєте що не стягнете — не робіть.
Часто буває так що є можливості розвитку і якщо ви озвучуєте побажання, а потім відмовляєтесь від пропозиції — то так вам перестануть щось пропонувати.
Хочете сеньйорну личку та зп, але не хочете брати менторство над джунами — так і кажіть. Надоїла робота, але не хочете вриватисяв третю штурмову двіж — мовчіть.
Відповідайте за базар, короче.
☝️Практична порада
👉Якщо 1:1 у вас вже перетворився на безглузду церемонію, то фільтруйте що говорите, щоб не зашкодити собі. Якщо не перетворився — запишіть собі план чим би ви хотіли поділитися і пильнуйте, щоб туди не попало нічого, за що ви готові брати та нести відповідальність.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Продовжую тему з токсичними колегами, цього разу говоримо про 1:1.
Такі мітинги з безпосереднім керівником вже досить давно стали ±стандартом в індустрії. Зазвичай ні менеджер, ні підлеглий не знають, як правильно використати цей час, і вони перетворюються на формальність, яку до того ж менеджер має звичку переносити й забивати на неї.
Менше з тим, 1:1 це асиметричні мітинги. Ваш бос володіє значно більшим обсягом інформації аніж ви, і потрібно це враховувати. Якщо ви чимось незадоволені, і особливо якщо нагостирили лижі геть з того місця, потрібно розважливо доносити це, аби не нашкодити собі.
Я зараз не говорю про те що потрібно брехати, або іншим чином поводитись непорядно, зовсім ні. Але потрібно розуміти що контора вам не друг, а партнер, і стосунки ці мають зміщений баланс. Коли ви станете баластом — вас тут же викинуть за борт, і краще не давати зайвих сигналів що щось не так, якщо це не в ваших інтересах.
---
Інша річ, це озвучування своїх побажань на таких зустрічах. Добре подумайте над тим, чого ви хочете, щоб не сказати абищо, а потім відмовитися від пропозиції. Наприклад, в мене неодноразово були ситуації, коли робота була нудною, але я не говорив про це, бо знав що не готовий зараз взятися за більш двіжовий проєкт. Мені потрібен був чіл та поступове зниження залученості, а не двіж та максимальний енгейжмент.
Інша проблема яку я мав то балабольство. Було таке що декілька разів я озвучував речі, які не робив, конкретно — казав що напишу пости в корпоративний блог і забивав на те. Ця активність не була обов'язковою і мені ніц не вартувало просто промовчати, але я, хвалько такий, не втримався. Не будьте як я, не будьте балаболом.
Це може пройти непоміченим, і ви не отримаєте ніяких санкцій, але люди запам'ятають що ви не берете відповідальність за свої слова.
Повертаюсь до «шукри в грі» — говорите — робіть. Не готові робити або знаєте що не стягнете — не робіть.
Часто буває так що є можливості розвитку і якщо ви озвучуєте побажання, а потім відмовляєтесь від пропозиції — то так вам перестануть щось пропонувати.
Хочете сеньйорну личку та зп, але не хочете брати менторство над джунами — так і кажіть. Надоїла робота, але не хочете вриватися
Відповідайте за базар, короче.
☝️Практична порада
👉Якщо 1:1 у вас вже перетворився на безглузду церемонію, то фільтруйте що говорите, щоб не зашкодити собі. Якщо не перетворився — запишіть собі план чим би ви хотіли поділитися і пильнуйте, щоб туди не попало нічого, за що ви готові брати та нести відповідальність.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
It Depends
— „Краще працювати в продукті, ніж в аутсорсі”
— „Ні, це залежить від того який продукт і який аутсорс, буває цікавий аутсорс”
— „Потрібно видавати людям овнершип та контекст, щоб вони самі робили задачі”
— „Залежить від того яка робота, на конвеєрі тобі потрібні прості виконавці які не вимахуються”
— „Робота має мати сенс та приносити задоволення”
— „Залежить від обставин, є ситуації коли просто потрібні гроші”
І так далі.
На кожне твердження знаходиться кмітливий коментатор який поважно скаже „люди різні, контори різні, ситуації різні, все залежить від купи факторів”.
І мати рацію!
Але тоді ріжку й писати нічого буде, а на каналі буде один пост: „все залежить від обставин, дійте на власний розсуд”
Програмістська натура дуже любить все абстрагувати, виносити спільне з різного, узагальнювати.
Але такі рафіновані поради та концепти ні до чого не годяться. Зрозуміло, що все залежить від обставин. Зрозуміло, що є різні люди, різні проєкти. Зрозуміло, що немає срібної кулі та універсальної теорії всього. Зрозуміло що те що підійде мені, не підійде вам, бо кожен — унікальна особистість.
Проте без якогось досвіду власних або чужих рішень у конкретних ситуаціях складно сформувати власну теку.
Для того я і намагаюсь ділитися конкретними ситуаціями з якими я мав справу і сам люблю читати такі історії. Чим конкретніше, тим краще, тим живіше воно все, а над конкретним кейсом з конкретним рішенням вже можна й подискутувати.
Але, як відомо, it depends.
#робота #мета
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
— „Краще працювати в продукті, ніж в аутсорсі”
— „Ні, це залежить від того який продукт і який аутсорс, буває цікавий аутсорс”
— „Потрібно видавати людям овнершип та контекст, щоб вони самі робили задачі”
— „Залежить від того яка робота, на конвеєрі тобі потрібні прості виконавці які не вимахуються”
— „Робота має мати сенс та приносити задоволення”
— „Залежить від обставин, є ситуації коли просто потрібні гроші”
І так далі.
На кожне твердження знаходиться кмітливий коментатор який поважно скаже „люди різні, контори різні, ситуації різні, все залежить від купи факторів”.
І мати рацію!
Але тоді ріжку й писати нічого буде, а на каналі буде один пост: „все залежить від обставин, дійте на власний розсуд”
Програмістська натура дуже любить все абстрагувати, виносити спільне з різного, узагальнювати.
Але такі рафіновані поради та концепти ні до чого не годяться. Зрозуміло, що все залежить від обставин. Зрозуміло, що є різні люди, різні проєкти. Зрозуміло, що немає срібної кулі та універсальної теорії всього. Зрозуміло що те що підійде мені, не підійде вам, бо кожен — унікальна особистість.
Проте без якогось досвіду власних або чужих рішень у конкретних ситуаціях складно сформувати власну теку.
Для того я і намагаюсь ділитися конкретними ситуаціями з якими я мав справу і сам люблю читати такі історії. Чим конкретніше, тим краще, тим живіше воно все, а над конкретним кейсом з конкретним рішенням вже можна й подискутувати.
Але, як відомо, it depends.
#робота #мета
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
frozen_string_literal: 🤡
Знадобилося тут попрограмувати трохи (поганий той штурмовик що забув як програмувати), поки прокрастинував та думав як краще організувати новий проєкт, дай думаю оновлю старий.
Ласкаво просимо до проклятого світу веброзробки!
Зробив
Іду розбиратися, виявляється що в релізі Rails 7.1 команду
А команда не пройшла на CI, тому що там не було css-файлів які брались з node_modules, які я там не інсталив в тестах, бо воно не треба було.
Взагалі мені JS не потрібен, а
Щоб не додавати ноду разом зі всім барахлом в тестовий імедж я вирішую піти шляхом, який треба було обрати з самого початку — завендорити той CSS. Добре що в гітхаб тікеті дворічної давності для бібліотеки
Приємно знаходити відповіді на свої питання, але ще приємніше бачити що ти взяв участь в обговоренні.
Качаю CSS, тестую — все працює. Бандл правда збільшився на скількись кілобайт, причина того мені невідома, десь
Проєкт оновився, ура, все працює. Час переходити до наступного.
Ставлю новий, а тут вже ж Різдво було, а що у нас на Різдво? А на Різдво у нас завжди виходить мінорний реліз Ruby, цього разу це 3.3.0.
Ставлю його, ініціалізую проєкт, туди-сюди, хочу запустити Rails Console, щоб відразу в репл і програміровать, запускаю, пишу там гелоу ворлд, а мені зась! Ніц немає, відповіді нема, репл пустий.
WTF, думаю може мене «чехи» з JetBrains надурили вчергове і я там не прописав якийсь дурнуватий параметр, йду перевіряти та нє, ніби все ок. Пробую інший проєкт — працює. Пробую новий — не працює. Згадую що колись мав таку проблему, але забув як вирішив. Чищу кеші, вмикаю-вимикаю комплюхтор, перестворюю конфігурацію. Не допомагає.
Йду на багтрекер JetBrains і звичайно ж знаходжу там багу, виявляється в Rails Console який запускається з IntelliJ не працює в Ruby 3.3.0, девелопери розбираються.
Ок думаю, з терміналу попрацюю, хоч це і не зручно, там все ок.
Роблю новий і клас — що за чудеса! — першим рядком в згенерованому файлі йде
Я згадав про геніальне
І подумав: шо за фігня, чому машини самі не можуть роздуплитися коли їм треба той рядок реюзати, а коли не треба, щзх, чому у 2024 у мене кожен файл має бути засраний архаїчними конструкціями двадцятирічної давності які ще й користі принесуть близько нуля!
Видалив той коментар гарбедж колектору на зло.
Ви кажете прогрес технологічний, але подивіться, мені досі треба знати про існування гарбедж колектору та якихось магічних коментів які полегшують йому (а не мені!!!) життя!
Короче шляпа повна наше програмування.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Знадобилося тут попрограмувати трохи (поганий той штурмовик що забув як програмувати), поки прокрастинував та думав як краще організувати новий проєкт, дай думаю оновлю старий.
Ласкаво просимо до проклятого світу веброзробки!
Зробив
bundle update, запустив локально, прогнав тести, „на моїй машині працює!”, пушу в репозиторій, build failed. Причому failed на тих самих тестах. WTF, в мене ж все працювало!Іду розбиратися, виявляється що в релізі Rails 7.1 команду
rake assets:precompile, яка збирає фронтедерські діла (css, js, ассети й тд) включили до команди rails test яка запускає тести. Ну типу раз ми вже тести женемо давайте фронтенд зберемо, а то мало що там може бути.А команда не пройшла на CI, тому що там не було css-файлів які брались з node_modules, які я там не інсталив в тестах, бо воно не треба було.
Взагалі мені JS не потрібен, а
node_modules є, щоб мати на диску Daisy UI, який Rails мені люб'язно пакує в проєктний CSS бандл.Щоб не додавати ноду разом зі всім барахлом в тестовий імедж я вирішую піти шляхом, який треба було обрати з самого початку — завендорити той CSS. Добре що в гітхаб тікеті дворічної давності для бібліотеки
tailwindcss-rails вже є рішення для конкретного CSS фреймворку і там є навіть мій комент.Приємно знаходити відповіді на свої питання, але ще приємніше бачити що ти взяв участь в обговоренні.
Качаю CSS, тестую — все працює. Бандл правда збільшився на скількись кілобайт, причина того мені невідома, десь
@import не так написав чи що, вже вирішив не гаяти на те час.Проєкт оновився, ура, все працює. Час переходити до наступного.
Ставлю новий, а тут вже ж Різдво було, а що у нас на Різдво? А на Різдво у нас завжди виходить мінорний реліз Ruby, цього разу це 3.3.0.
Ставлю його, ініціалізую проєкт, туди-сюди, хочу запустити Rails Console, щоб відразу в репл і програміровать, запускаю, пишу там гелоу ворлд, а мені зась! Ніц немає, відповіді нема, репл пустий.
WTF, думаю може мене «чехи» з JetBrains надурили вчергове і я там не прописав якийсь дурнуватий параметр, йду перевіряти та нє, ніби все ок. Пробую інший проєкт — працює. Пробую новий — не працює. Згадую що колись мав таку проблему, але забув як вирішив. Чищу кеші, вмикаю-вимикаю комплюхтор, перестворюю конфігурацію. Не допомагає.
Йду на багтрекер JetBrains і звичайно ж знаходжу там багу, виявляється в Rails Console який запускається з IntelliJ не працює в Ruby 3.3.0, девелопери розбираються.
Ок думаю, з терміналу попрацюю, хоч це і не зручно, там все ок.
Роблю новий і клас — що за чудеса! — першим рядком в згенерованому файлі йде
frozen_string_literal: true. А це ще що таке? Чому раніше не було? Ах, це якась оптимізація, типу щоб не казати кожному рядку що він імутабельний, ми це робимо на рівні всього файлу. Колись Matz (автор Ruby) хотів зробити всі рядки за замовчуванням іммутабельними, але потім передумав. А тепер розробники IntelliJ чомусь вирішили що треба цей комент додавати. Ну типу, а чому б і не викусити пару мікросекунд на виділенні пам'яті та не зекономити пару байт на перевикористаних рядках?Я згадав про геніальне
# -*- coding: utf-8 -*- в другому пітоні.І подумав: шо за фігня, чому машини самі не можуть роздуплитися коли їм треба той рядок реюзати, а коли не треба, щзх, чому у 2024 у мене кожен файл має бути засраний архаїчними конструкціями двадцятирічної давності які ще й користі принесуть близько нуля!
Видалив той коментар гарбедж колектору на зло.
Ви кажете прогрес технологічний, але подивіться, мені досі треба знати про існування гарбедж колектору та якихось магічних коментів які полегшують йому (а не мені!!!) життя!
Короче шляпа повна наше програмування.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Обісрався з кроном
Час розваг! Місяць тому я рефакторив @Donate1024Bot, щоб прибрати node.js та npm з білдчейну.
Через кілька днів помітив що кнопки на інтерфейсі попердолило. З'ясувалося що кудись дівся CSS який відповідав за теми, і замість того щоб зафорсити світлу тему, воно вмикало системну, відповідно частину UI пердолило, бо вона не була заточна під темну. Замість того щоб розібратися, я накопіпастив css-варіаблів світлої теми в дефінішн темної. Ну типу
Класно придумав, правда? Зробив так і забив.
На вихідних трохи мав часу, щоб нарешті замерджити фічу для сайту: список волонтерів, який зробила моя колега Олекса Лелека. Коли вже засів за мердж, давай думаю оновлю бібліотеку DaisyUI. Cкачав новий css, поклав у папку
Далі пішов в адмінку, дивлюся, а там інпути не такі як мають бути. В DaisyUI вони з закругленими бордерами, а у мене — з прямокутними🤔 Знову прошу Олексу подивитися, каже що там чомусь не відпрацьовує потрібний CSS.
Починаю підозрювати, що ідея викинути ноду та збирати все тайлвіндівським бінарником не дуже спрацювала, бо є якісь бока. Деякий час дебажимо, але не знаходимо проблеми. Думаю що проблема таки точно у збірці, тому що DaisyUI підключається як Tailwind плагін, а якщо брати чисто CSS, то воно там може щось пропустити.
Тому наступного дня вирішую що треба вертати все взад. Збирати CSS не бінарником, а через ноду. Насправді я й раніше збирав бінарником, але сам css тягнув через npm. Тому то було не зовсім «вернути взад», швидше, «зробити по-іншому».
Сів,
Ну я такий задоволений ура ура, стилі на місці, все красиво.
Давай тепер то в докер імедж запхати, а ви знаєте, не так просто зібрати докупи Ruby та Node. Короче я ставлю
Зібрав поставив запустив, все працює! Нюанс тільки в тому, що в новому імеджі
Деплою все туди сюди, запрацювало, сайт дзижчить. Дивлюся логи білда — впало. Нумо розбиратися — виявляється невстає підіймається
Перша проблема, в альпіні бінарник називається
Ну звісно, старий імедж в мене запускався з-під рута, а в новому яйцеголові зробили все по-сек'юрному, юзер 1000 і поїхав.
А тисячному юзеру ніхто не давав право запускати крон.
Сідаю з'ясовувати як то зробити правильно, гуглю, пробую всілякі
Крон це знаєте штука яку не так легко продебажити. Логи не пишуться, ні помилки, ні успіху. Не розумію в чому річ. Кронтаб є, самі команди виконуються якщо запускати окремо.
Короче годину я з тим і так і так провозився, ніц не допомогло. Думаю ганьба, 2024, а людина не може крон в контейнері запустити.
У відчаї йду на fly.io думаю може там вже шось придумали. І такі да! Розумні люди плюнули на бінарник 50-и річної давності та зробили drop-in replacement який працює з-під юзера і не вимахується.
Називається Supercronic. В інструкції вже готовий набір для докерфайла, бери й запускай. Зкопіпастив, задеплоїв, вуаля! Все працює. І логи і пише і їсти не просить.
Fin.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Час розваг! Місяць тому я рефакторив @Donate1024Bot, щоб прибрати node.js та npm з білдчейну.
Через кілька днів помітив що кнопки на інтерфейсі попердолило. З'ясувалося що кудись дівся CSS який відповідав за теми, і замість того щоб зафорсити світлу тему, воно вмикало системну, відповідно частину UI пердолило, бо вона не була заточна під темну. Замість того щоб розібратися, я накопіпастив css-варіаблів світлої теми в дефінішн темної. Ну типу
@media (prefers-color-scheme: dark) {
:root {
color-scheme: light;Класно придумав, правда? Зробив так і забив.
На вихідних трохи мав часу, щоб нарешті замерджити фічу для сайту: список волонтерів, який зробила моя колега Олекса Лелека. Коли вже засів за мердж, давай думаю оновлю бібліотеку DaisyUI. Cкачав новий css, поклав у папку
vendor, запустив, подивився, ніби майже нічого не зламалося. Посипалась пара елементів, але Олекса люб'язно підфіксила те що відпало та й по тому.Далі пішов в адмінку, дивлюся, а там інпути не такі як мають бути. В DaisyUI вони з закругленими бордерами, а у мене — з прямокутними🤔 Знову прошу Олексу подивитися, каже що там чомусь не відпрацьовує потрібний CSS.
Починаю підозрювати, що ідея викинути ноду та збирати все тайлвіндівським бінарником не дуже спрацювала, бо є якісь бока. Деякий час дебажимо, але не знаходимо проблеми. Думаю що проблема таки точно у збірці, тому що DaisyUI підключається як Tailwind плагін, а якщо брати чисто CSS, то воно там може щось пропустити.
Тому наступного дня вирішую що треба вертати все взад. Збирати CSS не бінарником, а через ноду. Насправді я й раніше збирав бінарником, але сам css тягнув через npm. Тому то було не зовсім «вернути взад», швидше, «зробити по-іншому».
Сів,
gem install cssbundling-rails, туди сюди, піф паф, yarn install, yarn build:css, там підфіксив, рефрешу — опа! Всі стилі стали як треба, а CSS скоротився в 19 разів. Походу все-таки або я той бінарник не так сконфігурив, або там щось не так.Ну я такий задоволений ура ура, стилі на місці, все красиво.
Давай тепер то в докер імедж запхати, а ви знаєте, не так просто зібрати докупи Ruby та Node. Короче я ставлю
dockerfile-rails, генерую Dockerfile де розумні люди за мене подумали як все так поставити, щоб не за всі гроші світу.Зібрав поставив запустив, все працює! Нюанс тільки в тому, що в новому імеджі
debian замість alpine. Ну, думаю, не проблема.Деплою все туди сюди, запрацювало, сайт дзижчить. Дивлюся логи білда — впало. Нумо розбиратися — виявляється не
crond який я запускаю окремим контейнером та який відповідає за те, щоб розіслати донаторам щоденний збір, звіт, оновити інфу по монобанках і так далі.Перша проблема, в альпіні бінарник називається
crond, а у дебіані cron. Геніально! Друга — відрізняються ключі. Міняю назву бінарника, міняю ключі... cron: can't open or create /var/run/crond.pid: Permission deniedНу звісно, старий імедж в мене запускався з-під рута, а в новому яйцеголові зробили все по-сек'юрному, юзер 1000 і поїхав.
А тисячному юзеру ніхто не давав право запускати крон.
Сідаю з'ясовувати як то зробити правильно, гуглю, пробую всілякі
cron.allow і chmod gu+rw /var/run && chmod gu+s /usr/sbin/cron звісно ця шляпа не працює. Ніби й помилок нема, але й джоби не запускаються.Крон це знаєте штука яку не так легко продебажити. Логи не пишуться, ні помилки, ні успіху. Не розумію в чому річ. Кронтаб є, самі команди виконуються якщо запускати окремо.
Короче годину я з тим і так і так провозився, ніц не допомогло. Думаю ганьба, 2024, а людина не може крон в контейнері запустити.
У відчаї йду на fly.io думаю може там вже шось придумали. І такі да! Розумні люди плюнули на бінарник 50-и річної давності та зробили drop-in replacement який працює з-під юзера і не вимахується.
Називається Supercronic. В інструкції вже готовий набір для докерфайла, бери й запускай. Зкопіпастив, задеплоїв, вуаля! Все працює. І логи і пише і їсти не просить.
Fin.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Інкапсуляція
Проходжу зараз туторіал по Rust, дійшов до розділу про інкапсуляцію.
Там як завжди: публічні поля у структур може змінювати будь-хто тому треба їх зробити приватними, а назовні вистромити гетери/аксесори.
Цю історію я чув ще з далекого 2004 коли починав програмувати на Java. Тоді про це не задумувався, ну дійсно, несолідно щоб ми писали
Більшість бібліотек теж дотримувалися цієї конвенції та очікували що на об'єктах будуть гетери та сетери. Так воно і тягнулося.
Але зараз я уважно ще раз прочитав що мені каже туторіал і подумав — WTF? Чому я повинен загортати значення в якісь додаткові методи, в чому сенс? «Безпека»? Не смішіть, безпека чого? Якщо треба, то все міняється в рантаймі без проблем.
Щодо того що значення зможе міняти будь-хто й будь-коли. Ну поміняє хтось значення так то вже будуть його проблеми, хіба ні? Сам собі злий буратіна, як казали в бородаті часи. Чи повинна бібліотека містити в собі механізми захисту від дурня? Навряд. Бібліотека повинна назовні віддати зрозумілий та невеликий фасад, та й все.
Валідація інпуту? Ну таке, валідується все зазвичай на рівні вище, хоча якщо ви працюєте з бібліотекою що дає API типу
Аргументів за тотальну інкапсуляцію у мене немає. Здається що це вірування яке лишилося з давніх часів, бо хтось так написав у книжці, зараз всі забули чому так треба, а накопичене легасі у бібліотеках не дає позбутися купи бойлерплейту, а на нових проєктах нові програмісти з ChatGPT генерують ще більше сміття ще швидшими темпами.
В чому сенс?
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Проходжу зараз туторіал по Rust, дійшов до розділу про інкапсуляцію.
Там як завжди: публічні поля у структур може змінювати будь-хто тому треба їх зробити приватними, а назовні вистромити гетери/аксесори.
Цю історію я чув ще з далекого 2004 коли починав програмувати на Java. Тоді про це не задумувався, ну дійсно, несолідно щоб ми писали
user.name = "Vova", має бути user.setName("Vova"). ООП ж!Більшість бібліотек теж дотримувалися цієї конвенції та очікували що на об'єктах будуть гетери та сетери. Так воно і тягнулося.
Але зараз я уважно ще раз прочитав що мені каже туторіал і подумав — WTF? Чому я повинен загортати значення в якісь додаткові методи, в чому сенс? «Безпека»? Не смішіть, безпека чого? Якщо треба, то все міняється в рантаймі без проблем.
Щодо того що значення зможе міняти будь-хто й будь-коли. Ну поміняє хтось значення так то вже будуть його проблеми, хіба ні? Сам собі злий буратіна, як казали в бородаті часи. Чи повинна бібліотека містити в собі механізми захисту від дурня? Навряд. Бібліотека повинна назовні віддати зрозумілий та невеликий фасад, та й все.
Валідація інпуту? Ну таке, валідується все зазвичай на рівні вище, хоча якщо ви працюєте з бібліотекою що дає API типу
@NotNull та @Size(max = 64) то ок.Аргументів за тотальну інкапсуляцію у мене немає. Здається що це вірування яке лишилося з давніх часів, бо хтось так написав у книжці, зараз всі забули чому так треба, а накопичене легасі у бібліотеках не дає позбутися купи бойлерплейту, а на нових проєктах нові програмісти з ChatGPT генерують ще більше сміття ще швидшими темпами.
В чому сенс?
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Ruby on Snails: 1 req/sec
Нещодавно один відомий консультант по перформенсу рельс написав твіт, де стверджував що більшість Rails апок тримають 1.5 req/sec на одному ядрі й тому треба мільйони vCPU, пам'яті та серверів, щоб воно хоч якось працювало.
Надзвичайно контроверсійна заява яка породила відповідну реакцію спільноти, де різні люди заявляли що в них все працює як мінімум в 10 разів швидше.
Згодом по треду виявилося, що 1.5 req/sec це те що автор бачить на своїх консалтингових проєктах. Тобто не всі проєкти, а ті, куди його запрошують (очевидно, з перформенс проблемами). І не нормально написані проєкти, а нездало написані. І основна проблема не в повільному Ruby, а в I/O до бази. Короче як в тому анекдоті, «— Чули Рабінович виграв мільйон у лотерею? — Все так, тільки не Рабінович, а Петренко, не мільйон, а тисячу, не в лотерею, а в карти, і не виграв, а програв».
Я звичайно крінжанув з поста, потім крінжанув що люди ганьблять Ruby, потім пішов дивитися скільки ж тримає сайт https://donate1024.org/
Поставив модну зараз програму oha, запустив у 20 потоків на 30 секунд:
~10 req/sec на одному ядрі з ±нормальним p95, бо сервер в мене найдешевший:
Ця сторінка звісно не рендерить нічого такого, але десяток запитів в базу і яка-не яка логіка присутня. Звісно всі запити оптимізовані по максимуму, але все ж.
Маю гіпотезу, що більшість часу що витрачається, це не Ruby, а I/O в базу. Тобто якби сюди запулити джаву, то результат був би не набагато кращим, бо код аплікейшена це десятки мілісекунд, стислися б вони у два рази, в загальній частці це не дало б суттєвого прискорення. Щоб перевірити, може знайду час написати два ідентичних сервери на Ruby та Java і порівняти.
І це я просто написав нормальний код. Простору для оптимізацій ще багато: додати кешування, оптимізувати рендерінг HTML (замінити стандартний шаблонізатор ERB на Phlex). Якщо запаритися, то гадаю, що вдалося б покращити результат вдвічі.
Я ж зупинився на тому, що в мене сторінка віддається за 300 мс.
Тому сміливо пишемо на тому, що подобається, оптимізуємо дані та SQL запити, а всім хейтерам які заявляють про тормознутість вашого рантайму у порівнянні з джавою/растом/го сміливоплюємо в обличчя ставимо реакцію клоуна.
P.S.: я звичайно не метр перформенсу, але ще 4 роки тому писав про те що корені всіх проблем веб апок — це запити в базу даних.
P.P.S.: особливо прискіпливі можуть сходити на TechEmpower Web Framework Benchmarks та подивитися, що Spring не набагато швидший ніж Rails, Laravel та Django повільніші, а виграють не фреймворки, а голі бібліотеки вебсерверів.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Нещодавно один відомий консультант по перформенсу рельс написав твіт, де стверджував що більшість Rails апок тримають 1.5 req/sec на одному ядрі й тому треба мільйони vCPU, пам'яті та серверів, щоб воно хоч якось працювало.
Надзвичайно контроверсійна заява яка породила відповідну реакцію спільноти, де різні люди заявляли що в них все працює як мінімум в 10 разів швидше.
Згодом по треду виявилося, що 1.5 req/sec це те що автор бачить на своїх консалтингових проєктах. Тобто не всі проєкти, а ті, куди його запрошують (очевидно, з перформенс проблемами). І не нормально написані проєкти, а нездало написані. І основна проблема не в повільному Ruby, а в I/O до бази. Короче як в тому анекдоті, «— Чули Рабінович виграв мільйон у лотерею? — Все так, тільки не Рабінович, а Петренко, не мільйон, а тисячу, не в лотерею, а в карти, і не виграв, а програв».
Я звичайно крінжанув з поста, потім крінжанув що люди ганьблять Ruby, потім пішов дивитися скільки ж тримає сайт https://donate1024.org/
Поставив модну зараз програму oha, запустив у 20 потоків на 30 секунд:
oha -c 20 -z 30s -m GET --latency-correction --disable-keepalive --redirect 0 https://donate1024.org/ і отримав наступний результат:Summary:
Success rate: 100.00%
Total: 30.0017 secs
Slowest: 18.8368 secs
Fastest: 0.2681 secs
Average: 1.1295 secs
Requests/sec: 9.7328
Total data: 2.68 MiB
Size/request: 10.11 KiB
Size/sec: 91.64 KiB
Response time distribution:
10.00% in 0.4612 secs
25.00% in 0.5410 secs
50.00% in 0.6348 secs
75.00% in 1.0161 secs
90.00% in 1.9351 secs
95.00% in 2.4722 secs
99.00% in 16.0569 secs
99.90% in 18.8368 secs
99.99% in 18.8368 secs
~10 req/sec на одному ядрі з ±нормальним p95, бо сервер в мене найдешевший:
shared-cpu-1x@512MBЦя сторінка звісно не рендерить нічого такого, але десяток запитів в базу і яка-не яка логіка присутня. Звісно всі запити оптимізовані по максимуму, але все ж.
Маю гіпотезу, що більшість часу що витрачається, це не Ruby, а I/O в базу. Тобто якби сюди запулити джаву, то результат був би не набагато кращим, бо код аплікейшена це десятки мілісекунд, стислися б вони у два рази, в загальній частці це не дало б суттєвого прискорення. Щоб перевірити, може знайду час написати два ідентичних сервери на Ruby та Java і порівняти.
І це я просто написав нормальний код. Простору для оптимізацій ще багато: додати кешування, оптимізувати рендерінг HTML (замінити стандартний шаблонізатор ERB на Phlex). Якщо запаритися, то гадаю, що вдалося б покращити результат вдвічі.
Я ж зупинився на тому, що в мене сторінка віддається за 300 мс.
Тому сміливо пишемо на тому, що подобається, оптимізуємо дані та SQL запити, а всім хейтерам які заявляють про тормознутість вашого рантайму у порівнянні з джавою/растом/го сміливо
P.S.: я звичайно не метр перформенсу, але ще 4 роки тому писав про те що корені всіх проблем веб апок — це запити в базу даних.
P.P.S.: особливо прискіпливі можуть сходити на TechEmpower Web Framework Benchmarks та подивитися, що Spring не набагато швидший ніж Rails, Laravel та Django повільніші, а виграють не фреймворки, а голі бібліотеки вебсерверів.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
100% coverage тести, які нічого не тестують
В далекому 2010 році, коли долар був по 8, я працював на ентерпрайзному проєкті разом з консультантами з компанії Thoughtworks. Тієї, звідки Мартін Фаулер, тієї, що публікує Technology Radar, за яким, ви, ймовірно стежите.
На нашому проєкті не було тестів, тому що в компанії на той час не було культури тестування. Власне, мінусів у такому підході я не бачу, але то вже інша історія.
Консультанти звісно відразу ж прийнялись виправдовувати свій рейт у 3000$ за день роботи та заявили що для успіху проєкту неодмінно потрібно мати високе покриття тестами.
Наш код у 90% випадків виглядав приблизно так:
Типова імперативно-процідурна ентерпрайзна локшина, де всі та все ходять у бази та зовнішні інтеграції.
Звісно, з коробки такий код не є тестабельним, через статичні методи. Тому спочатку консультанти винесли сервіслукап в окремі методи, а згодом ми зробили там вже нормальний DI.
Але, оскільки більшість коду ходила кудись назовні, то потрібно було писати моки та стаби (різницю питають у вас на співбесідах), а самі тести зводилися до того що ми перевіряли що мок викликається з необхідним параметром, та виглядали десь отак:
Таких тестів ми писали сотні. Цілі спринти були присвячені ретельному моканню. Каверадж відразу полетів у небеса.
Але, як ми можете здогадатися, ці тести нічого не тестували, а просто викривленим чином дублювали вже написану програму, та радикально ускладнювали рефакторинг.
Згодом, я зустрічав такі «тести» в інших компаніях на інших проєктах.
Формально каверадж є, а по факту ні.
Писали такі тести? Згодні з тим що вони марні чи вважаєте що все правильно нам консультанти сказали? Діліться у коментах👇
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
В далекому 2010 році, коли долар був по 8, я працював на ентерпрайзному проєкті разом з консультантами з компанії Thoughtworks. Тієї, звідки Мартін Фаулер, тієї, що публікує Technology Radar, за яким, ви, ймовірно стежите.
На нашому проєкті не було тестів, тому що в компанії на той час не було культури тестування. Власне, мінусів у такому підході я не бачу, але то вже інша історія.
Консультанти звісно відразу ж прийнялись виправдовувати свій рейт у 3000$ за день роботи та заявили що для успіху проєкту неодмінно потрібно мати високе покриття тестами.
Наш код у 90% випадків виглядав приблизно так:
class Action {
public void doThing(Context context) {
ResultOne resultOne = ServiceOne.getInstance().doThing(context);
ResultTwo resultTwo = ServiceTwo.getInstance().doThing(context, resultOne);
context.setResult(resultTwo);
}
}Типова імперативно-процідурна ентерпрайзна локшина, де всі та все ходять у бази та зовнішні інтеграції.
Звісно, з коробки такий код не є тестабельним, через статичні методи. Тому спочатку консультанти винесли сервіслукап в окремі методи, а згодом ми зробили там вже нормальний DI.
Але, оскільки більшість коду ходила кудись назовні, то потрібно було писати моки та стаби (різницю питають у вас на співбесідах), а самі тести зводилися до того що ми перевіряли що мок викликається з необхідним параметром, та виглядали десь отак:
class ActionTest {
@Test
public void testDoThing() {
ServiceOne mockServiceOne = mock(ServiceOne.class);
ServiceTwo mockServiceTwo = mock(ServiceTwo.class);
Action action = new Action(mockServiceOne, mockServiceTwo);
Context context = mock(Context.class);
ResultOne mockResultOne = mock(ResultOne.class);
ResultTwo mockResultTwo = mock(ResultTwo.class);
when(mockServiceOne).doThing(eq(context)).thenReturn(mockResultOne);
when(mockServiceTwo).doThing(eq(context), eq(mockResultOne)).thenReturn(mockResultTwo);
action.doThing(context);
verify(mockServiceOne).doThing(context);
verify(mockResultTwo).doThing(context, mockResultTwo);
verify(context).setResult(mockResultTwo);
}
}Таких тестів ми писали сотні. Цілі спринти були присвячені ретельному моканню. Каверадж відразу полетів у небеса.
Але, як ми можете здогадатися, ці тести нічого не тестували, а просто викривленим чином дублювали вже написану програму, та радикально ускладнювали рефакторинг.
Згодом, я зустрічав такі «тести» в інших компаніях на інших проєктах.
Формально каверадж є, а по факту ні.
Писали такі тести? Згодні з тим що вони марні чи вважаєте що все правильно нам консультанти сказали? Діліться у коментах👇
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Local-first dev environments
Найбільше мене харить коли код проєкту неможливо запустити локально.
Коли є мільйон залежностей, кафки-хуяфки, редіси-хуєдіси, бридка трійця S3/SQS/SNS, мерзенний OAuth 2.0 та інша шляпа яка не запускається або складно запускається на вашому комп'ютері.
Коли для підйому адмінки проєкту над яким ти працюєщ тобі пропонують докер композ на більше рядків ніж сорци кожного мікросервісу, з яких він складається.
Коли їхав мікросервіс через стаб і моком поганяв, а половина тестових даних складені в YAML файли які останній раз оновлювалися за першого коміта у той мікросервіс.
Коли на старті проєкту лід видає тобі вагон кредів та інструкцій де отримати ще вагон кредів щоб потім захардкодити їх в дотенв-файлі.
Коли тобі пропонується піднімати на ноуті, прости Г-ди, кубернетіс🤮
∈)☼(∋. Очко.
Найцікавіше, що для спрощення розробки міленіали придумали мейнфрейми з тонкими клієнтами — ваш код запуститься на потужному кластері десь в клауді, а ви зі свого IDE будете давати команди. Дуже круто, дякую. Один з найабсурдніших стартапів минулих років це Mightyapp — «Mighty makes Google Chrome faster & use 10x less memory. Mighty speeds up Chrome on your laptop by streaming it from a more powerful computer in the cloud—that makes your browser & other apps run significantly faster.» Просто вдумайтесь, браузер(!) в клауді(!!!)! Ідея звісно не полетіла і фаундер запівотився (хоча це не назвеш півотом) в AI-генерацію логотипів та дизайнів.
Зважаючи на те, що лептопи та десктопи розробників зараз набагато потужніші ніж ті крихти vCPU які нам відсипає гіпервізор за вказівкою Безоса, склалась просто ганебна ситуація. І ми самі себе в неї загнали.
E2E тести які проганяються по ночам тому що «тест suite займає 2 години» забивають ще один цвях у труну продуктивності. Як щодо того, що запустити їх локально? Ой, не можна? А як мені тоді продебажити тест що падає?
Проєкт має збиратися та запускатися локально без усіх цих хоботів. Цикл read-evaluate-print має бути настільки коротким, наскільки це можливо.
Зовнішні залежності мають бути мінімізовані. Звісно за роки роботи працьовиті міленіали навигадували різних стабів для хмарних сервісів типу DynamoDB Local. Але менше ж з ним — відсутня залежність ліпша за стаб.
Хотів би вам дати пораду сьогодні подивитися на свій стек та викинути щось, але я знаю що ви з більшим задоволенням додасте ще один мікросервіс та ще одну клаудну шляпу від амазону. Тому насолоджуйтесь роздуванням complexity. Ми,інженери кодери, це любимо.
Без порад.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Найбільше мене харить коли код проєкту неможливо запустити локально.
Коли є мільйон залежностей, кафки-хуяфки, редіси-хуєдіси, бридка трійця S3/SQS/SNS, мерзенний OAuth 2.0 та інша шляпа яка не запускається або складно запускається на вашому комп'ютері.
Коли для підйому адмінки проєкту над яким ти працюєщ тобі пропонують докер композ на більше рядків ніж сорци кожного мікросервісу, з яких він складається.
Коли їхав мікросервіс через стаб і моком поганяв, а половина тестових даних складені в YAML файли які останній раз оновлювалися за першого коміта у той мікросервіс.
Коли на старті проєкту лід видає тобі вагон кредів та інструкцій де отримати ще вагон кредів щоб потім захардкодити їх в дотенв-файлі.
Коли тобі пропонується піднімати на ноуті, прости Г-ди, кубернетіс🤮
∈)☼(∋. Очко.
Найцікавіше, що для спрощення розробки міленіали придумали мейнфрейми з тонкими клієнтами — ваш код запуститься на потужному кластері десь в клауді, а ви зі свого IDE будете давати команди. Дуже круто, дякую. Один з найабсурдніших стартапів минулих років це Mightyapp — «Mighty makes Google Chrome faster & use 10x less memory. Mighty speeds up Chrome on your laptop by streaming it from a more powerful computer in the cloud—that makes your browser & other apps run significantly faster.» Просто вдумайтесь, браузер(!) в клауді(!!!)! Ідея звісно не полетіла і фаундер запівотився (хоча це не назвеш півотом) в AI-генерацію логотипів та дизайнів.
Зважаючи на те, що лептопи та десктопи розробників зараз набагато потужніші ніж ті крихти vCPU які нам відсипає гіпервізор за вказівкою Безоса, склалась просто ганебна ситуація. І ми самі себе в неї загнали.
E2E тести які проганяються по ночам тому що «тест suite займає 2 години» забивають ще один цвях у труну продуктивності. Як щодо того, що запустити їх локально? Ой, не можна? А як мені тоді продебажити тест що падає?
Проєкт має збиратися та запускатися локально без усіх цих хоботів. Цикл read-evaluate-print має бути настільки коротким, наскільки це можливо.
Зовнішні залежності мають бути мінімізовані. Звісно за роки роботи працьовиті міленіали навигадували різних стабів для хмарних сервісів типу DynamoDB Local. Але менше ж з ним — відсутня залежність ліпша за стаб.
Хотів би вам дати пораду сьогодні подивитися на свій стек та викинути щось, але я знаю що ви з більшим задоволенням додасте ще один мікросервіс та ще одну клаудну шляпу від амазону. Тому насолоджуйтесь роздуванням complexity. Ми,
Без порад.
#робота
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot