Фрагмент комикса с простым объяснением, что такое числа с плавающей запятой

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

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

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

Примеры «деталей работы систем»

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

Фронтенд JS:

• как работает цикл событий;
• HTTP-методы, такие как GET и POST;
• что такое DOM и что можно с ним сделать;
• политика same-origin и CORS.

CSS:

• чем отличается рендеринг встроенных и блочных элементов;
• что такое «поток по умолчанию»;
• как работает flexbox;
• как CSS решает, к какому элементу какой селектор применить («каскадная» часть каскадных таблиц стилей).

Системное программирование:

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

Вы можете использовать технологии без понимания механизмов их работы (и это бывает нормально!)

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

Но если вы начинаете работать с какой-то системой более глубоко (например, CSS, HTTP, горутины, электронная почта) и не совсем понимаете, как она устроена, то могут возникнуть проблемы.

Ваши баги покажут, когда пришло время улучшить свою ментальную модель

Когда мне не хватает ключевого понимания какой-то технологии, это можно понять по косвенным признакам:

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

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

Ведущий программист (senior developer) не обязан знать абсолютно всё, но должен быстро распознавать, если он чего-то не знает — и изучать это. Кстати, о них…

Даже ведущему программисту приходится учиться в своей области

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

Например, я хорошо разбираюсь в фундаментальных понятиях Си и веб-программирования (например, тезисы в начале статьи), но когда дело доходит до графики/OpenGL/GPU, то знаний не хватает. И иногда вдруг оказывается, что мне не хватает системного понимания в какой-то конкретной области, например, CSS.

Конечно, это неприятное открытие — что вы действительно не понимаете, как работает система, с которой работаете уже десять лет («Разве я не должен уже знать это? Я так давно этим пользуюсь…»). Но это совершенно нормально! Технологий слишком много, и мы постоянно изобретаем что-то новое, так что никто не может быть в курсе всего.

Как подходить к изучению новых областей

Мне нравится такой шаблон:

1. Обращаем внимание, что какой-то вопрос ставит нас в тупик («Эй, а когда я пишу await в программе Javascript, что на самом деле происходит?»)
2. Разбиваем общий вопрос на конкретные фактические вопросы, например: «Когда срабатывает await, как он решает, какая часть кода запустится следующей? Где хранится эта информация?»
3. Узнать ответы на эти вопросы (написав программу, прочитав что-то в интернете или спросив у коллег)
4. Проверить своё понимание, написав программу («Эй, вот почему у меня была эта ошибка await! И я могу её исправить вот так!»)

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

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

Сильно помогает знание даже самых простых фактов

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

И вот однажды в 2013 году я посетила лекцию Стефана Карпинского с объяснением этой темы (примерно как в комиксе, только на лекции нам рассказали больше странных деталей). И теперь я совершенно уверенно применяю числа с плавающей запятой! Я знаю основные ограничения и когда их нельзя использовать (для представления целых чисел больше 2⁵³). Теперь мне ясно, насколько трудно реализовать численно устойчивые алгоритмы линейной алгебры — лично я понятия не имею, как это сделать. То есть я теперь вижу реальные границы своих знаний.

Соединить новые факты с информацией, которую вы уже знаете

Легко повторить фразу вроде «в одном байте восемь бит». Это правда, но что с того? Труднее всего (и гораздо полезнее!) связать эту информацию с тем, что вы уже знаете о программировании.

Например, возьмём факт «в байте восемь бит». Глядя на единственную строку Hello в коде программы, можно задать много вопросов, например:

• Сколько байт в памяти используется для представления этой строки? (пять!)
• Каким именно битам соответствует буква Н? (здесь используется кодировка ASCII, так что вы можете посмотреть в таблице ASCII)
• Если работающая программа выводит строку Hello, можно ли найти в оперативной памяти, где конкретно хранятся эти байты? Как это сделать?

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

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

