Программирование как искусство

Мой приятель, директор крупной компании, жалуется: "Представляешь, не могу найти программиста поддерживать работающую систему. Приглашаю, показываю. Если переписывать с нуля - соглашаются за половину зарплаты. Если поддерживать - не соглашаются за две".

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

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

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

Причем сам себе программист говорит с искренней уверенностью, что он учится для того, чтобы на новом проекте или на новой работе применить эти знания. Но программист меняет работу или просто приходит на новый проект, и … опять выбирает для себя следующую новую технологию для реализации. Почему? Потому, что хочет ее изучить и пробует уже на ней сделать проект. Именно пробует сделать, так как результат для него не имеет большого значения. Результат никакого отношения к обучению не имеет, ведь так? Сам себе он выставляет внутреннюю оценку не по достигнутому результату, а по творческому шедевру, изученному пласту документации или созданному коду. Результат - это просто как случайный подарок - может случиться, а может и не случиться (вероятность 1/2 ). Но результат обычно не возбуждает программиста к свершениям, больше интересен процесс профессионального роста или иллюзия роста.

Безусловно, не все программисты такие, но 99% выходящих из университета именно такие. И я был именно таким когда закончил обучение в университете.

Интересно, думаю я теперь, почему мне в университете ни один преподаватель не сказал, что, приходя на работу, мы должны реализовывать бизнес задачу компании наиболее точно и использовать наиболее эффективный инструментарий для этой реализации… А может и говорили, но я не поверил или не услышал, как и все?

В первом банке, который я осчастливил своим присутствием, банковский софт был написан компанией "Инверсия" на FoxPro с DBF файлами. Но мне казалось унизительным, именно унизительным, писать на FoxPro и дописывать чужую программу. Я считал, что это для трусов - типа, настоящий профессиональный программист так не пишет

