Причини, чому немає перекладених книжок про українське ІТ — бо їх майже немає як такових.

Чому?

1. NDA. Більшість проєктів в аутсорсі — під NDA. Більшість проєктів в MilTech — під ще більшим NDA.

2. Більшість компаній (до останніх років) — це аутсорс. Де не будували «культури розробки». Продуктових компаній було мало. Українських продуктових компаній — ще менше. А людям цікаво читати про процеси чи інструменти тієї компанії, яку вони знають. А не якоїсь noname.

3. Продуктовій компанії були важливі книжки, що промоутять їх культуру для того, щоб заманити найкрутіших спеціалістів працювати над крутими проєктами. Які круті R&D проєкти міг запропонувати аутсорс? Дуже мало. Зараз промоутити культуру компанії через книжки навіть для MANGA не потрібно, бо кандидатів більш ніж достатньо. В аутсорсі також.

4. Навіщо писати ІТ книгу про evergreen теми українською, якщо можна написати англійською одразу? Ринок — одразу світовий. Але разом із тим, треба з книгою конкурувати з усім світом. Кого будуть вірогідніше читати — людину, як працювала на багатьох проєктах разом з Martin Fowler чи Math Pocock чи знову ж таки, не дуже відомого українця?

5. Читати книжку на evergreen тему цікаво від українського автора цікаво або через цікавий проєкт або через цікавий досвід автора. В нас зараз цікавий досвід зосереджений в MilTech. Колись щось про це й напишуть (але потім, коли секретність знімуть).

P.S. Хоча останнім часом бачу дуже багато професійної ІТ літератури від українських викладачів ВУЗів. Але це скоріш суто навчальна література.

Загалом — ідея цікава. Може й знадобитись. Але ...

Ще можна книги (чи дослідницькі роботи) не читати. Є сервіси, де можна послухати «головне» з книги за 10 хвилин. А потім ще й попросити ШІ згенерувати нотатки на основі «прочитаного».
А де тут людина. яка взнала щось нове та зінтегрувала порцію цього нового в свою палітру знань? Її нема. Є тільки «чиста» інформація.

P.S. Підхід, який описаний у пості може спрацювати. Для деякої категорії контенту.

Мені одному ця, та деякі інші статті з тестування, що я бачу останнім часом на ДОУ, виглядають як щось, згенероване ШІ (частково чи повністю)? Чи це мої упередження?

Дуже дякую за статтю.

Однак хочу відзначити, що поняття General QA існує тільки в контексті ринку праці в Україні.
В більшості західних компаній тестування, автоматизацію та й багато іншого очікують від людини з роллю QA Engineer / Test Engineer.

В еру розквіту аутсорс-компаній треба було багато різних спеціалістів — тому й видумували Manual QA Engineer, Automation QA Engineer, Java Developer, Python Developer, etc.

Ринок ІТ в західних продуктових компаніях (та й у нас потихеньку) давно прийшов до поняття інженера. Software Engineer — пише код (без прив’язки до технології чи мови програмування). QA Engineer — забезпечує якість продукту (усім можливими способами — не тільки автоматизацією чи тестуванням як таким).

Єдине розділення, яке існувало (умовне), — на фронт чи бек. Але зараз, особливо з приходом ШІ, всім буде потрібен фуллстек або ж той самий X Engineer, який зможе розібратися з усім та вирішити задачу бізнесу. Те саме є й буде надалі в світі тестування.

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

На ринку кандидата можна було просто робити круті речі та час від часу перевіряти скриньку в Linkedin на предмет цікавих пропозицій. (І то, якщо хотілося чогось рівня Big Tech — треба було грати по їх правилам).

Після 24.02.2022 український ринок різко став ринком работодавця + маємо скорочення АйТівців по всьому світу через ШІ.

Потрібно розрізняти побудову персонального бренду та нетворкінг. Ці речі повʼязані, але можна робити їх окремо.
— нетворкати можна в чатах, на конференціях та додаватись до рандомних людей в Linkedin. КПД від останнього варіанту вкрай невелике.
— персональний бренд можна будувати з ціллю працювати консультантом або показувати свої знання та таким чином розширювати свій нетворк.

Отримати роботу означає пройти наступні кроки:

— знайти потрібну вакансію
— подати адекватне резюме
— отримати запрошення на співбесіду
— пройти усі етапи співбесіди
— отримати оффер та прийняти умови

