Профессия - программист

Теорий по созданию программ написано немало, но до сих пор они слабо работают. Так что для того, чтобы научиться писать программы есть один короткий, но весьма трудновыполнимый совет - пишите программы.
Берите любую задачу и пишите. Проектируйте набор классов, придумывайте алгоритм их взаимодействия и снова пишите. Берите инструмент в виде библиотеки, фреймворка и прочая, изучайте, снова придумывайте (просите придумать) задачу, проектируйте и пишите. И только после многочисленных проб и ошибок Вы научитесь думать и кодировать хорошо. Кому дается легко - достигнет высокого уровня быстрее, кто слабее - позже. Но без практики самый талантливый, самый гениальный не научится делать программы хорошо. Так что еще раз - практикуйтесь, проектируйте, кодируйте. Спасибо за внимание.

Среди нас есть Притворщики. Гении, способные стать любым, кем они захотят.
Это вы можете найти в Вики - Притворщик.

Наша профессия очень похожа. За годы работы мне довелось создавать программы в следующих областях:

• Моделирование динамических объектов
• Складской учет
• Документооборот
• Финансовый анализ
• Логистика
• Юридические системы
• Системы обработки статистических данных
• Системы безопасности
• Управление медицинским оборудованием
• Системы мобильных сервисов
• Интеграционные решения для оказания государственных услуг

Пожалуй, хватит. Я уже не говорю о том, что не раз я занимался несколькими проектами по одной и той же тематике. Да и области могут быть еще более детализированы. Вообщем, я тот еще “притворщик”.

Образование у меня техническое, стандартное во времена СССР - высшая математика, физика, сопромат, теормех, начертательная геометрия, электротехника, электроника, философия, научный коммунизм :). Ну и более инженерные - системы управления, системы навигации и прочие спец. предметы. Инженер-электромеханик.
Для многих, кто думает идти в программисты, необходимость знать математику (на самом деле весьма надуманная) является важным фактором не идти в эту профессию. Ну как же там без знаний математики ?
Учитывая невысокий уровень преподавания этого предмета в школах, после которого математика вызывает “такую личную неприязнь к потерпевшему …” - юное создание в шоке. Я очень настоятельно рекомендую - расслабьтесь. Лично мне приличный математический аппарат потребовался лишь для моделирования. Все остальное - там тригонометрии даже не было.

Со мной несколько лет работал программистом … патологоанатом. Сейчас работает в Германии - в одной из крупнейших транспортно-логистических компаний мира. Программистом. В соседней комнате сидит … анестезиолог. Тоже очень неплохой программист.
Если же перечислять технические профессии коллег и кто что закончил, то соберем скорее всего все технические ВУЗы Питера. И не только Питера. Про специальности лучше и не заикаться. Мало того - будет немало тех, кто не имеет высшего образования совсем. И многие являются весьма неплохими специалистами. Потому что нащупали главное - профессия подразумевает быстрое понимание основ и принципов работы области, которую надо автоматизировать. И умение пользоваться определенным набором инструментов для решения разных задач из предметной области.

Таким образом получаем два направления:

1. Предметная область
2. Набор инструментов

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

С пунктом а) - ну тут уже не судьба. Учитесь сами. Или спрашивайте специалистов. Например, меня
По пункту б) - круг инструментов настолько широкий (и этот список постоянно растет), что знать все невозможно. Сужение этого круга позволяет сделать понимание двух вещей:
а) Выделение аналогов. Ну и что, что в магазине молотков 5-6 видов. Вам же нужен один. выбирайте один из нескольких. И знайте, что еще есть другие.
б) Потребностями предметной области. Потому как использование микроскопа для забивания гвоздей не есть разумно.

Как видим, многое определяется пунктом - Предметная область. И набор инструментов, да и сама работа.
И вот тут мы поговорим о “притворстве”. Есть мнение, что программист должен ограничивать предметную область, в которой он пишет программы. Например, только банковское дело или документооборот. Или моделирование. Или разработка систем навигации. Возможно, что в этом есть доля здравого смысла, но я не уверен, что это правильный подход для постижения профессии.
Есть также другие варианты деления: быть специалистом написания пользовательских интерфейсов или только специалистом по разработке баз данных. Здесь я еще более сомневаюсь в разумности. Разве что вы не собираетесь двигать науку или создавать теорию. Потому что перед глазами стоит конкретный пример, когда интерфейс был сделан строго в соответствии с рекомендациями по интерфейсу и был сделан интерфейс с учетом предметной области - выиграл, как вы сами догадываетесь, второй. С ужасающими ошибками с точки зрения теории.

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

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

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

