Давайте научимся учиться 🤓
👇 тред 👇
Самое глупое что я могу написать тут, это просто рассказать о том как я учу новый материал и для большинства* это будут бесполезные знания 🤔
Поэтому сначала нужно разобраться с вашим стилем принятия унформации. Ключевая-гуглящаяся аббревиатура - VARK
Есть 4 типа студентов(на самом деле это диапозон), с разными стилями изучения:
Visual - визуалы
Aural - аудиалы
Read/write - дигиталы
Kinesthetic - кинестетики
Можно почитать про них тут
educationonline.ku.edu/community/4-di…
или тут
masam.by/stil_obuchenia…
Знать про это нужно хотя бы ради того чтобы знать как оптимально пользоваться своим временем при изучении нового материала ⌛️
Все тесты называют меня дигиталом - люблю заметки, читать, иногда это перерастает в доклады. В целом стараюсь оставлять для себя "виртуальные следы студента", чтобы была возможность вернуться к этим заметкам спустя какое то время 📝
После такого введения должно стать понятным что мои методики обучения подойдут не всем, но может быть это именно ты, поэтому давай читать дальше
Читайте книжки, читайте больше, всё подряд. Не будьте как этот парень, будет достаточно одной главы что бы понять что книга плоха или не для вас
youtube.com/watch?v=38tfhS…
Прочтите документацию того чем пользуетесь 📖
Зайдите в package.json и берём 5 зависимостей.
Идём на их гитхаб и прочитать от корки до корки(занимает не больше пары часов)
Часто можно закрыть пробелы в знаниях, о которых даже не подозревали.
Особый бонус в карму тем у кого есть список технологий и ссылки на их документации в доке по вашему проекту.
Если вы уже спокойно ориентируетесь на MDN, не стоит держать MDN за единственный источник знаний о веб технологиях.
Он хорош для общего ознакомления, но если вы хотите не "знать о технологии", а именно "знать технологию". Ознакомиться с спецификацией полезно!
Тут же вспоминается хорошая и не новая статья на эту тему
medium.com/hackernoon/11-…
Не бойтесь смотреть вне своей экосистемы, если вы стали учить бекендную часть смотрите и читайте про go/rust/younameit. Там часто решаются такие же проблемы и можно перенять опыт.
Этот совет я получил лет 5 назад от @dmitryzaets 🙌
Читайте совершенно чужой код. Откройте маленький чужой проект на github на один файл и разберитесь в нём.
Разобрались? Теперь другой на пару файлов.
Что нового вы узнали?
Прислушивайтесь с коллегам на кодревью, задавайте вопросы. Порой за небольшим сообщением лежит глубокая мысль чего то нового для вас
Еще один крутой источник знаний техновстречи - регулярные встречи команды для обмены опытом. Ключевое слово - регулярные
У нас в ПИ Яндекс.Маркета(~40 человек) проходят еженедельные техновстречи. Так же есть еженедельные техновстречи всего фронта маркета. Там рассказывают обо всём: новые форматы бекендов, паттерны написания кода, инструментарий и так далее
Само собой не все компании могут позволить себе выделить час-два всей разработки в неделю, но это прям сверх круто! И большой плюс в культуру разработки в компании
Если эти встречи проходят очно, а вы на них сидите в ноуте, сядьте в угол или на последний ряд. Это просто не этично по отношению к докладчику.
Это не конференция или митап, там это тоже делать некрасиво, но на техновстерчах это особенно не красиво 🙅♂️
Не скипайте такие встречи, если тем нет, возьмите инициативу в свои руки и расскажите что то сами. При чём не столь важно насколько банальной может быть тема "почему именованные экспорты компонентов лучше чем export default () => <div />"
Это работает так же как такой вопрос в группе:
- куда пойдём кушать?
- не знаю
- я тоже
- и я
- вы называете любое отвратительное место
- Нет! пойдём в ВАРИАНТ1
- я хочу в ВАРИАНТ2
- еще открылся ВАРИАНТ3
Зачем нужны техновстречи и почему они полезны мне помогли @_lttb и @pavelrevers 🙌
Плюсы в карму тем кто ведёт дневник таких встреч, где можно посмотреть когда кто и про что рассказывал, толстый плюс если остаются записи
помогли разобраться*