Павло Комков

Чим хороша робота в Гуглі, про користь і практику олімпіадного програмування і яму на Вольской

Це друге інтерв'ю для нашого порталу c інженером компанії Гугл.

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

Як тебе представити нашим читачам?

Так і уявити, Комков Павло.

Я Site Reliability Engineer в компанії Гугл, тобто відповідаю за надійність роботи сайтів. За Грейді - Сеніор, за фактом виконую обов'язки технічного ліда, і вже не на команді, а в напрямку.

Тобто ти командуєш фронтом робіт, а не якимись специфічними людьми. Ок. В Гуглі ти працюєш з 2007 р, а до цього?

Де я тільки до цього не працював. У лабораторії судової експертизи, в ПРЦНІТ СГУ, з 2003 - в МТС.

В Гугл - тебе покликали і ти поїхав? Або навпаки, ти вирішив, що пора їхати, і знайшов Гугл сам?

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

По-перше, я шалено контрібьютіл в опенсорс - коли інші відпочивали, займалися спортом і якийсь особистим життям, я сидів і патч лінукс, SQUID і все таке інше. Також робив специфічні речі, тому що за специфікою роботи з МТС, наприклад, довелося працювати з kannel і іншими спеціалізованими системами. З'явилося розуміння буття у всьому цьому, потім в якийсь момент мені прийшла в голову здорова (насправді скажена) ідея з'їздити на конференцію під назвою Лінукс Симпозіум, яка проходила в Оттаві, і в 2005 р я зібрався і поїхав. Це був той ще цирк, тому що за візою треба було їхати в канадське посольство в Москву, там на тебе дивляться підозріло - що це за людина з якогось Саратова на якусь конференцію? Потім квитки, і все це за свій рахунок.

Взагалі все?

Ну а хто, МТС мене, чи що, пошле? Загалом, я поїхав і побачив багатьох людей, яких знав по списках розсилання і IRC, познайомився з ними. Тоді лінукс-симпозіум був дуже великий, людина на 700. Зокрема, і з народом з Гугла познайомився, а в 2006 від їх рекрутерів мені прийшло запрошення спробувати себе. Зараз-то я краще знаю, що вони саме так і працюють - через контрібьютеров в опенсорс, конференції, списки розсилки. І я пройшов через усі етапи відбору - листи, розмова з рекрутером з питаннями "скільки біт в байті?" - і до кінця.

І ось 10 років ти в Гуглі. Задоволений? Що там хорошого для глибокого айтішника (як би смішно не звучало це питання)?

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

Можливості є. Навіть не змінюючи команду і посаду, можна спробувати дуже багато всього, і попрацювати з різними продуктами. Я можу аргументовано говорити тільки з точки зору SRE, але це насправді загальне правило.

А воно якось регулюється? Програма 20%, по якій можна один день в тиждень витрачати на будь-який підтверджений проект?

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

Буває навпаки, ці 20% витрачаються на якусь суміжну область, але ти все робиш там тим способом, яким добре володієш, і це актуально.

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

Насправді в Гуглі в 100% випадків ніхто не наполягає на способі виконання завдання - завжди вимагають тільки результат.

Ну а бувають випадки, коли ти вирішив задачу неприйнятним способом, що було неочевидно тобі особисто?

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

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

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

Тобто ступінь зрілості така, що все це очевидно. Що ще хорошого?

Досить давно в Гуглі йде систематична робота з метою зробити робоче місце людини більш комфортним.

Є загальнодоступні матеріали на сайті https://rework.withgoogle.com/ - там лежать результати дослідження чинників успішності команди. І основним фактором успішності є Psychological safety (психологічна безпека). Факторів взагалі виділено п'ять, є ще Dependability (відповідальність), Structure Clarity (ясна структура), Meaning (важливість роботи особисто для тебе), Impact (важливість роботи для всієї компанії). Безпека - головна.

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

Мені здається, навіть коли у Васі аврал, він повинен сказати не "так, звичайно", а "так, коли-небудь, не зараз".

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

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

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

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

Питання безглуздий, але задати його треба. Куди Гугл рухається, при тому, що він знаходиться на вістрі прогресу в технологічному і організаційному сенсі?

