Текст о профессии разработчика я написал давным-давно, еще когда "Свиттер" на свет не появился. Вот, наконец, решил опубликовать.
В наше время проявить себя творчески не так просто. В крупных компаниях человек может работать с людьми, с документами, что-то продавать, закупать, даже заведовать чем-либо. Но в корпорации человек - это, как правило, винтик. Он мало что решает, даже будучи руководителем. Грустно, что часто трудно понять, для чего нужна та работа, которую ты делаешь. Фермер производит продукт, который можно продать на базаре и получить за это справедливые деньги. Специалист по перестрахованию тоже делает сложную работу, но ее ценность не так очевидна. Торговец на бирже может хорошо зарабатывать, имея достаточный опыт и легкость руки. Его пользу для общества уловить еще сложнее.
* Перестрахование - это распределение рисков страховой компании по ряду других страховых компаний.
Раньше считалось почетным производить некий продукт. Например, владелец мануфактуры являлся очень уважаемым человеком. Ростовщик же, напротив, считался паразитом общества, к его деятельности относились пренебрежительно, хотя, когда нужны были деньги, все равно шли к нему. К сожалению, в понятиях того времени большинство современных работ можно назвать никчемными и паразитными.
Программирование выгодно выделяется среди прочей деятельности. Разработчик своими руками производит программный продукт. Можно сразу увидеть результат своей работы и, если не пощупать, то, по крайней мере, пощелкать его мышкой.
Программист, во всяком случае, на работе, живет в мире компьютеров и программ. Таким людям не свойственны закулисные игры, интриги и прочие дрязги, которые многим портят здоровье и настроение.
Однако, самая главная прелесть работы разработчика - возможность быть творцом. Создавая архитектуру приложения, он определяет структуру и правила создаваемого мира, стараясь придать им как можно большую стройность и изящество. Рисуя диаграммы и чувствуя красоту проектируемой системы, разработчику не терпится приступить к написанию кода, окунуться в придуманный мир. Даже если программист играет не главную роль в разработке приложения, а реализовывает конкретные узлы системы, простора для творчества обычно остается достаточно.
Хороший разработчик пишет хороший код. Он делает это вовсе не для того, чтобы оправдать высокую зарплату, а прежде всего для себя и людей, которые будут работать с этим кодом. Он любит свои программы и создаваемые строки текста. Лучшая похвала для программиста - похвала коллеги. Такие люди могут десятки раз править работающую программу лишь для того, чтобы сделать ее более стройной, концептуально верной и лаконичной. Глядя на качественно написанные исходные тексты, программист получает удовольствие и понимает, что труд был потрачен не зря.
Профессия разработчика прекрасна!
Признаюсь честно: было время, когда я буквально зачитывался исходниками Zend Framework
Подолью ложку дегтя.
Профессия программиста прекрасна до тех пор, пока она не ужимается со всех сторон сроками, бюджетом или иными внешними или внутренними воздействиями.
Пока ты работаешь сам по себе, сам вырабатываешь требования, сам проектируешь систему – ты творец и счастье твое безгранично. Но стоит тебе попасть в рамки командной разработки, в компанию, где в первую очередь важно реализовать, а во вторую – как реализовать, вот тут начинаются проблемы творческого кризиса.
Ты упираешься в стену фреймворка, заставляющего тебя писать так, как это предусмотрено, на тебя валятся сроки и авралы, начальство подгоняет, чтобы заказчик был доволен. Все это давит, все это происходит каждый день, и в конце концов наступает кризис – хочу что-то сделать красивое и полезное, а сил и времени уже не хватает…
Один раз «сгоришь» на работе, потом сразу приходит понимание, что все таки живое общение очень важно для программиста. Чтобы отлично программировалось, нужно удовлетворить другие потребности, которые находятся на более низком уровне)). Это я про то, что «как хорошо, что нет интриг на работе». Кто-то разделяет личную жизнь и работу(и в личной части жизни общения хватает), а у кого-то жизнь и работа это одно целое.
А насчет «видно результаты работы» – это относительно. Если, например, разрабатывать какую-то мелкую часть банковской системы, то её никто и не увидит, кроме нескольких работников банка. Вот и задумываешься о пользе своего такого труда.
Ммм. Я б тоже не согласился, что программист столь творческая профессия. Когда работаешь не один, когда есть сроки, когда есть стандарты, то диапазон для творчества сокращается.
Заказчику, по-моему, вообще пофиг что ты там натворил. Выполнил в срок – молодец, нет – гавно.
Диме просто везет, он пока не работал в крупной компании, где программирование поставлено на поток
Да, я действительно не работал в таких компаниях.
Вероятно, процесс можно так плохо организовать, что даже самый талантливый человек не захочет проявлять инициативу. Но это проблема руководителя. Где-то я читал, что хороший программист приносит в 20 (или 10, но не меньше) раз больше пользы, чем посредственный. Мне кажется, что этот показатель в большей степени зависит не от умственного потенциала, а от степени заинтересованности и отношения к работе.
Наверняка, все помнят, как быстро идет работа над интересной задачей. Можно не заметить, как наступит ночь или даже утро. И если задача не нравится, за день можно ровным счетом не сделать ничего. Получить лишь моральное неудовлетворение от того, что весь день протупил.
Мне кажется, хороший руководитель – тот, кто сможет организовать процесс так, что людям будет интересно. Если же он ставит процесс так, что не оставляет никакой свободы мысли программисту, не воспринимает никаких предложений, а тупо требует кодить «отсюда и до обеда», вряд ли его команда может быть успешной и решить задачу качественно.
Программирование нельзя сравнивать с другими видами деятельности. Например, со строительством. Известно, как построить мост, известны все нагрузки и есть четкая инструкция, как это сделать. При разработке софта требования могут меняться, предельная нагрузка на «мост» не известна и при написании кода не тратится бетон. Здесь нужна гибкость мысли, умение искать нужные велосипеды или изобретать собственные. Нужна смелость выкидывать плохой код и писать его заново.
Стоп, к чему я это?)
Пожалуй, с учетом приведенных выше комментариев, могу сказать следующее. Наша профессия на 100% дает возможность реализовать свой творческий потенциал (и я уверен, что таких профессий немного, по крайней мере востребованных). Если он у вас есть, плохой начальник не должен быть преградой этому. Просто смените работу и получайте от нее удовольствие.
Дело в том, что порой руководитель тоже находится в этих рамках.
В нашей компании, например, много проектов реализуются на фреймворке, который немного неудобен по своей сути, ибо использует устаревшие технологии, такие как VBScript, ActiveX (и это все – для веба). Большая часть системы, ее каркас, уже написан, тебе остается лишь допиливать его. Наверное, в самом начале проекта все было куда интереснее, но сейчас, когда проекту уже 3 года и близится сдача его окончательного этапа, все менее радужно. Руководитель не при чем, просто нет интересных задач и им неоткуда взяться.
Но один проект не показатель для всей компании. Все зависит от заказчика в первую очередь, насколько он готов жертвовать временем, чтобы получить элегантное решение. Плюс есть обновленная версия фреймворка, где все написано на WPF+C#, можно получить удовольствие от современного языка, и именно это меня мотивирует сдать текущий проект побыстрее, чтобы прийти в новый проект, где, возможно, будет интереснее…
Поделюсь своими мыслями по этой теме.
Мне моя профессия очень нравится. Иначе вряд ли бы я добровольно работал каждый день по 12 часов
Не знаю, как насчёт творчества, но больше всего в ней мне нравятся такие моменты… как бы это объяснить? Попробую на примере. Я писал одну небольшую программку для историко-документального департамента (проще говоря — архива) МИДа. Программа только и делала, что позволяла полнотекстово искать по нашему хранилищу документов и показывать результаты поиска. Казалось бы — экая херня. Запрос туда, результаты обратно. Однако у работников архива было другое мнение. Раньше, когда к ним приходил запрос из серии «Посмотрите, какой был номер приказа, по которому меня отправили в командировку в Ливию в 1973 году», им приходилось пешком спускаться в подвал, по памяти искать нужную книжку с этими приказами, пролистывать её в поисках нужного листа приказа, подниматься наверх, ксерить этот лист, делать выписку и тащить её в машбюро, а книгу приказов — обратно. И после этого, когда стало достаточно в одно поле вбить любое ключевое слово (страну, год, номер приказа — что угодно) и получить результат в виде нужных страниц документа с удобной навигацией и поиском, возможностью подготовить выписку и распечатать её — для них это была магия. Вот такие моменты мне и нравятся больше всего. Когда ты понимаешь, что с помощью своих знаний и навыков ты многократно облегчил кому-то жизнь — вот это да. Кроме того — плюс в карму :- )
Вторая мысль, которой я хотел бы поделиться и о которой (как мне кажется) многие разработчики часто забывают. Программист — это вторичная профессия. Вторичная в том смысле, что программист редко делает что-то для себя (как программиста) или других программистов. Он всегда делает что-либо для пользователей. Даже если он работает над какой-нибудь IDE, он делает инструмент для других программистов, которые затем будут делать что-то для пользователей. Даже человек, который пишет прошивку для какого-нибудь умного маршрутизатора Cisco, делает это для того, чтобы пользователи могли передавать свои данные. Как же часто разработчики забывают об этом, my god! Разумеется, программиста можно «измерять» качеством его кода (что тоже есть очень и очень широкое понятие), однако где в этой оценке тот, ради кого всё происходит — пользователь? Кто будет учитывать его? Какой процент программистов никогда не видел в глаза своего пользователя? Не видел, как пользователь работает с его программой? Мне кажется, довольно большой.
Ни один заказчик, я думаю, не захочет «жертвовать временем, чтобы получить элегантное решение». О элегантном решении чего идёт речь? Задачи пользователя (или заказчика, что не всегда одно и то же) или проблем, встающих перед программистом? Если второе, то мне кажется логичным его нежелание не то что жертвовать временем, а нежелание даже знать об этих проблемах. Однако часто бывает так, что программист, решив какую-либо сложную задачу, старается в самом интерфейсе дать понять, через что ему пришлось пройти (а иногда даже провести пользователя по тому же самому пути), дабы пользователь в конце этого пути также испытал удовлетворение от решения такой сложной задачи. Wrong! Ничего, кроме раздражения и ощущения, что ты сам дурак, это не приносит. Если для вас хорошие задачи — это те, которые интересны вам как программисту, а плохие — все остальные, тогда, действительно, может, поискать другую работу?
Третья не мысль, а скорее предложение. В ходе этого обсуждения мелькнули такие слова, как «программирование поставлено на поток», «командная разработка» и другие. Вероятно, это и есть тот самый мифический продакшн, которым нас пугали в универе. В связи с этим у меня просьба к тем, кто в теме: расскажите о процессах разработки ПО в вашей компании/учреждении. Как проходит работа над проектом? Какие должности есть у вас в команде? Какова технология разработки? Какие стадии вы выделяете для каждого проекта? Как и когда взаимодействуете с заказчиком? С пользователями? Как проходит тестирование (вы ведь занимаетесь тестированием, правда)? Проводятся ли у вас, скажем так, «служебные» процедуры, не направленные на улучшение пользовательских качеств продукта: рефакторинг, инспекция кода и т. п. Как и кем подготавливается документация? Как вы осуществляете поддержку своих продуктов? Исправляете ошибки? Добавляете новый функционал? Как определяются границы версий/релизов (если такое вообще есть)? Помимо того, что я честно думаю, что это многим будет интересно просто почитать, я преследую и корыстную, эгоистическую цель. Волю судеб, в нашей компании направление разработки прикладного ПО очень молодое (до момента моего прихода выезжали на аутсорсерах), и я как один из пионеров получаюсь и швец, и жнец и на дуде пиздец. Парень я, конечно, умный, однако опыта всё же маловато, и этим предложением я хочу выманить у вас все тайные шаманские практики разработки ПО, поразмыслить над ними, позадавать вам вопросы и попытаться применить что-то из этого на практике. Примерно так. У меня только одна просьба: не отвечайте цитатами из МакКоннела, Фаулера или из «Herding Cats». Мне не очень интересно, как вам кажется, как должно быть; гораздо более мне интересно, как всё есть на самом деле.
Присоединяюсь к просьбе Андрея рассказать о том, как работает ваша команда разработчиков. Это действительно очень интересно.
Анекдот про пользу для пользователей. Я знаю случай, когда в одной компании некий аналитический запрос выполнялся 10-15 минут. Люди привыкли прийти на работу, запустить этот самый запрос, налить чашку кофе и отправиться на перекур. По завершении этих приятных, но вынужденных дел как раз на экране появлялся результат.
Потом появился некий dba, который поколдовал над Оракловой базой и запрос стал выполняться мгновенно (кажется, он реорганизовал все таблицу как индекс).
На следующий день он наблюдал, как человек вводит параметры запроса, нажимает кнопку и уже тянется за чашкой. Тут происходит замешательство. Человек в недоумении повторяет запрос, нажимает кнопку… Недоумение с оттенком разочарования.
На dba смотрели недобро. Кажется, потом многих поувольняли)
Я вот что ещё хотел добавить. Если по каким-то причинам вы хотите сохранить анонимность своей компании/учреждения, то рассказ о вашем процессе разработки можно прислать мне на почту. В принципе, я мог бы проанализировать ваши рассказы и свести их в одну статью, без указания конкретных имён и названий организаций.
Андрюш, Дим – как выделится свободная минутка, опишу мою компанию и проект, в котором я сейчас участвую. Особо ничего сокровенного сказать не смогу, так как работаю всего 4 месяца и над уже состоявшимся проектом, который заканчивается осенью. Однако мне есть, что рассказать.
Для комментария слишком длинно получилось. Читайте все тут.