Исследователь бытия » Мысли

Карго-культ в программировании

intr13 — Sun, 28 Feb 2010 03:48:53 +0000

Культ карго или карго-культ (англ. cargo cult — поклонение грузу), также религия самолётопоклонников или культ Даров небесных — термин, которым называют группу религиозных движений в Меланезии. В культах карго верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В культах карго проводятся ритуалы, похожие на действия белых людей, чтобы этих предметов стало больше.

Источник Википедия.

Недавно я стал безработным программистом и стал искать новую работу. Сейчас я уже нашел один интересный вариант, но когда я его искал, то столкнулся с рядом компаний и людей, которые были поклонникам Карго-культа. Особенно трепетное отношение я увидел к unit-тестированию, у многих unit-тесты отсутствуют как класс, и они думают что если у них появятся unit-тесты, то произойдет чудо и “кузнечик запиликает на скрипке”.

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

Конечно, “правильные” подходы в Карго-культах важны. Иногда они позволяют чего то достичь, но истинные достижения невозможны без понимания плюсов и минусов. Надо знать когда процесс не работает, чтобы его успешно применять.

И напоследок ряд ссылок на почитать (самое интересное порой в комментариях):

Shu-ha-ri для программистов – об уровнях понимания
МИМУКРАПП – Методология Использования Методологий для Ускорения Карьерного Роста и Акселерации Прозводства Программ – о командных плясках с бубном вокруг костра разработки и том что не все вещи работают.
Читай код – о том что надо понимать что ты делаешь, и тренировать свое понимание.
Очередная солянка сборная – рекомендую прочитать комментарии о документировании исходного кода.
О божественном знании – немного об опыты айтишников, Бритва Оккамы штука полезная.
Programming Styles – о стилях программирования, и программистах Карго-культа. Осторожно, там немного специфический юмор.

И давайте думать, прежде чем делать.

p/s
К сожалению, не могу найти еще одну ссылку на холивар: о чтении умных книг неподготовленными людьми. Например когда студенты, читают книги о шаблонах рефактиринга или шаблонах проектирования, а потом не помыв руки лезут править код. Да порой это плохо и вредно, но путь без ошибок не бывает. Кстати и учится порой не у кого, есть только книги.

Делу дело или мечты о захвате мира

intr13 — Fri, 19 Feb 2010 14:49:47 +0000

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

Плюшкин уже начал представлять, как результаты реализованного проекта стукнут по серости жизни в этом задрипанном регионе. И мир изменится и нефтедоллары потекут рекой, причем не Default сити, а в его родной Русланск. Возможно даже на этот раз получится захватить этот глупый мир, а не случится казус как в прошлый раз. Но все это потом, а сейчас надо впарить заказчику Проект. И потому Плюшкин, начал писать План.

Прикинув пару интересных технологий и найдя пару кошерных фреймворков Плюшкин задумался. А ведь действительно, какое дело представителю заказчика Кумесову, до технологий. Ему ведь в первую очередь интересен результат, причем результат такой, чтобы хватило денег на новую машину для ночных гонок по улицам Руслановска или поездки на модный Киукоршаталь. Но тут Котов прервал его глубокий транс.

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

p/s
Все совпадения с данной реальностью случайны. Если вы проводите параллели или находите похожие ситуации, то это целиком на вашей совести

Сдвиг парадигмы. Черновик.

intr13 — Sat, 13 Feb 2010 18:04:58 +0000

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

Зайдем с другой стороны. Я люблю изучать теории классификации людей по различным признакам и контекстам. Недавно я прочитал про две интересные теории:

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

Кстати, если вы подчиняете свою жизнь данным теориям, то скорее всего вы “закостенелый неудачник”. Но я наверное увлекся, и речь совсем не об этом

Я хочу сказать, что данные теории позволяют понять суть процессов после того как они произошли. То есть приведенные теории очень слабо применимы в предсказании поведения нормальных адекватных людей, не говоря уж о том, что сложно запихать 6 миллиардов людей в четыре типа. Статистически они могут работать для предсказания поведения “неразумного стада” (леммингов), но вряд ли вы постоянно общаетесь с большим количеством людей

