Coders vs Programmers
Данная статья написана по просьбе одного моего хорошего друга, который часто задается вопросом по профессиональном развитии. Если мы берем IT-сообщество в целом, то мы часто можем увидеть такие определения как "кодер" и негативное "говнокодер". При это часть людей в то же время удостаиваются званий "инженер" или "программист". В этой статье я попытался ответить - а что это за такие сущности, с чем их едят и почему появились.
Важная ремарка
Данная статья не является попыткой кого-то обидеть или оскорбить. На мой скромный взгляд любая из специализаций так или иначе полезна для общества. И только общество (и бизнес?) способны оценить вклад того или иного конкретного человека в продукт.
Если же кто-то с чем-то не согласен... Буду рад увидеть Ваше мнение, которое Вы в праве высказать. Как и я высказал свое, в рамках этой небольшой статьи.
Ниже приводится видение индустрии автором, не более того. Вероятны исторические неточности и прочие путаницы.
Кто такие программисты?
Если верить Wiki (а ей верить можно всё меньше), то программист (ссылка) - это специалист, занимающийся программированием. То есть человек, который создает какие-либо компьютерные программы.
И такое определение было достаточно долго корректным, ведь компьютеры были большими и сложными, использовались для решения достаточно сложных и объемных задач. Особенность этого периода для профессии - необходимость хорошо понимать как работает "машина". Слоев абстракции или совсем нет, или они достаточно малочисленны. Отсюда же - языки низкого уровня, сосредоточенность на том как работает программа (а не то, что она в итоге будет делать), привлечение к решению задач исключительно профессиональных сотрудников.
Со временем, большие и дорогие компьютеры стали проникать в стратегически важные отрасли (оборонка) и разного рода НИИ, а ограниченность бюджета приводит к идее, что вчерашний "физик" вполне мог быть писать нужные ему расчеты без привлечения дорогих и мало разбирающихся в предметной области специалистов. Как итог - IT отрасль реагирует и появляются инструменты, которыми могут пользоваться уже чуть менее квалифицированные кадры (операционные системы, языки более высокого уровня и т.д.). Это приводит к зарождению "отраслевых" программистов, т.е. специалистов разрабатывающих программное обеспечение для конкретных отраслей или областей знаний. Такой инженер чуть менее подкован в IT, но зато понимает что именно он пишет (а не просто берет и "вслепую" реализует описанные формулы). Это дает нишевые продукты достаточно высокого уровня, начинают появляться первые "потуги" в сторону UX. Ведь теперь программист хоть и думает о том как это работает, но уже может уделить какое-то временя вопросу в вопросе "как это будет работать" время на интерфейс, учитывать пожелания пользователей.
Но, с начала бума персональных компьютеров, обычный пользователь получил доступ к вычислительной технике и стал использовать её уже для решения своих, бытовых проблем: написание документов, ведение учета, чтение, прослушивание музыки, общение и т.д.
Именно бум развития персональных компьютеров и привёл IT как отрасль к появлению среди программистов так называемых "прикаладников" (прикладной программист), которые уже работали не с железом или профессиональной предметной областью, а занялись решением описанных бытовых потребностей. Параллельно с этим компании начали так же осваивать персональные компьютеры и заявлять о желании решать свои рутинные задачи с помощью них.
Важно: я понимаю, что исторически бизнес-клиенты шли перед физическими лицами и знаю об этом. Но считаю, что именно спрос со стороны физических лиц был основой для дальнейшего развития. Именно с этим связан такой порядок.
Что было дальше, мы все прекрасно знаем - Microsoft, Apple, окно в web, а дальше и мобильный трафик. Скорость появления новых потребностей возрастает и компаниям, которые разрабатывают программное обеспечение надо как-то ускоряться. В условиях ограниченного бюджета. Как итог - IT реагирует появлением таких вещей как SDK, которые позволяют быстро и просто собирать минимально-жизнеспособный продукт, чтобы дальше его дорабатывать. А продавать уже сейчас. Как следствие - люди, которые работают с такими технологиями уже не должны зать всего того, что было необходимо в ранних периодах. Ведь инструмент дает ещё больший уровень абстракции.
Как ещё можно сделать разработку дешевле? Дать мультиплатформу - возможность писать программу один раз для всех приложений. С одной стороны начинают появляться языки, которые позволяют это сделать чуть менее затратно и начинается java-покалипсис. Пришествие Java и развитие концепций языка программирования Smalltalk (который, внезапно, не только про ООП) позволяет создавать продукты быстро и дешево. А можно сделать еще дешевле, если придумать какой-нибудь Python, которые сведет все возможные алгоритмы к одному правильному решению, а все, что связано с типами - просто выкинет из области ответственности программиста. Ведь его задача уже не придумывать как именно должна машина решать потребность, его задачей стало - решить потребность на абстрактной платформе, под конкретный SDK. И такой специалист уже не должен знать сложную и большую теоретическую базу. Фактически - для современного программиста компьютер стал просто машиной, которая способна запустить некую среду выполнения, которая уже реализует тот самый конечный автомат. Именно он берет на себя все вопросы реализации взаимодействия с ОС и userspace, управление памятью и прочими мало интересными для потребителя вещами. А появившееся время можно потратить на оттачивание программы, её пользовательского функционала. Чтобы сделать её проще и понятнее.
С другой стороны - раз не нужны глубокие познания, то можно и специалистов искать подешевле. И вот тут мы приходим к одной из причин зарождения понятия "кодера".
Но мы все же о программистах. Давайте выделим признаки настоящего программиста:
- Понимает как работает его программа на уровне железа.
- Способен понять бизнес-задачу не глубоко, но из-за применения инженерного подхода при корректной постановке задачи - может её решать качественно.
- Хорошо разбирается в алгоритмах, может решать задачи не имея под рукой подходящей библиотеки.
- Занимается как прикладными задачами, так и архитектурой.
- Может работать с любыми языками и технологиями за счет широкой теоретической базы.
- Делает долго и постоянно ссылается в сроках на необходимость работ ввиду технического решения. Чаще всего говорит правду, иногда - просто хочет довести код до какого-то своего идеала.
- Являются фанатиками, изучают все подряд и без причины. Просто потому, что обладают врожденной тягой к познанию.
- Пропагандируют идеи первых хакеров, любят ковыряться в новом.
- Не могут писать хорошую документацию. Для её освоения чаще всего потребуется подтянуть знания до уровня автора.
- Не переваривают гибкую разработку и SCRUM, так как это вносит неопределенность в процесс работы.
- Интересными считают сложные задачи. Для большинства людей они покажутся рутиной.
Основные проблемы программистов
Проблема у настоящего программиста одна - это то, что он хоть и является прикладным специалистом, все же остается инженером с вытекающей из этого "квадратно-гнездовой логикой". Иллюстрирует это бородатый анекдот:
Настоящий программист ставит на ночь 2 стакана воды. Один полный, на случай, если захочет попить. Второй - пустой, если пить не захочет.
Если вы попытаетесь потребовать от такого специалиста думать о клиентах... они будут страдать. Да, код, который он напишет будет соответствовать всем требованиям. А вот удобство использования... об этом можно забыть. Дело в том, что в своем поведении инженер отталкивается от сущности. И будье уверены - интерфейс взаимодействия будет коррелировать с тем, что крутится внутри системы. Со всеми шагами, которые требуется сделать машине, чтобы сущность работала.
Стоимость таких специалистов... это не проблема, а данность. Ведь применение высококвалифицированных кадров не может быть дешевым. Как говорит один очень квалифицированный специалист в IT и бизнесе "глупо ожидать от уборщицы, что она может спроектировать дом". Поэтому, если бизнесу нужно надежное и расширяемое программное обеспечение, соответствующее критериям скорости и отказоусточивости - надо привлекать программистов и платить за их труд.
Кто такие кодеры?
Как мы уже выяснили - часто минимально-жизнеспособное приложение бизнесу нужно вчера. Ведь конкурент уже стартовал или вот-вот выйдет на эту позицию. И гонка за деньги будет проиграна. Кто первый - тот и победит, это хорошо иллюстрирует история. Посмотрите на ошеломляющую капитализацию компании Apple, которая не была первой в плане разработки технологий, но первая внедряла в свои продукты то, что могло решить проблему потребителя.
Что есть у бизнеса, по-факту, на руках? Есть россыпь языков, которые позволяют писать не инженерам работающий под (упомянутый Python, его наследник в лице Go и еще с сотню языков). Еще большая куча технологий/фреймворков/SDK, которые позволяют особо не задумываясь об архитектуре наваять работающее решение. И для этого не надо знать вот эту всю сложную теорию. Достаточно хорошо знать как решать задачи на конкретном "стеке" (наборе языков, библиотек, программ - наборе технологий).
Так же часть сложных и больших программ содержат внутри себя упрощенные языки программирования - базы данных, учетные системы, игровые движки, CAD, офисные пакеты... чтобы пользователь мог удовлетворить потребности о которых пока не знает бизнес по разработке программного обеспечения в продукт начинают встраиваться языки программирования, позволяющие это сделать. А так же - автоматизировать работу. И люди, пишущие код для таких продуктов в целом уже могут знать только очень малый набор технологий и алгоритмов, которые реализованы в окружении конкретной программы. Зачем тут дорогие и "умные" специалисты?
IT отрасль и тут отреагировала на запрос рынка, выдав специалистов, которые будут названы сообществом "кодерами". Фактически это очень узкие прикладные специалисты, способные решать задачи только на определенных инструментах. Да, это уже не "универсальный" инженер, способный на все. Зато делает быстро и дешево.
У этих ребят проблем очень много. Но все же сначала о признаках:
- Поверхностное представление как это все работает, чаще всего не выходящее за рамки стека и без подробностей на уровне ниже операционной системы (в лучшем случае) или используемой платформы (в худшем). Имеют поверхностное представление о работе своего же кода.
- Почти нулевое знание алгоритмов и паттернов. Где-то на уровне их "гроканья" и рассказов на митапах как круто использовать фабрики.
- Не понимают чистых парадигм, не способны писать чистый код. Хотя поддерживаемый при регулярном избиении выдать способны.
- Если что-то выходит за рамки их стека - отказываются изучать, ведь их универсальный стек и так умеет все, что нужно.
- Отлично разбираются в предметной области. Все, что они не затратили на учебу в IT было потрачено на освоение задач бизнеса.
- Понимают потребности обычного человека, не понимают квадрат-гнездовую логику.
- Могут выдать очень быстро решение на основе проработанной архитектуры.
- Не могут работать без IDE и прочих примочек, очень много говорят о культуре кода. Правда не соблюдая её при первой же возможности.
- Могут писать на самом деле хорошую документацию. Её сможет понимать любой студент.
- Помешаны на эмпатии, гибкой разработки и фанатеют от SCRUM.
- Очень любят говорить об интересных задачах, хотя сами не могут сформулировать их критерии.
- Больше гуманитарии, нежели инженеры по мышлению. Чаще - очень не последовательны.
Основные проблемы кодеров
Как и говорил - их много. Но дабы не растягивать и без того не маленькую статью, просто скажу - их проблема почти полное отсутствие теории тех навыков, которые они приобрели за годы работы. Это специалисты которые могут сделать то, что от них требуется - но они не смогут вам объяснить почему именно так это должно было быть сделано.
И да, они в теории могут писать хороший, стандартизированный и поддерживаемый код. Даже могут правильно применить паттерн или алгоритм, ведь когда-то они уже это делали и так именно работало.
И очень хорошо, если такой кодер будет согласен наверстать то, что он пропустил. Но, чаще всего, он откажется это делать. Ведь дополнительных денег здесь и сейчас он за это не получит.
Кто и зачем нужен бизнесу?
И так, мы поныли кто такие инженеры.
И вроде бы кажется, что кто-то является лишним "на этом празднике жизни". Но это - не так. Более того - критика программистов к кодерам, а кодеров к программистам является глупой. Ведь каждый аргументирует с позиции того, что с ними представитель его же "подвида" IT-специалиста.
Сразу скажу, рынку и бизнесу нужны и те, и те. Вопрос кто и когда их будет использовать и для каких задач.
Когда нельзя применять кодера?
Если вам надо сделать сложную архитектуру, вы занимаетесь сейчас тулингом (разработка средств разработки для программистов), решаете задачи уровня "железа" (микроконтроллеры, здравствуйте!) или хотите сделать собственную платформу/язык/операционную систему - кодеры нужны только для решения рутины и под надзором программистов. То есть - нельзя выпускать кодера туда, где нет сложившейся экосистемы.
Что ими делать? Любую рутину, которая решит проблемы пользователю. Есть задача, которая нужна была вчера? Кодер посчитает её даже творческой.
Вообще, одна из лучших стимуляций для кодеров - это некие соревнования, где он может одержать верх. Ему хочется быть победителем (инженеры же в основном придерживаются другого подхода - в соревнованиях есть проигравшие, зачем иметь шанс на поражение?).
Когда нельзя применять программиста?
А вот с программистом все с точности до наоборот. Если у вас есть сложившаяся экосистема, все задачи представляют собой "творческую рутину" нет никакого платить огромные деньги за человека, который понимает как это все внутри работает.
А вот если у вас есть область, которую надо оптимизировать, создать экосистему и так далее - то это дело программиста. Кодер просто "не вытянет" эту задачу, не хватит квалификацию. А вот в рамках созданной экосистемы сделать 100500-ую форму для печати отчета - он будет незаменим. Ведь программист такую задачу скорее всего или просто будет не хотеть решать, или будет придумывать "комбайн", чтобы автоматизировать свой процесс.
Вместо заключения
Что тут добавить? Надеюсь вам было интересно и вы стали лучше различать "типологию" людей, пишущих код. А главное - больше нет предвзятого мнения.