И читайте классиков:
“В настоящее же время лишь немногие ученые могут назвать себя или математиками, или физиками, или биологами, не прибавляя к этому дальнейшего ограничения. Ученый становится теперь топологом, или акустиком, или специалистом по жесткокрылым. Он набит жаргоном своей специальной дисциплины и знает всю литературу по ней и все ее подразделы. Но всякий вопрос, сколько-нибудь выходящий за эти узкие пределы, такой ученый чаще всего будет рассматривать как нечто, относящееся к коллеге, который работает через три комнаты дальше по коридору. Более того, всякий интерес со своей стороны к подобному вопросу он будет считать совершенно непозволительным нарушением чужой тайны …
От математика не требуется умения провести физиологический эксперимент, но он должен уметь понимать такой эксперимент, уметь подвергнуть его критике и уметь предложить новый эксперимент. От физиолога не требуется умения доказать определенную математическую теорему, но физиолог должен быть в состоянии понять ее значение для физиологии и указать математику направление поисков.”
Винер Н. Кибернетика, или управление и связь в животном и машине (1948)

Более, чем за 60 лет мало что изменилось. Правда именно программист напоминает мне математика, понимающего физиологию. Притворщик, что тут скажешь
Так что если Вам хочется быть программистом - определите области, которые Вы хотели бы автоматизировать. И если Вы их видите и готовы изучать вместе с инструментами - то милости прошу в профессию программист. Иначе будет скучно просто кодировать.

Спасибо за внимание.

На днях столкнулся с проявлениями одного и того же, но совершенно по разным поводам.

Итак, ситуация номер 1:
Моей жене, как психологу нарисовали ситуацию: “Папа гулял с дочкой, пора было домой и папа сказал дочке собирать игрушки. Дочка заупрямилась. Папа взял ее и увел с площадки, а игрушки оставил. Правильно ли поступил папа ?”
Ответ: “Зависит от той цели, которую ставил перед собой папа. Если он хотел заставить ребенка собрать игрушки, то цель не достигнута. Если цель - быстрее дойти домой, то цель достигнута. Если цель - показать, что игрушки за дочку собирать никто не будет, то потребуется еще один шаг - не покупать дочке игрушки взамен оставленных”.

Ситуация номер 2:
Наблюдаю легкую перебранку между тестером и разработчиком. Тестер настаивает на том, что нигде не указано, что надо вводить именно латинские буквы, а разработчик пытается доказать, что ничего делать не надо.
На ум приходит ситуация номер 1 - какая у вас цель, господа ?

Именно умение определять цели и находить решения проблем являются проявлением зрелости в профессии программиста.
То, что вы умеет пользоваться несколькими технологиями и в совершенстве владеете каким-либо пакетом (пакетами) отнюдь не означает, что вы сможете решить проблему. Мало того - нередко можно наблюдать ситуацию, когда решение проблемы не ищется. От нее отворачиваются или подменяют другой.
Если вы будете искать решения - вы будете гораздо более ценным работником, чем тот, который просто ждет команды. Это трудно - взять на себя лишнюю работу по определению причин проблем и нахождению решений. Потому что очень заманчиво сказать - пусть заказчик сам скажет, что ему надо. Он бы может и сказал бы, но частенько это все равно, что требовать врачу от пациента поставить самому себе диагноз и уже после этого врач предложит набор средств по лечению.
Увы, нередко программисты поступаю подобным образом - мы хотим точно знать от заказчика, что он хочет получить. А он хочет быть “просто здоровым”. Что для нас означает - надо понять проблему и найти решение.

Спасибо за внимание.

Похоже. это уже возраст. И желание пофилософствовать накатывает все чаще

Думаю, что не буду оригинален и уже неоднократно сам это говорил. Но тем не менее.
В любой профессии, в в особенности в профессии, которая подразумевает накопление умений и знаний, существует два варианта создания великого или просто классного произведения:
1. Вы можете создать гениальное произведение на основе наития, яркой идеи. Просто потому что вам первому пришло это в голову.
2. Вы можете создать гениальное произведение потому, что вы ГОТОВЫ его создать. У вас есть опыт, умение, мастерство и талант. И есть база, на основе которой вы способны решить ЗАДАЧУ.

Оба варианта приносят положительные результаты. Но если вы хотите стать МАСТЕРОМ, то вам по пути с вариантом номер 2.
Можно перечислить немалое количество “почему это так”.
- Потому что вы обладаете знанием всего, что было создано до вас;
- Потому что вы будете создавать что-то замечательное гораздо чаще и проще;
- Потому что вы не будете изобретать велосипед. А если и будете, то вы будете знать все модели велосипедов, которые уже были созданы;
- и много чего еще…

