Вероника Самохина

Вероника Самохина

Темы
Неделя
Jun 14, 2021 → Jun 21, 2021

Архив недели @aminopyridin

Понедельник


Привет! На этой неделе jsunderhood переходит в управление мне (@aminopyridin). Давайте знакомиться!

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

Занимаюсь стажировками Руковожу кластером из 11 фронтендеров (целеполагание там и прочие штуки) Занимаюсь формулированием грейдов разработчиков в Контуре Иногда езжу на конференции с докладами и стендом компании Организовываю всякие движухи

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

🔥Тред (@aminopyridin)
Про что поговорим на неделе: - про преподавание фронтенда - про преподавание всяких сложных тем: архитектура и чистый код - про то, как заставить себя учиться (и чему), когда ты уже не джун - про грейды - про соревнования программерские - про верстку и css-in-js

Примерно так, распределено будет примерно по теме в день, но ничего не могу обещать, вдохновение может решить все перекроить)

Начну, пожалуй, с треда о вещах, которые расстраивают начинающих преподавателей. Полезно всем, кто планирует объяснять что-то новичкам

Преподаватель знает слишком много вариантов ответа. И вот такая история: спрашивает студент, прочитавший дома теорию, «вот есть три способа объявить переменную — var, let и const, ну, var, понятно, он устарел. А среди остальных мне как правильно выбирать?»

Преподаватель, знакомый с многообразием мира, рассказывает, что есть команды, в которых всюду let пишут; есть те, в которых const-first; есть те, кому вообще все равно, до тех пор, пока работает; есть даже те, что по привычке после var переменные инициализируют в начале функции

В обратной связи после урока студент напишет «так и не понял, как переменную объявлять».

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

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

Из лекции слушатель запоминает далеко не 100% В какой-то из книг я встречала упоминание об исследовании, в котором выяснили, что только 30% информации, рассказанной лектором его слушатели запомнили. Это был лучший результат — с хорошей презентацией и четкой речью лектора.

Так как само исследование я сейчас найти не смогла, то будем считать, что просто «далеко не все» запоминают. И это доставляет боль начинающим преподавателям «Ведь я же им говорил!». А опытные докладчики и лекторы просто трижды повторяют то, что аудитория должна запомнить.

«Проклятие знания» У всех нас есть когнитивное искажение, касающееся того, какие вещи являются очевидными, а какие — редкое знание, а мы им чудесным образом владеем. Это очень мешает в преподавании — тебе кажется, что это очевидная вещь, а аудитория никогда не слышала о ней!

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

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

🔥Тред (@aminopyridin)
Тредик о том, что не знает типичная аудитория мидлов-фронтендеров, которой я преподаю. Каждый приходящий в Контур разработчик проходит через 1,5 недели обучения. Фронтендеров мы учим реакту, редаксу, TS, асинхронному JS и всякому другому. Про такие группы и расскажу

Значение слова «реактивность» Когда я рассказываю про Реакт опытной аудитории, рано или поздно заходит разговор о том, что реакт он так назван, потому что реактивное программирование. — Кто знает, что такое реактивное программирование? Тишина...

— Хорошо, а давайте вспомним про реактивность из других отраслей. Ну, вот реактивное движение, например, это про что? — Ну, это когда быстро! — Это не обязательно, медузы тоже двигаются реактивно, но не очень-то быстро.

А вот в психологии говорят про проактивное и реактивное поведение. Это про что? — Ну, хорошие и плохие. Какие-то такие диалоги получаются в средней группе. Хотя иногда меня радуют ребята, говорящие «реактивное программирование — это эксель» и они правы =)

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

Чистой функцией что только не называют: - функцию, возвращающую значение - функцию, которая легко читается — в соответствии с правилами «чистого кода» - функцию, которую можно протестировать еще и Реакт со своим PureComponent добавил путаницы

expressions and statements В объяснении Реакта для начинающих есть необходимость объяснить одну, простую для опытных реакт-разрабов, вещь — что можно и что нельзя писать в фигурных скобочках в JSX.

Когда я только начинала проводить обучение по Реакту, я говорила что-то вроде «в фигурных скобочках может стоять произвольный JS, который возвращает значение — ведь вам нужно результат подставить вместо скобочек».

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

Тогда я стала явно проговаривать, что циклы for, if, switch-case, объявление переменных нельзя писать в фигурных скобочках. Аудитория реагировала в духе «ну, кому придет в голову так делать?» и через две задачки так делали.

Тогда преподавательский долг сосредоточить внимание на частой ошибке. И один из удобных способов так делать — дать аудитории самой придумать ответ, что именно нельзя писать в фигурных скобочках.(Вопросы вообще вовлекают в материал, могу написать об этом отдельно)

Я начала с вопросов типа: — в фигурных скобках можно писать только конструкции, возвращающие значение. Давайте придумаем такие, которые нельзя в них записать. Ну, такие, которые значение не возвращают. — console.log и alert не возвращают ничего!

Тогда я подумала «да, к черту, буду спрашивать правильно, а не попроще». — в фигурных скобках можно размещать только тот код, который является expression, statement запрещены. Кто знает, что такое expression?

Так оказалось, что мидлы-фронтендеры обычно не знают, что такое expression и statement. Но после подробного разбора теории языков программирования мне говорят: — всего-то? Ну, и кому придет в голову писать if в таком месте?

Для полного катарсиса еще можно рассказать про if-expression в Kotlin. Вот такие три темы не знает средняя аудитория мидлов фронтендеров. Но удивительно, что если спросить их опросом в чатике, то все все знают =) Проверю аудиторию jsunderhood опросом в следующем посте

🔥Тред (@aminopyridin)
Время опросов. Четыре вопроса в тредике. Хочу понять про вас все)

Знаешь ли ты термин «реактивность»?
🤔 70.3% Знаю в программировании
🤔 12.7% Знаю из физики
🤔 3.5% Знаю из психологии
🤔 13.4% Не знаю

Знаешь ли ты термин «чистая функция»?
🤔 10.5% Слышал
🤔 82.7% Знаю
🤔 1.0% Погуглил только что
🤔 5.8% Не знаю

Знаешь ли ты термины statement и expression?
🤔 65.5% Знаю оба
🤔 7.6% Знаю только один
🤔 8.6% Погуглил
🤔 18.3% Не знаю

Сколько лет опыта в программировании у тебя?
🤔 26.5% <2 лет
🤔 34.9% От 2 до 5 лет
🤔 23.1% От 5 до 10 лет
🤔 15.5% Больше 10 лет

🔥Тред (@aminopyridin)
@jsunderhood Ну тут вопрос скорее к вашим рекрутерам и собеседующим, которые набирают таких "мидлов". Либо же у вас какая-то другая матрица скиллов. Ты писала в начальном посте про то, что разрабатываешь грейды в компании, это закрытая инфа или можно посмотреть?
Про грейды я напишу еще на неделе, в общем про мидла так: он должен уметь делать типичные задачи так, чтобы не нужно было переделывать за ним. Мы не проверяем фундаментальные знания языков программирования на собеседовании, потому что без этих знаний люди нормально работают 🤷 twitter.com/__kondratyev/s…

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

Развлекательный тред: какие темы из Реакта ломают мозг неподготовленным сишарперам. Иногда учиться Реакту заходят бэкендеры (потому что могут, потому что им интересно или потому что в команде закончились фронтендеры). Некоторые темы учебного блока заставляют шестеренки скрипеть

