Це воно у всіх так?

[malyj_gorgan]

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

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

Це у всіх так? Чи лише у мене? Чи лише в деяких родах занять, типу прикладної науки чи data science проектів? Бо у мене -- весь час так. Вірніше, не весь-час, 3/4 проектів так пшиком і закінчуються, тому треба паралельно робити кілька, щоби хоч щось вийшло.

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

Comments

[rudolf_bochkin]

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

Тому, якщо кілька людей працюють над однією проблемою, то кожен може послуговуватися уже обробленими колегою даними і відтак залучати вже сьогодні оті додаткові в обробку.
якщо ж колектив невеликий, або людина сама - тоді працює "метод Леонардо": займатись кількома справами, робити часті короткі перерви (в тому числі на сон), змінювати діяльність (наприклад: творчу на рутинну, статичну на рухливу тощо), занотовувати навіть проміжні результати.
Занотовування (навіть голосове - на диктофон) уже сприймається мозком як обробка даних і тому "оперативка" звільняється швидше.

[malyj_gorgan]

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

[rudolf_bochkin]

Проект - це завжди щось абсолютно нове. І на оте нове ніхто не має досвіду "раніше зробили - зробімо так само". Відтак попасти в "запрацює" і промазати "незапрацює" має переважну імовірність для "не запрацює".
Адже на одне "точно" є як мінімум два: "недо" і "пере".
І якщо для певних умов "точно" має широкий діапазон,
то і "недо", і "пере" мають ще ширші діапазони.
Таким чином 1/4 - цілком пристойний результат.

[malyj_gorgan]

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

[juan_gandhi]

Изредка так бывает. Изредка. Ну, я программист. Но мой математический опыт - это как динозавра встретить. 20 лет долбишь-долбишь, днём и ночью. И или получится, или не получится, кому как повезёт в жизни. Проблемы-то разные бывают.

[malyj_gorgan]

У мене таке навіть в програмуванні -- коли програмуєш модель чогось: модель спочатку не працює, а потім, якщо пощастить -- працює. Я про те, що ти ніколи наперед не знаєш, коли саме вона запрацює. Менеджери навколо ходять, бубнять "estimated time of delivery", "project in the red", "project on track", ще щось, тоді як насправді, воно все -- абсолютний і повний bullshit. Може, запрацює сьогодні ввечері, може -- не запрацює ніколи

[juan_gandhi]

В программировании есть стандартная оценка: 2 недели. Но может и не получиться. А можно уложиться в пару часов.

[malyj_gorgan]

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

[juan_gandhi]

В реале может быть и дольше. Но поди догадайся в начале этих пресловутых two weeks.

[malyj_gorgan]

О. Це, коли я вперше прийшов з нац. лабораторії в індустрію, мій onboarding buddy і колега по проекту пояснював мені, як працює Джіра, тікети, оцеотвсе, що, за межами інженерно-софтверних задач, makes zero sense. Коли дійшли до кількості story points, я завис, а Тайлер мені пояснив дужд просто: "put down three points"
З того часу так і живу, дуже корисна порада виявилася.

[juan_gandhi]

Ценнейший совет. Поставишь один пойнт - будут спрашивать, поставишь пять - будут спрашивать. А три - норм.

Систему этих пойнтов разработали невежественные идиоты - но кому это можно объяснить, тем же идиотам?

[sassa_nf]

Іт депендз.

Гасло Sun Labs: половина проектів має бути успішними. Якщо більше половини успішні - ви займаєтесь очевидними речами; будь-хто таке може. Якщо менше половини успішні - ви займаєтесь занадто ризикованими речами; теж будь-хто таке може, кидатись на всі підряд ідеї.

[malyj_gorgan]

> Якщо більше половини успішні -- [проблема 1]. Якщо менше половини успішні -- [проблема 2]

О, як я такого не любло.
А якщо рівно половина успішні -- ви, сцуко, підганяли результати

[sassa_nf]

😹😹😹

[malyj_gorgan]

Був класичний совєцький анекдот про те, за що посилали в ГУЛАГ людину залежно від відповіді на питання "з якого боку від жінки ви спите"

[juan_gandhi]

Когда я был тимлидом, архитектором и профгруппоргом (одновременно), я эти результаты подгонял только так - чтоб в четвёртом квартале отделу была премия.

[malyj_gorgan]

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

[juan_gandhi]

Я могу только присоветовать, где таких программистов взять, какие у нас тогда были. Индийские программистки. Лучшее качество кода.

[malyj_gorgan]

Чорт з ними, з програмістами, де менеджмент правильний взяти?!? :)

[juan_gandhi]

Да, сложная тема.

[yaceya]

>3/4 проектів так пшиком і закінчуються, тому треба паралельно робити кілька, щоби хоч щось вийшло.
(Зараз вилетіло з голови ім'я) спікер дуже полюбляв приклад, в якому він зустрівшись з юристами DOJ спитав: хто з вас виграє усі процеси? (А там як раз подібна практика - не рідкість) І продовжив: якщо ви виграєте усі процеси - це означає, що ви працюєте неправильно. Бо це означає, що ви автоматично відкидаєте усе, де можна програти.
Якщо у вас завжди усе одразу і просто виходить - ви просто явно живете не за своїм потенціалом. Не знаю про "будь-хто таке може" (я точно знаю людей, які можуть раз за разом робити успішно те, що будь-хто не може :) ), але ви точно могли б краще.

[sassa_nf]

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

[yaceya]

Ну, це якщо інші юристи теж можуть вигравати ці справи) Якщо ти один такий Біллі Флин, то ціни чудово собі диктуються
Втім, це дуже теоретичне питання, бо на практиці не просто так ця ілюстрація починалася з юристів DOJ - у державних чиновників є сенс нагадувати про те, що програвати справи - це частина життя, бо по-перше, чиновнику як раз ціну диктувати не доводиться, по-друге, як раз є тенденція вимірювати успішність відсотком виграшів (ще ц політично може скандал бути якщо ту справу програєш) і по-третє, юристів куди менше ніж справ і простіше обирати найнадійніші. Як раз середовище для wrong incentives і загальної деградації системи

[sassa_nf]

То так