«Щоб вилізти вище середнього, потрібна якась мотивація за межами грошей» — інтерв'ю з Русланом Череминым



Друзі, перед вами черговий випуск «Без слайдів» — програми, видеокаста, подкасту, де я беру інтерв'ю з цікавими мені людьми. Гостем цього випуску став Руслан Черемин aka cheremin, експерт з Java і Concurrency. Ми поговорили про Java Memory Model, технічне блогерство, культуру експерименту, фундаментальна освіта і багато іншого.



Як завжди — під катом розшифровка інтерв'ю.

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

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

— Серед твоїх колег, з якими ти стикаєшся по роботі, чи є потреба в цих знаннях?

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

— Це патерни багатопотокового проектування типу «Java Сопсиггепсу in Practice»?

— Так. Якщо ти це знаєш, більше 99% завдань вирішиш. Важливіше розуміти, де проходить твоя межа: щоб ти зрозумів, коли наступаєш на ті піввідсотка, де ти не можеш компетентно самостійно зробити. Тоді ти йдеш з питанням.

— Де проходить твоя межа?

— Крім моделі пам'яті, як якоїсь абстрактної моделі, є ще безліч перфомансных деталей, де все набагато глибше. З абстрактною моделлю пам'яті я більш-менш розібрався. Це не означає, що все розумію — там є велика частина про Data Races, і незрозуміло, чи потрібно її розуміти ще для чогось, крім як для завершення формальної моделі.
А є інша задача — окей, ти зробив правильний алгоритм, але чи буде він швидше, ніж що-небудь примітивне, зібране з готового конструктора? Це велике питання, тому що люди, які пишуть елементи готового конструктора, які пишуть java.util.concurrent, знають набагато більше за тебе. У них більше ресурсів для того, щоб зробити хороше рішення.

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

— Це правда. Але ти стикаєшся в якомусь конкретному сценарії, і виходить, що ніша для самопальних рішень – це коли у тебе є конкретне залізо, конкретна версія або діапазон версій Java, конкретний софт. Тут, звичайно ж, обставити Дага не так вже складно, якщо у тебе все це зафіксовано. Тому що геній Дага в тому, що він намагається зробити хороший алгоритм, який працює на цілому спектрі платформ та віртуальних машин і для цілого спектру сценаріїв використання. І все це працює на 70-80% від оптимуму. Ось це дуже круто, для того, щоб таке робити, потрібно в голові дуже багато всього тримати. А коли у тебе є конкретне залізо, є конкретна версія Java, і пиши бенчмарки — тут теж потрібна якась експертиза, але не захмарна.

— чи Був у твоїй практиці досвід, коли ти писав щось самопальним, і воно починало працювати швидше в рази?

— Був такий досвід. Інша справа, що прискорення алгоритму в рази ще не гарантує, що система почне працювати в кілька разів швидше. Ти прискорив конкретну штуку, наприклад, в три рази, що дає 5% приросту, і це ще добре, якщо вийшло стільки. У мене був досвід прискорення конкретного місця в рази — просто це не має значної ваги в масштабі всієї системи.

— Зазвичай ти переходиш до іншого вузькому місцю?

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

— Виходить, що загальний приріст продуктивності не дуже великий, і вкладення не окупають себе?

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

Про технічному блогерстве
— Ми з тобою познайомилися п'ять років тому. Ти тоді серйозно захоплювався всією цією темою, і за concurrency у тебе був один з найбільш популярних в рунеті блогів. Зараз ти знову пишеш, але все ж трохи про інше — тобто, розповідаєш теж про перфоманс, але вже про Escape Analysis. Ти з цим закінчив або будеш розвивати далі?

— Сам не розумію. У мене немає планування на рік вперед — мовляв, написати серію постів за Escape Analysis. Якщо є щось цікаве, про це і пишу.

— Звідки у тебе з'явилося бажання ділитися своїм досвідом з світом?

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



— за останні роки Змінилося твоє власне розуміння області concurrency? Чи були різкі розвороти, або воно просто обросло «м'ясом»?

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

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

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

— Ти слідкуєш за тим, що відбувається в сопсиггепсу-interest?

— Стежу. Але, наприклад, за тим, що зараз відбувається з JMM 9, новою моделлю пам'яті, поки не слідкую — чекаю, поки вони домовляться до чогось, що зможу зрозуміти. Там є певний відсоток фахівців, які цю тему знають набагато краще за мене, і коли я намагаюся розуміти, про що вони говорять… загалом, чекаю.

— Поговоримо про escape analysis. Як тобі прийшла ідея цим займатися?

— Це кльова ідея і далеко не молода, про неї почув вперше 5-7 тому. Здавалося, що це може бути чимось революційним, якщо буде добре виконане в Java.