Использование логических операторов в качестве ветвления (как на картинке). Если с тем, что HTML можно писать в файле JS несложно смириться (хотя все еще больно некоторым), то с использованием && в качестве if уже тяжело.
notion image

Дело в том, что здесь задействуются сразу три неочевидные вещи: - короткий цикл вычислений логических операторов: он во многих языках такой, но мало кто о нем помнит, потому что редко сайдэффекты в логических конструкцияз применяют

- использование логического выражения вне «логического контекста» — тут нет конструкции if или for, в которых привычно встречать такие выражения - знание о том, что логический оператор возвращает значения в исходном формате, а не приведенным к булевому виду.

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

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

Кстати, добить аудиторию можно вопросом к коду с картинки выше, «что будет, если забыть написать > 0, а массив будет пустой?» После этого выясняется еще одно скрытое знание в использовании этой конструкции: реакт не отображает false, null и undefined.

Асинхронность в JS. Когда я рассказываю, например, что setState — асинхронный метод, а значит, строчкой ниже еще точно изменений не применились, люди воспитанные многопоточными языками, спрашивают «откуда мы можем быть уверены? А вдруг успел сработать асинхронный код?»
notion image

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

Опрос перед тем, как продолжать: знаешь ли ты такие термины, как debounce и throttling?
🤔 73.2% Знаю оба
🤔 10.5% Знаю debounce
🤔 4.6% Знаю throttling
🤔 11.8% Не знаю оба

Стандартно, фронтендеры чаще знают про debounce, а бэкендеры — про throttling. Причем бэкендеры, говоря про тротлинг, говорят про процессоры; фронтендеры про тротлинг обычно вспоминают про выпадашку в DevTools. Дебоунс фронтендеры обычно в связи с полями поиска вспоминают.

HTML+CSS — язык программирования?! У многих разработчиков есть некоторое пренебрежение к верстке и периодически на моих занятиях встречаются шутники с остроумными шутками про HTML-программистов.

Тогда я этим шутникам рассказываю, что после выхода HTML5 и CSS3 связка из HTML+CSS стала Тьюринг-полным языком программирования (lemire.me/blog/2011/03/0…). Так что «вы просто не умеете программировать на этом языке»

Если вы сами пришли в мир JS после других языков, расскажите, что вам кажется или казалось странным/непривычным/неудобным в JS или TS?

🔥Тред (@aminopyridin)
@jsunderhood а теперь было бы интересно узнать, что эта аудитория знает
Тут же как: их знания мне проверить сложнее, чем незнания. Поэтому не знают мои аудитории одинаково, а знают по разному twitter.com/sergey_crossbo…

Бывают крутые ребята из других, незнакомых мне языков, которые рассказывают «а как у них»; Бывают те, кто глубоко в исходный код Реакта лазили и рассказывают, какие-то тонкости реализации Бывают люди из параллельных вселенных, например DevOps, готовы что-нибудь рассказать

Лучшее, что может быть в жизни преподавателя — умная аудитория. Можно у них научиться чему-то крутому.

Но чему может быть равен this в js не знают одинаково все =)

🔥Тред (@aminopyridin)
Использование логических операторов в качестве ветвления (как на картинке). Если с тем, что HTML можно писать в файле JS несложно смириться (хотя все еще больно некоторым), то с использованием && в качестве if уже тяжело. pic.twitter.com/4SGhc95I0s
История к картинке из этого твита: Преподавала Реакт тестировщикам. Обсуждаем, что если не написать явно > 0, то при нулевой длине массива выведется 0 на экран. — А зато если написать не два &&, а один &, то выведется сообщение! — радостно сообщает учащаяся twitter.com/jsunderhood/st…

Я очень люблю, когда учащиеся проверяют демонструционный код на прочность, жаль, только, они не всегда понимают, что они делают

Вторник


@jsunderhood Стоп, но ведь Реакт не реактивный?
Меня тут логично поправляют, что Реакт не реактивный. Я поняла, что действительно «реактивность» Реакта, (которая «реактивность»-то скорее как оппозиция императивному стилю), путаю с реактивным программированием. twitter.com/nikitonsky/sta…

Исправляюсь: реактивное программирование на Реакте будет, если вы подключите RxJS =)

Тредик о том, что не знает типичная аудитория мидлов-фронтендеров, которой я преподаю. Каждый приходящий в Контур разработчик проходит через 1,5 недели обучения. Фронтендеров мы учим реакту, редаксу, TS, асинхронному JS и всякому другому. Про такие группы и расскажу
Сегодня продолжу про всякое разное преподавание рассказывать, в частности, про сложные темы: архитектуру и чистый код. В предыдущих сериях: twitter.com/jsunderhood/st… — про меня twitter.com/jsunderhood/st… — преподавательские открытия twitter.com/jsunderhood/st… — чего не знают мидлы

Развлекательный тред: какие темы из Реакта ломают мозг неподготовленным сишарперам. Иногда учиться Реакту заходят бэкендеры (потому что могут, потому что им интересно или потому что в команде закончились фронтендеры). Некоторые темы учебного блока заставляют шестеренки скрипеть
twitter.com/jsunderhood/st… — про сишарперов, изучающих фронтенд

@jsunderhood Меня давно беспокоит такой вопрос: является ли чистой функция на приложенной картинке? pic.twitter.com/CGe0M832Vn
Я бы сказала, что в js — нет. Просто потому, что множество возвращаемых значений неограничено. Для чистой функции нужно два фактора:✅ отсутствие сайд-эффектов ❌ определенный результат, который одинаковый для одинаковых аргументов twitter.com/nightexpat/sta…

Второго пункта тут не выполняется, потому что нельзя предсказать результат и сравнить с предыдущим. Но, возможно, я ошибаюсь =)

Пока я пишу большой тред про архитектуру, отклонюсь немного в сторону — мини тред про незнание фундаментальных терминов. Вчера много было возмущений, утрируя «и таких людей вы называете мидлами?!»

Отвечу на это — мне бы тоже хотелось, чтобы все люди вокруг меня разбирались лучше в базовых терминах, чтобы у них был широкий кругозор и все такое. По факту у меня есть два рычага, как на это влиять: не нанимать тех, кто не шарит учить

Когда я только начала заниматься переделыванием процесса найма, я хотела пользоваться первым — «давайте не будем нанимать тех, кто не знает такие вот базовые вещи, как их вообще программистами можно называть?!!» И это было проявление юношеского максимализма.

К счастью, мне не дали это сделать, а просто выдали второй инструмент — теперь я могу всех нанятых людей на входе учить всему, что считаю нужным. Так, например, мы не проверяем знание Реакта на входе — зачем, мы все равно научим. Давайте лучше про задачи опытных людей спросим.

А не нанимать людей, которые могут работать работу, но не учились в университете и поэтому не в курсе, что такое np-полные задачи или не знают термин statement — это расточительство. Проще научить, если мы считаем это важным.

🔥Тред (@aminopyridin)
Про учебный курс по архитектуре фронтенда. Лет 5 назад, когда я только начала задумываться о том, что такое архитектура приложения, статьи про архитектуру, например, Ангулар-приложения, обсуждали примерно «как раскладывать код по папочкам». И мне казалось, что это ересь какая-то!

