Cіпласпластик
описание
🇺🇦 Про айті та дотичні теми загалом, ну й трохи про C++. Усі думки тут відображають виключно мій особистий погляд. Мої емоджі: https://t.me/addemoji/AdaptiveDevIcons https://t.me/addemoji/VehicleBrands
720
подписчиков
Охват к подписчикам
132,1%
ERR
Реакции к просмотрам
2,59%
625 на 32 постов
Пересылки к просмотрам
0,75%
181
Постов в день
0,3
всего 33
Где отзываются чаще
доля реакций к просмотрам- 29 июн.Пан К. у своєму каналі «Мамкін Архітектор» написав днями про довіру в команді, зокрема довіру керівника до виконавця. Історія там така, що гіпотетичний(?) чувак заестимейтив та зробив задачу, але в керівника лишився осад. «Телефон чорно-бєлий, а довжен буть цвітний. Шо мені робить?» Ну й висновок автора, що варто будувати «zero trust», де кожен завжди під ковпаком (причому так, щоб ніхто цьому не дивувався й не ображався), хоча конкретних методів не дає. Я з певними твердженнями погоджуюся, але загалом маю альтернативний погляд на все це, про який і напишу. Значить ситуація: […] розробник ставить оцінку на тиждень, зникає на чотири дні, і повертається з пул-ріквестом, де коду на три години з перекурами. […] Лишається відчуття, що тебе трошки намахали… У мене тут картинка якось не склалася. Якщо манагер оцінив, що «коду на три години», то він, певно, тямить. Тоді як він прийняв початкову оцінку в тиждень? А якщо не тямить, то чому зараз береться оцінювати самотужки? 🧐 (До речі, статистично доведено, що люди значно більше поважають керівників, якщо думають, що ті здатні виконувати їхню роботу.) Як хтось написав у коментарях — скрам уже всі ці проблеми розвʼязав, і в чомусь це правда. Інша розмова, що скрам у всіх різний, і мало хто бачив його в канонічній формі, та ще й щоб працював. Принаймні стосовно оцінювання я виніс з однієї з контор чудову пораду. Оцінювати задачу мусить не той, хто її імовірно робитиме, а вся команда. Якщо команда не пристріляна, то естимейти зазвичай мають нормальний розподіл. Тоді ті, хто дали найнижчу та найвищу оцінки, мають пояснити чому. Це корисно з усіх боків: по-перше, шариться досвід, по-друге, випливають раптові нюанси, про які подумав лише хтось один, по-третє, члени команди вчаться працювати один з одним. Ідемо далі. «Розробник зникає на тиждень» — це очевидна дурня. Ті ж дейліки винайшли саме для того, щоб такого не було. Взагалі даю пораду програмістам: менеджери завжди мають значно більше задач, ніж фізично можна виконувати. І єдине, про що вони мріють з боку команди — щоб усе йшло за планом. А значить ви як виконавці маєте два обовʼязки: робити все можливе, щоб виконувався план, і повідомляти одразу, щойно він перестав. Тоді керівник має більше простору для маневрів з вищими менеджерами або замовником, а отже відносно задоволений. Додаткова порада, як уникати зайвих питань «чим займався?»: робіть більше комітів! 💡 Почали робити задачу — одразу створили гілку, запушили на ремоут і створили чернетку PR; далі щовечора докидаєте туди те, що встигли зробити. Перший раз манагер спитає, а на другий — піде й сам гляне. Всі задоволені. Ну й нарешті дійшли до теми про zero trust. Якщо ваша команда — це циферки на дашборді, то може воно й норм, але загалом вважаю такий підхід украй шкідливим. Навіть девіз щойно вигадав: zero trust — zero thrust 😮💨 Все йде з культури. В якийсь момент (мабуть, після книжок No Rules Rules та «Принципів») мене осяяло, що якщо ставитися до кожного як до спеціаліста своєї справи, котрими вони і є, (а не як до баранів, котрих треба за мотузку тягати), то вони раптом починають працювати збс, беруть на себе більше відповідальності тощо. В українському айті, на жаль, найчастіше зустрічаються два типи «менеджерів»: учора-програміст, на якого навалили купу задач з керування командою за додаткові пів гривні на рік, або той, хто дорвався до влади й починає всіх дойобувати. Школа менеджменту фактично відсутня. Мені ж більше імпонує тема про servant leader й оце все. Щоб це працювало, керівники мусять давати більше інформації. (Згадайте, як ваш менеджер відміряє вам крихти інфи, наче в аптеці). Коли в людей є достатньо даних, щоб сформувати ширшу картину того, що є й чого треба досягти, вони починають знаходити значно ефективніші рішення. Окрім інформації треба давати ще відповідальність+авторитет. Перше треба для того, щоб працівник був умотивований досягати результатів (і отримував за це дофамін), а друге, щоб у нього були потрібні засоби. Очевидно, що на «нульовій довірі» це все не працюватиме. Навіть навпаки: треба дуже багато довіри. А от куди zero trust добре пасує — так це до себе. Щоразу, як вам здається, що ви знаєте щось краще, спитайте себе, а чи дійсно ви довіряєте своєму судженню і чи не сліпа це довіра. Тепер якщо ще раз перечитати оригінальний допис, на який я посилався на початку, то можна побачити дуже багато спільних рис і висновків з декількома важливими відмінностями. Та в одному, я думаю, ми б точно дійшли згоди: треба вибудовувати здорові взаємини в команді. Це важко й довго, але воно точно окупиться. А бракованих цеглин краще позбуватися 🙂5,76%
- 2 авг. 2024 г.без подписи5,61%
- 12 авг.без подписи5,53%
- 13 авг.без подписи5,43%
- 9 авг.без подписи4,33%
- 21 мая 2024 г.без подписи3,58%
- 8 июл.Дізнався пару днів тому з якоїсь статті, яку вже загубив, про фічу в Git 💻, котрої мені бракувало. Річ у тім, що в моїх робочих копіях git-сховищ часто купа якогось сміття: прототипчики, скрипти, тимчасові файли або ж файли, які не треба комітити — одним словом те, чим користуюся я сам і що варто ігнорувати. Так, існує .gitignore, але засмічувати його своїми масками файлів чи тек не завжди добре: по-перше, часто воно дійсно треба лише мені, по-друге, файл розростатиметься, по-третє, бувають випадки, коли сама наявність певного імені файлу в списку небажана. Виявилося, що .gitignore — не єдине місце, куди можна щось таке вписувати. Є ще .git/info/exclude, який працює так само, але сам він під контролем версій не знаходиться, тож при стягуванні репи іншими членами команди у них цього всього не буде. (Хуки теж десь усередині .git лежать і страждають від цієї ж проблеми, чим мене бісять. Але тут навпаки зручно). Також є глобальний список ігнорування, який лежить в ~/.config/git/ignore. Я на macOS, тож у мене там приблизно таке: .DS_Store **/.claude/settings.local.json Якщо ви на вінді, то впишіть туди thumbs.db 😆 Ну й наостанок можна ще розповісти про команду для перевірки, чи щось ігнорується ґітом: git check-ignore <path> (Хто б сумнівався, що вона існує. У моїй версії git зараз у районі 160 підкоманд 🤯 Unix way, ага). Краще запускайте з --verbose, і воно тоді покаже, звідки саме прийшов ігнор: > git check-ignore .DS_Store --verbose /Users/cpplastic/.config/git/ignore:1:.DS_Store .DS_Store3,42%
- 17 авг. 2024 г.без подписи3,41%
- 5 июн.Я доволі лояльно ставлюся до багатьох мов програмування. Багатьма з них користуюся, інші просто пробував і здебільшого всі поважаю. Але одне лишається незмінним: Я ненавиджу Bash 💻 усім своїм єством! Я ненавиджу його читати й ніколи не пишу. Того тижня попросив 🅿️ зробити собі тул для Nushell 🆕, і щойно він закінчив, я тут же заборонив йому використовувати вбудований Bash. Авжеж це не дуже допомогло 🙁 Усі моделі так надрочені на той клятий баш, що їм до сраки якийсь Nushell. Я прямо в системний промпт прописав, що це НЕ баш, що це навіть не POSIX-оболонка, написав відмінності, написав аналоги для типових шел-патернів — по барабану. Воно продовжує мене дрочити своїми 2>&1 і 2>/dev/null, комбінує команди через && та пише декілька ls у рядок, щоб подивитися вміст кількох директорій за один виклик. Nushell на це, звісно, скаржиться, або ж це просто дає не ті результати, і модель починає переписувати команди по пʼять разів, доки не вгадає синтаксис. Буквально «вгадає» — інакше це назвати не можна. Ось де чудово видно, що це аж ніяк не інтелект. Ну добре, біс із тим Pi. Запущу-но старий-добрий Claude Code 💻, подумав я. Не чіпав його місяць узагалі, може півтора. Здавалося б… місяць… це ж ніщо. У мене деякі пет-проєкти по 2 роки лежать, а я потім їх відкриваю й продовжую, наче останній коміт зробив учора. Такий собі анабіоз. Але не в цьому випадку! Відкрив claude, він наче на вигляд такий самий, але поводить себе інакше. Самі моделі реагують інакше, ярмо відчувається інакше! Тули Grep та Glob зникли, і ця хуйня тепер все ганяє через Bash. Я розумію, що вони зробили свій супер-пупер автоматичний «інтелектуальний» режим, де інша(?) модель оцінює, наскільки безпечно виконувати команди, і тепер це такий типу дефолт. Але я дід — мені таке не треба. Я люблю сам оцінити, що треба, а що не треба викликати. От тільки не коли воно мені висирає по 15 рядків на баші замість запустити два ґлоба та три ґрепа! Так, я міг би не вимахуватися, а бути читати баш, як усі. Але ви ж розумієте, що річ не в ньому? Річ у виборі. Не стоїть вибір між «використовувати ШІ з Bash» та «використовувати ШІ з Nushell» — є вибір «використовувати ШІ з Bash» або «не використовувати ШІ», бо воно просто не працює інакше. А скільки разів ви вибирали саме TypeScript 🕸 чи Python 💻 для своїх чергових пет-проєктів, бо на них ШІ знається краще? Закладаюся, що були ліпші альтернативи за кількома параметрами, окрім хіба що швидкості розробки. І навіть тулзи вам не належать. Вони встановлені у вас локально на компі, ви не чіпаєте їх місяць, а потім гоп — а там усе інакше. Ваші звички, які ви формували, більше не актуальні; налаштування не працюють — читайте мануал знову, витрачайте свій час, бо хтось вирішив, що вашому ярму (гг) час оновитися. Єдине рішення, яке лишається вам: робити щось із використанням ШІ чи без. «Але ж, Сіпласпластик, — вигукнете ви, — якби не ШІ, то багато моїх ідей взагалі не матеріалізувалися б!» — і матимете в чомусь рацію. Хоча я все частіше розмірковую: а може воно було й на краще? Так чи інакше, щодо себе звернув днями увагу, що з появою ШІ я значно більше почав програмувати саме руками, ніж до того (бо раніше просто нічого не робив 😌). Цікавий ефект.3,19%
- 29 окт.без подписи3,09%
- 28 июл.без подписи3,01%
- 4 авг. 2025 г.без подписи2,97%