Тому що є багато людей, які скаржаться — мовляв, мало можливостей, незрозуміло, як і де пам'ять аллоцируется і коли деаллоцируется. Але цього, правда, дійсно не вистачає — наприклад, я точно повинен знати, що N-ий об'єкт лежить від сих до сих. Та й навіщо мені в Garbage Collector сміття здавати. І здорово, коли за мене все це робити — можу розслабитися і отримувати задоволення від життя.

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

Але ніхто цю роботу не робив. І вже потім я читав чий-то гарячий код — то це бик код Aeron-a, який все там робив, то Chronicle Map Пітера Лорі.

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

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

— Якщо коротко, який результат твоєї роботи?

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

— Якщо десь Escape Analysis машина не може зробити, значить, їй не вистачає якоїсь інформації, або вона упирається в якісь трейд-оффы. Зазвичай інформації не вистачає і які трейд-оффы зазвичай в цьому місці з'являються?

— Oracle тепер не дуже-то напирає на Escape Analysis, в тому числі тому що Value Objects вже в RoadMap-ті, які, з іншого боку, частково вирішать цю проблему. Алгоритм, за яким працює escape analysis, мутував, але його вузькі місця залишилися такими ж, якими і були в 2010 році — кардинально змінювати їх означає випиляти великий шматок і вставити на його місце якийсь інший. Не впевнений, що в HotSpot на це підуть. Є інший алгоритм, який реалізований в Graal. У них інший підхід і, можливо, він у багатьох випадках більш розумний.

— Ця річ сильно пов'язана з тим, як працює конкретно JIT?

— Так, звичайно, escape analysis досить вклеєна в JIT, але й у нього самого є алгоритми.

— Як я розумію, з точки зору IR-а (внутрішнього подання компілятора), Graal і C2 не дуже сильно відрізняються. Тобто, ніби як модель, з якою працює компілятор, дуже схожа. За рахунок чого і чому в Graal зроблено по-іншому?

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

— Ти експериментував з Graal?

— Швидше, поки читаю, що про нього пишуть.

Практика розходиться з теорією
— чи Думав ти про те, як тебе занесло в цю історію? Чому з усього різноманіття технологій ти займаєшся тим, чим займаєшся? Твоя повсякденна професійна діяльність сильно пов'язана з перфомансом і його оптимізацією?


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

— І наскільки часто вдається обходитися простими рішеннями? А скільки доводиться сидіти і ламати голову?

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

— Часто твоя практика розходиться з теорією? Часто реальність, яку очікуєш побачити, вона відрізняється від того, що бачиш насправді?


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

— Особливо, мабуть, С2-компілятор.

— Так. Тому там складно робити висновки, і можна керуватися лише припущеннями.

Про освіту
— Нагадай, хто ти за освітою?

— Я теоретик, закінчив фізфак МДУ — займався там хаотичними процесами.

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

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

Другий важливий пойнт — важко чітко провести межу освіти. У кожної людини є власний шлях через систему освіти, кожен проповзає своїм маршрутом. У мене був не тільки фізфак, був інтернат і — СУНЦ МДУ. Там я теж займався фізикою, але більше математичними науками. І мені складно сказати, хто я в плані світогляду, що більше вплинуло — фізфак або інтернат. Я адже IT освоював самостійно, і самостійний процес навчання відрізняється від того, коли вчать тебе — з'являється ще свій, інший погляд.

— Чим ти займався кілька років між тим, як став займатися серйозно performance і concurrency, та тим моментом часу, коли закінчив фізфак?

— Заробляв гроші. Ще на фізфаку займався програмуванням, спочатку не навантаженнями — звичайним ентерпрайз невеликого масштабу. Потім якийсь час працював в освіті — в 1С є відділ, що займається продуктами для освіти, навчальними курсами. Спочатку я робив математичний конструктор, який «Жива геометрія», потім дійшов до фізичних. Математичних випустили п'ять версій і продовжують випускати. Це був цікавий досвід — якийсь гібрид програмування і освіти, але все ж маленька робота за масштабом. Client-side софт, багато інтерфейсних завдань, і баланс між складними алгоритмами і інтерфейсом найчастіше зміщений в «давайте побільше кнопочок».

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



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

— Мені здається, що все-таки в природничих науках є певний погляд на те, як «тикати паличкою природу», він формувався століттями. Є значна кількість випускників того ж фізфаку, так і не встигли зрозуміти цю ідею, та й я сам взагалі теоретик, чесно кажучи. Руками взагалі працювати не люблю. Це прищеплюється з лекціями Фейнмана або з чим-небудь подібним. Просто різні мотивації у людей, які ставлять експерименти в IT.

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

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

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

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

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

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

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

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

