АЕС будують 10-20+ років і кожен проєкт унікальний, отриманий досвід майже ніяк не переноситься на наступні проєкти. Сонячні електростанція це модульний дизайн а-ля LEGO, де майже нуль ризиків і кожен елемент перевірений і відмасштабований.

Це ще називають learning curve або experience curve.

Чим довше ти щось робиш тим краще (і дешевше!) це виходить.

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

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

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

Замість висновку: щоб навчитися робити щось класно треба багато ітерацій.

P.S.: приклад з історії Ford Model T:
≈15% падіння ціни на кожне подвоєння виробництва

В моєму персональному досвіду трекінг калорій це too much work, а де у мене реально проблема так це кількість солодощів, які я споживаю. Особливо коли втомлений, поганий настрій, новини і тд.

chatGPT прикольно рахує, але це морока, тому зробив собі власний трекер з Claude. :)

Спробувати можна тут:
​https://maxua.com/sugar​

Скріншот для історії:

PS: мені було цікаво глянути промпт, який Claude написав. Ось він:

const prompt = `User describes what they ate. Estimate sugar content in grams, split into natural sugars (fruit, milk, etc.) and added sugars (table sugar, syrups, honey, etc.).

Input: "${input}"

Reply ONLY with valid JSON, no markdown:

{"name": "<short name in Ukrainian, max 30 chars>", "natural": <integer>, "added": <integer>, "note": "<very brief explanation in Ukrainian, max 60 chars>"}

If the input includes a weight/amount, use it for calculation. If not, assume a typical single serving. Round to nearest integer. If you can't estimate, return {"name": "${input}", "natural": 0, "added": 0, "note": "не вдалося оцінити"}`;

ДОУ здається знайшов новий shove-selling business і це івенти, а не вакансії -- у березні маємо all-time high revenue, навіть враховуючи зростання курса долара в порівнянні з 2021.

Молодці.

Джин поки в пошуку.

Зараз у мене інша проблема :) забагато часу в новинах.

Я знайшов навіть ​News Addicts Anonymous​, але це шось занадто складне. Support group, daily meetings, twelve steps program. :)

Claude зробив мені простенький трекер, який рахує дні без новин і social media.

​https://maxua.com/zero​

Воно ніяк не перевіряє чи ти заходив в новини чи відкривав інстаграм, це суто інструмент для само-контролю. Дані зберігає в localStorage, реєстрація не потрібна. Якщо зробити аппку можна буде додати ще daily check-in, але як для v1 думаю норм.

Спробуйте і напишіть що ви думаєте.

Навіть похайкав трохи, дякую Маріє і Микола за нотатки.

Кайф!

Шкода що лише на тиждень. :))

р. Прут

Вид на гору Синяк з Хомʼяка

Рендомна стежка в лісі

Підйом на оз. Несамовите

Чорногірський хребет, вид в сторону Данциж - Кукул

Я опублікував майже ​692 статей і 4587 коментарів​ на ДОУ і продовжую вести цю розсилку. Чи це робить мене письменником?

"English is the most popular programming language" каже Карпатий .. чи означає це, що ​десятки мільйонів програмістів​ тепер теж письменники?

...

Питання власне зрозуміти хто я і чого я хочу.

Занадто часто ми намагаємося "придумати" собі aspirational title. Ким ми думаємо ми хочемо бути. Або думаємо щоб інші хочуть, щоб ми були цим. А можна подивитися на те, що ти реально робиш коли тебе ніхто не змушує. Це і є ти. Always has been.

Я памʼятаю свою розмову з Владом з OWOX після запису з ним (жахливого) ​епізоду​ Профіт ШОУ. Він запитав мене Макс, для чого ти це робиш і я зрозумів що у мене немає хорошої відповіді.

Мені хотілося мати більший імпакт, ніж ще одне шоу на ютуб, яке ніхто не дивиться. І напевно для цього потрібен продукт, а не медіа. Щоб був leverage -- один раз написав код, який виконується знову і знов. Останній епізод Профіт ШОУ ми записали у січні 2013, а менше ніж через рік зʼявився Джин.

Хто я сьогодні і чого я хочу?

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

"The engineer needs to stop typing and start thinking."

Building AI Engineering Culture
1/ Smaller teams mean everyone must own more. You own every feature from requirement gathering through to production. The "I just write code" era is over.
2/ No design-to-dev handoff. No PM-to-engineering handoff. No QA as a separate gate. Everyone ships.
3/ Reaching $100M ARR historically required 500–1,500 employees in the 2000s, 200–500 in the 2010s, and now fewer than 100 in the AI era.

Management In The Age Of AI
"gap between good management and bad management got a whole lot wider thanks to AI."

Zen of AI coding
1/ The highest leverage work is what unblocks shipping
2/ Making imperfect decisions is no longer fatal
3/ Repaying technical debt is now cheap
4/ Good tests are the first feedback loop. CI access and server logs is second
5/ The constraint is no longer tokens. It is cognition

The Brand Age
Напевно ессе Пола, яке зайшло найбільше з новеньких. “Go where interesting problems are”.

Avoiding a Culture of Emergencies
"One of the dumbest form of emergencies is simple underestimation of the amount of effort required to get a team’s projects done."

