[prog.work.idiotic] Решение кадрового кризиса в РБ: перекуем бухгалтеров на программистов!

Ув.тов.Сергей Галичанин поделился ссылкой на статью: Силиконовая Белоруссия. Один фрагмент оттуда особенно доставил:

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

"Если мы возьмем любого бухгалтера, то, во-первых, он уже умеет работать на компьютере, - говорит Мамоненко в интервью изданию "Компьютерные вести". - Второе: ему свойственны, так сказать, качества прецизионности. То есть он не делает ошибок в цифрах. Он умеет работать с программным обеспечением. Сейчас, по данным Всемирного банка, в Беларуси у фирмы на бухгалтерский учет уходит в среднем 900 часов в год. Средняя цифра по миру - 160 часов. А в Объединенных Арабских Эмиратах вообще уходит 12 часов. Поэтому если мы время на бухгалтерию сократим хотя бы в пять раз, то от 400 тысяч бухгалтеров мы оставим 80 тысяч.  А 320 тысяч человек у нас высвободятся. Конечно, это не должно произойти одномоментно - мы рассчитываем примерно на пять лет. То есть специалисты будут постепенно высвобождаться из бухгалтерской сферы, сфера образования их будет "подхватывать". Также никто не спорит с тем, что предоставление льгот привлечет в Беларусь всех мировых лидеров в области IT-образования".

Мамоненко считает, что, если этот проект удастся, переученные бухгалтеры смогут приносить в страну около 7 миллиардов долларов в год:  "Если 150 тысяч индусов в одной компании зарабатывают 10 миллиардов долларов, то почему 300 тысяч белорусов не могут заработать 7 млрд? Мы просто умножили 300 тысяч человек на 15 долларов за человеко-час и отняли 20 процентов, традиционно приходящиеся на время отпусков и учебы".

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

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

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

[life.work] Когда читаю такие поучения…

Вот такие (тема уже древняя, но такие персонажи на профильных форумах раньше появлялись регулярно, не исключено, что и сейчас где-то кого-то “лечат”):

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

Кроме того, я далеко не уверен, что молодёжи есть смысл идти вообще в IT. Есть гораздо более перспективные для карьеры направления. Но если уж решено идти в IT — то потребуется очень многое. В ближайшее же время потребность в низкоквалифицированных кадрах может резко упасть — технологии на месте не стоят, и подай-принесиев очень эффективно заменяет автоматика. Тот, кто хочет оказаться на вершине пирамиды, кто хочет быть мастером, тому потребуется:

— фундаментальное математическое образование, включая все теоретические основы computer science.

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

— умение работать руками. Кто в детстве не играл фанатично с конструкторами — может заранее сам себя отсеять. Модульные встраиваемые архитектуры будут доминировать, и приличная инженерная смекалка и хотя бы минимальное отсутвие криворукости — обязательное требование. Так что, в перерывах между штудированием Цицерона и Сенеки и решением задач по комбинаторики и теорверу, надо браться за паяльник, и творить. Для души.

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

— как это ни банально, но требуется хорошее здоровье. Да и бессонные ночи даром не проходят. В общем — спорт, и ещё раз спорт. Только не тяжелая атлетика и не бокс, конечно же.

Всё это — лет 7-8 после школы. Минимум. Да вы, детки, не пугайтесь — врачи — так те и вовсе, пока не начнут собственно карьеру, учатся более 10 лет. И не жалуются. Радуйтесь, что они так долго учатся — иначе на кладбищах место быстрее кончалось бы. А ведь ответственность компьютерщика часто не меньше чем у врача. Только оплачивается, бывает, существенно лучше.

Итак, отучились мы, сверкаем эрудицией, за плечами не один десяток самостоятельно выполненных учебных проектов во всех отраслях индустрии — можно теперь и о карьере подумать. Все дороги открыты. Такой специалист может делать всё, что хочет, и там, где ему будет угодно. И когда подай-принеси сядут на свой разнесчастный велфер, с тоской вспоминая времена, когда за примитивную работёнку можно было до $6k в месяц взять — они, мастера, будут тащить цивилизацию вперёд, поднимаясь всё выше и по социальной лестнице.

И вот еще оттуда же, феерическое:

К 30 в IT надо бы получать дивиденды, а не зарплату.

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

[life] Сразу видно – усилитель!

[prog] Маленькое дополнение к недавней заметке о читабельности кода

В комментарии к недавней заметке о читабельности кода прозвучала мысль о том, что хорошо было бы сделать возвращаемое методом make_and_send_packages значение именованным. Безотносительно к моему собственному мнению на сей счет, это хороший повод вспомнить принцип Command/Query Separation, который лежит в основе идеологии языка Eiffel.