Я взял компилятор С++, нашел и переписал под Win32, использовал многопоточность (зачем спрашивается , библиотеку для работы с DBF, написал свой парсер отчетов, на котором в последствии и «набомбил» массу отчетов для банка. Замечательный образец полного игнорирования целей и возможностей организации. Я просто учился за счет банка, скажем честно. Причем, никто в банке не был против такой формы обучения, они просто не понимали. Руководители и менеджеры организации понимали, что от ИТ зависит их бизнес, но близко не понимали, какими критериям его измерять и оценивать (и сейчас ситуация не особенно лучше). Конечно, приложение умерло вместе с моим уходом через два года, так как новый программист аргументировано доказал, что это все "фигня" и принялся писать эту же "фигню" на Java (начинала входить в моду тогда).

Но в этом банке я уже усвоил один урок. Меня всегда интересовали SQL-ные базы данных и глобальные сети. Сделав парсер на C++, я сел изучать SQL. Но никакого SQL сервера под рукой не оказалось. И я взял Excel и через ODBC драйвер стал писать SQL запросы к DBF файлам базы данных банка. Нашлось и применение. Я за пару недель сделать полный комплект ЦБ-шной отчетности банка на Excel, причем такой красивой, по тем временам, ну просто жуть Сводные таблицы Excel - вещь выдающаяся. Инструмент и правда получился отличный, пользователь просто ставил даты и получал нужный отчет. Причем, я обнаружил забавный эффект: созданные мною отчеты стали использовать другие программисты, стали править их и делать на их базе свои модификации. Технология оказалась очень дешевой, яркой и эффективной в поддержке для банка. Даже после моего ухода отчеты и инструмент продолжали использовать. Но надо признаться, опять же, правильный эффект был совсем не запланирован. Это был случайный побочный результат изучения мной SQL технологий.

Следующим на моем рабочем пути был Инвестбанк. Вот там мне голову и вправили. Уже в те времена повального FoxPro, в этом банке уже работал Oracle, UNIX сервера… Все приложения были написаны на Oracle Forms и банковский день разработан был Форсом (первые реализации). Скажем прямо, визуально это не особенно привлекательные формы. И я, конечно, не мог не начать высказываться относительно того, что стоит все переписать на Win, что Oracle не лучшее решение, ну и массу других глупостей.

Пользуюсь случаем скажу спасибо Алексею Ежкову, директору по ИТ, Татьяне Кудиной, тогдашнему руководителю отдела Oracle разработки, Архипенко Сергею, моему руководителю. Они улыбались моей наивности и задавали на мои инициативы вопросы про стоимость владения, обучение специалистов, независимый ИТ-аудит для банка, сертификацию ПО и другие нормальные вопросы, которые мне самому почему-то в голову не приходили. Не могу сказать, что они учили меня как-то предметно. Они просто думали так, жили так и по-другому не понимали, как может быть. Они были профессионалами ИТ-бизнеса. Думаю, именно к ним применимо слово Профессионал. И это во многом изменило мой взгляд на вещи.

Может, обучение – это решение своих личных задач и карьерный рост? К сожалению нет. Обучение – это попытка приобрести уверенность, что ты что-то можешь. Но до тех пор, пока программист не нацеливается на решение бизнес-задачи организации, в которой он работает, все его усилия по обучению уходят бесследно, как вода в песок. Бесследно для него лично, так как уверенности он не приобретает, как и славы и денег. В резюме не появляется новых строк, которые были бы ценными для других компаний. Кстати, именно по этой причине многие резюме программистов очень часто выглядят как перечисление всех известных технологий. Мы часто такие получаем, и каждый раз это вызывает улыбку. Технологии меняются очень быстро, ты понимаешь, что со временем надоест без цели изучать новые языки, платформы, команды… да и возраст уже не студенческий. Обучение без цели не имеет большого значения. Но понимание приходит со временем. А как бы хотелось получать эти знания сразу и так убедительно, чтобы не сомневаться и не проверять на своей шкуре.

Да, наша система обучения программистов содержит системный дефект: программистов никогда не учат, что они приходят в компанию для того, чтобы реализовывать задачи компании. Нет у нас в программе обучения программиста тренингов по оптимальному решению задачи организации с использованием тех или иных инструментов, с учетом имеющихся возможностей компании. Кстати, я подобные курсы и вопросы видел в одной из программ сертификации Microsoft (конечно с учетом их решений). Но учить чему-то подобному стоит.

И все же, искусство или ремесло?

Я думаю, что ВСЕ профессии, в том числе и программирование, это и творчество, и ремесло, и искусство. И очень важно учиться, быть всегда на пике своей профессии. Но также важно понять, что такое "профессионализм" вашей профессии. Для программистов профессионализм - это не количество изученных технологий, а, как и для любой другой профессии, критерием профессионализма программиста является профессиональное выполнение поставленной задачи!

Компания ставит задачу, а профессионал выбирает для ее решения наиболее эффективные решения. Действительно, задачи ставят не всегда "правильно" с точки зрения специалиста и не всегда полно. "Хочу дом, 1000 м2 должна быть общая площадь, денег у меня столько, земли у меня столько..." Архитектор оценивает и делает ряд проектов, вписывать в архитектуру города, делает здание заметным, выбирает фасады... В том и состоит профессионализм архитектора, чтобы продумать за заказчика вопросы, в которых он не разбирается и не будет никогда разбираться. Выберет ли архитектор для работы новые материалы только потому, что он с ними никогда раньше не работал, и ему интересно построить такой дом? И не окажется ли потом, что в дом не удается внести ни один стандартный диван, потому что он не проходит в пролет лестницы? ... Как архитекторы, так программисты должны быть специалистами в своей области и не объяснять неудачи тем, что им неполно поставили задачу.

И независимо от профессии все люди делятся на тех, кто ЗНАЕТ как надо делать проекты, и тех, кто на самом деле ДЕЛАЕТ проекты.

Все, что вы знаете и изучали, все, что вы еще изучите, нужно вам не как самоцель, а как средство достижения результата! А все остальное приложится: деньги, слава, женщины, машины и квартиры. Компания сама вытащит вас наверх, потому, что любой компании, как воздух, нужны люди производящие результат. Даже если вы не гений, но делаете результат - вы уже гений!