Людей, которые пишут код, можно разделить на два типа: кодеры и программисты. Дмитрий Соколов, сооснователь Alef Development, на примерах из рабочей практики объясняет, как отличить их друг от друга, и рассказывает, почему любить код, стараться не использовать «грязные» методы программирования и решать задачу не быстро, а качественно — крайне важно.
Семь признаков того, что ты не станешь программистом
https://rb.ru/opinion/ne-programmist/
Колонки
Автор: Дмитрий Соколовhttps://rb.ru/author/dsokolov/
Для начала стоит разобраться с терминами. Кодером может быть любой человек, чей IQ позволяет заниматься интеллектуальной деятельностью. Он решает набор типовых задач по образцу. В целом это не сложнее, чем решать школьные и институтские задачи по математике.
Программист — это образ мышления. Он не впадает в ступор, столкнувшись с задачей, решение которой не знает с ходу. Программист придумывает свои подходы к работе и стремится разобраться, как все системы и алгоритмы устроены изнутри.
Фундаментальными отличиями программиста от кодера являются:
влюбленность в дело (если человек в жизни не написал ни единой строчки кода для себя, потому что нравится, — вряд ли он является программистом);
подход к программированию как к искусству (стремление к построению архитектуры, которая радует глаз, и поиску красивых решений задач, а, главное, получение от этого неподдельного удовольствия).
Все остальное — уже следствия из этих базовых различий:
программист смотрит на любую задачу шире, продумывая и предусматривая все особенности, а кодер решает задачу поверхностно и очень редко заглядывает за рамки формулировки;
программист заинтересован в том, чтобы его решение работало как можно лучше – кодер хочет сдать задачу побыстрее.
Например, у нас есть задание «сделать программу, которая при нажатии на кнопку рассчитывает ближайшее простое число, начиная с числа, введенного в поле ввода, и показывает его на экране».
Типичный подход кодера: найти первый попавшийся алгоритм поиска простых чисел в интернете и реализовать его. Или найти готовый код, добавить кнопку, прикрепить к ней обработку нажатия, проверить пару раз. Все, программа готова.
Возможный подход программиста:
найти разные алгоритмы поиска простых чисел, изучить их и выбрать наиболее подходящий,
реализовать его,
внедрить проверку введенных данных и продумать уведомление об ошибке, если число написано в недопустимом формате,
проверить алгоритм на большом количестве разных примеров и прийти к выводу, что для больших простых чисел расчет занимает много времени,
добавить индикатор загрузки и заблокировать кнопку, чтобы избежать повторного нажатия.
Программист постарается избежать решения задачи «грязными» способами, если есть другой выход.
Вот пример из реальной жизни. В базе данных одной системы была негласная закономерность: идентификаторы объектов начинались с цифр, соответствующих дате их создания (908157567437 — обозначало, что объект создан в 2009 году, 15 августа).
Это не было задокументированной особенностью, такой вывод можно было сделать только на основе наблюдений. Никакой гарантии, что так будет работать всегда, не было. Вместе с этим существовала надежная возможность узнать дату создания объекта, обратившись по связке к другой таблице, — такой способ требовал больше времени и усилий.
Фото: Unsplash
Нашлись люди, которые из-за банальной лени много лет делали отчеты, пользуясь закономерностью совпадения первых цифр идентификатора. В январе 2010 года эта закономерность неожиданно перестала работать, и все даты в отчетах стали отображаться некорректно.
Ошибка получилась, потому что люди сэкономили время и не стали подтягивать фактические данные из таблицы. Хороший же программист не сможет спать нормально, если в решении задачи используются предположения, вместо фактов.
В этом примере сбой было легко обнаружить и исправить. Но бывает так, что ошибка не проявляется годами, возникает в каком-то сложном случае и снова исчезает, а все вокруг ломают голову, что же это было. Если такая халатность будет иметь место в программе по управлению марсоходом, реактором на АЭС или автопилотом самолета — цена может быть очень высокой.
Важно отметить формулировку «постарается избежать», приведенную выше в тезисе. В реальной жизни хороший программист все же иногда прибегает к «грязным» решениям, взвешивая все «за», «против» и цену вопроса.
Допустим, что программисту понадобился инструмент для единоразового анализа большого объема специфических данных. Для разработки красивой архитектуры понадобится неделя работы, но можно выполнить задачу и за 30 минут. Получится некрасиво, зато инструмент отработает как надо и никогда больше не понадобится. Искусство быть хорошим программистом заключается и в том, чтобы осознанно нарушать «красоту», когда это оправдано.
Признаки непрограммиста
Вернусь к заголовку статьи. Итак, программистом никогда не станет человек, который:
не получает удовольствия от написания кода;
не использует законы логики в повседневной жизни;
при виде сложных вычислений или страницы кода впадает в уныние и хочет, чтобы это поскорее убрали с его глаз долой;
не готов проводить много часов, анализируя свои ошибки и занимаясь поиском лучших решений;
не умеет самостоятельно обучаться новому;
не интересуется фундаментальным устройством компьютера: что такое процессор и его команды, как устроена оперативная память, во что превращаются программы после компиляции;
печатает двумя пальцами и не планирует переучиваться.
Прежде всего любой программист начёт с изучения потребностей, истинных целей задачи и бизнес-логики и только потом начнёт работу над задачей. В примере с простыми числами у вас всё-равно описан кодер, чуть немного более продвинутый, но всё-же кодер.
В 80% случаев истинные цели задачи можно сделать по-другому, проще, быстрее, перенести задачу в другую область или вообще не делать.
Задачу с формой, выводящей простые числа вполне мог поставить плохо соображающий менеджер, потому что он решил что именно так это нужно сделать.Николай Янкин
Николай, спасибо за комментарий. Согласен с вашими уточнениями. Я старался не перегружать пример деталями и обозначил лишь некоторые особенности, чтобы читатель уловил главную суть различий.Dima Sokolov
А сейчас уже принято делить на три типа - кодеры, программисты и разработчики. Последние еще задумываются об added value для бизнеса и концепции good enough. Например, фича которая окупается 375 лет или оптимизация алгоритмла которую можно заменить на планку памяти - работа может и приятная, но пользы продукту фактически не приносит. У разработчика в приоритете не написать идеальный алгоритм, а решить задачу бизнеса максималтно эффективно.Alexander Avdeichik
Да, можно ввести и такой способ разделения. Изначально формулировка про разделения на 2 типа появилась из постановки вопроса статьи. "Кто никогда не сможет стать программистом?". Именно для того, чтобы определить кто такой программист перед началом рассуждения на эту тему. Я, конечно же, не имею в виду что это единственный способ разделения.Dima Sokolov
Странная философия. Всегда считал что кодер это кто хорошо разбирается в низкоуровневом машинном коде, а программист - общее название профессии.Родион Гречишкин
Родион, вероятно, ваше определение слова кодер тоже встречается. Проблема в том, что нет какого-то единого источника, на который можно было бы ориентироваться при определении подобных понятий. Но, в целом, в большинстве источников, которые встречаются мне, это слово имеет смысл сходный с описанным мной.
В этой статье я рассказываю, что именно понимаю под "кодером" и что под "программистом" скорее в контекстуальном смысле, чтобы в дальнейшем опираясь на эти слова дать ответ на вопрос статьиDima Sokolov
Мне кажется это больше крик души, чем осознанная статья)Nikita Titov
Да, мне кажется, что любой человек, который в этой жизни нанимал и менеджил программистов, в середине статьи начнет кивать головой и утирать слезы.Stas Goldenshluger
Почитал статью и не понял самой первой строчки в аннотации «Людей, которые пишут код, можно разделить на два типа: кодеры и программисты».
На мой взгляд, это, как минимум, странное разделение.
Кодер – человек, который пишет код.
Программист – человек, который пишет программы.
Все программы – это код в том или ином виде. По свойству транзитивности, программист = кодеру.
Разработчик, как заметил Alexander Avdeichik, это уже немного другой программист-кодер, с чем абсолютно согласен, но надо оговаривать разработчик чего (например, бэкенд сайта – это тоже разработчик, но сайта).
Вернусь признакам, которые Дмитрий выделил в самом финале статьи:
С 5-7 согласен на 100%.
Дальше хочу поговорить о каждом пункте:
Пункт 1. Лично я не получаю дикого удовольствия от написания кода, но для меня это и НЕ необходимое зло. Мне нравится делать удобные системы. Для УДОБСТВА, а не тупого написания кода ради кода.
Пункт 2. Согласен, что хорошо думать логически в жизни, но к кодерам это не имеет отношения. Если человек умный (а кодеры именно такие в большинстве своём), то они думаю логический, а не действуют наобум.
Пункт 3. Наслаждения от муторного описания кода в 1000 формул без простого алгоритма ничем не привлечёт моё внимание. Я писал программу по анализу изображений. В формулах - огромное, сложнейшее математическое нечто (даже системой назвать сложно). Зато, в алгоритмах всё становится понятно: "Тут "мусор удалил", тут эрозии добавил". Нужны формулы - гугл в помощь или тех. документы к программе.
Пункт 4. Классно, конечно, сидеть много часов над одной программой и думать как сделать её лучше и интереснее реализовать, анализируя решения других программистов, но когда сроки горят, а ты сидишь с формулой сокращения памяти в 3 бита, это пустая трата времени для собственного удовлетворения.
Дмитрий, простите, за резкость, но Вы вышли на публичную сцену и говорите вещи, который читают люди (в том числе и подрастающие программисты или непрограммисты). Не стоит давать такие жёсткие разделения, если в них нет необходимости.
К слову, почитали статью с коллегами-программистами (кодерами или ещё кем в данном Вами разделении) и в офисе встал вопрос: «Ну а мы-то, тогда кто?!»Валерий Линьков
Валерий, спасибо за комментарий!
Вся селедка – рыба, но не вся рыба – селедка. Все программы это код, но не весь код является программами, особенно работающими и качественными. Именно про эту разницу написана статья.
1) Программист – не тот, кто получает удовольствие от программирования всегда, а тот кто получает его хотя бы иногда; умеет видеть красивые задачи и наслаждаться изящными решениями.
2) Здесь речь идет, не о достаточном, а о необходимом условии. Если у человека есть логическое мышление, из этого вовсе не следует что он станет программистом. Смысл этого пункта в том, что если у человека отсутсвует логическое мышление – он не сможет стать программистом.
3) Речь идет не о наслаждении, а о способности воспринимать и структурировать большие объемы сложной информации. Да, сложность и интересность задачи часто не коррелируют друг с другом. Называться полноценным программистом вы можете только, если способны разбираться в сложном.
4) Программист должен уметь взвешенно выбирать качество разработки против скорости. Об этом я как раз написал перед списком. Некоторые люди всегда выбирают "оптимизировать 3 бита, не считаясь с потерей времени", некоторые наоборот всегда решают "делаю быструю затычку, не важно, к каким проблемам она приведет в будущем". Умение балансировать эти подходы – признак профессионализма.Dima Sokolov
Дмитрий, спасибо за ответ!
Сейчас абсолютно с Вами согласен!
Спасибо за коррективы и разъяснения! С учётом комментария статья получается прекрасной!Валерий Линьков
ну а если я могу скачать имейлы с hh в файлик - я могу стать "праграмистам"?Капитан Ларин
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter