Заклинач пітона. Легенда Python-спільноти Андрій Свєтлов — про шлях до посади Core Developer і проблеми та майбутнє мови програмування

Андрій Свєтлов вже майже 25 років у програмуванні. З 2012 року — Python Core Developer, автор та активний учасник розробки таких пайтонівських бібліотек, як asyncio та aiohttp.

Ми поговорили з Андрієм про його кар’єру, розвиток Python, як стати членом core-команди, чим вона займається і як влаштована. А ще про те, які бонуси дає статус Python Core Developer та чому це неоплачувана діяльність.

Як стати Python Core Developer: «Раніше процедура була значно простішою»

— Як взагалі прийшли в програмування?

Я народився у місті Лисичанськ, Луганська область. Програмуванням цікавився зі школи. Звичайно, в самій школі ми трохи Basic пройшли й все. Але можна було вчитись самостійно: з’явився ZX Spectrum, книжка з асемблера (на Spectrum без асемблера нічого серйозного не напишеш) — і закрутилось. 1995 року поїхав навчатися до Донецька до вишу зі смішною назвою «Інститут проблем штучного інтелекту».

— Коли почали працювати?

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

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

Наразі вже понад три роки працюю у Neu.ro. Це платформа для Machine Learning, щоб Data Scientists, хороші математики з мінімальними знаннями в адмініструванні віддалених серверів могли робити свою справу, концентруючись на предметній галузі. З цією платформою їм уже не потрібно дбати про те, як залізти в Kubernetes і отримати потужні машинки з високопродуктивними GPU, порахувати щось серйозне. Адже ноутбук для цього геть не підхожий інструмент: надто повільний, мало пам’яті та дискового простору.

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

— З якими технологіями працювали? Починали із С++?

Якщо йдеться про мови, то так. Взагалі Python — відкрита архітектура, тому часом треба брати C і дописувати шматочки, щоб прискорити критичну частину або зв’язати з API, якого на Python ще немає. Доводилося мати справу і з Java, і з C#. Але це було давно, і мені це не дуже цікаво, хіба що подивитися, як в інших все влаштовано.

JavaScript — окрема велика тема, його трохи знаю, але гуру себе не вважаю.

— Коли та чому зацікавилися Python?

Це був 1999 чи 2000 рік — прочитав на сайті IBM статтю Девіда Мертца про Python із зазивною назвою. Сподобалося, почав пробувати. До речі, років зо п’ять тому зустрів Девіда, розповів про цю історію. Дідусь дуже здивувався.

Якийсь час Python ми використовували як скриптову мову сценаріїв для саморобного ігрового двигуна. Тобто якогось чоловічка намалювати, зробити йому анімації, фізику — це все робили на C++, а на Python писали логіку, за якою цей персонаж рухався. Так набагато зручніше. Тому довелося добре вивчити зв’язок між мовами, розібратися, як скомпільовану частину підʼєднувати до Python. Це дало гарну основу.

Так я сидів на попі рівно, виконував роботу, але якось мені на думку і не спадало, що можна контриб’ютити для Python. А коли вже був в Америці 2009 року, мені запропонували злітати на PyCon — щорічну найбільшу у світі конференцію з Python у США. Мені було цікаво, ба більше, ми з колегами в Києві самі організовували присвячені Python заходи.

Треба розуміти, що звання core developer дається та не відбирається

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

Далі — більше. Їздив на PyCon до Атланти, Сан-Франциско... І ось 2012 року на черговій конференції мені сказали: «А приходь до нас у команду core-розробників добровільним помічником». Я з радістю погодився.

Тоді процедура була набагато простішою, людей у ​​core-команді було менше — близько сотні. Тут ще треба розуміти, що це звання дається та не відбирається. Іноді люди самі кажуть: «Вибачте, я йду з галузі, щасти вам», але якщо тебе одного разу вже внесли до списку core-розробників і видали відповідні права, ти в ньому перебуваєш довічно. Тому насправді активних core-розробників не так багато. Наприклад, нещодавно у нас пройшли вибори комітету [орган, який розглядає пропозиції щодо Python — ред.], 75 осіб мали право голосувати — це ті, хто протягом останнього року хоч щось зробив для Python. Інші майже 180 осіб із загального переліку — «сплячі».

— А як зараз надають статус core-розробника?

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

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

— Хто взагалі ці люди, які стають Core Developer?

Це може бути хто завгодно. Наразі з’явилася помітна кількість жінок. Раніше це були переважно люди зі Штатів, Європи, зараз додаються хлопці з Японії, Китаю, Латинської Америки... З Кенії є розробник, наприклад.

— А є ще програмісти з України в core-команді?

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

— Повернімось до процедури прийняття до команди. Людина зазвичай сама просить досвідченого розробника про менторство?