Так, года 4 назад я собрала самых крутых фронтендеров компании (удивительно, но все самые крутые фронтендеры в Контуре того времени состояли из переквалифицировавшихся бэкендеров) и спросила — Вот вы все классно пишете приложения. Посоветуйте, как учить студентов архитектуре?

Мне ответили в духе: — Какая архитектура? Нет никакой архитектуры! (а я видела решения, которые были приняты ребятами, код который они пишут и они совершенно точно умеют проектировать) Начала задавать разные вопросы и получила в ответ, что надо просто давать побольше практики

В общем, ушла я со встречи с пониманием, что коллеги, которые умеют проектировать хорошую архитектуру, не могут этому научить других. Это, в общем, нормально: умение сформулировать как надо размышлять — довольно редкое умение.

Так как идея создать семестровый курс по архитектуре фронта для старших курсов университета меня не отпускала, я на несколько лет ушла читать и смотреть, что по этому поводу пишут и рассказывают в индустрии (в конце треда будут рекомендации)

Курс в итоге сделан пока частично — только про Реакт и только на два занятия по 3 часа, вместо семестра (и испытан на кроликах). Так как полноценный пересказ всего курса займет те же 6 часов, то напишу рандомные мысли, которые мне кажутся интересными и остальное прочитаете сами

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

И начинать как раз с умения спроектировать интерфейс функции или компонента (если речь про визуальные составляющие).

Вообще архитектура — это про элементы системы и связи между ними. Это если кратко. Если полнее, то она в себя еще включает окружение и принципы проектирования. Это я из стандарта соответствующего вычитала en.wikipedia.org/wiki/IEEE_1471

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

Самый низкий уровень проектирования — функции и компоненты — полностью покрывается правилами «чистого кода» (про них сегодня будет отдельный тред). Базовое умение тут — описать интерфейс для будущих функций, еще не написав реализацию: что они получают на вход и что возвращают

После беглого чтения несокльких разных ресурсов, я пришла к простой картине мира: — нижний уровень архитектуры — Чистый код и, в частности, SRP — средний уровень (связь компонентов) — паттерны проектирования — верхний уровень (приложение) — слоистые подходы (MVC и аналоги)

Как всегда, реальность не укладывается в простые модели... Оффтопик: Когда я поймала одного из крутых коллег, закрылась с ним в переговорке и заставила обсуждать со мной архитектуру фронтенда, первое, что он спросил: — А что ты имеешь в виду, говоря «фронтенд»?

И я задумалась, что и вправду, когда говорю про фронтенд, последние годы имею в виду SPA на React. Хотя, вообще-то лендинг, серверная шаблонизация, «микрофронтенды» на Vue и SPA на Реакте — это все фронтенд и архитектура их очень различается. Конец оффтопика.

Уровни выше компонентного, они про поток данных и манипуляции над ним. Данные, если говорить про все приложение, — это состояние приложения (state), нужно только понимать, что state может быть размазан в том числе по url, history, localStorage,...

«Поток данных это про flux-архитектуру, которая заменила неподходящий MVC, а еще там были MVP, MVVM (на котором ангулар живет)» — примерно так я себе представляла все, когда начала погружаться в это Оказалось все интереснее!

Да, когда Фейсбук показали flux-архитектуру, они действительно ее противопоставляли MVC. Но оказывается, что, хотя MVC — это Model View Controller — это все знают, вопрос о том, как между этими сущностями ставить стрелочки потока данных каждый решает по-разному
notion image

В конце будут ссылки, в том числе с следованием о том, что flux — это тоже MVC =)

Для описания бизнесового состояния полезно попробовать применить подход DDD (domain-driven design). Тут я проверила на одной команде подопечных. Сказала перед следующей задачей прочитать про DDD и постараться при проектировании строго следовать его подходам.

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

и в целом сам факт проектирования (и дизайн-ревью) до того, как кидаться писать код благотворно влияет на скорость написания кода и дальнейшего код-ревью

Внезапно, хороший инструмент проектирования есть у тестировщиков — «Диаграмма переходов состояний». Он в чем-то похож на DDD, но с другой стороны на все смотрит — с точки зрения состояния объекта системы, а не бизнес-сущности. ulearn.me/course/testdes…
notion image

Хватит озарений, рекомендации: refactoring.guru/ru/design-patt… — если еще не читали паттерны. Укладываются в голове они не быстро и поначалу кажутся бесполезными и одинаковыми, но когда уложатся — дают возможность выйти на следующий уровень абстракции.

medium.com/front-end-in-r… — цикл статей, из которых мне больше всего нравится эта =) Но если захотите, прочитаете и остальные «круги» frontendmasters.com/courses/enterp… — очень подробный курс на FrontendMasters

blog.webf.zone/contemporary-f… — хороший лонгрид про историю. Если хотели разобраться, зачем MVC заменился на MVVM и что все это значит, то однозначно рекомендую. medium.com/front-end-in-r… — статья с мыслью про то, что FLUX это тот же MVC

🔥Тред (@aminopyridin)
Про кругозор. В процессе одной из итераций работы над грейдами, мы экспериментально добавили такой критерий как «саморазвитие» — он должен был бы закрываться у джунов и мидлов, но немного по разному проявляясь.

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

От мидла хотели, чтобы он как минимум знал, где у него нехватает компетенций и закрывал дыры, а как максимум, проактивно изучал технологии и методологии и уместно предлагал их команде.

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

Это происходит потому что есть удивительно много людей, которым «норм». Они что-то делают, задачи закрывают, обычно даже зарплатой довольны. И вот если во власти менеджера подсовывать ему задачи посложнее, стажера на воспитание — на это менеджер разработки или тимлид могут влиять

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

Что делать с этим пока не знаем, будем пробовать как-то менять критерий. А иначе получаются грустные истории: Есть один фронтендер, который стал разработчиком довольно недавно из тестировщика. И вот он дофига всего делает, но ненавидит все эти новые фронтовые технологии

— ну, вот чего им не сидится спокойно, ведь уже есть же для всего решения! Нет, придумывают... Раздражает его все это мельтешение. В какой-то момент его менеджер сказал: надо переводить в техлиды человека — он один (с юным стажером) на всю нашу большую команду фронт фигачит!

Для этого пошли с этим потенциальным техлидом поговорить другие техлиды, чтобы понять что-то про него — он же один в команде, непонятно, он классно все делает или нет. И вот они у него спрашивают: слушай, вот ты делаешь много сайтиков, они все простенькие, визуализируют всякое

И у тебя везде используется одинаковый стек Реакт, редакс и TS. Почему такой выбор? Он им отвечает: — В смысле? это же фронтенд, тут такой стек. Ну, не jQuery же использовать!

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

А для этого нужен кругозор, расширение которого исключительно в руках самих разработчиков. Эта история, кстати, одна из моего будущего доклада на TechLeadConf. Если кто еще не купил билет, а хотел, то вот промокод на 15% скидки: TechLead{speak} techleadconf.ru/2021/abstracts…

🔥Тред (@aminopyridin)
Про чистый код. Все еще о преподавании, а не о реальном мире, тут я часто работаю героем анекдота. Встречаются два преподавателя: — Слушай, как писать чистый код — Сейчас расскажу — Да, рассказать я и сам могу, как писать-то?