Подытожу, что данные теории хороши в двух случаях: проведение ретроспективы поведения человека и определение поведения человека который действует на автомате (возможно движимый стадным чувством). Первый вариант я рассматривать не буду, ведь интересно знать что сделает человек, а не что он уже сделал. Второй же вариант интересен, если рассматривать разум человека как две составляющие: подсознательные процессы и сознательные процессы.

Для начала рассмотрим подсознательные процессы. Теорий описывающих что такое подсознание много, но ни одна из них не имеет научного подтверждения. Мне нравится определение-аналогия, что подсознание это компьютер который выполнят различные виды подпрограмм. Хотя конечно тут не все так просто, эти подпрограммы сложны и не чета тому, что сейчас разрабатывают великие программисты И я считаю что использование различных теорий поведения человека оправдано только на данном уровне. Данные теории представляют собой поведенческие “таблицы Брадиса”, и в грубом приближении работают почти всегда.

Если рассматривать сознательные процессы, то тут подходит определение-аналогия, что сознание это оператор компьютера-подсознания. К сожалению не все готовы управлять своим поведением на данном уровне. Возможно только пресловутые 10 процентов могут это. Стать рабом своего подсознания очень просто Кстати, те кто пытается жестко управлять своим подсознанием тоже скорее всего не в выигрыше. Они обычно очень не эффективно тратят силы своего организма, ведь подсознание знает как все делать правильно, оно лишь не до конца уверенно что надо делать.

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

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

Практики которые я возьму с собой

intr13 — Sat, 30 Jan 2010 15:02:02 +0000

Я имею довольно небольшой опыт работы в сфере разработки программного обеспечения (всего 6 лет), но я уже накопил ряд полезных и правильных практик, которые можно использовать при создании программного обеспечения.

Только прежде чем читать, учтите тот факт, что я работаю в области разработки приложений на Java, потому буду рекомендовать средства учитывающие данную специфику. Также учтите, что это пока черновик, и ваши замечания (в том числе по орфографии и пунктуации) будут полезны