Why does DocuSign has 7,000 employees
Everything is hard when you reach global scale.

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

Це те, що я хочу реалізувати і на Джині теж.

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

Тобто ми наче й використовуємо AI agents, але буст продуктивності (відносно) скромний. Щоб отримати реальні 10х швидкості треба прибрати цей боттлнек. Стаття якраз про це.

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

Оце буде справжня магія.

Грубо кажучи, це питання де немає (однієї) правильної відповіді.

• Яку фічу варто робити наступною?
• Яку іконку обрати?
• Чи хороший драфт розсилки у мене вийшов?
• Як краще назвати доньку?

Деякі з цих питань спеціально абсурдні, сподіваюсь ніхто їх не ставить. І так, LLM тут може бути корисним як research assistant, eg: шукаю імʼя для проєкту з шести літер щоб починалося і закінчувалося на M.

Але:
LLMs don't have judgement

І це треба завжди тримати в голові.

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

LLM тут поганий радник.

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

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

Так що може це й не жарт.

PS: Stay Saasy пише, що культура постійних emergencies це ознака поганого менеджменту.

“Revenue and profitability are my North Star metrics”

Розповсюджена помилка в роботі над продуктом - це коли ми робимо нові фічі, але не думаємо про їх імпакт і success metrics. Бажано до початку роботи, а не після релізу.

SVPG називає цей підхід feature teams -- "ми релізнули цього кварталу вісім фіч, ми молодці". Окей. Nobody cares. Який імпакт від ваших релізів?

Друга помилка зʼявляється коли команда починає думати про імпакт і шукає нові метрики для оцінки релізу. "Ми зробили флоу Х і у нас є 2,534 використання флоу Х на тиждень". Nobody cares.

Окей, не зовсім так.

Adoption це важлива метрика, щоб побачити чи користувачі знайшли/зрозуміли вашу нову супер фічу. Але це нічого не каже нам про імпакт. Він може бути навіть негативний, eg. ми додали обовʼязковий крок на sign-up flow і у нього adoption 100%. Тільки реєстрації впали на 20%.

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

Для Джина це кількість наймів, вакансії онлайн, відгуки, контакти. Може реєстрації, якби ми зараз запускались на нові ринки. Revenue. Weekly active users. Все.

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

Ще по темі:

• "Креш курс ПМ" для розробників

Здається ця ідея була ще у Пітера Друкера в Managing Oneself і памʼятаю подкаст з Jim Collins, де він розповідає про ексельку в якій оцінює кожен день по шкалі від -2 до +2 і окремо трекає кількість writing hours, щоб було не менше 1000 годин за останні 12 місяців.

Напевно мало хто може сказати що 100% чи навіть 80% часу вони роблять речі, які дають їм енергію, але з іншого боку якщо цей показник падає до 20-40% можливо час задуматися. Я для себе визначив, що >60% це good enough.

Ось що у мене вийшло.

Gives energy:

• Прогулянки на сонці
• Writing
• Книжки і подкасти
• Придумування чогось нового
• Обговорення маленькою компанією
• Meeting great people
• Спортзал

Saps energy:

• Поїздки в пробках
• Стояння в черзі
• Очікування на когось або щось
• Казати комусь що робити і контролювати результат (check-in)
• Дебажити помилки Claude/ChatGPT
• Великі туси з малознайомими людьми

Бонус: загнати результати в Claude/ChatGPT і послухати що він тобі скаже.

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

Нормальні такі затримки, коли в квітні тобі дають "аванс" за лютий. Або ти ходиш просиш $100 в рахунок зарплати, бо тобі в неділю за квартиру платити. Ти можеш звісно звільнитися, але по-перше не так просто тоді було знайти роботу, ну і по друге скажи гудбай боргу компанії по зп перед тобою.

Так от.

Разом з падінням дисципліни розрахунків керівництво вирішило підняти дисципліну серед робітників.

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

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

В якийсь з днів він написав таке:
"Сьогодні я запізнився на роботу, бо мені приснилося що я отримав свою зп за три місяці"

А наступного разу продовжив:
"Сьогодні я запізнився на роботу, бо витрачав гроші, які отримав у минулому сні"

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

Володя, якщо раптом це прочитаєш, тобі привіт!

І це насправді офігєнна тактика.

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

Не пушити це як "ось твоя нова відповідальна роль і якщо ти її зафейлиш всі про це дізнаються". Нє нє. Навпаки, сформулювати це як максимально low-risk штуку. Ось у нас є задачка, давай спробуємо. Якщо не вийде, ми нічого не втрачаємо, повертаємось як було.

Або для найму.

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

Запропонуйте тестовий проєкт. Щось, що можна зробити за тиждень. Парт-тайм на місяць. Або інший формат, не принципово. Ви одразу все побачите.

"Давай спробуємо"

Файл або нотатка в телефоні, де ти пишеш завжди зверху, нічого не видаляєш.

Книжки, які хочеться прочитати. Фільми на подивитись. Journal. Навіть TODO.

Ось наприклад мій What I'm reading.

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

В теорії можна створювати купу маленьких файликів або придумувати більш складну систему, але цей простий патерн дуже класно скейлиться. І шукати легко. Єдина поступка - розбиваю свій Journal на файли по роках, щоб Obsidian Sync не тормозив.