«Я классный разработчик»: Чек-лист когнитивных заблуждений у программистов
2026-02-26 22:57 Diff
https://ru.hexlet.io/blog/posts/chek-list-kognitivnyh-zabluzhdeniy-u-programmistov

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

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

Это адаптированный перевод статьи 8 Signs You Are Not As Good A Programmer As You Think. Повествование ведется от имени автора, Джозефа Круза.

Содержание

Заблуждение 1. Ты считаешь себя «очень хорошим разработчиком»

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

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

Заблуждение 2. При одном взгляде на код большого проекта ты говоришь: «Я могу лучше»

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

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

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

Это распространенная проблема новичков. Да, они понимают, что их код предназначен не только для чтения процессором. Они пишут код на высокоуровневом языке, предназначенном для других людей. Что делать, если код вышел ужасным? Уж точно не прятать его — показывайте свою работу другим и учитесь на обратной связи, которую получаете. И научитесь писать в общепринятом стиле.

Заблуждение 4. Ты ничего не знаешь о парадигме структурного программирования

Структурное программирование влияет на все современное программирование. Его основа — иерархия блоков (control structures). У этих блоков только одна точка входа, но несколько точек выхода. Дискуссии на эту тему не утихают, но для нашей статьи нужно лишь знать, что подобные ограничения имеют две веские причины.

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

Вторая причина существования блоков в том, что это эффективный для процессора способ обращаться к данным — он либо держит все данные неподалеку (spatial locality), либо переиспользует конкретные данные в течение ограниченного промежутка времени (temporal locality).

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

Заблуждение 5. Ты заявляешь о том, что «новый фреймворк X — самый лучший»

Или не фреймворк. Тут можно подставить любое название библиотеки или языка. Еще программист может сказать что-то типа «C и Ассемблер скоро исчезнут", или еще хуже — будет предсказывать, что «C++ заменит C в операционных системах". Все это звучит одинаково ужасно.

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

Заблуждение 6. Ты игнорируешь race condition

Мы уже говорили про race condition (иногда говорят «состояние гонки» или неопределенность параллелизма) во втором пункте. Это когда несколько потоков одновременно обращаются к одному общему ресурсу, и происходит несогласованность вывода данных.

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

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

Заблуждение 7. Ты думаешь, что в университетах надо учить Java, а не фигне типа Pascal

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

Да, первая задача начинающего программиста — это понять, что такое алгоритм и как он представлен в самой распространенной модели. Я бы сказал, что эта модель — высокоуровневая, последовательная, императивная. На ум приходят Java и C++.

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

Заблуждение 8. Кто-то сказал, что незачем оптимизировать код, а ты и не поверил

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

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