Хочеться вірити, що він рухається до світлого майбутнього. З моєї точки зору, зсередини, здається, що Гугл рухається вперед. Була у всіх на слуху хвора тема з закриттям Google Reader - але проекти відкривають і закривають, тут нічого не поробиш.

Напевно, в більшій мірі суспільство турбує доля Гугла як Імперії Добра в цілому - концепція, що він все про всіх знає і продає ці знання зловісним корпораціям за гроші.

Не готовий обговорювати рептилоїдів і військову таємницю ... хоча чому б і ні: я знаю людей, які не ставлять собі Гуглмапс на телефон, щоб про них не знали нічого. Незрозуміло, правда, що це змінює.

Гугл - круто, але давай поговоримо про Саратов. Ти поїхав 10 років тому, але контакти підтримуєш, і тому скажи - що змінилося за цей час, і чи змінилося.

Всі, хто працює не в центральному американському офісі Гугла в Маунтін-В'ю, часто їздять туди у відрядження, і я в тому числі. А в Саратові є такий захід, як літня школа інформатики, де я з 93 року брав участь, а з 95 був організатором і викладачем. І в 2009 на корпоративній квартирі Мірантіса і Гріддінамікса у Фрімонті зібрався склад один в один як в цій літній школі. Так що треба уточнити, про що ми говоримо - про Саратов там або Саратов тут.

Є ще третя частина, яка виросла вже після того, як ти поїхав. І на всі ці частини хотілося б якихось коментарів.

З Саратовом було цікаво - для провінційного міста тут було багато олімпіадників - загальний ряд міст був "Москва, Пітер, Саратов", що виглядає дивно. І коли команда СГУ виграла чемпіонат з програмування, багато хто підходив і питали: «А де це - Саратов?». Починати відповідь доводилося з вказівки півкулі Землі.

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

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

Ок, відповідь зрозуміла. Це мені, тут живе, навіть дрібні зміни кидаються в очі, а в порівнянні з Дубліном все, значить, сумно.

Дублін - це окрема розмова насправді. Це одноповерхова село, де живе 500.000 чоловік, і в багатьох будинках там до сих пір топлять торфом. Як холодніше стає - в повітрі над містом щільна хмара диму висить. Центрального опалення немає (але зате його і не відключать), з медициною і освітою все ще гірше, ніж в Росії. Ми кілька років намагалися організувати олімпіаду з програмування для школярів, але проблема в тому, що в церковно-парафіяльних школах немає предмета "інформатика".

Ок, а з дітьми-олімпіадниками тут ситуація якось змінюється? Ти ж її монітор постійно.

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

Тобто ті завдання, які вирішували ви, вже не вирішують.

Насправді, ми вирішували прості завдання, потім вони трохи ускладнилися, а зараз тенденція в зворотну сторону. Хоч це і спрощений погляд на речі. У олімпіадників зараз деякі проблеми з мотивацією - таке враження, що частина учасників туди просто палицями заганяють. Втім, в деяких вузах така проблема була завжди, наприклад, в СГТУ. Не знаю, що там у них відбувається - вони завжди записуються на чемпіонат і не приходять. Навіть якщо і приходять на основний тур, то вирішують зі скрипом одну задачу і йдуть. Чи то там релігія така, то вони вирішили, що це все дитячі ігри і користі від олімпіад ніякої - незрозуміло. У той час, як практика показує, що користь безсумнівна, і якщо подивитися на чемпіонів-олімпіадників, можна побачити, що у них подальша кар'єра часто велика і вражаюча. Хтось в Гуглі, хтось встиг попрацювати в швейцарському IBM; і я можу впевнено сказати, що за інших рівних буття олімпіадника ніяк кар'єрі не шкодить.

Є зворотне думку, що олімпіадні практика псує інженерів.

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

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

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

Тобто вони настільки вище середнього рівня, що навіть при просідаючих навичках "реальної" роботи швидко наганяють. Ок.

Що потрібно "хорошого олімпіадника"? І як їм стати?

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

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

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

Я б сказав, що їх достатньо, і вже точно більше, ніж людей, здатних їх зайняти.

А ось ця активність з олімпіадами - вона багато часу в тебе займає?

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