Далее поговорим о двух способах получения информации: вопросы «да/нет» и компьютерные эксперименты.

Как получить информацию: задавайте вопросы «да/нет»

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

Такие вопросы заставляет чётко сформулировать свою текущую ментальную модель. Кроме того, на такие вопросы человеку проще ответить.

Например, вот несколько вопросов различного типа:

• Проверить свои текущие знания
  
  • Пример: «Пиксельный шейдер — то же самое, что и фрагментный шейдер?»

• Проверить, как связаны друг с другом разные концепции
  
  • Пример: «Shadertoy использует OpenGL?»
  • Пример: «Видеокарты получают информацию о треугольниках?»

• Вопросы высокого уровня об основной задаче какой-нибудь технологии
  
  • Пример: «Оркестратор для MySQL проксирует запросы к БД?»
  • Пример: «OpenGL даёт больше или меньше контроля над видеокартой, чем Vulkan?»

С вопросами «да/нет» вы контролируете ситуацию

Если задать открытый вопрос «Как работает X?», разговор часто уходит в сторону, здесь два неприятных сценария:

1. Человек начинает рассказывать кучу вещей, которые я уже знала.
2. Человек начинает рассказывать кучу вещей, которых мне не интересны.

И то и другое расстраивает. Но это не вина человека, которому вы задаёте вопрос! Он ведь не может знать, какая информация вам нужна. Тем не менее, всегда неприятно прерывать его: «О нет, извините, пожалуйста, это совсем не то, что я хотела узнать!»

Хотя вопросы «да/нет» труднее сформулировать, они позволяют получить точную информацию на конкретную тему. И вы не потратите впустую время специалиста, заставляя его объяснять кучу вещей, которые вас не интересуют.

Задавать вопросы «да/нет» не всегда легко

Иногда ситуация развивается не очень хорошо:

я: Просто чтобы проверить моё понимание, это работает так, верно?
он: На самом деле нет, это работает <совершенно иначе>
я (внутренне): (краткий миг паники)
я: Хорошо, позвольте минутку обдумать следующий вопрос.

Оказывается, моя ментальная модель была совершенно неправильной. Хотя это очень полезная информация сама по себе, но она вызывает крайне неприятные ощущения. Задавая действительно конкретный вопрос (хотя он и более эффективен!), вы ставите себя в уязвимое положение, потому что приходится раскрывать конкретные знания, в которых вы бываете совершенно не правы!

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

Как получить информацию: провести эксперимент

Когда некого спросить, я могу погуглить, почитать документацию — и иногда ничего не нахожу.

Но самое замечательное в компьютерах то, что часто можно получить ответы у самого компьютера!

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

• Атомики быстрее или медленнее мьютексов? (Статья в блоге: «Проверяем мьютексы и атомики»)
• Если добавить пользователя в группу, то существующие процессы от имени этого пользователя выделяется в новую группу? («Как работают группы в Linux?»)
• Если сервер на адресе 0.0.0.0 без сетевых интерфейсов, можно ли подключиться к этому серверу? («Что такое сетевой интерфейс?»)
• Как на самом деле организованы данные SQLite на диске? («Как работает SQLite? Часть 1: страницы!»)

Проверять на компьютере — это навык

Определённо требуется время, чтобы сформулировать вопрос, а затем провести реальный эксперимент для проверки.

Но это действительно мощный инструмент! Если не ограничиваться просто гуглом, документацией и разговорами с коллегами, то вы можете сделать ГОРАЗДО больше.

Подумайте, каких знаний у вас нет

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

• Как работают транзакции базы данных и уровни изоляции
• Как работают вершинные шейдеры (в графике)
• Как работает рендеринг шрифтов
• Как работает BGP и пиринг
• Как работает множественное наследование в Python

Прямо сейчас эти вещи мне не нужны. Но почти наверняка однажды мне встретятся транзакции БД, так что я готова изучить эту тему, когда она понадобится 🙂