Кстати, про реальный мир. Всем приходящим к нам в компанию джунов и мидлов мы проводим, среди прочего, учебный блок «Чистый код». Однажды ко мне пришел коллега и сказал: — ну, вот зачем вы их учите чистому коду, а потом они придут в команды, а там... всякое!

— Представь, вот мы всех их учили и они пишут... всякое. А что было бы, если бы не учили?..

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

Занимательные опросы, 2 штуки. Умеешь ли ты писать чистый код?
🤔 12.3% Да
🤔 48.4% Скорее да
🤔 29.6% Скорее нет
🤔 9.7% Нет

Есть ли у тебя коллеги, которым нужно научиться писать более «чистый» код?
🤔 60.6% Есть такие
🤔 26.5% Мы все тут хорошо пишем
🤔 12.9% Нет коллег

Я запускала эти же опросы во флудилке фронтендеров Контура. И один из коллег, очень опытных и крутых написал в ответ вот опасения, что непонятно, как проверить это.
notion image

И это логичное опасение. Еще вчера я писала, что запоминаем мы из хорошей лекции далеко не 100% (возможно, порядка 30%), не думаю, что книги имеют больший показатель. Соответственно, прослушав какой-нибудь курс, или прочитав книжку, ты запомнил какую-то часть сказанного.

Если через год, например, просмотреть, прочитать тот же материал еще раз, то узнаешь много нового. Я, например, так первые лет 5 программирования на js раз в году перечитывала learn.javascript.ru — и каждый год столько нового узнавала.

То есть, есть большая вероятность, что ты когда-то давно прочитал/посмотрел что-то про чистый код, запомнил оттуда пару приемов и «все понятно». А потом у тебя зацементировалось то понимание, которое когда-то тогда сложилось.

Кроме того, что после прочтения однократного запоминается не все, против такого обучения идет еще ощущение «мне это не надо, я итак норм пишу». Кстати, чем взрослее разработчик, тем чаще от него такое слышишь, а у него за спиной коллеги матерятся и стесняются ему сказать вслух.

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

У нашего учебного блока Чистого кода используется несколько приемов, которые стараются сломать предвзятость учащихся: С самого начала блока дается задача, которую все решают как могут, а потом сравнивают с «красивым» решением и понимают, что их коду есть куда стремиться

Мы не учим правилам нейминга и расстановки комментариев — это скучно. Поэтому дома все изучают тему SRP (single responsibility principle), а на очной/онлайновой встрече мы решаем задачки, связанные с принципами декомпозиции, компонуемости, читаемости

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

Порекомендую чего поизучать, если есть желание: Кусок курса про проектирование, правда он на C#, но смыслу это не мешает: ulearn.me/course/cs2/Kri… И отличную онлайн-версию книжки про рефакторинг, которую сегодня уже рекомендовала: refactoring.guru/ru/refactoring…

Кстати, когда на собеседовании на стажировку мы спрашиваем студентов «Что такое, по-твоему, чистый код?», почти всегда они говорят две вещи: хорошие названия переменных и много комментариев.

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

🔥Тред (@aminopyridin)

Среда


Сегодня будет тема грейдов, но позже. Пока я занята подготовкой к предстоящей конференции — приобретением нового окраса.
notion image

Новый цвет приобретён, теперь поеду писать для вас новые треды =)
notion image

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

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

1 тип: те, кто в джуниорстве успешно обучались на курсах, вроде «фронтенд для начинающих», чувствуя, что им надо подкачаться, снова берутся за похожие курсы. Поначалу это весело, чувствуешь себя самым умным, решая задачки на использование цикла for, потом становится скучно.

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

2 тип: люди, которые «учатся в твиттере» — это условное название. Это когда ты встречая неизвестное слово, спрашиваешь у автора твита, что оно значит, он тебе в 140 символов отвечает, ты думаешь, что понял. Кстати, к таким же образом бывают люди, которые учатся на конференциях

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

3 тип: люди, бесконечно углубляющиеся в какую-то одну тему. Когда нападает экзистенциальная пустота от ощущения, что ты ничего нового не узнаешь, некоторые люди идут еще глубже разбираться в том, что они итак хорошо знают, игнорируя те темы, которые им на самом деле нужно освоить

У меня есть недавняя история про это: одни разработчик очень полюбил REST API: после прохождения первого курса про проектирование рест апи, он, при желании изучить что-то новенькое, гуглил еще какие-нибудь статьи/видео/курсы про рест и изучал. Наверное, ему становилось спокойнее.

4 тип: «блин, надо чего-нибудь подучить, но не знаю чего. О, нашел рандомное слово, которое звучит круто, выучу его» — так люди задаются целью выучить WebGL, GraphQL или что-то аналогичное, при абсолютном отсутствии идеи, зачем это использовать

Если спросить «а зачем», то ответит что-то невразумительное, что переводится как «я искал какие-нибудь штуки которые я еще не знаю, откуда я могу знать, зачем они мне нужны?» И это хороший вариант, если разработчику хватит мотивации учиться при полном непонимании «зачем»

5 тип: «Я уже 1,5 года изучаю JS, курсы “JS за 21 день” уже не приносят ничего нового. Кажется, тут я все знаю... Нужно выбрать следующий язык и учить его» Встречается такой тип и в форме «за следующее полугодие я планирую выучить питон, хаскель и котлин»!

Это были не самые лучшие варианты попыток учиться, которые я встречала. Понятно, что есть и хорошие, и хорошие встречаются часто. В следующих тредах напишу, про новые стеки и про то, как учиться, чтобы не было мучительно больно.

🔥Тред (@aminopyridin)
Про отношение к новым стекам. Когда у меня случается разговор о том, что «чет мне скучно, выучить новый язык, что ли...» с опытными разработчиками или со студентами, я на это реагирую каждый раз по разному. Тред о том, когда не надо, и когда уже очень желательно учить новый язык

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

Или наоборот, ты выбрал фронтенд или мобилку, а от наведения красоты тебя тошнит. Тут все просто, бросай это как можно скорее — нервы дороже!

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

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

Ситуация 3: твой текущий язык — не первый, на котором ты работаешь. В этой ситуации ты и сам взрослый и самостоятельный, разберешься без моих советов. Ситуация 4: ты уже больше 3 лет пишешь на текущем языке (даже если он первый) — смело можешь пробовать новое.

Общее правило, которым я руководствуюсь: если у моего собеседника текущий язык программирования — первый на котором он работает и он на нем работает меньше трех лет, то рекомендую не менять язык. Причем «работа» на языке в этом случае — это важно.

У меня есть история университетсяких времен (я, кстати, на химика училась): я не знала одинаково хорошо все языки программирования, так что мне было без разницы, на чем писать: я писала на JS, PHP, C# и Python. И ни одного из них не запомнила.

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

Так вот, эмпирическое правило из наблюдений родилось такое: если у тебя есть хотя бы три года опыта в одном языке, то изучение следующего расширяет кругозор, а не смешивает все в кашу. И расширение кругозора очень полезно: оно обогащает и ваш опыт, и языки программирования =)

А если вы хотите порасширять кругозор в языках программирования, то я сплагиачу советы от @_bravit: Книжка «Seven Languages in Seven Weeks» (только не берите на литресе, они не дают ее скачивать, только через их приложение с отвратительным ux)