В конце рабочего дня подведение краткого итога, и письменный ответ на три вопроса: что было сделано, какие проблемы возникли, что планируется сделать. Также неплохо предоставить данную информацию всей команде (электронная почта, внутренний блог), и если у них будет интерес, то они могут прочитать данный отчет. Полезность данной практики неоценима, каждый кто составляет отчет задумывается в конце дня над вопросом: а что он сегодня полезного сделал. И ради ответа на данный вопрос уже стоит использовать данную практику. Кстати, некоторые заметят что данная практика писутствует в Scrum методологии. Но я первый раз увидел ее на Иркутском Авиационном заводе, мне о ней рассказал один очень интересный человек.
Все материалы по проекту должны быть сосредоточенны в одном месте. Например, ссылки на логи общения с заказчиком или URL, для репозиториев исходного кода. Порядок никогда не бывает лишним, а порой очень сильно способствует повышению производительности.
Надо управлять требованиями заказчика. Что понимается под таким общим утверждением? Все просто, все запросы на изменея вносимые в проект от заказчика должны быть зафиксированны в электронном виде. В тяжелых случаях заказчик должен ставить подпись под каждым своим требованием. Да это бюрократия, да интереснее писать код, но без этого ваш проект имеет очень высокую вероятность провала. Хотя тут многое зависит от.
После получения задания от заказчика надо объяснить своими словами что он хочет. Данная вещь очень важна, без нее очень часто реализовываются вещи которые хочет разработчик, а не заказчик. Хоть это и звучит дико, но тут надо искать компромис, ведь разработчик тоже не дурак и понимает к чему приведет реализация странных требований.
Повесить на общее обозрение диаграмму описывающую архитектурные особеннности проекта. В идеале рядом с ней повесить диаграмму с ходом движения работ по проекту. Это позволит поднять уровень коммуникации между членами команды на принципиально иной уровень. Главное не забывать тыкать пальцем в элементы диаграмм при обсуждении проекта.
Исходный код проекта должен хранится в системе контроля версий. Особенно это важно когда код пишет более одного человека, хотя я уже не представляю себе как можно писать код без системы контроля версий. Наверное у меня комплекс, но мне нужен хотя бы SVN для комфортной работы.
Должна быть инструкция для настройки рабочего окружения по работе над проектом. Если данного документа нет, то получается истинный хаос при подключении нового человека в проект. Да и передача дел значительно затрудняется. Вики по проекту это идеальный вариант.
Использование системы управления задачами. Наличие данной системы позволит более продуктивно исправлять различные проблеммы и не забывать про них. Не забывать это хорошо. Кстати, я рекомендую обратить внимание на Redmine.
Наличие описания сборки проекта. Если каждый раз сборка проекта это череда магических пасов, и собрать проект может только единственный гуру в команде, то это бардак. Если будет описание процеса сборки приложения хотя бы в текстовом виде это значительно упростит работу работу всех членов команды, и избавит от ряда глупых вопросов. Идеальный вариант когда процесс сборки приложения автоматизирован (например при помощи Ant или Maven), тогда счастье разработчиков поистине безгранично.
Разработка unit-тестов. Это очень противоречивая практика, иногда unit-тесты разрабатывать нецелесообразно, да и не все можно протестировать в рамках отведенного бюджета. Но когда unit-тесты есть и написанны правильно это очень сильно повышает уверенность разработчиков в устойчивости исходного кода. Тесты можно писать на JUnit.
Использование системы непрерывной интеграции. Возможно вам это и не надо, но меня очень уж радует факт того, что каждый день происходит сборка системы, и возможно проходят все тесты. Это значительно повышает уверенность в разрабатываемой вами системе. Я рекомендую обратить внимание на системе непрерывной интеграции Hudson.
С опаской относится к независящим от вас системам. Например ставить mvn-proxy репозиторий (я рекомендую Nexus), и пользовать его, а то вдруг глобальные репозитории упадут. Интернет ненадежная штука.
Быть готовым к изменениям. Не все изменения одинаково полезны, но надо быть готовым принять разумные вещи и использовать их в своих целях. Я рекомендую использовать мозг.

Все вышеприведенные практики были полезны для меня лично и если они будут полезны вам, то я буду рад. Кстати, данные практики в основном описывают что необходимо делать для поддержки процесса программирования, но не затрагивают процесс планирования хода работ. Сам процесс программирования и полезные плюшки для него (например расслоение системы на уровни, использование шаблонов проектирования) я пока решил опустить, но к ним я еще вернусь

И напоследок: не забывайте думать, прежде чем делать!

UPDATE 2010-06-09: причесанная версия данного текста на хабре.

Жизнь которую я возьму с собой

intr13 — Fri, 29 Jan 2010 13:17:52 +0000

Одно время показывали фильм про человека, которому в конце трудовой деятельности стирали память об его работе в компании. Причем данный факт был закреплен в трудовом контракте. Идея наверное хорошая, с точки зрения компании. Никакие ее секреты и наработки не уйдут в другие компании. Но вот хорошо ли это для конкретного человека? Разве компания не платит ему зарплату? Что ему еще надо? Да и обидно, компания вкладывала в человека время и ресурсы, а он берет и уходит! Эдакая неблагодарность!

А ведь если задуматься, то человеку в работе нужны не только деньги. Также он хочет получить признание, ощущение нужности, опыт, и ряд других полезных для него плюшек. И самое интересное, что эти дополнительные вещи очень сложно закрепить в трудовом контракте. Например, как измерить уровень опыта или ощущение нужности? Но оставим философский вопрос: “Чего хотят люди?” И задумаемся о моменте ухода человека из компании.

