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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте розрізняти дві речі — «в ПОТОЧНІЙ роботі треба було швидко задевопсити, підпилити фронтенд (хоча я бекендер), дописати трохи в бекенд (хоча я фронтендер) — то ж я зробив це легко» та «шукають людину під конкретну роботу з конкретним досвідом». В першому випадку минулий досвід може бути плюсом. В другому випадку — колись шось трохи писав — може бути недостатнім. Треба конкретні глибокі пізнання та досвід.

Має ще купу прикладів коли повертався до роботи з чимось десь через 5 років.

Але тут питання в тому, щоб зацікавити рекрутера + інтервʼюера саме ВАМИ. Якщо буде два резюме, в одному сіньйор бекенджер на JS, а в іншому — на інших технологій (але десь колись шупав Next.JS) — то на перший погляд запросять на співбесіду першого. Який би другий не був крутецький.

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

Інтерв’юер, що цікавиться минулим досвідом — це вже проблема.

Задача інтервʼюера якраз зрозуміти знання + досвід людини. Бо теоретично можна вивчити усі модні актуальні питання та відповідати на них. А практичного досвіду може й не буде.

Загалом я згоден, що підходи майже не змінюються. Але змінюються технології, фреймворки та бібліотеки. Досвідчений інженер авжеж розбереться з усім новим. Бо є фундамент. Але це, нажаль, рідко який рекрутер розуміє. Тому й наймають в нас часто (не завжди) людей тільки за конкретними ключовими словами та з питаннями типу «назвіть по памʼяті всі методи класу Object!»

Пишіть так, щоб вами зацікавились конкретні люди в конкретній компанії. Інакше — резюме просто потоне серед сотень інших.

“Implemented automated tests using C# and Selenium Webdriver” vs “Increased end-to-end UI test coverage for large-scale web application by 90%” vs “Improved time-to-market of software delivery from 5 days to 3 hours by integrating automated UI tests”. Пишіть так, щоб було за що зачепитись, щоб привернути увагу.

Коротко.

Резюме повинно «продавати» Вас для конкретної вакансії.
Рекрутеру та інтервʼюеру цікавий насамперед Ваш релевантний досвід.
Не треба писати усе можливе, що Ви робили.
Не треба писати технологію, яку Ви останній раз бачили 5-10 років тому. Знання та навички ЗАБУВАЮТЬСЯ й ржавіють, якщо їх не практикувати.

Таким чином, дуже рідко коли кожен елемент Вашого різнобарвного досвіду буде цікавий під вакансію. Тому зазвичай 1- 2 сторінки це максимум.

Усі резюме на 3+ сторінок, які я бачив мали просто купу копіпасти на кшталт «тестував тести, заводив баги, писав код». Це — «червоний прапірець» та збільшує ймовірність отримати відмову чи навіть ігнор.

Єдине, що можу тут доповнити.

Я поки не бачив прямої кореляції між «пишеш статті чи ведеш канал => отримуєш цікаві офери та круті проєкти». Те саме із виступами на конференціях, подкастами і тд) Але я роблю то, тому що мені подобається ділиться знаннями.

Те, що у статті 500 переглядів, не означає, що усі 500 прочитали статтю. Не означає, що усі зрозуміли статтю, не означає, що усі подивились — хто ж автор статті. Тим паче — не означає, що вони запамʼятали щось про вас. Це просто чергова «стаття на DOU».

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

Бачу декілька причини чому люди не пишуть статті.
1. Немає часу. Треба витратити багато часу щоб написати дійсно цікаву авторську статтю — навести приклади, результати своїх досліджень. Плюс треба вміти це вміло подати. Так — щоб людям було дійсно цікаво то читати. (Для цього треба попередньо навчатись).
2. Не можна ділитись інформацією через NDA. А писати щось «схоже» займає багато часу.
3. Майже немає зворотнього звʼязку. Один з мотиваторів для написання статті — це отримати цікавий конструктивний зворотній звʼязок, подискутувати, прийти до якихось нових ідей. З того, що я бачив — коментарів дуже мало. Тобто зворотнього звʼязку майже нема. А що, так коментарі в стилі «тю, так це ж очевидно» чи подібні їм.
4. Для персонального бренду краще підходять канали в Телеграм, персональні блоги, реддіт, відео на ютубі. Там ви будуєте саме «свою» аудиторію, якій цікаві саме ви. Та у якої є очікування від Вас. Я, наприклад, не можу пригадати жодної людини, статті якої я б приходив читати саме на DOU.
5. Технічні статті майже завжди губляться на фоні «гарячих тем». Як не сири, так релокація. Як не релокація, так чергові «зміни в податковій системі». Саме для таких статей люди насамперед йдуть сюди. Це не погано. Це — факт.
6. Немає інших мотиваторів — наприклад грошових. Так, в такому випадку модерація може бути жорсткішою, але є хоча б мотивація отримати гроші за витрачений час.

Загалом. DOU — класне місце айтівців щоб обговорити важливі соціальні питання та проблеми. Або — порадіти за досягнення інших (з якогось інтервʼю).

«Ми одна родина» може бути, можливо, тільки якщо у вас багато опціонів компанії (але й не факт). Все інше — просто бізнес. Сьогодні ви треба, завтра — може ні.

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

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

А як відрізнити фахівців від інфоциган?

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

Про освіту vs самостійне навчання.

Є такий собі Scott H Young. Він якось придумав та виконав MIT Challenge — пройшов 4-річну програму MIT з Computer Science за рік. Здав екзамени. Він зараз працює в Google чи NASA? Ні, написав книгу про те, як вчитися :). Та він показав, що таке навчання можливе — причому онлайн.

В Україні є різні ВУЗи, з різним рівнем підготовки кадрів та програмами навчання. Можливо десь програми актуальні — та можна вчитись.

З іншого боку — зараз дійсно дуже багато матеріалів для навчання . Але є декілька але.

— Для самостійного навчання треба система. Треба знати що вчити, де знайти необхідні знання.
— Для самостійного навчання треба «залізна дупця». Тобто мати офігенну мотивацію кожного дня після роботи вчити те, що треба та робити це ефективно. Просто «пописати код для фану» чи «подивитись відосик» не пройде — бо таким чином навчання може тривати десятками років без видимого успіху.
— Для самостійного навчання треба якісний зворотній звʼязок.
— Для самостійного навчання треба якісна практика. Однотипні учбові проєкти будуть корисними лише на початку.
— Для самостійного навчання треба вміти копати вглиб. Зазвичай — самому. Бо хороших курсів навіть для середнього рівня зараз дуже мало. В 99% відсотках — будуть навчати однотипним типовим проєктам, які через пару років кожен другий ШІ зможе наваяти за 3.5 секунди.
— Для самостійного навчання краще було б непогано знати англійську мову. Бо варіантів курсів, книжок та статей для навчання стає в рази більше.

Висновок.

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

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

P.S. Маючи перегрітий ринок праці із тисячами резюме на одну вакансію джуна — кого розгляне роботодавець — людину з IT факультету чи випускника noname 3-місячних курсів, яких вже сотні тисяч? (Розгляне != візьме на роботу)