Книжка «Exercises in Programming Style» (amazon.com/Exercises-Prog… тут про русскую версию ничего не знаю, не пыталась даже искать) А еще можете посмотреть чудесный доклад @_bravit, откуда я сплагиатила советы: youtu.be/pHq3HDEXQXM

Участвуйте в контестах, чтобы попробовать новые ЯП. Про контесты расскажу подробнее в следующие дни, но уже сейчас можно отправиться порешать задачки adventofcode.com или codingame.com на других языках.

🔥Тред (@aminopyridin)

Четверг


Обману всех и не буду рассказывать сегодня про грейды, расскажу про то, чему учиться, когда ты уже не джун и как себя на это сподвигнуть. И для начала снова развлекательный тред о том, какие ошибки в самообучении я встречала (добавляйте свои, которые я не расскзаала)
Итак, сегодня продолжу что-то про рост рассказывать, а тем временем «в предыдущих сериях»: twitter.com/jsunderhood/st… — Новые стеки: когда пора, а когда еще рано twitter.com/jsunderhood/st… — Ошибки самообучения

Про учебный курс по архитектуре фронтенда. Лет 5 назад, когда я только начала задумываться о том, что такое архитектура приложения, статьи про архитектуру, например, Ангулар-приложения, обсуждали примерно «как раскладывать код по папочкам». И мне казалось, что это ересь какая-то!
Холивар про реактивность: twitter.com/artalar_dev/st… и twitter.com/jsunderhood/st… Холивар про чистые функции twitter.com/jsunderhood/st… twitter.com/jsunderhood/st… — Про незнающих «фундаментальные вещи» twitter.com/jsunderhood/st… — Чистый код twitter.com/jsunderhood/st… — Архитектура

Пока я пишу большой тред про архитектуру, отклонюсь немного в сторону — мини тред про незнание фундаментальных терминов. Вчера много было возмущений, утрируя «и таких людей вы называете мидлами?!»
В вопросе о том, что должны уметь разработчики, ни в частности, фронтендеры, раньше у меня был однозначный ответ — все! Если вы читали мой тред про людей без «фундаментальных знаний» (twitter.com/jsunderhood/st…), то помните, что я была подвержена юношескому максимализму

Это было удобно — руководствоваться пониманием, что я, как хороший фронтендер, должна знать все — и дизайн, и менеджмент, и бэкенд, и тестирование. Лонгрид @bespoyasov «Фронтенд — это не больно» (bespoyasov.ru/front-not-pain/) был моей первой рекомендацией для всех.

А потом от моих решений стали зависеть другие люди и все перестало быть так однозначно =) Выяснилось интересное... Если сказать некоторым фронтендерам, что они должны понимать, как устроен бэкенд и уметь проектировать API, это может вызвать негодование:

«КОМПАНИЯ ХОЧЕТ ЭКОНОМИТЬ ЗА МОЙ СЧЕТ! Вы намеренно хотите сделать из меня фуллстека, чтобы не нанимать бэкендеров! ИДИТЕ НАХРЕН! Я отвечаю только за фронт!» (случай из разговора с фронтендером, которому предложили в следующей задаче поучаствовать в проектировании АПИ сервера)

Если заявить, что сеньор бэкендер, пишущий бэк для веб-приложений, должен знать, как работает фронтенд, то потенциальные сеньоры начинают угрожать уволиться, потому что «не полезу я в этом разбираться!»

И я удивлялась: «Как так-то? Неужели вам не интересно понять, как устроен мир? Узнать шире, чем нужно?» А потом поняла, не без помощи книжки Барбары Шер mann-ivanov-ferber.ru/books/otkazyva… что люди могут быть те, кому интересно закопаться поглубже в его родной стихии («дайверы»)

И те, кому интересно поверхностно, но широко («сканеры»). И я отношусь ко вторым. И не я одна: есть много бэкендеров, которые приходят учиться фронтенду, чтобы лучше понять; есть дизайнеры, жажущие научиться верстать; есть фронтендеры, которые хватаются и за бэкенд, и за дизайн.

Но это не отменяет и первый тип (Барбара Шер их назвала «дайверы»): люди, которые выбрали верстку и не лезут в остальное не потому что боятся нового, а потому что в верстке еще столько непознанного; люди, которые раскапывают устройство компиляторов до самых процессорных команд...

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

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

Чуть более стекоспецифичные, но все еще общие вещи: безопасность, тестирование. Во фронте меньше полезны юнит-тесты, зато часто применяются скриншотные. Не могу не посоветовать доклад моего коллеги про тесты habr.com/ru/company/ole…

Кстати, про безопасность. Фронтендеры расслабились, потому что Реакт, например, за них большинство уязвимостей закрыл. Но Реакт закрыл не все уязвимости, а еще, иногда мы пишем код не на Реакте. И забываем по привычке о безопасности. Не надо так!

Волшебное слово «софт-скилы»: навык аргументированного спора, умение давать обратную связь, умение объяснять, навык наставничания. Хоть в софт-скилах есть много навыков, которые можно в них включить, я выделяю эти, как обязательные для разработчика, работающего в команде