Имеем: человека, компанию, трудовое соглашение, работу и так далее. И вот человек решил уйти, и нет причин по которым он может остаться. Заявление написано, завершены попытки договорится об отмене данного заявления, и человек уходит. Для большинства правильных компаний (которые действительно работают) это плохо, ведь человек встроен в текущие процессы, он знает и умеет. И просто так извлечь его из процессов потребует их перестройки и возможно значительно снизит эффективность компании. А это деньги! Да и человек владеет информацией о работе компании, которую он потом может осознано или неосознанно использовать при работе в других компаниях. Если с потерей винтика можно справится путем резервирования и избыточности, то что делать с потенциальной возможностью человека использовать информацию о работе компании?

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

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

В принципе разумное зерно в данном документе есть, но есть несколько “но”. Во первых, что делать если опыт человека уникален и может быть использован только в компаниях конкурентах? Что делать человеку после увольнения? Хороший специалист, подметающий улицы, это очень грустное зрелище.

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

Хорошо, “но” я привел, осталось понять что с этим делать. Самое главное это понять что любое соглашение имеет ценность, как материальную, так и не материальную. И всегда договариваться надо на берегу. Например, если бы сейчас существовала работающая технология стирания памяти о работе в компании, то я бы отказался работать в такой компании. Нет материальных ценностей которые бы позволили мне уничтожить часть своего опыта и личности. Другим примером может являться соглашение, в котором сказано, что человек не имеет права работать три года в компаниях конкурентах. Я бы возможно подписал данное соглашение, но и цена уплаченная мне работодателем была бы высока. Очень высока!

Итогом я могу сказать что любое соглашение (трудовой договор) имеет ценность и должно быть оценено как в материальных так и не материальных вещах. И если вы задумываетесь только об одной из ценностей, то вряд ли вам нравится эта жизнь.

p/s
И не забывайте про банальную честность.

Эксплуататоры программистов в Иркутске. Взгляд со стороны программиста.

intr13 — Fri, 16 Oct 2009 16:45:58 +0000

Жизнь в небольшом городе на окраине нашей страны имеет как свои преимущества, так и недостатки. Основное преимущество – это родное окружение, вокруг тебя – друзья и родственники, которые всегда помогут и поддержат. Недостаток тоже существенен – это отсутствие интересной и высокооплачиваемой работы. Сложно быть профессионалом, когда хочется кушать:)

Но в последнее время этот недостаток начал нивелироваться, крупные компании стали открывать свои филиалы, а местные компании стали испытывать потребность в профессиональных программистах. Правда не все так гладко в датском королевстве, но и никто не говорил что будет легко:) Ладно, оставим философские вопросы для встреч друзей, и посмотрим что творится на рынке разработки программного обеспечения в городе Иркутске.

Кстати, я постарался, чтобы приведенное ниже мнение было не только моим. Мне помогали следующие эксперты:

Кирилл Лебедев
Антон Черноусов
Максим Пензин

Также огромное спасибо:

Константину Бурову
Александру Петровскому
Павлу Ситникову
Григорию Ткачуку
И всем другим, которые пожелали остаться неизвестными:)

Итак, начнем?

Для начала давайте посмотрим, а кто вообще пользуется услугами программистов в городе Иркутске. Список эксплуататоров можно найти здесь. Список конечно не полный и в нем есть ряд неясностей, но все же он говорит о том, что:

Программисты в Иркутске имеют место быть, и их порядка 150 человек.
Основные используемые языки программирования: 1С, PHP, Java, Delphi, C, SAP/R3 (скорее всего в порядке убывания популярности).
Средний размер команды 7 человек (от 1 до 40 человек).
Средняя зарплата для опытного программиста находится в рамках 25-50 тысяч рублей, а для программиста среднего уровня в районе 15-30 тысяч рублей. Хотя тут как повезет:)

Если у вас есть замечания по списку или по моим скомпилированным выводам, то пишите комментарии, будем обсуждать:)