Вообще - МАСТЕР, на мой взгляд, гораздо более востребован, чем ГЕНИЙ. Но самое важное заключается в том, что ГЕНИЙ практически всегда прежде всего МАСТЕР.
Поэтому IMHO - изучайте, пробуйте, достигайте высот, отдавайте сердце. И если вы не проклянете то, чем вы занимаетесь - станете МАСТЕРОМ. А там если вас чем-то кто-то осенил - то и до гения недалеко.
Самое приятное в том, что не надо будет врать самому себе, что “не стыдно за бесцельно прожитые годы”. Т.к. цель была. И была оправдана процессом постижения мастерства.

Спасибо за внимание.

Наконец стало больше времени и захотелось чем-то поделиться
Недавно (в очередной раз) опять позабавило ощущение спиралевидности профессионального роста. Когда-то давно я активно занимался спортом - прыжками в воду (дошел даже до мастера спорта СССР), а потом каратэ. Так что хорошо могу оценить качество движения. Один и тот же элемент может сделать и перворазрядник и заслуженный мастер спорта. Но качество движения будет разным. Или взять первогодку, который делает шаг в ката и человека, который отдал каратэ 10-15 лет. Качество движения иногда может просто поражать - ты стоишь с открытым ртом и понимаешь. что ТАК ты двигаться не можешь. Причем движение может быть достаточно простым.
В профессии программиста существует тоже самое - ты можешь читать код и понимать, кто его писал.
Так вот написание кода, использование инструментов, создание приложений идет всегда (во всяком случае у меня) по спирали. Каждый раз ты переоцениваешь свое умение писать код, строить приложение, использовать инструменты. Ты уже на автомате делаешь то, о чем раньше даже не знал. В какой-то момент времени происходит переход на следующий уровень понимания и ты начинаешь путь заново. Код может быть красивым и ты можешь это видеть. Как стежок опытного хирурга отличается от стежков интерна. Мало того, что опытный хирург умеет делать то, что новичок не в состоянии - он и в мелочи на голову выше. И в этих мелочах тоже есть проявление мастерства.
Надо только научится. И набраться опыта. Может это и есть восприятие/принятие Профессии и Мастерства.

Спасибо за внимание.

Попробую использовать блог в качестве опросника

Уже не первый раз всплывает тема о возможности удаленного обучения на наших курсах (Разработчик JEE), но я не знаю ответы на некоторые вопросы. Предположим, что я найду софт и установлю. И тогда:

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

2. Некоторые моменты приходится объяснять у доски - а значит на приличном расстоянии от камеры. Которая вряд ли обладает слишком приличным разрешением на большом расстоянии. Ну это вообщем техническая проблема, но она тянет за собой следующий вопрос

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

Если вы придумаете достаточно причин делать бесплатно эту работу или придумаете вариант бизнеса, который можно построить на этой схеме - буду работать в этом направлении.

Последние два-три года меня неотступно преследует ощущение, что IT на пороге огромных изменений. Набрана критическая масса, которая готова к превращению во что-то совершенно новое. Даже более верно будет сказать, что это уже случилось. Плотину прорвало. Я говорю не о программном обеспечении, а о восприятии информационного мира обычными пользователями.
Когда-то давно, на заре алгоритмических языков мы пользовались стандартными библиотеками. Причем библиотеки решали (и решают) достаточно специализированные задачи. И это казалось большим достижением.
Теперь мы (не только программисты, а все пользователи Интернета) используем глобальные сервисы. В отличии от старых файлов библиотек, которые подключались на стадии компиляции, сервисы мы используем в режиме on-line. Причем сервисы решают задачи, которые являются глобальными - их используют миллионы (сотни миллионов) пользователей. И програмисты теперь должны это учитывать.
Конечно же я не говорю о том, что текстовый редактор на компьютере тети Маши не важен. Его надо тоже писать. Но сегодня вы можете зайти на Гугл, отредактировать файл и допустить к его обсуждению (или редактированию) тех, кого хотите. Причем файл доступен просто потому, что он в сети. Вы можете получить к нему доступ откуда угодно и с какого угодно устройства.
Мы начинаем жить более публично, более социально. И судя по популярности форумов, соц. сетей - нам это нравится. Под “мы” я опять подразумеваю не только программистов - я подразумеваю всех, кто пользуется компьютером и Интернетом.
Настала эра, о которой Sun говорил много лет назад: “Компьютер - это сеть”. Пользователь должен (и несомненно будет) иметь возможность работать со своими данными из любого уголка Земли, в любое время и с любого устройства (которое конечно что-то может делать в сети). А также пользоваться глобальными (или корпоративными) сервисами: mail, YouTube, Facebook и т.д. и т.п.

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

Как вы уже догадались, речь идет о СОА (сервисно-ориентированной архитектуре). По идее понятие СОА для пользователей совершенно не важно - но оно становится крайне важным для современных программистов. Так что СОА ждет нас с нетерпением.