Не чув, щоб хтось сам просив потенційного ментора про допомогу. Радше навпаки. Наприклад, я помітив, що один хлопець з Індії вкладає дуже багато часу, подумав, що це було б чудове надбання для команди, написав йому: «Картик’ян, давай до нас» (таке у нього складне ім’я, ще складніше пишеться — Karthikeyan, тому я просив його навіть зробити транслітерацію). Я запитав, чи має він бажання стати core-розробником, чи не співпрацює він з кимось іншим, і запропонував попрацювати разом. Він погодився, а далі я підказував йому, що робити, проводив рев’ю, приймав роботу. Згодом виніс його кандидатуру на голосування, її ухвалили.

Про команду core-розробників: «Цьогоріч Python найняв першого програміста на зарплату»

— Чим займається команда core-розробників Python? Наскільки це відрізняється від розробки інших мов?

У розробці інших мов я не брав участі, тому знаю лише з чужих слів. Річ у тім, що є мови, які були давно придумані, та ж C.

C++ молодша, але у неї теж довга історія, за її розвиток відповідає великий комітет з різних людей, компаній, які виробляють компілятори, тому там все неквапливо. «Плюси» змінилися на краще за останні десять років, раніше там був застій і болото.

А Java чи Go — мови однієї компанії, Oracle та Google відповідно. Go, по суті, open source, але йде туди, куди його Google розвертає. Простій людині з ком’юніті нелегко проштовхнути свої пропозиції, не ініційовані компанією.

Python від початку був не таким, це community-driven development. Тут все демократично: берись за те, що цікаво, і роби. Якщо вдасться переконати інших, що це корисно — чудово. Немає жодної сили, яка розповідала б, у якому напрямку все має розвиватися. Якщо у розробника достатньо часу та кваліфікації на те, що він задумав, буде результат. Але якщо сил чи знань не вистачає, то навіть добрий почин залишиться нереалізованим.

— На вашу думку, що ефективніше для самої мови?

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

Мій хороший знайомий Віктор працює в R&D в IBM, у них багато зав’язано на Python. Для такої великої компанії це має сенс, їм неважко виділити ресурси, щоб працювали кілька core-розробників Python. Ось він і ще кілька його колег із Red Hat займаються цим весь робочий час. Нещодавно Microsoft стала активно вкладатися в Python, і це теж гарна новина.

— Це часта практика чи поодинокі випадки?

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

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

— Хто ця людина? Чому саме вона?

Лукаш Ланга, поляк, до цього працював у Facebook. Чому він? Саме з’явилися фінанси на одну фултайм-позицію, а Лукаш мав і час, і досвід: хлопець був реліз-менеджером Python 3.8 і 3.9. А це підтвердження і технічних, і комунікаційних навичок та достатньої самоорганізації. Нині розгрібає пул-реквести, роботу, підготовлену іншими.

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

Python не мав ніколи стільки грошей, скільки було вкладено в Java, щоб довести до досконалості інтерпретатор

— Як ви вважаєте, чи правильно, що Python Core Developer — це неоплачувана посада? У чому тут плюси та мінуси? Якби це була оплачувана зайнятість для всієї core-команди, працювало б усе ефективніше?

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

Жорна мелють повільно. Декілька років тому почали обговорювати: «А вкладаймо більше в сам Python, а не в тусовку довкола нього? Тусовка — це теж важливо, корисно, але не конференціями єдиними...». І врешті все ж найняли програміста. Якщо експеримент буде успішним, то відкриється ще вакансія.

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

— Ви сказали, що Python ніхто не скеровує, а як же сам автор мови Гвідо ван Россум?

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

— Ви були серед цих п’яти?

Ні. Я не хочу, це займає чимало часу.

— Які поправки пропонують зовні?

Різні. Від тривіальних, коли в документації друкарська помилка, щось треба уточнити або в функції додати певний параметр, щоб увімкнути прапорець, режим. А бувають серйозні. Для таких ми маємо певну процедуру: потрібно писати окремий документ Python Enhancement Proposal, його довго й уважно обговорюють, готують робочу демонстраційну версію. До ухвалення рішення має бути не просто ідея чогось класного та корисного, а робочий приклад пропонованої функціональності. Саме розглядом таких пропозицій і займається наш «уряд».

— Комітет займається і пропозиціями, які надходять від core-розробників?

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

Все обговорюється в розсилках та на Disqus. Доводиться переконувати інших у своїй правоті, щось змінювати після конструктивної критики. Потім, коли обговорення затихає, наш комітет із п’яти осіб засідає і вирішує: приймаємо чи ні. Вони можуть сказати й так: «Ми не можемо ухвалити рішення, нехай ті, хто прийдуть після нас, це роблять». Це не можна назвати затягуванням — є складні та неоднозначні речі, щодо яких важко передбачити, це буде виграш чи помилка.