У програмування я прийшов в 1992 році, через олімпіади і гурток на станції Юних техніків, яким керувала Наталія Львівна Андрєєва. Все це було цікаво, комп'ютерів не було, тому я пішов на роботу до мами і спробував там щось збагнути. Потім була олімпіада з якимось смішним місцем на ній, літня школа, інші олімпіади, де я з Наркайтісом познайомився, і ми призові місця займали. А вже в вузі нас покликали до Пітера, де проходив перший в Росії півфінал чемпіонату ACM, і ми туди з'їздили і повернулися дуже натхнені - новизна зашкалювала, комп'ютери на початку 90-х були чимось екзотичним, а тут ми подивилися на автоматизовану систему перевірки рішень і врахування результатів чемпіонату. Я приїхав і зробив свою, якій перевіряв потім шкільні олімпіади.

З'їздили вдруге, знову жахливо виступили, але несподівано отримали пропозицію провести у себе в Саратові чвертьфінал. І ми почали проводити його у себе, зі своїми успіхами і пригодами. Один раз нам подзвонили і сказали, що в будівлі (коледжу Яблочкова) закладена бомба, довелося евакуюватися. Пощастило, що я з технічних причин затримав тур, не встиг засвітити олімпіадні завдання, і їх не довелося судорожно замінювати чимось, ми просто час проведення перенесли. Ось 20 років я цим займаюся.

Треба зауважити, що в 90-х було неочевидно, що з цього щось путнє вийде.

Ну не зовсім. Мене з середини 90-х звали, наприклад, в Каліфорнії. Так що було очевидно, що програмування - це перспективно. Плюс я досить рано вирішив для себе, що я не буду просто вирішувати завдання, а буду вчитися писати системи - тобто отримувати досвід в системному адмініструванні та інших суміжних областях.

Чому? Як у тебе протікав цей процес?

Неофіційна причина булу в тому, что я зрозумів, что в олімпіадному програмуванні переграті Макса Бабенко не зможу, ВІН готувався за іншою системою, якові я б НЕ потягнув. Плюс у мене БУВ годину, Який можна Було вітратіті на Суспільно корисна роботу, и так підзаробити окуляри. Дерло у вузькій спеціалізації я не стану, значить, доберемося широким профілем. І заднім числом можна сказати, що це і є шлях вперед. Я дивився виступ хлопця з Нетфлікс, він був в смішному рогатій шоломі ( https://youtu.be/yIPbE7BssOs ) І міркував про те, що таке Сеніор в розробці софта - це той, кому нудно, або кому грошей багато платять? Спочатку він поговорив про досвід - це те, що ми отримуємо, не отримавши те, що хотіли.

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

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

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

Про сеніорності, до речі, у нас з колегами цікава дискусія була. Ось є проблема, можна взяти її і вирішити. А можна зробити крок назад, і побачити клас проблем. Можна ще крок, і в більш загальній картині побачити, що саме їх породжує. Ось скільки ти таких кроків зробиш - настільки ти і Сеніор.

Просто відійшовши досить далеко, можна задачу і не вирішити, чи навіть не вирішувати, зрозумівши, що це зовсім навіть не проблема, а важливий і потрібний елемент системи.

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

На скільки кроків відступаєш ти?

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

Просто якщо говорити про Скоуп робіт не в горизонтальному поділі - "ось план робіт, тоді-то ми до нього дійдемо", а в більш широкому - часто то, що було оптимальним рішенням, при цьому більш широкому погляді виявляється не просто неефективним, а навіть шкідливим. З'являється більше загальна проблема, і добре, якщо у тебе є кошти її рішення. А якщо немає - що робити?

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

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

Це не проблема розробки софта, це проблема побудови будь-якої складної системи.

Просто коли ти будуєш систему з бетонних блоків і паль, у тебе не так багато можливостей відкотити все на довільне число кроків назад і спробувати все по-іншому. У айті і розробці ПО така можливість є.

Є смішні картинки "будинків, побудованих за аджайлу", коли до двоповерхового будинку зверху прибудовані ще два і веранда, і відразу зрозуміло, що це безглуздо. З програмним продуктом це не так наочно, але по суті ефект такий же.

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

Така ситуація досить типова для великих Ентерпрайз.

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

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

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

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

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

Це аджайл.

Так. На кожному кроці ми повинні пам'ятати, до чого ми йдемо, вміти швидко коригувати це бачення при отриманні нових даних.

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

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