Спасибо за внимание.

“И вечный бой, покой нам только сниться”.

Это больше не профессиональная заметка, а заметки на полях. Мы часто сталкиваемся с тем, что должны использовать “по политическим мотивам” не то программное обеспечение, которое считаем нужным и удобным в данной ситуации, а то, которое было продано. Или будет продано.
Поэтому к коммерческим продуктам я отношусь сложно. С одной стороны они иногда предоставляют удобные функции, с другой - они стоят немалых денег. Об взаимоотношениях коммерческих и свободных программ я постараюсь написать в другой раз.

Возвращаясь к прерванному - когда ты пытаешься донести до начальства, что в данной ситуации надо использовать то-то и то-то, а тебе навязывают использовать совсем другое, и обосновывается это не техническими требованиями, а тем, что “продукт уже купили, и надо оправдать его покупку”, мне не очень по себе. Бывает, что оправдание еще циничнее - с лицензии можно получить какую-то денежку тебе родному. Вернее не тебе лично, а компании. Единственное, что спасает, это если покупной продукт действительно решает проблему. С этим еще как-то можно жить.
Устраивать революцию из таких ситуаций конечно же не стоит, но может тогда пора появляться фирмам, которые будут делать независимую экспертизу и за нее получать деньги ? Написал “независимые” и сразу ощутил, как немало людей улыбнулись, кто-то может даже приготовил помидор для метания. Но тем не менее выход, на мой взгляд, есть - независимость строится на конкуренции. Одна фирма предлагает решение с одними продуктами, другая - с другими. Третья может вообще оценить все варианты и выбрать наилучший.
Продавать экспертизу можно и нужно, но почему-то пока я не вижу спроса на нее. Это может экономить фирмам приличные деньги. Надо только им до этого дойти.

Видимо, у нас пока нет авторитетов - нет фирм, людей, которым можно доверять (их опыту, их деловой репутации) и которых нельзя подкупить. Вернее, купить можно что угодно - важно предложить правильную цену. И это не только деньги. Предложите продукт, который для данной задачи подходит гораздо лучше, чем остальные. Покажите, сколько можно экономить на разработке и поддержке - и это может подкупить. И я скажу “Да, это решение стоит тех денег - покупайте этот продукт”. Жаль, я о таком только говорю - видеть такое мне не удавалось. Вернее пару раз я в этом участвовал - правда продукт покупали по моей просьбе и для моего использования. Но как бизнес это пока не наблюдается. Спасибо за внимание.

Сразу оговорюсь, что высказанные ниже мысли могут не совпадать с мнением других программистов.
Я полагаю, что немало неудачных архитектур и проектов начинались с неправильной формы написания требований. Я имею в виду не сам набор функций - он является уже следствием еще более ранней ошибки.
Как обычно начинается большинство наших ТЗ (технических заданий) ?
“Система предназначена для …”, “Система выполняет следующие функции … “.
Кто принимал участие в 2-3 крупных проектах (или даже не очень крупных) прекрасно знает, что список этих функций будет меняться, что логика работы не вечна. И это уже никого не удивляет - это совершенно нормально. Мы уже научились жить в таком мире. И есть способы проходить это малой кровью Работаем не “водопадной” моделью, а “циклической”. Делаем минимальный набор наиважнейших функций и смотрим, что получилось. Ну и т.д. Те самые RUP, XP, Agile и прочая.

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

Спасибо за внимание.

За свою профессиональную деятельность я прочел немало книг и в итоге пришел к следующей классификации:

1. Книга-мысль.
Основную идею и назначение этой книги можно выразить в одном предложении. Или абзаце. Все остальное - разжевывание этой же мысли. Как мысль - это может быть просто здорово. Как книга - зачем столько лишних слов ?

2. Книга-учитель
После такой книги все последующие можно оценивать так: если больше 10-15% нового - хорошая книга попалась. Такая книга дает каркас, на котором можно легко понять практически все. Их лучше читать перед книгами 3.

3. Книга-справочник
Читать нередко очень скучно и много приходится пробовать на практике. Но после них читать чаще всего ничего уже не надо. Обычно это туториал, который идет с продуктом. Правда не всегда он хороший. При возникновении вопросов ответы можно найти именно там.

Абсолютного рецепта выбора книги у меня нет, но есть некоторые подсказки:
- Просмотреть оглавление
- Почитать введение
- Поискать примеры кода и описание работы этого кода
Оглавление и введение дают информацию об области применения. И если ничего не понятно - может ну эту книгу. Пример кода и описание дают информацию - а понятно ли это все написано.

Стопроцентного попадания не гарантирую, но ошибаюсь редко. Спасибо за внимание.