Про асинхронне програмування: «У 2015–2016 роках було голе поле, на якому три хирляві осики, а все інше бери та пиши сам»

— Як згодом змінювалася ваша роль у розробці Python?

Спочатку берешся лагодити те, що можеш — потрошку. Далі, коли став Core Developer, була свідома стратегія братися за баги, якими неохоче займалися інші. Припустимо, не дуже популярні проблеми з юнікодом, які мені, як російськомовній людині, знайомі від самого початку. Американців та європейців, у яких латиниця, це менше турбувало. Плюс Windows — я вже понад 10 років використовую переважно Linux, але свого часу добре знав Windows API. А Python-розробники недолюблюють Windows, не користуються ним, отже і програмувати під цю платформу не хочуть. Річ не в тім, хороший він чи поганий — просто інший. А мотивація щось робити, лагодити зазвичай виникає щодо того, чим користуєшся щодня. Тож я свого часу займався такими нішевими речами.

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

— Чому вирішили зайнятися асинхронним програмуванням та чому це важливо?

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

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

Для мережевого програмування можна будувати програму інакше, відкривати різні з’єднання і потім говорити: «Засинай. А коли мережею прийдуть дані, прокинься і подивися одразу від усіх, роби це по колу: прокинулися, заснули». І писати такі програми можна по-різному. На колбеках: «Коли щось буде готове, виклич ось цю функцію, вона викличе своєю чергою ще щось»... Ось так робиться класичне програмування на JavaScript під Node.js. І це вибух мозку, нетривіальні речі стає складно виконувати.

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

І це дозволяє писати мережевий код, який працює швидко та одночасно підтримує багато з’єднань — вебкраулер, який витягує пів інтернету. Був випадок, що ми не поставили «гальмівники» і в Данії «поклали» один провайдер, який обслуговує більш ніж половину країни. Ну, країна маленька :) Наш техдиректор, данець, перепрошував, все обійшлося. Пообіцяли більше не робити такого.

Можна давати велике навантаження, обробляти багато всього відразу, це корисно для серверних, розподілених систем, коли багато серверів спілкуються між собою, організовуючи мережу. Так працює багато популярного софту, той самий nginx — вебсервер № 1 на сьогодні. Коли в Python з’явився зручний виразний засіб, що дозволяє писати ось у такому стилі, це було цікаво. Раніше такі ж завдання розвʼязували, але оскільки мова не містила потрібних синтаксичних конструкцій, то й програмний код виходив набагато складнішим: складніше писати, розуміти, легше припускатися помилок.

— В одному подкасті ви розповідали, що спочатку працювали втрьох над бібліотекою асинхронного вводу/виводу asyncio...

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

— А потім ви почали займатися aiohttp...

Так, адже asyncio — низькорівнева бібліотека, яка дає набір цеглинок, «блоків Лего», але під неї відразу після створення не було нічого. А якщо йдеться про мережеві комунікації, то робота з HTTP-протоколами, вебсервери, вебклієнт — перше, що потрібно. Ось ми це й зробили. Друге, що потрібно — спілкування з різними базами даних. Теж «запилили». Потім все це обростало бібліотеками, які роблять щось на основі HTTP. Наразі в asyncio близько 50 мільйонів завантажень на місяць.

— Які завдання розвʼязують бібліотеки, над якими працюєте?

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

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

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

— Що варто враховувати, щоб бібліотека була зручною, популярною?

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

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

Якщо підсумовувати, то під час вибору бібліотеки варто орієнтуватися на такі критерії: зрозуміло, зручно, велике ком’юніті, тобто на Stack Overflow буде безліч запитань і відповідей, хороша пошукова видача в Google. Якщо ж це маргінальна річ, про яку ніхто як слід не знає, значить у разі проблем їх не дуже загуглиш — то навіщо час витрачати?

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

Про розвиток Python: «Бажання ван Россума піти з диктаторського посту — свідчення того, як зросла мова»

— Як розвʼязувати проблему з тим, що деякі патчі для Python висять на модерації роками? Чи після того, як побільшало core-розробників, ситуація змінилася?

Ні, не змінилася. Core-розробників побільшало, але й кількість зовнішніх колабораторів збільшилася. Тож ситуація не така вже й райдужна: відкрито десятки тисяч патчів, пул-реквестів.

Зазвичай виходить як: розробник Python побачив 20 тисяч тикетів у роботі, відкрив деякі з них, подивився; зазначив, що треба переробити. І якщо зовнішній колаборатор не дуже мотивований вносити правки, то він може просто сказати: «Ах так, ну й добре!» — і піти.

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

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

— П’ять років тому в одному інтерв’ю на запитання «У чому, на твій погляд, найважливіша проблема, яка зараз стоїть перед спільнотою розробників Python?» ви відповіли: «Добити» перехід на «трійку» [третю версію Python — ред.]«. Цієї проблеми більше немає. Як відповісте на це питання зараз?

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