— Це важко. Якщо 10 років тому можна було сказати, що у нас є процесор Intel, у нього MESI-протокол когерентності кешів, то зараз ми знаємо тільки, що там MESI-подібний протокол когерентності кешів, але я навіть не впевнений, що це є в спеке. По-моєму, це закрита інформація. Як жити у такому світі, коли тобі не лінь дізнатися щось, а просто не повідомляють інформацію?

— Складно жити, звичайно, в такому світі. У цьому випадку доводиться покладатися або на те, що розробники JVM домовляться з розробниками Intel і їм нишком все розкажуть, або вони самі все з'ясують — непоганий варіант, для великого відсотка випадків це працює. JVM сама зробить роботу, яка тобі потрібна. В цьому напрямку і йде IT — ми все далі відходимо від заліза.

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

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

— Я радше про те, що люди, які беруть 10 стандартних способів і намагаються якось комбінувати — може бути, вони й праві?

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

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

Як знайти час на саморозвиток
— А ти любиш свою роботу?

— Так. Думаю, що мені пощастило, так як мінімум кілька днів в тиждень я її люблю.

— За службовим обов'язком я багато спілкуюся з різними людьми, і часто скаржаться: «Я хотів би написати статтю, зробити доповідь або щось для себе, але начальство не дає часу нормально дослідити. Оскільки не можу гарантувати серйозний приріст, мені зазвичай кажуть: «Перебери 10 способів, які ти знаєш, скомбінуй з них що-небудь, і давай далі, тому що часу на дослідження у нас немає, фічі пиляти треба». Як ти вирішуєш це питання?

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

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

— Ну область можна через розумних грошей вибрати. Я недавно їздив до друзів у Тулу, так там вони зі своїми программистскими зарплатами королі Тули. Приходиш в клуб, і там люди з цієї компанії. І в Білорусії те ж саме, в Мінську приходиш в будь-шинок — там айтішники.

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

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

— Блоги, юзергруппы, конференції — це публічна діяльність. Допомагала вона тобі в кар'єрі?

— Звичайно, допомагає. У Deutsche Bank я так і прийшов, не думав подавати туди своє резюме, але виявилося, що я як раз там і потрібен.

— То є, зокрема, це теж спосіб — копати-копати щось цікаве і показувати назовні?

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

— Якщо говорити про IT-шників, як тут влаштований баланс? Люди більше хочуть піаритися, або їх пре, і вони хочуть систематизувати?

— В тому, що я читаю, бачу інтерес до теми. Але тут виникає інша задача: треба писати ще і зрозуміло, а у людей з IT найчастіше з цим проблеми.

— Як і з будь комунікацією. Ось ти займаєшся контактною імпровізацією в танці — вона розвиває в тобі комунікативні навички?

— Думаю, що не дуже.

— тобто, це про інше?

— Для мене так, хоча багато хто говорить, що їм допомагає потім в спілкуванні.

— Коли ти починав писати, чи був в тебе страх бути осмеянным, і пройшов він?

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

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

— Ось у моєму доповіді про JMM, якому вже кілька років, була помилка, але не тільки я помилився, і це дещо вибачає мене.

— Там у вас була взагалі складна історія.

— Так, і ця історія повисіла в моєму блозі рік, перш ніж прийшов перший коментатор, який написав: «Чувак, так сопсиггепсу-interest ж написали, що це неправда!» Тобто цей feedback loop затягнувся. І я відчуваю якусь відповідальність за те, що яка-небудь дурість може висіти так довго, тому що люди читають мене і вважають, що це все-таки авторитетна інформація.

— Кого з блогерів у цій області ти порадиш почитати?

— Незважаючи на всі недоліки, добре пише Martin Thompson. Думаю, навіть недоліки в цьому сенсі хороші — розвивають критичне мислення. Треба читати і думати: «Так. Не помилився тут Мартін?» І він не боїться визнавати свої помилки — чесно і пише, мовляв, налажал. Ну, і про Льошу Шипилева можна вже не говорити.

— Так. Льоша зараз пише великі статті, — мені здається, глави книжки готує.

— Там вже на невелику книгу написано. Льоша — це приклад для наслідування, як треба ставити експерименти.

— Мене порадував список людей, які на прохання Льоші дали фідбек за його останньої статті. З'явилося людина 10 мастодонтів, що приємно — з'являється великий матеріал, і люди приходять на допомогу один одному, в даному випадку Льоші, і допомагають зробити чіткіше. Це кльово, робота як ком'юніті.

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

— Кого ще порадиш, крім Льоші і Мартіна?

Nitsan Wakart пише гарні статті, і його теж кілька досить вагомих людина ревьюит. Він теж любить солідні лонгриды, як наукові статті.

— Але у нього є деяка простота, читати його легко.

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






Корисні посилання
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.