Проектирование декларативного API

Контент про узкие знания уходят в небытие. Все уже устали спрашивать про память, многопоточку, UIKit. Это становится скучно. Легко можно загуглить, узнать у коллег. Чатгпт дает точнее ответы.

Мы начинаем новый цикл оценки знаний. Архитектуры, проектирование, стиль. Оценка инженерности теперь оценивается не сколько знаний ты имеешь, а как ты ими пользуешься. Насколько чистый твой код. Элегантны решения. Понятны и удобны механизмы, которые ты пишешь или ими делишься.

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

В статье автор разбирает одну из удобных и модных практик — декларативный стиль на примере валидатора. Как написать удобный и простой механизм проверки наших полей ввода.

Вычислительные мощи и процессы нашего мозга

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

Насколько быстро ты понимаешь информацию? Как долго держишь в голове прочитанное? Как хорошо строишь комплексные картины в голове?

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

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

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

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

Это, как никогда не бывая в зале, сразу пытаться брать нагрузку в разы за пределами нормы. Или учить первоклашку базе 11 класса, пропуская остальные 10 классов. Мозг не выдержит. Он выплюнет знания как только мы раслабимся. Или заставит взять долгий период на восстановления, где все труды и работа пойдут под откос. В добавок все ресурсы тратятся на поддержку легенды, а побочный эффект этого — синдром самозванца. С таким грузом легкость не обретешь.

Любое развитие — это повторение с предельной искренностью к себе. Иттерации. Дробление огромной работы на маленькие части. Логированием и фиксом своих ошибок.

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

Собрал подборку статей для развития мозга и здоровья:
- Mind Training for Programmers
- A Daily Workout For The Software Developer's Brain
- Why Regular Exercise is Important for Software Developers

Фильтров опытов стало больше или проверенный временем

Время — главная метрика в ит. Сколько у тебя опыта? За сколько времени ты сделаешь задачу? Какая скорость интернета? Как быстро идет билд в пайплайне? Как можно оптимизировать работу кода? Почему Xcode такой медленный? Сколько лет эта библиотека объездилась в комьюнити? Какой у вас последний таргет? Привязка ко времени будет всегда. Бороться с этим — не понимать индустрию.

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

На самом деле на них смотрят все:
- технический спец, с первых вопросов на интервью, поднимает тему о ваших самых сложных задачах. Это понимание уже на 50% оценило и выстроило дальнейшее интервью, а где-то даже и закончило. Имея хоть небольшой опыт, он легко поймет сколько времени понадобится сделать хорошо задачу.
- нанимающий менеджер, имея фидбэк от технического и hr, смотрит на оценку опыта. Многие не знают, но часто менеджеры могут не поверить в оценку технического интервью. Пообщавшись о вашем опыте уже в живую, дать либо ниже, ниже выше оценки от теха.
- и только потом, рекрутер, зная весь фидбэк и мнения от техспецов, зная все недовольства менеджеров, ставит свои фильтры.

Став опытным ты сам будешь лучше понимать метрику. Оценивать коньяк по его выдержке. Шашлык не маринуется за секунду. А ребенок не рождается за час. У всего есть свой инкубационный период и возраст совершеннолетия

Таксономия Блума или как учиться эффективней

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

Таксономия Блума — один из методов эффективного обучения, который сильно закрепился в IT. Основная идея заключается в том, что обучение — это последовательный процесс. Состоит он из 6 уровней: запоминание, понимание, применение, анализ, синтез и оценка. Каждый из них опирается на предыдущий: без знания невозможно понимание, без понимания — применение и далее. Например, если человек не знает, что такое молоток, то не поймет как с его помощью вбить гвоздь.

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

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

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