— Гвідо ван Россум продовжує брати участь у житті Python?

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

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

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

— Python залишається однією з найбільш популярних мов програмування в Україні. Як гадаєте, чи реально їй увійти до першої трійки?

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

До речі, можу сказати, що сильне зростання популярності Python в останні роки зумовлене науковими обчисленнями. Багато хто забуває про спеціальні мови для статистики, про Mathcad, MATLAB, і робить все на Python, тому що він допомагає скоротити бар’єр між прототипом та продуктом, який компанія продаватиме.

Автору треба писати хорошу документацію, тести, відповідати на запитання

Знову ж таки, останні п’ять років комерціалізація Machine Learning послуг йде семимильними кроками, зараз штучний інтелект — модна річ. Складна математика не обчислюється на самому Python, вона написана на C і Fortran. Багато алгоритмів як були написані в 1970-х на Fortran, так і продовжують залишатися такими, але, на щастя, їх можна скомпілювати і причепити до чого завгодно — і тут Python виявився дуже гарною мовою, що допомагає легко з’єднувати їх між собою.

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

І що більше у нас розроблятимуть софту, який використовує машинне навчання, то більше буде Python на ринку.

Про пошук роботи: «Робота в IT-гіганті ніколи не була для мене метою»

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

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

Загалом за моє життя бували курйозні ситуації з пошуком роботи. Якось пишу оголошення про те, що я відкритий до пропозицій, і за годину мені дзвонить знайомий: «То ти роботу шукаєш? Ну що ж ти! Навіщо такими складними шляхами? Треба було одразу говорити».

— Тобто ви за годину знайшли наступну роботу?

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

— Читала, що ви повернулися до України, як тільки закінчився контракт у США. Чому не захотіли залишитись, шукати там роботу?

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

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

Все відбувалося досить випадково. Розумієте, 15 років тому все було по-іншому, і компаній, де були потрібні фахівці на Python, було не так вже й багато. А Python цікавив мене ще з 2000 року. Це був свідомий вибір: я не хотів мати справу ні з Java, ні з C#. Хоча й доводилося, і вмію, але Python подобався більше. А далі вже вибирав те місце, де все збігалось: колектив, проєкт, технології.

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

Про підхід до зміни роботи: «Термін „в активному пошуку“ — це не про мене»

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

Ні, зараз інакше. 2014 року народився вебфреймворк aiohttp, де я виступив одним із головних розробників. І ось він і супутні інструменти забирають багато часу. Це теж open source, але не завжди Python.

— Але фреймворком теж займаєтеся щодня?

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

— До цього з розумінням ставляться?

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

— Як змінилося ваше життя після того, як ви стали Python Core Developer? Почали частіше надсилати офери, менше розпитувати на співбесідах...

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

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

Про код, улюблені завдання та саморозвиток: «За десятиліття програмування в тебе виробляється чуття»

— В одному з інтерв’ю на запитання «Що є найкращою та найгіршою частиною вашої роботи?» ви відповіли: «Найкраща — робити гарний код та вчити цього інших. Найгірша — коли доводиться жертвувати красою заради бізнесових запитів. Ми всі розуміємо, що програмування має розвʼязувати бізнес-завдання, але прикро, коли з об’єктивних причин вимушене рішення виходить негарним». Як виходить досягати балансу між красою рішення та тим, як воно розвʼязує бізнес-завдання?

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

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

— Які завдання вам подобається розвʼязувати, а які ні?

В останні роки це завдання, пов’язані з архітектурою та вузькими місцями — там, де потрібно зробити щось неочевидне. Багато займаюся інфраструктурними питаннями довкола кодування, тобто тим, щоб правильно налаштувати інструменти, які роблять автоматичні перевірки, Continuous Integration. До цього можна підходити формально, а можна з вогником, роблячи життя розробника в колективі кращим, зручнішим. Якщо частину роботи можна виконати автоматичним інструментом, краще на нього витратити час. І нехай, як у тій пісеньці, «працюють роботи».

— Займаєтесь самоосвітою? Що можете порадити читачам?

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

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

Є відчуття, що найкорисніше, що я робив, це був якраз open source — щонайменше за кількістю людей, яким це допомогло розвʼязувати проблеми та завдання.

Все про українське ІТ в Телеграмі — підписуйтеся на канал редакції DOU

👍ПодобаєтьсяСподобалось26
До обраногоВ обраному3
LinkedIn



1 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
А Python-розробники недолюблюють Windows, не користуються ним, отже і програмувати під цю платформу не хочуть.

Тим не менш, під Windows є офіційний embeddable package, а для Mac нічого такого нема. І зробити його не те щоб тривіальна справа. Дуже складно відокремити від того, що є у системі.

Підписатись на коментарі