Как обычно, поделюсь ресурсами. Для умения аргументировано спорить мне нравится курс «Научное мышление» stepik.org/course/578/ Умение объяснять неплохо описано в книжке «искусство объяснять» (mann-ivanov-ferber.ru/books/paperboo…) Про наставничество и ОС у нас есть курс, но он внутренний(

А еще есть много всякого со звездочкой: навык публичных выступлений, умение писать тексты, умение говорить на менеджерском. Навык публичных выступлений даже включен в программу специальности ФИИТ, которую @xoposhiy делает в УрФУ (fiit-urfu.ru)
notion image

Про умение писать тексты Я когда-то давно купила «Пиши, сокращай» @perepisal и постаралась научиться писать тексты (с тех пор все забыла и пишу как получится, конечно). Самый заметный эффект от книжки — бесят чужие письма и по 5 минут формулируешь заголовок к своим.

Но после «Пиши, сокращай» вышла более профильная книжка — «Новые правила деловой переписки» (litres.ru/ludmila-sarych…). Ее очень рекомендую — письма и сообщения в чатиках становятся гораздо более эффективными.

Про умение говорить на менеджерском: когда-то давно, года 4 назад, была распродажа всех курсов @stratoplan и это лучшая покупка в области саморазвития, которую я совершала. После этого учишься разговаривать с людьми правильно, менеджерить проекты и работа становится веселее

А мотивации к обучению могу прибавить отличным докладом Вадима Макишвили «36» youtu.be/xPPCzryZK44 — если не смотрели, то очень зря

🔥Тред (@aminopyridin)
Пока еду домой, расскажу несколько рандомных историй, которые мне сейчас вспомнились с разными моралями. История 1: Когда создавали курс для университета, для всей теории решили использовать ссылки на уже написанные статьи (не было времени писать свое).

И вот в качестве статьи поиска по DOM даем ребятам статью learn.javascript.ru/searching-elem… Там есть раздел о том, что «Все методы "getElementsBy*" возвращают живую коллекцию». Я читаю это и думаю, «блин, ну кому это может быть нужно знать?..»

Через полгода приходит ко мне стажер, пишет код, который ищет все textarea в документе и вызывает с контентом от textarea CodeMirror, чтобы отобразить код раскрашенным. И вот CodeMirror создает textarea под свой код, стажер методом «getElementsByTagName» выбирает textarea...

Зовет меня пожаловаться, что все сломалось, ошибок в консоли нет, на странице ничего не рисуется, что делать?! Оказывается, знание о «живых» коллекциях может быть нужно, но ровно один раз в жизни

История 2, которую мне рассказала одна менеджер разработки. Был у нее подчиненный разработчик, который плохо работал. На него жаловались тестировщики, что он не тестирует задачи совершенно. На него жаловались другие разработчики, что он пишет некачественный код.

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

Он это понял из-за традиции оценки задач — считал, что раз задачи надо оценить, значит их надо как можно быстрее делать. Ну, и старался всеми силами. А так как разработчик был уровня джуна, ну, получалось не очень хорошо...

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

Что такое кластер. Так как у нас продуктовая разработка, то команды укомплектованы разработчиками всех ролей. И в типичной команде 3-10 бэкендеров и у них есть тимлид, а фронтендеров обычно 1-2. Поэтому для тимлидских задач к каждому разработчику приставляют руководителя кластера

А для этого нужен кругозор, расширение которого исключительно в руках самих разработчиков. Эта история, кстати, одна из моего будущего доклада на TechLeadConf. Если кто еще не купил билет, а хотел, то вот промокод на 15% скидки: TechLead{speak} techleadconf.ru/2021/abstracts…
Я приехала, поэтому остановлюсь на двух историях. Если хотите больше, то у меня есть пара докладов с историями: youtu.be/rg74xkQquXM youtu.be/TwXy0pz5Wp4 Ну, и будут еще истории в будущем докладе: twitter.com/jsunderhood/st…

🔥Тред (@aminopyridin)

Пятница


@jsunderhood Могли бы чуточку раскрыть тему? В моей голове попытка выделить бизнес логику и отделить ее от архитектуры фреймворка выглядит как натягивание совы на глобус
DDD предлагает описывать только бизнес-процесс, ну, например, вот есть какая-нибудь заявка, она может быть сначала создана, потом отредактирована, потом взята в работу или отклонена, или можно, например, передать заявку другому или мало ли какие еще вещи в ее жизни бывают. twitter.com/tilimillitryam…

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

Кстати, есть метрика состояния: количество бизнес данных / количество визуальных данных. Чем выше по дереву разметки находится рассматриваемый state, тем больше должно быть это значение и наоборот, у низкоуровневых компонентов может быть исключительно визуальное состояние.

Пятничный тред про соревнования. В школе и университете (я на химика училась) я активно участвовала в разных олимпиадах, ЧГК и других соревнованиях. А потом стала программистом и при мысли от соревнований и конкуренции мне становилось плохо.

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

Сначала я стала организовывать мероприятия для любителей попрограммировать соревновательно. Первым таким мероприятием стал CodeRetreat — кстати, очень рекомендую организовать у себя в команде или компании coderetreat.org/the-workshop/

Смысл код-ретрита такой: несколько сессий по 45 минут, в каждой сессии: - люди рассаживаются рандомными парами, - берут один компьютер, - реализовывают игру Жизнь ru.wikipedia.org/wiki/%D0%98%D0… - через 45 минут код удаляют, пары меняются

После первой сессии, в которой единственная цель — реализовать игру Жизнь, каждая следующая сессия предлагает разные ограничения, например, могут быть такие: - не использовать цикл for - не использовать курсор (мышь, тачбар...) - методы и функции не длиннее трех строк - ...

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

Как видите, первый опыт организации соревнований был ни разу не соревновательным =) Следующим был внутренний хакатон, где мы делали полезные продукты; потом был внешний хакатон, где мы собрали 250 человек, чтобы писать игры. А потом настало время и мне начать соревноваться.

Первая движуха, к которой я присоединилась, был adventofcode.com Вот уже 6 лет каждый день с 1 до 25 декабря открывается задачка, решаешь задачку, получаешь за нее звездочку и помогаешь этим Санте в его приключениях.

Очень люблю эту активность за то, что: - нет соревновательности - тратишь меньше часа в день на задачку и чувствуешь себя крутым =) - удобно для того, чтобы взять новый язык и выучить его на задачках - атмосфера нового года

После нескольких лет участия, я решила сделать активность более масштабной: мы решили сделать 25 дней видеоразборов где разные люди (а с какого-то дня на самых разных языках), с уютным чатиком и лидербордом для всех желающих. Разборы: youtube.com/playlist?list=…

Следующее соревнование, в которое я включилась — codingame.com У них, кроме задачек на разные темы для многих языков, есть соревнования, которые они запускают раз в квартал-полгода. Там уже соревнование с лидербордом, лигами и топом компаний/университетов

За что я люблю соревнования CodinGame: - Интересный сеттинг - Очень красивая визуализация работы твоих решений - Неделя или больше на то, чтобы взяться за решение

И самым топовым соревнованием для меня оказался ICFPC. - Оно длится 3 суток (72 часа), - командное (команда любого размера), - любой язык, - одна задача, - разные организаторы каждый год

Тут твиттер решил не показывать вам ссылки) Сейчас восстановлю посты

В 2019 году я напросилась в команду к коллегам, провела прекрасно время, описала тут этот интересный опыт: t.me/KonturTech/477 А в 2020 мы стали первыми российскими организаторами соревнования! Об этом рассказали на хабре: habr.com/ru/company/skb…

Всю статью с хабра пересказывать не буду, но любимым видио поделюсь: youtu.be/EjL-5EuQeCU Это было вводное видео перед стартом. Мы постарались вложиться в атмосферность =)

Sharpen your lambdas, pop your stacks and polish your registers: ICFP Contest 2021 is now less than one month away! The contest takes place 9-12 July, starting and ending at 12:00pm UTC.
Ну, а следующий ICFPC совсем скоро — 9-13 июля! Собирай команду и присоединяйся к веселью! twitter.com/icfpcontest202…

А вообще, мы много соревнуемся сами и устраиваем соревнования другим, если хочешь об этом узнавать, то мы пишем анонсы в канале в телеграме: t.me/KonturTech

🔥Тред (@aminopyridin)
Рассказала, в каких соревновательных штуках я участвовала, теперь расскажу про пользу, которую я вижу в участии в них.

Самое главное — «коммьюнити». У всех таких движух есть чатики, обсуждения... Если вовлекать в такие активности коллег, то у вас будет активное сообщество внутреннее. От этого «коммьюнити» есть вполне практичная польза — они обсуждают умными словами умные вещи!

От обсуждения умными словами умных вещей происходит перекрестное переопыление умными мыслями в сообществе. Вторая польза — поделать что-то необычное — спасение себя от выгораний. Мало кому из нас нужно писать 3д-визаулизаторы, а в контесте вполне может пригодиться

Третья польза — изучение новых языков или подходов на задачах, которые не жалко. В работе сложнее браться за новые языки — ведь от тебя нужна предсказуемого качества польза в предсказуемые сроки. А в контесте можно экспериментировать. В том числе на совсем экзотических языках

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

Если у вас чешутся руки в чем-нибудь поучаствовать, то присоединяйтесь к ICFPC 2021, а если хотите сами провести что-нибудь, то попробуйте code retreat — он имеет несомненный плюс в ненавязчивой обучательной направленности. Пишите мне в личку (@aminopyridin), я помогу советом