Ладно, хватит цифр и сомнительных выводов, давайте пообщаемся с нашими экспертами. Я подготовил для них список вопросов, а они уделили свое драгоценное время, и ответили на них:)

Максим Пензин.

Что вы можете рассказать о себе?
ФИО – Пензин Максим Юрьевич, сайт-визитка – www.penzin.ru, род деятельности – работаю по контрактам, руковожу группой разработки ПО Иркутского Онкодиспансера.
От себя добавлю:
Максим очень интересный человек, один из самых посещаемых сайтов Иркутска – angara.net, который посвящен туризму (в том числе экстремальному), это его детище. Также по мнению многих он является гуру во многих вопросах посвященных программированию.
Давно вы занимаетесь разработкой программного обеспечения?
Первую программу на заказ сделал в 1988 году (ПЭВМ Искра: CGA монохром, односторонний флоппи 160кб, ТурбоПаскаль 2.0)
От себя добавлю:
В 20 лет написать первую программу на заказ, и особенно если учесть что это был 1988 год, это круто:)
Почему вы решили стать программистом?
С детства мечтал стать конструктором, а компьютерная среда как нельзя лучше подходит для этого.
Как изменилась ситуация на рынке разработки программного обеспечения за последние 5 лет?
Сложно ответить.
Что будет на рынке разработки программного обеспечения через 5 лет?
Сложно ответить.
Вы или ваши знакомые ищут программистов? Если да, то какие программисты им нужны?
Умеющие самостоятельно ставить задачи и решать их не кидаясь из
стороны в сторону, работающие на результат, и в срок. Одновременно с этим не забывающие о самообразовании.
От себя добавлю:
Есть такая формула: книги + программисты = деньги. Я считаю что настоящий программист никогда не забывает о самообразовании, и не ждет когда его вынудят обстоятельства:)
Что нужно делать, чтобы стать востребованным на рынке разработки программного обеспечения?
Необходимо учиться смотреть со стороны клиентов/пользователей/и т.п. Понимать особенности цикла жизни ПО и требуемых ресурсов на разных этапах его разработки. А только потом решать, что круче или что концептуально правильнее.
Ваше пожелание, совет для программистов города Иркутска?
Перестать искать документацию на русском языке
От себя добавлю:
Также писать комментарии на английском языке при выгрузках в систему контроля версии.

Антон Черноусов.