Если следовать этому принципу, то в моем прикладном агенте не должно было бы быть метода make_and_send_packages. Вместо него потребовался бы вспомогательный класс package_maker_and_sender_t с методом-командой make_and_send и методом-запросом number_of_packages_sent. Который бы использовался следующим образом:

if( !messages->empty() )  {    package_maker_and_sender_t sender( *messages, /* плюс еще какие-то параметры */ );   sender.make_and_send();   m_load_batcher.increment_current_load( sender.number_of_packages_sent() );  }

В Eiffel-е принцип разделения методов на команды и запросы является одним из краеугольных. Мне же представляется, что такое жесткое разделение не всегда разумно. Может из-за того, что я учился программировать на процедурных языках, где функция могла производить побочный эффект (открывать файл, например) и возвращать значение. Поэтому я не вижу в таком подходе ничего плохого. Может из-за того, что command/query separation principle ведет к распуханию кода – туча мелких вспомогательных классов + выполнение самих действий удваивается в объеме: сначала вызов command-метода, затем query-метода. Upd. Забыл про еще один негативный момент: в таких вспомогательных методах появляется лишняя забота о том, чтобы методы вызывались в должном порядке. Так, объект класса package_maker_and_sender_t должен бить программиста по рукам, если тот вызывает number_of_packages_sent до вызова make_and_send. Что так же увеличивает объем работы программиста.

С другой стороны, принцип весьма простой, местами удобный. Особенно в ОО-языках, где нет понятия константности объектов и их методов (т.е. Java, C#, Eiffel, Ruby и пр.). Поэтому вполне может использоваться на практике. В частности, в упомянутой заметке на таком принципе работает класс load_batcher_t, который обладает методами-командами check_for_new_period и increment_current_load, а так же методом-запросом remaining_load.

PS. При следовании принципу Command/Query Separation методы-запросы начинают выступать в роли “чистых функций”, т.е. не меняющих состояние объекта и, по идее, всегда возвращающих одинаковый результат (если только они обращаются к каким-то изменяющимся из-вне объектам). Что может вносить в обычные ОО-языки некоторое подобие функциональщины, где функции не имеют побочных эффектов. Но только подобие, очень бледное ;)

[life] Магазин одежды б/у премиум класса

Большую вывеску с таким содержанием я увидел сегодня на одном из магазинов нашего города. Как по мне, так вещи премиум класса не могут быть бывшими в употреблении в принципе. И данное вывеска – пример оксюморона вроде “светлая тьма” или “живой труп”.

Хотя, может это магазин премиум класса, просто торгует он б/у-шной одеждой, а не сантехникой или мобильными телефонами :)

[prog] На тему читабельности кода

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

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

Все это я в коде видел за исключением самой отсылки пакетов :)

Вот сей фрагмент в первозданном виде:

void a_out_pkg_sender_t::try_send_or_resend_packages()    {       const ACE_Time_Value current_time = ACE_OS::gettimeofday();       m_load_batcher.check_for_new_period( current_time );       const unsigned int max_packages_to_send =             m_load_batcher.remaining_load();       if( 0 != max_packages_to_send )          {             if( m_cfg.m_diagnostic_logging.m_rescan_db_for_resending )                so_log_msg_same_ns( outgoing_package, load_started )                      .max_package_count( max_packages_to_send )                      .finish( *this );             std::auto_ptr< db::out_message_info_list_t > messages =                   m_db->select_out_pkg_for_sending(                         max_packages_to_send,                         date_time_in_past(                               current_time,                               m_cfg.m_notifies.m_out_pkg_throughput.m_resend_timeout ),                         ACE_Date_Time( current_time ) );             if( m_cfg.m_diagnostic_logging.m_rescan_db_for_resending )                so_log_msg_same_ns( outgoing_package, load_finished )                      .messages_loaded( messages->size() )                      .finish( *this );             if( !messages->empty() )                m_load_batcher.increment_current_load(                      make_and_send_packages( *messages ) );          }    }

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

[work.doc] Большая бесплатная книга по LaTeX-у на русском

Из-за работы с опозданием узнал о публикации в Интернете еще одной большой книги по LaTeX-у на русском языке: Е.М.Балдин, Компьютерная типография LaTeX. Автору книги огромный респект и уважуха.

Сам я не большой спец по LaTeX-у, но для написания документации использую именно его. На мой взгляд, для разработчика это намного более удобный инструмент, чем Word. Поскольку написание текста документа происходит почти как программирование, с использованием макросов, подпрограмм и рефакторингом повторяющихся фрагментов ;)

Плюс к тому текстовые LaTeX-овые исходные файлы, имхо, намного лучше приспособлены для совместной работы над документом посредством системы контроля версий, чем Word-овские файлы или какие-нибудь XML-ные DocBook-и.

PS. Пишу LaTeX-овые тексты в ViM-е, использую какую-то версию MikTeX-а, орфографию не проверяю ;)