Про ошибки обучения

Часто новички-фронтендщики считают, что если изучат синтаксис языка программирования, выучат много свойств в CSS, создадут по туториалу простое приложение, то будут готовы к реальной работе. По моему опыту, это не так.

На мой взгляд, проблема тут кроется в ошибочном подходе к обучению. Выучить синтаксис, еще не все. Тут как на уроках физики в школе. Если постараться заучить все законы и формулы будет неплохо, но как только настанет момент применить комбинацию известных конструкций, возникнут сложности.

Вот несколько аргументов:

1) Некоторые особенности JavaScript часто принимают за баги или рудимент от древних времен.

Странные понятия всплытие переменных и функций, наличие лексического окружения и сложная система для асинхронных операций вызывают растерянность. А если до этого у новичка не было опыта с другими языками программирования, то сложности только усугубляются.

Понять причины странного или нелогичного на первый взгляд поведения можно обратя внимание на причину возникновения самого языка. JS создавался из-за потребности сделать интерактивным страницы, сохранять и отправлять данные моментально. Все что требует незамедлительной реакции должно быстро работать и исполняться в среде. В нашем случае средой является сам браузер.

Браузер для менеджмента всего происходящего использует EventLoop. В нем решается когда отрисовывать страницу, исполнить скрипты, отреагировать на действие пользователя и т.д. Уверена, что если хорошенько разобраться, как это работает, нелогичные особенности JS станут понятными и очевидными. А значит, не надо будет заучивать и повторять все определения и особенности перед каждым собеседованием. Очень удобно.

2) Тоже самое касается верстки.

Часто слышу: «Я уже выучил гриды, флексы, а вот и несколько макетов сверстал, думаю я отлично верстаю». Но тут та же ошибка, выучить синтаксис свойств — не означает научиться верстать. Тут важно понять почему элементы на странице отображаются именно таким образом, почему некое свойство меняет поведение элемента.

Экстраполируем и выводим аксиому:
«Если человек понимает базу, почему что-то работает именно так, то в дальнейшем он легко освоит любой инструмент, библиотеку или фреймворк»

А что про тех, у кого уже есть коммерческий опыт за плечами, не на одном проекте?

Для них открываются новые челленджи и точки роста, но при этом могут оставаться те же проблемы.
Например, разработчик может знать, что некий баг фиксится определенным, знакомым разработчику образом. Однако тот раз за разом его сажает в код. Невнимательность? Безответственность? Плохая память? Вполне может быть. Но что более вероятно, разработчик просто не знает, почему этот баг там появляется. Виноваты все те же пробелы, посаженные еще на этапе обучения, закрепленные неоднократно на разных проектах.

И что, это и есть ваши хваленые точки роста?

Не совсем, такие пробелы больше похожи на техдолг в легаси-проекте. А вот точками роста могут быть:
- понимание работы команды,
- понимание что мы не просто пишем код, а решаем проблемы бизнеса,
- изучение новых технологий и глубокое погружение в уже известные.

Тут куда вас заведет ваше видение собственной карьеры.

В какой-то момент и я обнаружила у себя большое количество пробелов и начала работу по их устранению.

Предлагаю нам вместе расти и повышать уровень разработки там, куда дотягиваются наши руки.

Вот некоторые хештеги, по которым будет легко найти мои заметки на те или иные темы в канале. Со временем категории будут пополняться.
#верстка #JS #TS #планирование #мотивация

Не ленитесь разбираться в причинах и следствиях и будет вам крутой оффер 😎

Что важно знать, в чем важно разобраться, чтобы с чистой совестью заявить: «Я хорошо верстаю»?

- Поток документа (как располагаются элементы на странице, почему они себя так ведут, почему есть деление на блочные и строчные документы)

- Как управлять потоком (позиционирование, флексы и гриды) #потокДокумента

- Семантичность и доступность (как это влияет на SEO-показатели, чем это поможет пользователям) #семантичность #SEO

- Уметь верстать в сочетании адаптивного и резинового дизайна #адаптивность #резиновость

- Работа с типографикой (подключение запасных шрифтов, подгрузка из внешних и внутренних источников, декорация текста) #типографика

- Все про селекторы в CSS (какие бывают, как определить их вес и приоритетность, как их правильно комбинировать) #селекторы

- Корректная работа с изображениями (загрузка картинок, работа с новыми форматами в браузере, интерактивность SVG изображений) #изображения

- Работа с анимациями (создание простых анимаций, оптимизация большого количества анимаций, чтобы у пользователя со слабым железом не фризила страница) #анимация

#верстка

Поток документа: Что это? Зачем? Как им управлять?

Поток документа — это то, как элементы на странице располагаются относительно друг друга и самой страницы.

Все написанные нами теги, если не стилизовать их дополнительно, располагаются на странице в том порядке, в котором мы их написали. Часть из них будут занимать всю ширину (блочные элементы), а часть ширину своего содержания и вставать в один ряд (строчные элементы).