Что вы можете рассказать о себе?
ФИО – Черноусов Антон Владимирович, сайт – golodnyj.ru, работаю в ИСЭМ СО РАН Начальником Научно-технического центра информационно-вычислительных сетей. Самый голодный java-разработчик города Иркутска. Обожаю опасные бритвы.
От себя добавлю:
Антон это вообще нечто феерическое, это уникальная смесь профессионализма с желанием учить других людей правильному и хорошему:) На его лекциях никогда не бывает скучно, он вовремя может разбавить скуку резким словцом или интересной байкой. Да, кстати он преподает в ИрГТУ. Также он ведет аудио-подкаст о программировании – The Art Of Programming. И самое главное – он кампус амбассадор в ИрГТУ.
Давно вы занимаетесь разработкой программного обеспечения?
С начала 2000 года, но тогда это было ужасно примитивно.
От себя добавлю:
Начинать профессиональный путь программиста на втором курсе университета, это самое правильное. Главное начать, а дальше уж не отвертитесь:)
Почему вы решили стать программистом?
Прежде всего, практическая необходимость и тесная связь с системным администрированием заставили заняться этим не самым благодарным делом. Потом втянулся, процесс и результаты приводили меня в восторг. Как-то так незаметно и стал разработчиком.
От себя добавлю:
Он притворяется, он очень хороший программист. Хотя и системное администрирование ему удается:)
Как изменилась ситуация на рынке разработки программного обеспечения за последние 5 лет?
Хороший вопрос. Сделаем уточнение, на каком рынке? На Иркутском! Все как обычно: тихо как на кладбище, только падальщики (1С-разработчики) могут находить заказчиков. А в целом рынок стало более цивилизованным. Меньше кидалова. Больше умных заказчиков. Положительная динамика на лицо, несмотря на кризис.
От себя добавлю:
Действительно рынок становится все более интереснее и цивилизованнее. Уже потенциальные заказчики начинают понимать, что и как им нужно. Например, я недавно общался с заказчиком, который требовал грамотно составленный лицензионный договор на разработанное в моей компании ПО.
Что будет на рынке разработки программного обеспечения через 5 лет?
Глупо загадывать. Думаю Java и .Net платформы будут как и сейчас в значительной степени востребованы. Возрастет востребованность outsource-разработчиков. Кросплатформенные и мобильные приложения будут занимать большую долю чем сейчас.
От себя добавлю:
Действительно в последнее время количество outsource-проектов значительно возросло. Уже сейчас есть несколько компаний, для которых основной источник дохода – это outsource-разработка.
Вы или ваши знакомые ищут программистов? Если да, то какие программисты им нужны?
Дело в том, что хороших сотрудников всегда мало. Нужны как всегда:
ответственные, грамотные, активные. К сожалению, материальное вознаграждение в России всегда хромало. И здесь, я думаю, если что-то и измениться то только после того, как на нашем рынке пропадут откаты. А это не произойдет в скором времени.
От себя добавлю:
Действительно откаты – это бич современной России, тем более, работа в откатном проекте демотивирует. Цель не сделать проект, а заработать как можно больше бабла. В итоге проигрывают все кроме тех, кто распределяет откатные средства:) А про то, кто нужен работодателю можно послушать здесь и почитать тут
Что нужно делать, чтобы стать востребованным на рынке разработки программного обеспечения?
Считаю, что хороший программист обладает двумя важными качествами – головой и жопой: головой он думает, а с помощью жопы доводит дело до конца!
От себя добавлю:
Точка зрения Антона очень хорошо коррелирует с мнением Джоела Спольски. Но в целом все именно так и есть!
Ваше пожелание, совет для программистов города Иркутска?
Учите английский язык.
От себя добавлю:
Особых вариантов нет:)

Кирилл Лебедев.

Что вы можете рассказать о себе?
ФИО – Кирилл Сергевич Лебедев, в ИрГТУ, начальник Центра Интернет-технологий и начальник учебной части МОЦ Aptech-ИрГТУ.
От себя добавлю:
Кирилл – это просто кладезь разной полезной информации, нет вопросов на которые он не знает или не придумает ответ. Он как рентген видит потенциальные проблемы в любых проектах и очень хорошо оценивает риски. Балуется преподаванием в ИрГТУ, ведет там технологии программирования. Имеет сертификат архитектора программного обеспечения от компании Tekama. И самое главное, он забавный зануда:) Но с ним можно долго, продолжительно и интересно разговаривать на АйТи темы:)
Давно вы занимаетесь разработкой программного обеспечения?
Около 10 лет.
От себя добавлю:
Благодаря Кириллу я начал свою плавание в океане профессионального программирования. Спасибо тебе Кирилл, хотя ты не всегда прав:)
Почему вы решили стать программистом?
Семейные традиции + особый склад мышления, требующий использование системного подхода к решению задач и поиска нетривиальных решений.
От себя добавлю:
Первый раз я увидел человека, у которого один из родителей занимается программированием, хотя скоро подобных традиций станет больше:) А мышление действительно важная штука, я например, неосознанно тренировал его при помощи огромного количества книг:)
Как изменилась ситуация на рынке разработки программного обеспечения за последние 5 лет?
В Иркутске никак, а в мире появилось веб-программирование, как конкурент десктопа. Причем именно конкурент, а не дополнение. Соответственно сильно изменились как подходы к созданию ПО, так и взгляды на то, когда и что надо использовать.
От себя добавлю:
Действительно веб-программирование стремительно наступает на рынке разработки программного обеспечения. Но тут надо без фанатизма, иногда обычные десктоп приложения более эффективны.
Что будет на рынке разработки программного обеспечения через 5 лет?
Все больше Интернета и гридов. Все больше будет уменьшаться роль программиста как самостоятельной единицы, так как объем информатизации все увеличивается, что требует большей предсказуемости процесса создания ПО. Программист – это аналог конструктора в машиностроении. Вот девиз развития отрасли в России.
От себя добавлю:
Вряд ли когда-нибудь будут требоваться только программисты-конструкторы приложений. Без разумных и творческих людей индустрия разработки ПО не обойдется.
Вы или ваши знакомые ищут программистов? Если да, то какие программисты им нужны?
1С – специалисты. Универсальные верстальщики и PHP-кодеры.
От себя добавлю:
На самом деле в Иркутске иногда нужны .Net и Java программисты. Можете пройтись по списку
Что нужно делать, чтобы стать востребованным на рынке разработки программного обеспечения?
Иметь хорошее портфолио, опыт разработки проектов (желательно крупных), хорошие связи (правда для многих программистов это прямо скажем задача просто непосильная). Жить в Москве или Питере.
От себя добавлю:
На данный момент все большую популярность набирает удаленная разработка. Например, на odesk.com есть много Заказчиков, правда за заказ придется немного повоевать:)
Ваше пожелание, совет для программистов города Иркутска?
Группироваться и объединяться. Индусы и китайцы берут массовостью. Мы должны тоже работать не по одному. Было бы классно, если бы я мог сказать, что знаю большинство программистов из Иркутска хотя бы в лицо. В целом нашей отрасли в Иркутске не хватает открытости.
От себя добавлю:
Тут иногда публикуются планируемые встречи программистов. Также в ближайшее время будут новые встречи Иркутской JUG.

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