🔥Тред (@aminopyridin)
Спонтанное размышление: если спросить у человека «что такое Чистый код?», то его ответ очень меняется, в зависимости от его уровня. Вот сейчас перед глазами у меня конспект с собеседования совсем молодого разработчика (3 месяца назад начал учить JS).

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

Мои студенты старших курсов уже не вспоминают про горизонтальные отступы, для них это очевидно. Студенты старших курсов говорят про хорошие имена переменных и наличие/отстутсвие комментариев.

Разработчики постарше уже вспоминают SOLID, DRY, KISS и другие аббревиатуры. А совсем взрослых разработчиков я как-то давно не спрашивала о таком, не знаю, что они отвечают =)

🔥Тред (@aminopyridin)
Продолжу размышления о том, как по-разному ведут себя разработчики разных уровней. У нас для приходящих опытных разработчиков есть «буткамп» — после двух недель обучения они идут работать по нескольку недель в нескольких командах (от 1 до 3, изредка 4, команд).

Я помогала ребятам выбрать команду по душе: вариантов много, выбирать тяжело. Для этого я спрашивала ребят о том, чего им хочется. Так вот, на что обращают внимание разработчики разных уровней:

Джуны: — «Хочу Реакт, потому что я его пробовал и потому что он приятнее, чем просто скрипты писать» — «Не хочу в стартап, потому что слишком большая ответственность: вдруг я не смогу» — «Хочу в команду, где уже есть фронтендеры» — «Боюсь не разобраться с TypeScript»

Однажды был такой диалог: — Не хочу в команду, в которой легаси. — Почему? Есть какой-то опыт? — Нет, опыта нет, просто знаю, что легаси — это плохо.

Джуны не знают ничего о процессах, обычно, и им не важно как часто будут встречи, тет-а-теты, как задачи ставят... Однажды была история с джуном, который просил дать ему package.json всех команд и пойти в те команды, у которых меньге всего неизвестных ему пакетов будет

Мидлы: — Хочу Реакт/Ангулар и умею объяснять, почему Реакт/Ангулар — это хорошо — Хочу туда, где хорошо построены процессы (был негативный опыт) — Хочу в стартап, потому что там современные технологии — Не хочу в стартап (был негативный опыт) — Чтобы скрам — Чтобы не скрам

— «Хочу делать инфраструктурные продукты, чтобы вокруг меня были мои пользователи, чтобы они могли мне в чатике баг-репорты писать и чтобы обратная связь буквально в коридоре давалась»

— «Я хочу, чтобы моим продуктом пользовались тысячи и миллионы пользователей, чтобы чувствовать, как я приношу пользу миру. Хочу, чтобы эти пользователи были непрограммисты, потому что именно непрограммистам сложнее всего без автоматизированных решений!»

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

Сеньоры: — Вообще все равно, какие технологии — Смогу ли я там влиять на процессы? — ну, то есть сразу не верит в хорошее в процессах =) — «Могу в стартап, если он интересный» — Хочу стул удобный, место у окна и не опен-спейс — сеньоры чаще всех высказывают бытовые пожелания

В общем такие выводы: — Джуны боятся не разобраться и накосячить. — Миддлы помладше хотят попробовать новое, а постарше уже понимают какой им нужен карьерный и профессиональный рост: хотят ли наставничать, выучить ли еще и C#… — Сеньор пробовал все, может везде и ищет комфорта