Сейчас мы управляем элементами довольно гибко, зачем нам вообще строгие правила?

Дело в том, что изначально верстка переносилась в интернет по принципам верстки печатной продукции (например как в газетах или журналах). Про это очень здорово написано в Доке. Но со временем веб начал все больше отличаться по своим задачам от печатных изданий и появилась потребность большего контроля над потоком.

Свойства, помогающие нам управлять потоком:

- Display — как ни странно звучит, но он первый. Он может заставить блочный вести себя как строчный и наоборот. Значение none — заставить вырвать элемент из потока

- Float — безвозвратно устарел и не используется сейчас, но до появления Flexbox это было, пожалуй, самое мощное свойство

- Position: absolute / fixed — вырывают элемент из основного потока, создавая для него собственный поток. А свойство static возвращает блудный элемент в основной поток (является дефолтным в браузере)

- Flexbox — расположить ряды карточек, расположить их по центру, сжать/растянуть/выровнять. Тут, тут и тут можно потренироваться флексить

- Grid — король хаоса и непонимание всей мощи среди новичков. Позволит расположить элементы нарушая последовательность, созданную нами в html, а потом еще и еще раз на разных разрешениях. Тут и тут можно потренироваться использовать гриды

Причем, последние два создают свой контекст (flex-контекст и grid-контекст). Сам контейнер ведет себя как обычный блочный элемент(display: flex) или строчный (display: inline-flex), а вот все его дочерние элементы начинают подчиняться соответствующим правилам.

Уточним: что значит вообще — вырываться из потока?

Когда говорят, что элемент вырывается из потока, обычно подразумевают, что:
- Для него создается свой поток
- Все его соседние элементы забывают о его существовании и занимают место по правилам базового (или основного) потока.
- При этом его размещение в нашей разметке (в html) остается неизменным

На собеседованиях часто можно услышать вопрос: В чем разница между display: none и visibility: hidden?

И этот вопрос как раз относится к пониманию потока.
Поскольку, первое влияет непосредственно на поток (вырывает элемент из потока), а второе по сути накладывает на него прозрачность.
Следовательно в первом случае соседние элементы займут место элемента, а во втором у нас останется пустое место (дыра между видимыми соседними элементами)

Мне лично нравится, как в Доке объясняется материал, поэтому ссылки туда будут часто встречаться от меня в качестве рекомендаций.

#потокДокумента #верстка

Микро-анонс

Совсем скоро мое выступление на митапе, где я буду говорить про менторство в целом и свой опыт в частности. Сейчас я готовлюсь, дорабатываю презентацию, пишу план рассказа.

Кстати, как вам эти тезисы?
— Цель должна быть четкой, а путь до нее понятным
— Необходимы точки контроля за результатами, чтобы не заблудиться по пути к цели (про это тут)

Вроде очевидно же, не?

Да-да, но как именно определить реальную цель и сформировать эти точки контроля? Есть вариант применить на практике методы, сюрприз, применяемые при разработке проектов и продуктов.

Сомнительно на первый взгляд, но как-то в чате менторов кто-то поделился, что пользуется ими, чтобы помочь своим менти. Я заинтересовалась, почитала о них и... Выглядит рабочей схемой. Про их применение я и хочу рассказать.

Я много лет учусь планировать свои цели и задачи, постоянно ищу рабочие техники и пробую их адаптировать под себя. Тема повышения эффективности меня не обошла стороной, как ни крути, мы живем в эпоху достигаторства. Так что время от времени, я буду писать про планирование, тайм-менеджмент и мотивацию. 🤷‍♀️

#планирование #мотивация #планРазвития

Если вы еще не знаете о SMART и GROW, тогда мы идем к вам.

Метод SMART особенно популярны среди руководителей проектов и продуктов.
Если думать например про цель: «Увеличение среднего чека», то можно прикинуть в голове, как ее описать по буквам аббревиатуры, но как интерпретировать в случае личной цели?

Для начала, в обоих случаях, необходимо декомпозировать глобальную цель.

Например глобальная цель: Устроится на первую работу

Устроится на первую работу => Пройти собеседование, попасть на собеседование.

Пройти собеседование => Знать теорию, уметь применить ее на практике и т.д.

Давайте сразу к атомарному кусочку: Научиться уверенно и качественно верстать.

Как проверить цель по SMART:

S — Specific — конкретная.
Цель должна:
- Давать точный ответ на вопрос «Что делать?» — Научиться уверенно и качественно верстать.
- Подразумевать только один результат — вроде подходит, никаких двойных смыслов

M — Measurable — измеримая.
Результат должен иметь критерий оценки — Могу сверстать сложный макет по всем правилам (семантичность, адаптивность, резиновость, достуность, отсутствие ошибок линтера)

A — Achievable — достижимая.
Цель должна:
- Укладываться в реалистичные сроки — Можно изучить основы и натренироваться с нуля за 3 месяца интенсивной работы? — Да
- Опираться на объективные показатели — Цель будет считаться достигнутой, если я смогу сверстать макет соответствующий требованиям не больше, чем за 3 дня (24 рабочих часа)