Стремиться не выйграть?

intr13 — Wed, 01 Jul 2009 14:11:46 +0000

Довольно интересный взгляд на достижение результата в управлении проектами – Стремиться не проиграть. По мне так мысль интересна, но если делать все по принципу ”как не хуже” (ключевое слово – все), то может случится коллапс. Люди любят самовыражаться:)

p/s
И не забывайте что сила в простоте. И самое главное – дозируйте фанатизм при достижении простоты. В простоте сила, но ведь нужна сила чтобы достичь простоты:)

Управление неизвестностью

intr13 — Sat, 02 May 2009 15:02:16 +0000

После публикации записи – “Черная дыра agile“, вышел у меня с коллегой спор о необходимости планирования и оценке сроков реализации проектов. По его мнению, планирование и оценка сроков мешает созданию программного обеспечения. И особенно это касается создания новых продуктов, аналогов которых нет, или аналоги находятся в начальной стадии разработки. Причина проста: разработка программного обеспечения довольно сложный процесс, и предсказать истинную сложность процесса практически нереально! И поэтому вместо занятия ерундой надо писать код!

Его точка зрения показалось мне интересной, и я начал смотреть статистику:)

The Standish Group выпустила свой ежегодный отчет о состоянии дел в программной индустрии:

32% проектов завершились успешно, 44% испытали различные трудности (превысили бюджет, выпали из сроков и пр.), 24% проектов просто провалились. Результаты ухудшились по сравнению с предыдущим годом. А если взглянуть на отчеты за последние N лет, то какого-либо значимого изменения увидеть не удастся.

Другими словами только 32% процента проектов были завершены в соответствии с ожиданиями заказчика. Причем это статистика по буржуям, а в России все должно быть еще веселее.

Ну так вот, повторю вопрос моего коллеги еще раз: «Зачем планировать и оценивать сроки реализации проектов»? Не лучше ли найти отечественных исполнителей, и пусть они делают проект, причем не тратя лишнего времени на планирование и оценку сроков (возможно минимальные работы по планированию).

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

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

Понимание сложности проекта позволит понять:

Потянет ли исполнитель проект? Есть ли у него необходимые ресурсы (люди, опыт)?
Потянет ли заказчик проект? Есть ли у него необходимые ресурсы (деньги, время)?

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