Щоб знайти вакансію треба або шерстити сайт з вакансіями АБО мати хороший нетворк та питати в людей напряму (навіть до публікації вакансії). В деяких випадках до вас самих будуть приходити люди та пропонувати цікаві проєкти. Теж через нетворк та те, що ви показуєте що можете. Якщо ви під NDA та мовчите — світ не дізнається про те, який ви крутий сіньйор. Ніяк. Хоч ви вдома переписали Linux за заплющеними очима за 2 години.

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

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

Нетворк також може дати вам тренування на тих же самих мок-інтервʼю чи правдиві історії співбесід в різні компанії. Можна запитати загальні речі, типу «на що звернути уваги, до чого готуватись».

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

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

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

Кожному треба самостійно визначити — які навички потрібні зараз та які навички потрібні будуть у майбутньому.

Можна ще на інші роадмапи подивитись
— roadmap.sh/prompt-engineering
— roadmap.sh/computer-science
— roadmap.sh/...​structures-and-algorithms
— roadmap.sh/system-design
— roadmap.sh/devops
— roadmap.sh/backend
— roadmap.sh/frontend

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

Парадокс наявності досвіду для першої роботи завжди був та й залишається. Незалежно від того чи є ШІ чи немає. Люди якось стають трейні та джунами весь цей час.

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

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

Якщо у людини в руках є молоток (LLM) то будь-яка задача виглядає, як To-Do List app.

Вивчати Rust зі старту це як вивчати C++ для автоматизації веб тестів на selenium. Звичайно можна, але буде дійсно боляче. Особливо — шукати роботу.

Хороша історія! Пару моментів:
1. Не треба починати з Rust. Javascript (Typescript) чи Python — найкращий варіант для початку.
2. При вивченні нового — закріплюйте знання на практиці. Робіть проєкти, навіть прості.
3. Повертайтеся до вивченого час від часу та перевіряйте свої знання.
4. Фундаментальні знання важливі. Але ще важливіше — отримати перші результати від написання коду (автотестів).
5. Час від часу перевіряйте свою «дорожну карту» — що ви вже знаєте, що вам ще треба вивчити та про що ви ще взагалі не чули. Різні комʼюніті чи ментори можуть допомогти таку карту скласти.

На ринку кандидата, особливо в часи тотального аутстаффу чи аутсорсу — можна й не знати ті «внутряки» й тд. Завчи «усі методи класу Object» та паттерни на памʼять — й пройдеш майже будь-яку співбесіду в Україні.

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

— В Обсідіані є купа плагінів, які додають багато функціональностей. Наприклад малювати схеми від руки (стилуса) в Excalidraw, або менеджети проєкти чи таски.
— Але можна легко зловити перегруз — налаштовувати плагіни замість того, щоб робити нотатки.
— Обсідіан «заточений» саме під zettelkasten підхід. Основна фішка — це звʼязування нотаток між собою. Але щоб отримати максимум користі — треба з самого початку правильно вести нотатки. Я поки не зміг усі свої нотатки перевести на цей підхід — бо перехід займає чимало часу.
— Теги не дуже працюють вдовгу — бо треба постійно тримати в голові усі наявні теги. А це — неможливо.
— Підхід PARA працює, можна навіть його модифікувати під себе.
— Таблиці в Обсідіан — це жах. Я всі свої трекери переніс з Обсідіан в Ноушн. Бо там — зручніше.
— Не всім до душі писати нотатки в markdown.

Я чесно намагався використовувати Обсідіан замість усіх інструментів, але це не зручно. Наразі це звʼязка Obsidian + Notion + TickTick.

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

cardano-wallet — не такий великий проєкт. Але раджу подивитись на cardano-node — повністю на Haskell, з першого дня. Навіть смарт контракти на Haskell-like мові програмування — Plutus.

Ну це поступово напрацьовується. Не після одного відео, але можливо. Так само визнання чи бренд не формується лишень після однієї статті.

Частково я, звичайно, згоден з Вашими коментарями. Але.

Визнання — доволі розмите поняття. Нащо воно рядовому айтівцю?

Щодо роботодавців — їх цікавлять не вміння писати статті, а вміння досягати конкретних вимірюваних результатів. (Донесення інформації, навчання — це своєрідний бонус від співробітника. Особливо, коли це якийсь devrel).

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

Курс чи вебінар — дає монетизацію. Перегляди на ютубі — дають монетизацію.
Бейджик на форумі — чи дає він щось, крім закритого гештальту «написати статтю на ДОУ»?

Щоб люди самостійно хотіли писати якісні статті — треба формувати якісне «підтримуюче» комʼюніті людей. Де можна отримати конструктивний фідбек. А таку спільноту формувати дуже складно та займає багато часу й зусиль.

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

А за технічним контентом треба полювати деінде.