R — Relevant — значимая.
Цель должна быть значимой для достижения глобальной цели — Если я буду хорошо верстать, это даст мне преимущество среди других кандидатов.

T — Time bound — ограниченная во времени.
Необходимо ограничить время достижения цели, чтобы не откладывать и не деморализовываться — Через 3 месяца я должен приступить к другой цели, чтобы приблизится к основной цели.

Если возникает ощущение, что можно так же расписать более мелкие задачи, это можно и нужно сделать, главное, не забудьте ограничить срок выполнения, исходя из того срока, который в определили для родительской цели.7

Есть мнение, что последняя буква (Time bound) самая важная из всех, потому что именно она показывает, как отставание от графика отдаляет вас от вашей глобальной цели.

А что на счет GROW?
Он больше направлен на мотивационную составляющую:

G — Goal — цель.
«Что делать?» — Научиться уверенно и качественно верстать.

R — Reality — настоящее.
Что мотивирует? Чувства/эмоции/ощущения — Неуверенность в своих навыках, желание иметь преимущество перед другими кандидатами, желание стать первоклассным специалистом.

O — Options — варианты достижения.
Как делать? Каким способом — Здесь описываются конкретные способы и какие эмоции в вас вызывают эти способы. Они вас демотивируют или наоборот? Сомневаетесь вы в них или твердо убеждены в их эффективности

W — Will — волеизъявление.
Взятие ответственности за результат на себя — Теперь я уверен, что для меня это важно, я знаю как действовать. Я беру на себя ответственность получить результат.

Вы в праве использовать эти методы, видоизменить их под себя или отказаться. Воля ваша.

Каков итог?

GROW поможет отфильтровать те цели и способы их достижения, которые будут все замедлять, оставляя только то, что мотивирует или является важным.

SMART поможет составить конкретный план реализации, который избавит от вопроса: «А что мне вообще нужно сейчас делать?»

А если вам лень самим этим заниматься, можно попробовать найти ментора, который об этих методах знает. Тогда он выстроит вам план и из тени будет подсовывать нужные итерации. А отличный ментор еще и будет синхронизировать свой план с вашим видением/желаниями/волеизъявлением)
#планирование #мотивация

Конкретная цель и способы ее достижения

Как-то в обсуждение целеполагания в чате менторов пришел автор книги "Карта Гипотез". И рассказал, что её можно использовать не только для развития продукта или проекта, но и для личных целей. Ну я и пошла смотреть 🤓

Вот мой комментарий, написанный сразу после прочтения и обмозгования прочитанного:

Мне понравилась идея карты гипотез, потому что она организует этап планирования, смещая фокус на то, что между задачами и результатом должно быть пояснение.

Почему выполнение задачи приведет нас к результату?

В процессе размышлений на эту тему могут проявиться явно критерии, по которым будет легко отслеживать прогресс исполнения задачи и уменьшится вероятность потери мотивации.

В чем суть? Есть 4 сущности:

1) Цель — Рекомендуется явно указывать по каким критериям считать цель достигнутой, какие критерии принципиальны/обязательны для достижения результатов.

2) Субъект — человек или группа людей, влияя на которые, мы сможем достичь цели. Субъектом никогда не может быть исполнитель задач или сам человек, если речь идет о личном планировании.

3) Гипотеза — идея или аргументация, соединяющая между собой субъекта, на которого мы собираемся влиять, и задачи, которые необходимо для этого выполнить. При этом, гипотеза должна объяснять почему те задачи, которые мы выполним, окажут на субъекта желаемый эффект.

4) Задача (их может быть множество) — должна прикрепляться к определенной гипотезе. Если проверка причинно-следственной связи нарушается, то необходимо временно оставить эту задачу висящей в воздухе.

Для описания задач рекомендуется использовать SMART. Поскольку каждая задача должна быть оценена в качественно-количественном показателе.

При заполнении гипотезы необходимо соблюдать такую конструкцию:

Если: сделаем А

То: поведение субъекта изменится Б

Потому что: теперь субъект *получит/не делает и т.д

Цель может видоизмениться тотально несколько раз в процессе работы над картой гипотез. И это норма

Нельзя написать: "Если я изучу React, то смогу разрабатывать приложения, потому что теперь умею" (субъект и исполнитель задачи один)

Скорее должно получиться: "Если я смогу писать полоценные приложения на React, то работодатель оценит меня выше, потому что получит сотрудника, которого не нужно много обучать"

Гипотез можно нагенерировать массу. И не все из них приведут к желаемому результату. Как понять с какой начать?

Нужно расставить приоритеты. Гипотеза, которая кажется вам наиболее правдоподобной и практичной, пойдет в работу первой.

А как вы проверяете свои цели и задачи на релевантность?

Скоро митап, про который я недавно писала, приходите поддержать)