Не спорю, мой коллега идеалист, но статистика пока на его стороне:) Время нас рассудит:)

p/s
Картинка найдена здесь.

p/s/s
Кстати, где найти ответственных и проверенных исполнителей? Я пока знаю только одну компанию

Черная дыра agile

intr13 — Fri, 24 Apr 2009 14:45:45 +0000

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

Кстати, на данные размышления меня подтолкнула аудиозапись презентации Стаса Калканова “Agile – взгляд со стороны бизнеса” (44 мин., 10 Мб).

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

Вообщем используйте agile с большой осторожностью и не забывайте что автоматизация бардака даст автоматизированный бардак!

p/s
Тут есть еще немного аудио записей.

p/s/s
Картинка взята здесь.

Пациент скорее мертв, чем жив

intr13 — Tue, 03 Mar 2009 15:36:46 +0000

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

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

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

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

Но не все так плохо, шаманов и магов можно использовать вместе. Причем это дает довольно неплохие результаты, если правильно организовать взаимодействие внутри команды. Но если в команде устроить демократию, то вы увидите нулевой результат. Как я уже говорил: Резать мясо и отвечать за результат должен только один хирург.

Рассмотрим гипотетическую ситуацию: в команде есть два программиста-шамана и два программиста-мага. Если мы устроим демократию и все решения будут приниматься путем голосования, то самый опытный шаман переругается с самым опытным магом и результат будет нулевым (если у них опыт и талант одинаков). А остальные программисты будут смотреть на их ругань и тупо ничего не понимать.

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

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

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

p/s
Терпеть не могу грязный хирургический стол (плохо организованный процесс разработки), даже копание в трупах не так страшно (поддержка унаследованного кода). Когда вы не доверяете процессу разработки, то это диагноз.

p/s/s
Настанет время великой чистки! Товарищ Сталин готовьте списки!

Продай слона

intr13 — Sat, 03 Jan 2009 08:57:15 +0000

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

Цитата от пресс-центра США:

Мы не обманываем, мы просто медленно сообщаем правду.

В 90-х годах наша семья жила довольно бедно, питались мы овощами. Мясо и рыба были деликатесом. Да и к тому-же мы только переехали в город Иркутск. Тогда моя Мама начала продавать различную еду на нелегальном рынке. И ей приходилось обвешивать и обманывать других людей. А почему? Ответ банален прост – все вокруг нее занимались тем же самым

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

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

Поэтому чтобы заработать нормальные деньги на продажах, порой надо умалчивать правду, и даже откровенно врать. Но готовы ли Вы на это? Я вот например не готов

p/s
В России нормальные деньги это когда доходы компании на 100 процентов превышают расходы В Европе норма 10-15 процентов

p/s/s
Уезжать я не хочу, мне нравиться эта бесшабашная страна )

p/s/s
А теперь взглянем на ситуацию с точки зрения подготовленного заказчика Он специально выбирает компанию, которая ответственно относиться к своему делу, но не имеет большого опыта работ. Ответственное отношение к делу проверяется путем проверки предыдущих заказчиков у этого исполнителя И дальше он просто заставляет и продавливает исполнителя и получает приемлемое качество за приемлемые деньги Но и исполнитель не остается в накладе, он получает бесценный опыт работы с подобными заказчиками

Исследователь бытия » Мысли

Карго-культ в программировании

Related Posts:

Делу дело или мечты о захвате мира

Related Posts:

Сдвиг парадигмы. Черновик.

Related Posts:

Практики которые я возьму с собой

Related Posts:

Жизнь которую я возьму с собой

Related Posts:

Эксплуататоры программистов в Иркутске. Взгляд со стороны программиста.

Related Posts:

Стремиться не выйграть?

Related Posts:

Управление неизвестностью

Related Posts:

Черная дыра agile

Related Posts:

Пациент скорее мертв, чем жив

Related Posts:

Продай слона

Related Posts: