«Погано написаний код — не завжди проблема». 28 мудростей від програміста-блогера Діми Малєєва

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. Напевно, найбільша проблема, коли наймаєш аутсорс-партнера — саме програмісти

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

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

28. Якщо ви не отримуєте задоволення саме від програмування — то краще оберіть щось інше.

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

 Якщо в програмісти — то тільки так.

«Дуже багато речей і в армії потребують програмістів. Ми нескоро втратимо роботу». Сповідь мобілізованого розробника про навчання, їжу, настрій та цінності в ЗСУ

По темi

«Дуже багато речей і в армії потребують програмістів. Ми нескоро втратимо роботу». Сповідь мобілізованого розробника про навчання, їжу, настрій та цінності в ЗСУ

В українських школах оновлять викладання та програму предмета «Інформатика». Вже шукають викладачів

По темi

В українських школах оновлять викладання та програму предмета «Інформатика». Вже шукають викладачів

До 21 000 злотих та на 47% більше вакансій, ніж торік. Як змінилися заробітки програмістів у Польщі

По темi

До 21 000 злотих та на 47% більше вакансій, ніж торік. Як змінилися заробітки програмістів у Польщі

dev.ua запускає джобборд з акційною пропозицією для IT-роботодавців

Надсилайте вакансії