🔥Тред (@aminopyridin)
@jsunderhood Хех, у меня тот случай, когда кроме легаси разного уровня старости(от совсем хренового до "не, ну жить можно в принципе") ничего и не видал:(
На курсе для менеджеров разработки о том, как разговаривать с разработчиками, мы с ними начинаем с обсуждения значения важных терминов. Так вот, один из терминов — «легаси». И задавая наводящие вопросы, мы доводим менеджеров до понимания, что любой код старше пары недель — легаси twitter.com/technosham/sta…

А однажды я интервьюировала менеджеров разработки в стартапах о том, каким должен быть разработчик в стартапе. И у каждого спрашивала: — Бытует мнение, что в стартапах нет легаси и этим они очень привлекают разработчиков. Это так? — Нет, конечно! — отвечали они с нервным смехом

Это я к тому, что в целом все мы живем в окружении легаси, и нужно просто отрастить панцирь покрепче, чтобы оно не так расстраивало.

@jsunderhood у меня после этих тредов что я бенджамин баттон мира разработки, никогда не была джуном
Я не знаю ваш случай, но в целом так часто бывает, когда люди становятся разработчиками после каких-то других специальностей, потому что многое из этого — просто жизненный опыт, а не конкретно в технологиях. В конце концов, чтобы ценить удобные стулья, не нужно много лет кодить twitter.com/asyavee/status…

Один интересный случай с выбором стажера был пару лет назад: одна команда выбрала своего будущего стажера очень быстро, буквально за пару часов, из списка примерно в 30 кандидатов на стажировку. Я спросила у них «чего это так быстро?»

Команда ответила, что они как увидели подходящего, так и перестали смотреть дальше. — как поняли, что этот — подходящий? — ему 30 лет, он переходит из другой профессии и хорошо сделал тестовое. Что еще можно хотеть?

— а чем взрослый вам подходит больше, чем студенты? — так с ним будет меньше детского сада и больше осознанности. Словно подтверждая это ожидание, этот стажер во время обучения перед стажировкой подошел ко мне и сказал: «Я чувствую, что я слабее других здесь соображаю⬇️»

«я не хочу подвести команду. Дайте мне, пожалуйста, контакты команды, я обсужу с ними, как лучше поступить в этом случае» Команда его успокоила, стажировка прошла успешно, уже три года он работает с нами и все довольны

🔥Тред (@aminopyridin)

Воскресенье


Воскресное развлекательное: тред о том, как мы изобретали грейды. 1 этап: «разделим фичи языка по грейдам». Где-то в 2017 сели мы думать, как решить, кто из приходящих на собеседование мидл, кто джун, а за сеньоров браться страшно. Решили, что наверняка, это связано с знанием JS

Расписали табличку какие методы и термины из языка (и верстки) должен знать джун, а какие уже мидл. Ну, вроде, замыкания должен знать джун, а если он еще и про регулярки знает, то уже мидл. Не так буквально, но похоже.

Посмотрели на получившуюся табличку, сказали «фигня какая-то» и выкинули результаты. И пришли к выводу, что хотя есть вещи, которые статистически люди знают хуже или реже, но они примерно никак не связаны с грейдом человека.

Если смотреть на моих учащихся, то, например, из методов массива почти никто не знает про reduceRight и мало кто вспоминает про some и every (хотя встречая в коде могут легко догадаться). Потому что редко ими пользуются (мне всегда обидно за some и every).

Генераторы, Map и Set — все из той же оперы. Мало кто ими пользуется достаточно часто, чтобы легко вспомнить про них в обычном обсуждении задачи. Тут мне обиднее всего за Set, я его нежно люблю, но понимаю, что чаще всего им пользуюсь, когда решаю всякие контесты.

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

Вначале придумали крупные критерии этой матрицы: Техника/Мастерство Продуктивность Критическое мышление Работа с процессами Коммуникации Результативность и управление проектами Применение архитектурного контекста Применение продуктового контекста
notion image

Потом пошли описывать индикаторы, которые доказывают наличие критерия и назначать их разным грейдам. Идея была такая: в каждом критерии есть сколько-то индикаторов. Каждый индикатор бинарный и либо проявляется, либо нет. И формулировки такие, чтобы точно можно было проверить
notion image

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

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

Еще есть индикаторы, которые мы написали за сеньорские и которые стабильно отмечали выполняющимися большинство джунов. Например, индикатор «Использует глубокие знания технологии для более качественного решения задач». И даже примеры проявлений не спасают
notion image
notion image

Ну, и самая главная проблема — перфекционизм, который заставляет разработчиков хотеть закрыть все индикаторы, но не все из них возможно было закрыть без смены команды. Например, индикатор «При необходимости выполняет смежную с разработкой роль (аналитик, тестировщик, devops)»

Индикаторы были сделаны так, чтобы, если человек помимо всего прочего делает сверх того, что должен, то должна быть возможность отметить, что он молодец и мы это ценим. Но это создавало ощущение, что «если у меня хорошая команда, то я не смогу закрыть 100% индикаторов!»

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

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

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

На картинке один из 5 критериев для перехода из джуны в мидлы. Показывать все критерии я пока не хочу, потому что они еще дорабатываются — формулировки местами оказались спорными и сложными, поэтому сейчас делаем их безопаснее.
notion image

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

И очень больно было некоторым менеджерам осознавать это. Они говорили: вот вы там придумали всякое, как мне растить разработчика в ведущего (по факту, в лида), если у меня задач больше нескольких часов не бывает, в команде 3 человека и расти мы не планируем. Критерии мне мешают!

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

(от ведущих мы ждали лидерских качеств, это тимлиды, техлиды и прочие лиды) — до этого грейда можно расти лет 5 или больше, или никогда не дорасти. И это, конечно, демотивирует многих. И как такового у нас не было грейда «сеньор», то есть «старший» разработчик.

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

— мидл: это разработчик, который может делать типичные задачи самостоятельно, за ним не нужен присмотр — мидл+: разработчик, который может сделать почти все задачи из бэклога команды, но не может планировать крупные рефакторинги

или принимать значительные архитектурные решения — сеньор: разработчик, который кроме собственно деланья задач, умеет брать ответственность или за людей, или за архитектурные решения, или выполняет роль менеджера на крупных фичах. Либо умеет делать какие-то сверхсложные задачи

— Лид: это сеньор, который успешно и неоднократно доказал свои лидерские качества. Может быть тимлидом, техлидом, фичалидом или разработчиком rocket science задач. Ну, и у лидов тоже есть усиленный грейд лид+, который про масштаб проявленй — еще крупнее, еще больше, чем у лида.

🔥Тред (@aminopyridin)
@jsunderhood а как вы решаете эту проблему? как растите/мотивируете разработчиков, которые упёрлись в потолок из-за специфики проекта? рассматриваете какие-то внутренние переходы, индексируете зп за стаж и внутреннюю экспертизу, ещё какие-то инструменты есть?
Сейчас у каждого менеджера над ним есть менеджер бизнес-направления и обычно он заинтересован в том, чтобы выявлять таких людей и перебрасывать их на другие проекты в рамках направления, на которых есть куда расти. twitter.com/purr_pure/stat…

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

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

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

🔥Тред (@aminopyridin)

Понедельник


@jsunderhood А можно пожалуйста подробнее про техлида и фичалида - кто такие? И получается можно быть лидом без тимлидства?
У нас есть понимание, что некоторые лиды целиком про людей — мотивация, целеполагание, наставничество и вот это вот все. Это тимлиды. Их мало, но они есть. twitter.com/midfilecrisis/…

Есть техлиды — люди, которые в основном про принятие архитектурных решений, про разговоры типа «в следующем году нам надо больше денег на железо», про планирование крупных рефакторингов... Это такие авторитетные технари.

Есть фичалиды — это одной ногой менеджеры разработки. Это собственно те, кто берут на себя какой-то проект или фичу и выполняют в ней всю менеджерскую работу: следят за сроками, работают с рисками, организовывают работу команды, занимаются коммуникациями с другими командами...

Фичалиды — суперценные кадры в стартапах или командах с большой потребностью в работе с высокой неопределенностью. Это когда по объективным причинам невозможно поставить строгую задачу.

В командах часто бывает тимлид и техлид в паре — один душевный и эмпатичный, а второй — хардкорный технарь. Бывает, что один человек в себе всех совмещает. В общем, мы считаем, что можно быть лидом без тимлидства.

🔥Тред (@aminopyridin)
Тредик о том, что не знает типичная аудитория мидлов-фронтендеров, которой я преподаю. Каждый приходящий в Контур разработчик проходит через 1,5 недели обучения. Фронтендеров мы учим реакту, редаксу, TS, асинхронному JS и всякому другому. Про такие группы и расскажу
Ну, что ж, моя неделя подошла к концу, было интересно! Спасибо всем за вопросы и обсуждения. Вот что успели обсудить: twitter.com/jsunderhood/st… — про меня twitter.com/jsunderhood/st… — преподавательские мудрости twitter.com/jsunderhood/st… — чего не знают мидлы

Я бы сказала, что в js — нет. Просто потому, что множество возвращаемых значений неограничено. Для чистой функции нужно два фактора:✅ отсутствие сайд-эффектов ❌ определенный результат, который одинаковый для одинаковых аргументов twitter.com/nightexpat/sta…
twitter.com/jsunderhood/st… — про сишарперов и фронтенд twitter.com/jsunderhood/st… — про архитектуру Холивар про реактивность в двух частях: twitter.com/artalar_dev/st… и twitter.com/jsunderhood/st… Холивар про чистые функции twitter.com/jsunderhood/st…

Пятничный тред про соревнования. В школе и университете (я на химика училась) я активно участвовала в разных олимпиадах, ЧГК и других соревнованиях. А потом стала программистом и при мысли от соревнований и конкуренции мне становилось плохо.
twitter.com/jsunderhood/st… — Про людей, не знающих «фундаментальные вещи» twitter.com/jsunderhood/st… – Про кругозор twitter.com/jsunderhood/st… — Чистый код twitter.com/jsunderhood/st… — Новые стеки twitter.com/jsunderhood/st… — Ошибки саморазвития twitter.com/jsunderhood/st… — Соревнования

На курсе для менеджеров разработки о том, как разговаривать с разработчиками, мы с ними начинаем с обсуждения значения важных терминов. Так вот, один из терминов — «легаси». И задавая наводящие вопросы, мы доводим менеджеров до понимания, что любой код старше пары недель — легаси twitter.com/technosham/sta…
twitter.com/jsunderhood/st… — Польза от участия в соревнованиях twitter.com/jsunderhood/st… — Как выбирают команды разработчики разных уровней twitter.com/jsunderhood/st… — разработчики разных уровней и Чистый код twitter.com/jsunderhood/st… — Про легаси

Воскресное развлекательное: тред о том, как мы изобретали грейды. 1 этап: «разделим фичи языка по грейдам». Где-то в 2017 сели мы думать, как решить, кто из приходящих на собеседование мидл, кто джун, а за сеньоров браться страшно. Решили, что наверняка, это связано с знанием JS
twitter.com/jsunderhood/st… — Грейды twitter.com/jsunderhood/st… — Разные виды лидов

🔥Тред (@aminopyridin)

Ссылки