«Код частіше читають, ніж пишуть» і ще 27 ІТ-мудростей від Діми Малєєва

Український програміст та блогер Діма Малєєв, який живе в Каліфорнії, на честь 16 років досвіду роботи в ІТ поділився у Twitter-треді важливими спостереженнями та висновками, які він зробив за ці роки. AIN.UA зібрав все в одному матеріалі.

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

2. IT в кожній країні різне. І дуже залежить від того, яка направленість айті в країні. До прикладу – в Україні аутсорс – і тут можна знайти крутих спеців по одній технології, рідше – двом. Середній програміст на Python у нас – на голову крутіший, ніж середній дев в США, але дев в США буде крутити білди, фіксити рубі і ї*атись з конфігураціями «Амазона» по вайтлістенінг. А якщо завтра скажуть писати на С++, покряхтить, покряхтить, і почне писати.

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

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

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

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

7. Х10-програміст то міф, про який сказали на якійсь конференції. Будь-який х10-програміст починає вигорати через 2 місяці, ниє що нецікаво, і не знає, що робити далі. Програмування як і життя – це марафон, а не спринт.

8. Дуже часто програмісти вирішують інженерну задачу, не думаючи, що вони працюють на бізнес. Місць, де треба вирішувати інженерні задачі на віки – дуже мало. Бізнес-задачі вирішуються набагато простіше, часто брудніше, супершвидко, і най поки не падає – працює. Бо нікому не потрібен калькулятор, який не дозволяє ділити на нуль великою кількістю перевірок. Звичайного меседжа про помилку – вистачить 🙂

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

10. Інтервʼю має бути складним. Якщо робити інтервʼю простим, то люди дуже часто мігрують по компаніям. Якщо воно складне – люди будуть думати: «та я не хочу готуватись за +500 до цієї ***». Штати пішли шляхом складних інтервʼю, Україна – простими інтервʼю.

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

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

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

14. Мої улюблені інтервʼю – system design. Там немає правильної відповіді, але є місце, де можна поспілкуватись з кандидатом і оцінити його практичний досвід. Або теоретичний. Але те, як кандидат до прикладу дизайнив би твіттер – цікаво послухати. І воно якесь не дуже стресове.

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

16. Код частіше читають, ніж пишуть. Просто подумайте про це.

17. В житті все циклічно, і мода в айті також. Насправді багато всього в айті – культ карго. До прикладу мікросервіси. Колись вийшов «Нетфлікс» і сказав, що це за***сь. І вся почали робити мікро- і навіть наносервіси. А потім виявилось, що в багатьох випадках це не потрібно. Бо ваш стартап не «Нетфлікс». Набагато краще і дешевше зробити всьо в моноліті, глянути, чи це комусь потрібно, замість того, щоб мучитись з CI/CD, бо у вас на метод по сервісу. Ще й коштує багато. І замість того, щоб перевірити продукт – ви робите космоліт. Без космосу.

18. Знання джунів з політеху, карнегі мелона, УКУ і курсів фронтенд за 3 місяці різні в перші пів року. За пів року допитливість та посидючість може вивести навіть андердога вперед. Звісно круто знати, коли в хеш табличці колізія хешів, але чи використаєш ти це в житті – дуже маловірогідно. Як і багато академічних знань. А через три роки ви навряд скажете різницю між тими 4 джунами.

19. Академічна освіта CS в Україні переоцінена. Воно тому і називалось computer SCIENCE – це суто академічний напрямок, який в нас майже не існує. Тому в цілому вуз для програміста – опціональний, а магістерка тим паче не потрібна.

20. Зарплата – це обман. Насправді, якщо ви працюєте за частинку компанії (як в Штатах з акціями), то ви можете заробити в рази більше. Я бачив десятки програмістів мільйонерів в Калі, і не бачив жодного програміста-мільйонера, який би залишився просто програмістом.

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

22. Погано написаний код — не завжди проблема. Проблема – погано написаний код, який постійно треба підтримувати. З модою – любий код, який написали – в якийсь момент стане погано написаним. Але якщо він працює – чи треба його переписувати? В мене було багато проектів, де до якогось куска коду не повертались десятки років. І він був страшний як Сара Джессіка Паркер, але робив свою роботу, заробляв гроші, і не ламався. Тому чи треба його переписувати, навіть як технічний долг – це питання на мільйон 🙂

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

24. В моїй практиці я зустрічав тільки два типи менеджерів. Менеджер-ексель (це погано), для якого люди – це просто рядок в табличці екселя, і все, що його хвилює – щоб інвойс генерився. Це менеджера, які називають людей ресурсами. І менеджер-чірлідер-бодігард (це добре). Це менеджер, який максимально старається мотивувати команду на роботу: що їх робота має значення, що вони важливі, і піклується про їх розвиток, а також захищає їх від зовнішніх процесів і старається розібратись з тим самотужки: розмова зі стейхолдерами, всяка бюрократія і вирішення операційки. Це менеджер, який розуміє, що він нічого не може зробити, і його успіх – це успіх команди. Кароче, вот це топовий менеджер 🙂

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

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

28. Якщо ви не отримуєте задоволення саме від програмування – то краще оберіть щось інше. Хтось з відомих писав: ми отримаємо так багато задоволення від програмування, що воно має бути признаним незаконним. Якщо в програмісти – то тільки так 🙂