Про нові або фундаментальні знання. Дуже корисно приділити 5-10 хвилин вивченню історії технології. Відповідь на витання "Навіщо це створили?" та "Що було не так із уже існуючими штуками?" дуже допомагає розібратись, як речі працюють. Ось це "Для чого?" часто дає змогу швидше зрозуміти, що це таке в документації описано чи навіщо мені про щось там на відео розповідають. Це як із тасками: спочатку "Навіщо нам це робити?" і "Що ми хочемо отримати?", а потім вже "То як же нам цього досягти?"
Подобається ваш підхід і погляди на навчання. Це що, що я підсвідомо розумів, але ви це виразили вербально і підсумували мені замість мене. Дуже дякую за працю.
Гарна метафора. Цікаво теж почути: - які знання ти вважаєш фундаментальними? (стовбур дерева) - які знання ти вважаєш непотрібними? (які здебільшого витрачають твій час та засмічують голову)
Дякую. Гарне питання про непотрібні знання. Є знання, які дають нам розуміння чогось (наприклад, як працює інтернет), а є знання, які потрібні на короткий час для виконання якоїсь задачі (сігнатури методів React компонентів). Й друге можна забувати сміливо, коли його не користуєш, але це не те, що є витратою часу (все ж таки це підвищує продуктивність на період виконання задачі). А так щоб щось, що "зайва витрата часу", то на моєму досвіді й не згадаю такого (можливо у тебе є приклади). Тут скоріше питання пріоритетів - на що "краще" витратити час в умовах його обмеженності. PS: Про стовбур відписав якраз іншому коментарі
@@AboutProgramming Дякую, так, тут скоріше про менш потрібні знання, аніж про зовсім непотрібні. Хоча прикладом може послугувати вивчення сігнатур реакту, коли ти з ним навіть не працюєш) P.S. Та відповідь з переліком виглядає вже як майже готовий пост в тг-канал)
так це ж суб`єктивно... на колір і смак...... мені, наприклад, абсолютно нецікаве водіння авто... тим більше ремонт... вони якось їздять, хтось у цьому розбирається - і добре )
Дякую Віктор за досвід та метафору щодо розвитку інженерів в глибину. Дуже сподобався мультик, який яскраво демонструє різницю олдскульного професіонала і адепта нових технологій, котрий в них розбирається дуже поверхнево і сліпо вірить рекламі )
з приводу того як можна краще запам'ятовувати інформацію, я вважаю що треба практикувати так би мовити активне читання тобто не просто читати, а працювати з інформацією. наприклад робити нотатки. я особисто почала вести свій технічний блог
Я люблю книги читати, бо там часто більш системно й повно розглядається проблема. Про бібліотеки й фреймворки не читав книги, але в планах є почитати книгу про Angular 🙂
Ну все, можна починати курс малювання дерев 😁 Насправді вельми корисні поради даєте, без міцного фундаменту не побудуєш надійний будинок... Однак, як початківцю легко відфільтрувати потрібні знання від тимчасових віяній?
Було б круто зробити відео на прикладі OSI Model з вашими коментарями - як працює веб і наш код на клієнті та сервері спілкується в розрізі OSI Model. Або просто про OSI layers
Дякую за відео, певно єдиний канал, на якому я дивлюсь всі відео відразу як вони виходять 😅 Було б круто якби ви навели конкретний приклад технології і те, як можна з неї збудувати повноцінну гілку з листями, яка буде міцно триматись на дереві Наприклад бази данних - і далі приклад літератури і матеріалів, який потрібен для того, щоб сформувати повноцінну "гілку"на цю тематику
Дякую :) Є ідея зробити декілька відео на схожу тематику в майбутньому (й про бази даних й з рекомендаціями по літературі). Але з найближчого - на наступному тижні планую відео з демонстрацією еффекту від розуміння базових алгоритмів й алгоритмічної складності (й буде трохи про бази)
Дякую за круті відео. Є питання. У багатьох компаніях де я працював стикаюсь з одним і тим же. Це нерозуміння використання паттернів, SOLID,… є компанії де навіть якісь правила є. Але все одно біда таж сама: «Краще зробити ще один if-чик ніж використати стратегію» чи «краще написати все в одній функції, бо бігати по класам то не зручно» і коли код збільшуються всі бачать ту какашку, але роблять знов такуж помилку зі словами «та воно точно не буде розширюватись» і знов і знову… питання в тому - як зробити, як продати правила команді, якщо вона наче не проти, але не бачить користі і знов пише функцію з логікою запуску ракети ?
Дуже гарне запитання. Колись у мене був цікавий випадок. Я написав невелку апку з віджетами й віджети були в окремому файлі. Сумарно займали 100 строк. Приходжу через півроку на проект, а там щось типу 10 тис строк в одному файлі й усюди if, величезні функції й так далі. Й мені кажуть "ну, ми робили по аналогії все". Й основна проблема, це не стільки не слідування якимось ідеям з самого початку, а не готовність міняти структуру, коли це треба. Й колись почув гарну фразу: "якщо ви просто пишете код, то ви вже накопичуєте технічний борг". Тобто щось, що має гарну архітектуру на малому масштабі, при додаванні коду, вже вимагає переписування, бо змінюється масштаб й умови. "воно не будет розширюватись" чув таке багато разів й багато разів було разширення й зміна реалізації й команда потім була вдячна, що зробили правильно. Але тут треба теж обережно, щоб не переускладнити те, що реально не буде розширюватися, бо зустрічав й випадки значного оверінженіренгу. Й виникає питання балансу. Й тут я би виділив 2 речі: 1. Оцінка ризиків й затрат на їх перекриття. 2. Писати код, який легко змінити. Тобто, якщо у нас зараз одна "стратегія," то нам й не потрібна прям повноцінна абстракція під це. Може бути єдина імплементація в одном класі, але писати так, щоб деталі реалізаії не протікали й організуваувати кода так, щом можна було зробити рефакторинг й винести стратегію окремо, наприклад. Часто якісний код не вимагає більше часу, але вимагає білше досвіду. Це як задачу з математики - її можна вирішити правильно й не правильно. Але час на правильне рішення приблизно такий самий. Й останній аспект, який важливіший ніж паттерни це coupling та cohesion. Якщо думати про це, то код завжди виходить якіснішим. На це треба явно робити окремо відео, бо можна багато цікавих прикладів навести)
@@AboutProgramming дякую, крута відповідь. Та є невеличке уточнення, коли команда змішана (тобто є багато реп і кожен працює з усіма) і коли ти щось зробив, як у вашому випадку про 100 строк, а повертаєшся чи навіть бачиш PR, у якому все написано "по простому" і так що SOLID десь відпочиває, то єдине що можна робити з тим PR - або закрити очі, або написати "перероби все". Скорше за все буде відповідь "треба вводити стандарти", але то така штука, що вимагає принципу "code first" і бажання з боку лідів, менеджерів, я думаю то не секрет що 99% працює по "business first" та бажанням менеджерів робити кількісно. Я також працюю з node.js і інколи продати перехід з 12 ноди - складно, лише коли якийсь aws lambda - заборонить цю версію. То як можна продати покращення? Як менеджерам, які ставлять бізнес попереду, як команді яка не бачить у тому реальних крутих змін і як деву, який зробив PR і просто ліньки переробити у щось якісне і переводить прохання покращити у халівар?
@@sergbs питання, скільки будуть бізнесу коштувати міграції й оновлення пізніше. Також питання, скільки буде коштувати підтримка коду. Тобто технічний борг накомпичується й можливо має сенс його менеджерити явно - тікети в системі, щоб була видно чи критична ситуація чи ні. Також кількість багів зазвичай зростає й швидкість додавання нових фіч падає й це вже для бізнес-орієнтованих менеджерів важливо. Але це вимагає від усіх наявність певного досвіду, щоб розуміти наслідки тих чи інших рішень. Зазвичай повне ігонорування якості коду менеджерми свідчить про їх недосвідченість або специфічність досвіду (робили тільки прототипи, або робили тільки на базі готових систем, де вже була правильна архітектура й тд). Що працює - це намагатися зрозуміти аргументацію й приорітети менеджера й говорити з ним на його мові. Й також доности приорітети й мотивацію команди. Наприклад, "на легасі код складніше найняти розробників" це вже бізнес аргуент
@@AboutProgramming знову дякую за круту відповідь. Насправді коли "code smells" і ти кажеш про те менеджеру - йому ок трохи щось покращити, але коли ти кажеш що ми вже декілька років робимо не так з аргументами і треба просто зробити з 0, про таке навіть слухати не хочуть.
Так, велику частину дерева (й не тільки стовбур) можна отримати з профільної освіти. Але можна й з курсів, книжок, Ютуб відео й тд. Тут головне питання, як ці знання подавати/споживати, щоб вони одне за одного чиплялися
З точки зору технологій, то є база, яка не залежить від мови програмування й дозволяє багато речей між собою поєднати: * Як працює операційна система * Як працює інтернет й мережі * Як працюють бази даних * Розуміння базових алгоритмів й структур даних * Архітектера й проектування, паттерни/підходи й антипатерни, вміння працювати з абстракціями. * Безпека * Розуміння, як працюють компілятори й рантайми Але все це не тільки в теорії, а й в контексті реальних систем. Звучить банально, але це фундамент, який дозволяє легше розуміти вже більш складні й специфічні речі. Думаю, що по кожному пункту буде не одне відео на каналі :)
Виходячи з комменту, на скільки я зрозумів це дуже схоже на CS программу, тільки порядок трохи інший, я правий? @@AboutProgramming що Ви думаєте о CS в цілому, чи варто шукати якісь программи (якщо немає змоги, наприклад, вчитись в Стенфорді)? Може Ви створювали/зустрічали якісь гарні программи?
@@mrart5498 порядок може бути будь-який, але так - це такий собі зовсім базовий CS, але бажано, щоб це була не зовсім теорія, а й практичні навички, тоді воно краще все клеїться в одну систему. Відносно комплексної CS програми, то складно щось порадити, а відносно окремо кожного пункт достатньо по 1-3 книжці. Зроблю огляд книг на каналі
@@AboutProgramming на скільки я зрозумів всі дуже чекують книг :) як на мене, трохи важко без програми йти, типу коли є лист в якому бачишь, що за чим + якась домашка = просто топ, але, мабуть, в тому і є одна із основних цінностей вищої освіти в топах.
Щоб глибоко розбиратись, наприклад, в якихось бібліотеках потрібно прочитати соурси. А як навчитися читати чужий код? Які поради, чи правильні підходи? Може, якісь наставлення з вашого досвіду.
Якщо бібліотека відома (наприклад, React), то часто багато всього в документації й сторонніх постах. Я зазвичай лізу в код, коли треба зрозуміти, як працює якійсь конкретний аспект в деталях. Тобто код набагато легше читати, якщо стоїть конкретне питання як щось реалізовано. Наприклад, я так читав соурси open office, gnumeric, POI, коли хотів зрозуміти, як імплементовані функції електронних таблиць. Якщо бібліотека маленька, то я часто дивлюся в код, щоб зрозуміти наскільки якісно вона написана. Там вже просто впирається в досвід
що ви думаєте про те, що навіть якщо ми щось читаємо і забуваємо, то те прочитане стає новим досвідом сприйняття інформації. коли ти прочитав щось базове і зрозумів, це тобі дає сходинку для читання щось складнішого або навіть іншого, що скоріше ти зрозумієш з більшим рівнем осмисленості ніж без читання.
@@AboutProgramming 'забуваємо' і 'накопичується' - хіба не протиріччя у ваших словах ? 😊 якщо знання мають фізичний еквівалент - значить мають вагу... поступово організм переповнюється (інтуітивними) знаннями, і нові вже не сприймаються 🤨
так... дерево знань... трохи поколупаюся у словах 🤔 --------------------------- дерево - це рослина, рослини вивчає Ботаніка (розділ Біології) дерево - це рослина, яка має надземну частину, і підземну частину (коріння) Живлення рослин... з одного боку надходить сонячне світло, фотосинтез в листях... з іншого боку - з коріння всмоктуються водні розчини мінеральних солей... ------------------- А шо це таке на малюнку? Ну... без коріння є водорослі... це наче рослина, живиться світлом, але живе у воді... Або на малюнку - неживе дерево... дрова тобто... Якось так 😊
@@AboutProgramming пробував удосконалити цю метафору... ось що вийшло... сонячне світло - це мотивація... гроші, визнання... листя - це оперативна інформація, поточні справи... структура дерева - це архітектура комп`ютера, чи іншого пристрою... 'залізо'... (може бути не обов`язково дерево, а кущ... чи трава... і т.д.) програми - це ті поживні речовини, які рухаються всередині гілок і коріння живого дерева... там усякі фітогормони... несуть якусь інформацію... багато там всього... не знаю точно ---------------- як це працює... приміром, зима... сонця менше... метафорично це буде означати - менше мотивації, грошей.. руху менше, програми не хочуть розроблятися усе... на сьогодні мозковий штурм закінчився )
Красива аналогія дерева знань, але коріння та стовбур так само можуть зникнути, якщо то не використовувати. Можливо у наступному відео з прикладами буде більш зрозуміло як ті фундаментальні знання підтримувати. Ідеально мати роботу, де фундаментальні знання важливі, але як наприклад підтримувати актуальність знань про нутрощі якогось протоколу, коли всі задачі на роботі зводяться до підтримки чергової тікетінг системи так і не зрозуміло.
Дуже гарне зауваження. Але зазвичай стовбур залишається, бо від нього багато залежить й якщо постійно вчити щось нове, то доводиться через стовбур й великі гілки пов'язувати нові знання з вже існуючими. Тобто вивчення нового вимагає повторення базових речей й тому вони тримаються в голові. Так, деталі протоколу забудуться, але якщо від знань протоколу будуть залежати інші знання, то тоді це працює краще. Ну й практика допомогає
Мій викладач з електроніки в універі казав, що складні системи мають багато відмінностей. Важко представити складну систему, в якій би не було б недоліків.
Будь-яка система, яка є ефективною має йти на компроміси, бо покращення одних властивостей вимагає погіршення інших. Тому зазвичай немає ідеальної універсальної системи, але є системи, які гарно вирішують певну задачу
@@AboutProgramming про ланцюжок: від процесів замовника - формулювання задачі звичайною мовою - потім у вигляді блок-схем, алгоритмів - потім написання програми... якщо буде настрій - може зробите відео, щоб був зрозуміліший весь процес )
@@AboutProgramming в мене таке враження, шо зараз усі заходять в ІТ з боку вивчення мови програмування... а вже потім шукають завдання... може краще заходити з боку бізнес-процесів, від реальних ситуацій, які потребують покращення... і вже далі робити програму, як інструмент вирішення конкретної проблеми 🤔
Взагалі не розумію про що ви говорите, коли вдаєтесь до конкретних кейсів. Але не треба бути професійним кухарем, щоб зрозуміти, що страву приготував майстер, який знається в тому, що він робить.
може трохи відпиляйте спинку крісла... бо весь час таке враження, що у вас довге волосся... чи то спинка крісла така... чи довге волосся... ну і шо... чи то спинка крісла така... так, а про що ж він говорив 🤔
Про нові або фундаментальні знання. Дуже корисно приділити 5-10 хвилин вивченню історії технології. Відповідь на витання "Навіщо це створили?" та "Що було не так із уже існуючими штуками?" дуже допомагає розібратись, як речі працюють. Ось це "Для чого?" часто дає змогу швидше зрозуміти, що це таке в документації описано чи навіщо мені про щось там на відео розповідають. Це як із тасками: спочатку "Навіщо нам це робити?" і "Що ми хочемо отримати?", а потім вже "То як же нам цього досягти?"
Learning How To Learn - гарний курс, який показує як щось вивчити і не забути
Так, проходив його - корисний курс. Й ще є книги від авторки курсу (Барбари Оаклі) про те, як правильно вчитися - теж можна їх рекомендувати
дуже сподобалався підхід та мислення про набування нових знань, дякую
Подобається ваш підхід і погляди на навчання. Це що, що я підсвідомо розумів, але ви це виразили вербально і підсумували мені замість мене. Дуже дякую за працю.
Те що має бути почуте - обовʼязково буде кимось сказано.
Дякую вам.
Гарне порівняння з деревом, гілками та листями. Дякую за відео
коли сказав знання як дерево, я собі в голові зовсім інше дерево уявив😂 профдеформація вона така)
А про яке дерево подумав? Як структуру даних?🙂
Найс байт на коммент)@@AboutProgramming
Дякую за відео! Було корисно отримати пораду до загального підходу до навчання.
Концепція з деревом дуже крута
Дякую за відео!
Круто, аналогія з деревом фантастична
Гарна метафора. Цікаво теж почути:
- які знання ти вважаєш фундаментальними? (стовбур дерева)
- які знання ти вважаєш непотрібними? (які здебільшого витрачають твій час та засмічують голову)
Дякую. Гарне питання про непотрібні знання. Є знання, які дають нам розуміння чогось (наприклад, як працює інтернет), а є знання, які потрібні на короткий час для виконання якоїсь задачі (сігнатури методів React компонентів). Й друге можна забувати сміливо, коли його не користуєш, але це не те, що є витратою часу (все ж таки це підвищує продуктивність на період виконання задачі). А так щоб щось, що "зайва витрата часу", то на моєму досвіді й не згадаю такого (можливо у тебе є приклади). Тут скоріше питання пріоритетів - на що "краще" витратити час в умовах його обмеженності.
PS: Про стовбур відписав якраз іншому коментарі
@@AboutProgramming Дякую, так, тут скоріше про менш потрібні знання, аніж про зовсім непотрібні. Хоча прикладом може послугувати вивчення сігнатур реакту, коли ти з ним навіть не працюєш)
P.S. Та відповідь з переліком виглядає вже як майже готовий пост в тг-канал)
так це ж суб`єктивно... на колір і смак......
мені, наприклад, абсолютно нецікаве водіння авто... тим більше ремонт...
вони якось їздять, хтось у цьому розбирається - і добре )
Дякую Віктор за досвід та метафору щодо розвитку інженерів в глибину. Дуже сподобався мультик, який яскраво демонструє різницю олдскульного професіонала і адепта нових технологій, котрий в них розбирається дуже поверхнево і сліпо вірить рекламі )
Мультику вже багато років, а актуальності він не втрачає :)
Супер, лайк, коментар, підписка.
найс пушка
дуже змістовно
Файні метафори. Давайте більше подібних відео! :)
з приводу того як можна краще запам'ятовувати інформацію, я вважаю що треба практикувати так би мовити активне читання тобто не просто читати, а працювати з інформацією. наприклад робити нотатки. я особисто почала вести свій технічний блог
ну і як - є зворотній зв`язок?
може ви просто тиражуєте нікому не потрібну інформацію? 🤔
❤❤❤❤❤❤❤❤
Клас
Дякую за відео
клас дуже дкую))
👍👍👍👍
Обома руками за👍🏻 не читав жодної книжки про фреймворки або бібліотеки. Чим більш абстрактно тим краще
Я люблю книги читати, бо там часто більш системно й повно розглядається проблема. Про бібліотеки й фреймворки не читав книги, але в планах є почитати книгу про Angular 🙂
Ну все, можна починати курс малювання дерев 😁
Насправді вельми корисні поради даєте, без міцного фундаменту не побудуєш надійний будинок... Однак, як початківцю легко відфільтрувати потрібні знання від тимчасових віяній?
Було б круто зробити відео на прикладі OSI Model з вашими коментарями - як працює веб і наш код на клієнті та сервері спілкується в розрізі OSI Model. Або просто про OSI layers
Дякую за відео, певно єдиний канал, на якому я дивлюсь всі відео відразу як вони виходять 😅
Було б круто якби ви навели конкретний приклад технології і те, як можна з неї збудувати повноцінну гілку з листями, яка буде міцно триматись на дереві
Наприклад бази данних - і далі приклад літератури і матеріалів, який потрібен для того, щоб сформувати повноцінну "гілку"на цю тематику
Дякую :) Є ідея зробити декілька відео на схожу тематику в майбутньому (й про бази даних й з рекомендаціями по літературі). Але з найближчого - на наступному тижні планую відео з демонстрацією еффекту від розуміння базових алгоритмів й алгоритмічної складності (й буде трохи про бази)
Дякую за круті відео. Є питання. У багатьох компаніях де я працював стикаюсь з одним і тим же. Це нерозуміння використання паттернів, SOLID,… є компанії де навіть якісь правила є. Але все одно біда таж сама: «Краще зробити ще один if-чик ніж використати стратегію» чи «краще написати все в одній функції, бо бігати по класам то не зручно» і коли код збільшуються всі бачать ту какашку, але роблять знов такуж помилку зі словами «та воно точно не буде розширюватись» і знов і знову… питання в тому - як зробити, як продати правила команді, якщо вона наче не проти, але не бачить користі і знов пише функцію з логікою запуску ракети ?
Дуже гарне запитання. Колись у мене був цікавий випадок. Я написав невелку апку з віджетами й віджети були в окремому файлі. Сумарно займали 100 строк. Приходжу через півроку на проект, а там щось типу 10 тис строк в одному файлі й усюди if, величезні функції й так далі. Й мені кажуть "ну, ми робили по аналогії все". Й основна проблема, це не стільки не слідування якимось ідеям з самого початку, а не готовність міняти структуру, коли це треба. Й колись почув гарну фразу: "якщо ви просто пишете код, то ви вже накопичуєте технічний борг". Тобто щось, що має гарну архітектуру на малому масштабі, при додаванні коду, вже вимагає переписування, бо змінюється масштаб й умови.
"воно не будет розширюватись" чув таке багато разів й багато разів було разширення й зміна реалізації й команда потім була вдячна, що зробили правильно. Але тут треба теж обережно, щоб не переускладнити те, що реально не буде розширюватися, бо зустрічав й випадки значного оверінженіренгу.
Й виникає питання балансу. Й тут я би виділив 2 речі:
1. Оцінка ризиків й затрат на їх перекриття.
2. Писати код, який легко змінити. Тобто, якщо у нас зараз одна "стратегія," то нам й не потрібна прям повноцінна абстракція під це. Може бути єдина імплементація в одном класі, але писати так, щоб деталі реалізаії не протікали й організуваувати кода так, щом можна було зробити рефакторинг й винести стратегію окремо, наприклад.
Часто якісний код не вимагає більше часу, але вимагає білше досвіду. Це як задачу з математики - її можна вирішити правильно й не правильно. Але час на правильне рішення приблизно такий самий.
Й останній аспект, який важливіший ніж паттерни це coupling та cohesion. Якщо думати про це, то код завжди виходить якіснішим. На це треба явно робити окремо відео, бо можна багато цікавих прикладів навести)
@@AboutProgramming дякую, крута відповідь. Та є невеличке уточнення, коли команда змішана (тобто є багато реп і кожен працює з усіма) і коли ти щось зробив, як у вашому випадку про 100 строк, а повертаєшся чи навіть бачиш PR, у якому все написано "по простому" і так що SOLID десь відпочиває, то єдине що можна робити з тим PR - або закрити очі, або написати "перероби все".
Скорше за все буде відповідь "треба вводити стандарти", але то така штука, що вимагає принципу "code first" і бажання з боку лідів, менеджерів, я думаю то не секрет що 99% працює по "business first" та бажанням менеджерів робити кількісно.
Я також працюю з node.js і інколи продати перехід з 12 ноди - складно, лише коли якийсь aws lambda - заборонить цю версію.
То як можна продати покращення?
Як менеджерам, які ставлять бізнес попереду, як команді яка не бачить у тому реальних крутих змін і як деву, який зробив PR і просто ліньки переробити у щось якісне і переводить прохання покращити у халівар?
@@sergbs питання, скільки будуть бізнесу коштувати міграції й оновлення пізніше. Також питання, скільки буде коштувати підтримка коду. Тобто технічний борг накомпичується й можливо має сенс його менеджерити явно - тікети в системі, щоб була видно чи критична ситуація чи ні. Також кількість багів зазвичай зростає й швидкість додавання нових фіч падає й це вже для бізнес-орієнтованих менеджерів важливо. Але це вимагає від усіх наявність певного досвіду, щоб розуміти наслідки тих чи інших рішень. Зазвичай повне ігонорування якості коду менеджерми свідчить про їх недосвідченість або специфічність досвіду (робили тільки прототипи, або робили тільки на базі готових систем, де вже була правильна архітектура й тд). Що працює - це намагатися зрозуміти аргументацію й приорітети менеджера й говорити з ним на його мові. Й також доности приорітети й мотивацію команди. Наприклад, "на легасі код складніше найняти розробників" це вже бізнес аргуент
@@AboutProgramming знову дякую за круту відповідь. Насправді коли "code smells" і ти кажеш про те менеджеру - йому ок трохи щось покращити, але коли ти кажеш що ми вже декілька років робимо не так з аргументами і треба просто зробити з 0, про таке навіть слухати не хочуть.
Базовий стовбур це якраз профільна освіта
Так, велику частину дерева (й не тільки стовбур) можна отримати з профільної освіти. Але можна й з курсів, книжок, Ютуб відео й тд. Тут головне питання, як ці знання подавати/споживати, щоб вони одне за одного чиплялися
@@AboutProgramming Погоджуюсь
@@AboutProgramming
без мотивації нічого не буде...
нічого не сприймається, або швидко забувається...
з мотивацією знання засвоюються миттєво...
Дякую, дуже цікаве відео!
Віктор, щоб Ви розглядали як стовп у програмуванні і його найбільші гілки?
З точки зору технологій, то є база, яка не залежить від мови програмування й дозволяє багато речей між собою поєднати:
* Як працює операційна система
* Як працює інтернет й мережі
* Як працюють бази даних
* Розуміння базових алгоритмів й структур даних
* Архітектера й проектування, паттерни/підходи й антипатерни, вміння працювати з абстракціями.
* Безпека
* Розуміння, як працюють компілятори й рантайми
Але все це не тільки в теорії, а й в контексті реальних систем.
Звучить банально, але це фундамент, який дозволяє легше розуміти вже більш складні й специфічні речі. Думаю, що по кожному пункту буде не одне відео на каналі :)
Виходячи з комменту, на скільки я зрозумів це дуже схоже на CS программу, тільки порядок трохи інший, я правий?
@@AboutProgramming що Ви думаєте о CS в цілому, чи варто шукати якісь программи (якщо немає змоги, наприклад, вчитись в Стенфорді)? Може Ви створювали/зустрічали якісь гарні программи?
@@mrart5498 порядок може бути будь-який, але так - це такий собі зовсім базовий CS, але бажано, щоб це була не зовсім теорія, а й практичні навички, тоді воно краще все клеїться в одну систему. Відносно комплексної CS програми, то складно щось порадити, а відносно окремо кожного пункт достатньо по 1-3 книжці. Зроблю огляд книг на каналі
@@AboutProgramming на скільки я зрозумів всі дуже чекують книг :)
як на мене, трохи важко без програми йти, типу коли є лист в якому бачишь, що за чим + якась домашка = просто топ, але, мабуть, в тому і є одна із основних цінностей вищої освіти в топах.
Щоб глибоко розбиратись, наприклад, в якихось бібліотеках потрібно прочитати соурси.
А як навчитися читати чужий код? Які поради, чи правильні підходи? Може, якісь наставлення з вашого досвіду.
Якщо бібліотека відома (наприклад, React), то часто багато всього в документації й сторонніх постах. Я зазвичай лізу в код, коли треба зрозуміти, як працює якійсь конкретний аспект в деталях. Тобто код набагато легше читати, якщо стоїть конкретне питання як щось реалізовано. Наприклад, я так читав соурси open office, gnumeric, POI, коли хотів зрозуміти, як імплементовані функції електронних таблиць. Якщо бібліотека маленька, то я часто дивлюся в код, щоб зрозуміти наскільки якісно вона написана. Там вже просто впирається в досвід
що ви думаєте про те, що навіть якщо ми щось читаємо і забуваємо, то те прочитане стає новим досвідом сприйняття інформації. коли ти прочитав щось базове і зрозумів, це тобі дає сходинку для читання щось складнішого або навіть іншого, що скоріше ти зрозумієш з більшим рівнем осмисленості ніж без читання.
Якщо навіть ми щось забуваємо, то це накопичується й стає інтуїцією
@@AboutProgramming так. будь-яке читання, будь-яка "розвиткова" діяльність приносить користь. це робота на перспективу.
@@AboutProgramming
'забуваємо' і 'накопичується' - хіба не протиріччя у ваших словах ? 😊
якщо знання мають фізичний еквівалент - значить мають вагу...
поступово організм переповнюється (інтуітивними) знаннями, і нові вже не сприймаються 🤨
так... дерево знань... трохи поколупаюся у словах 🤔
---------------------------
дерево - це рослина, рослини вивчає Ботаніка (розділ Біології)
дерево - це рослина, яка має надземну частину, і підземну частину (коріння)
Живлення рослин...
з одного боку надходить сонячне світло, фотосинтез в листях...
з іншого боку - з коріння всмоктуються водні розчини мінеральних солей...
-------------------
А шо це таке на малюнку?
Ну... без коріння є водорослі... це наче рослина, живиться світлом, але живе у воді...
Або на малюнку - неживе дерево... дрова тобто...
Якось так 😊
Коріння є, але під землею, тому не видно) Про коріння треба робити окреме відео 😁
@@AboutProgramming
пробував удосконалити цю метафору... ось що вийшло...
сонячне світло - це мотивація... гроші, визнання...
листя - це оперативна інформація, поточні справи...
структура дерева - це архітектура комп`ютера, чи іншого пристрою... 'залізо'...
(може бути не обов`язково дерево, а кущ... чи трава... і т.д.)
програми - це ті поживні речовини, які рухаються всередині гілок і коріння живого дерева...
там усякі фітогормони... несуть якусь інформацію... багато там всього... не знаю точно
----------------
як це працює...
приміром, зима... сонця менше...
метафорично це буде означати - менше мотивації, грошей..
руху менше, програми не хочуть розроблятися
усе... на сьогодні мозковий штурм закінчився )
@npocmo. Не з усім згоден, але ідея розвинути метафору мені подобається💪🙂
@npocmo. Не з усім згоден, але ідея розвинути метафору мені подобається💪🙂
Красива аналогія дерева знань, але коріння та стовбур так само можуть зникнути, якщо то не використовувати. Можливо у наступному відео з прикладами буде більш зрозуміло як ті фундаментальні знання підтримувати. Ідеально мати роботу, де фундаментальні знання важливі, але як наприклад підтримувати актуальність знань про нутрощі якогось протоколу, коли всі задачі на роботі зводяться до підтримки чергової тікетінг системи так і не зрозуміло.
Дуже гарне зауваження. Але зазвичай стовбур залишається, бо від нього багато залежить й якщо постійно вчити щось нове, то доводиться через стовбур й великі гілки пов'язувати нові знання з вже існуючими. Тобто вивчення нового вимагає повторення базових речей й тому вони тримаються в голові. Так, деталі протоколу забудуться, але якщо від знань протоколу будуть залежати інші знання, то тоді це працює краще. Ну й практика допомогає
мені неясно, наскільки треба заглиблюватися у фундаментальні знання... фізику\математику треба знати на шкільному рівні, чи на якому? 🤔
Мій викладач з електроніки в універі казав, що складні системи мають багато відмінностей. Важко представити складну систему, в якій би не було б недоліків.
так це проблема тієї системи, чи твого уявлення ? 😅
@@npocmo. Проблема виховання і шкільної освіти.
Будь-яка система, яка є ефективною має йти на компроміси, бо покращення одних властивостей вимагає погіршення інших. Тому зазвичай немає ідеальної універсальної системи, але є системи, які гарно вирішують певну задачу
@@AboutProgramming про ланцюжок:
від процесів замовника - формулювання задачі звичайною мовою - потім у вигляді блок-схем, алгоритмів - потім написання програми...
якщо буде настрій - може зробите відео, щоб був зрозуміліший весь процес )
@@AboutProgramming
в мене таке враження, шо зараз усі заходять в ІТ з боку вивчення мови програмування... а вже потім шукають завдання...
може краще заходити з боку бізнес-процесів, від реальних ситуацій, які потребують покращення... і вже далі робити програму, як інструмент вирішення конкретної проблеми 🤔
слідуючи аналогії з відео - інколи здається, що знання це велика купа опалих гілок і листя 😁😁
Мені подобається 😄
Це ваше програмування це все весело звичайно, але давайте обговоримо дорослі речі. Де можна купити ту картину яку ви малювали?!
Питання про те, де ці всі знання можна отримати? Чи я неправильно зрозумів?)
Взагалі не розумію про що ви говорите, коли вдаєтесь до конкретних кейсів. Але не треба бути професійним кухарем, щоб зрозуміти, що страву приготував майстер, який знається в тому, що він робить.
Планую ще багато відео й буде багато розборів конкретних кейсів вже в деталях 🙂
@@AboutProgramming я тільки на початку шляху в ІТ. Світчер з інженера телебачення в Пайтон розробника.
Ви надто часто стрибаєте з думки на думку, дуже важко вловити суть
Тут ніби одна думка на все відео й просто приклади. Чи про що мова? Не зовсім розумію, де саме виникають складнощі
дерево без коріння - це дрова 😊
може трохи відпиляйте спинку крісла...
бо весь час таке враження, що у вас довге волосся... чи то спинка крісла така... чи довге волосся... ну і шо... чи то спинка крісла така... так, а про що ж він говорив 🤔
Цікавий ефект)) Є план наступне відео писати на фотік, а не на телефон. Може буде краще об'єм передавати