О русских программистах
Вот этот пост Андрея Колесова натолкнул меня на рассуждения о наших программистах.
Я уже достаточно давно начал руководить разработкой, но начинал простым программистом. По прошествии многих лет все ощущения от работы как программиста и как руководителя успели систематизироваться. Думаю, что сейчас я готов поделиться ими.
На самой заре 90-х прошлого века я занялся программированием как хобби. Это было интересно, увлекательно. Этакий драйв. Информации по программированию было недостаточно. Были программистские журналы, были какие-то книжки, но они давали лишь пример решения каких-то специфичных задач, а зачастую вообще ничего не давали – авторы писали «мусор». Поэтому у меня все задачи, которые я себе ставил, носили скорее исследовательский характер. При решении этих задач я часто изобретал «велосипед».
Следует отметить, что желание стать профессиональным программистом сподвигло меня на поиск интересной специальности для обучения в институте (на самом деле, в университете). Мне как раз стало интересно направление систем автоматизированного проектирования (САПР) – перспективное, сложное и интересное направление. Реклама сотрудников института сработала и я поступил на соответствующий факультет. Но правда жизни оказалась не такой радужной – на факультете САПР готовили не программистов, а инженеров, которые иногда могут автоматизировать свои расчеты в этих системах САПР. Какое же это было разочарование для меня! Итогом этого разочарования стало то, что я просто бросил институт, не окончив обучения.
Ближе к концу 90-х я занялся программированием профессионально. Это не значит, что до этого я был ламером – наоборот, технические знания были достаточно высокие. Просто я стал получать деньги за то, что так нравится.
Итак, устроившись на работу я попал в коллектив программистов. Вполне понятно, что ранее полученные знания были лоскутными и не давали полной картины, как можно их применять в реальной работе на реальных проектах. Именно эту информацию мне хотелось получить у своих коллег. К сожалению, ни достаточной культуры ведения проектов, ни хороших технических знаний я не нашел – все были почти такими же зелеными юнцами, как и я (при этом контора была одним из лидеров на рынке). В других организациях ситуация была, а зачастую и остается до сих пор такой же плачевной.
В этот момент я принял два ключевых решения для себя: продолжить обучение в институте именно по направлению программирования и самостоятельно обучаться всем премудростям программирования на основе открытых источников (книги и Интернет). Сказано – сделано: восстановился в институте, но на другом факультете, и начал впитывать и анализировать информацию отовсюду, откуда только было можно.
Обучение в институте показало, что в институте не готовят профессиональных программистов. Да, были занятия, которые корелировались с программированием (правда, в таком убогом виде, что это невозможно применять в реальности), а по методологиям разработки, можно сказать, вообще ничего не было (за исключением одного из предметов, но там было все настолько обще и скудно в теории, что на практике это, опять же, невозможно применять). В итоге, успешно окончив институт, я отказался от предложения поступить в аспирантуру – не видел, что она могла бы мне дать, да и что я мог бы принести реально полезное в нашу «науку». Ну а разочарование в нашей системе образования оказалось настолько огромным, что сильно сказывается и сейчас.
С самообразованием повезло значительно лучше – я профессионально вырос, мог выполнять работу архитектора. При этом изучил различные методологии (класса Agile и Rigorous – строгие), которые стал применять и адаптировать в своей команде. Как мне кажется, я получил очень хорошие знания и научился применять на практике знания от технических до методологических. Как это часто бывает с самообразованием, часто приходилось учиться на своих ошибках, но это лучше, чем ничего.
В процессе работы я часто сталкивался с тем, что в команду приходят новые люди. Зачастую, они оканчивали хорошие институты, да еще и с хорошими оценками. Но мое понимание текущей ситуации в образовании не позволяло все принимать за чистую правду – ни красный диплом, ни громкое имя ВУЗа не давали гарантии того, что реклама соискателя на рабочее место окажется правдой. В итоге приходилось выбирать наиболее адекватных (с необходимыми техническими знаниями, со способностью обучаться и с возможностью легко и бесконфликтно встроиться в рабочий коллектив). Ну а дальше начинался долгий процесс обучения и тонкой настройки.
Отдельно расскажу о тех, кто приходил ко мне на собеседования и не получил «счастливый билет». Самооценка у соискателей очень завышена (возможно, что в этом тоже виноват миф об «отличных русских программистах»). Зачастую, приходят совершенно неподготовленные люди, получившие базовые знания о языке программирования и верящие в то, что они могут творить чудеса. При этом они не могут выполнять работу в коллективе, не могут проанализировать задачу и затребовать недостающую информацию. Так же очень часто (около 90% от общего количества) встречаются и те, кто при недостатке информации или наличии противоречий в задании выбирает собственное решение, которое не согласовывает с коллегами (иногда после такого приходится очень долго выправлять ситуацию, чтобы устранить результаты такого «творчества»).
Исходя из выше сказанного я могу отметить основные параметры, по которым можно оценивать разработчиков, а начинающим (а иногда и профессиональным) разработчикам готовиться к взрослой жизни:
- Разработчик должен понимать, что разработка – это не только умение программировать, но и коллективная работа. От каждого конкретного разработчика зависит общий успех проекта. В данном случае действует правило: подвел один – пострадали все.
- У разработчика должен быть внутренний стимул к самостоятельному развитию, обучению. Нет ничего хуже, если человек остановился в развитии и не пытается получать и активно применять информацию в работе.
- Необходимо знать, какие методологии используются при разработке (класса Agile и Rigorous – строгие, например RUP или MSF). Просто знать названия недостаточно, необходимо понимание самих процессов в команде и какие документы должны готовиться при этом. Следует так же учитывать, что в каждой команде присутствует своя адаптация того или иного процесса разработки (хуже, когда ее нет).
- Необходимо понимать, что в большинстве случаев поставленная задача или уже была решена кем-то в подобной ситуации, или при решении задачи можно использовать уже разработанное другими (дополнительные компоненты и фрэймворки). Чтобы не изобретать велосипед, необходимо посоветоваться с коллегами (может, кто припомнит какое-либо решение, свое или чужое), изучить внутреннюю документацию по проекту или поискать в Интернете.
- Иногда определенное решение задачи может повлиять негативно на другие компоненты разрабатываемой системы. Чтобы измежать этого, требуется обязательно консультироваться с разработчиками «соседних» компонентов и архитекторами на предмет совместимости решения и системы.
- Если разработчик делает оценку задачи, то он должен всесторонне проанализировать ее. При этом должны быть определены риски (придуманное в первом приближении решение может не удовлетворять требованиям к производительности или новая технология может сильно затянуть разработку или вообще остановить ее) и пути их устранения, основные направления решения и альтернативные варианты, каким образом будет проводиться тестирование. Часто разработчик оценивает некий идеальный вариант, даже не закладывая время на тестирование и отладку. Из-за этого он срывает сроки и подводит своих коллег.
- После выполнения задачи любой разработчик должен проанализировать результаты своей работы и сделать выводы. Иногда, полученное решение является удовлетворительным на текущий момент, но в дальнейшем потребует переработки. Для этого можно вести список потенциально проблемных мест в решении, чтобы заранее предотвращать возможные негативные последствия, а не ждать, когда гром грянет.
Видите, что я описал параметры для разработчиков, а не программистов? Дело в том, что разработчиком может быть как программист, так и тестировщик и архитектор, одним словом, создатель системы. Ну а данные параметры применимы ко всем – они универсальны.