О жизненных тяготах инженеров-программистов

[fregimus]

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

Вот, например, задача, которую я могу переформулировать для простоты так. Каждое целое число n изоморфно упорядоченному множеству цифр в своей десятичной записи S(n). Найти сумму по модулю 9 всех чисел, изоморфных элементам булеана множества цифр S(n) данного числа n. Например, для числа 123 это (0+1+2+3+12+23+13+123) mod 9. Алгоритм должен работать по крайней мере для n ≤ 10⁸⁰.

Задача в принципе не сложная. Мне хватило минут 15 на то, чтобы допереть до алгоритма решения. Что меня потрясло, так это то, что трое лучших олимпийцев решили эту задачу за, соответственно, 86, 90 и 96 секунд. В это время вошло чтение задачи — а там несколько абзацев текста с несколькими примерами чисел, придумывание алгоритма и написание собственно кода. Если до того, как я это увидел, у меня еще были некоторые сомнения насчет своих программистских неспособностей, теперь они развеялись окончательно.

Однажды я прочел книгу по пользованию «Фотошопом», где говорилось, что тот, кто не учится работать с этим редактором клавишами, а тыцает в команды мышкой, не имеет никаких шансов на выживание в скоротечном бизнесе редактирования изображений. Сэкономленные доли секунды в пересчете на каждое действие проводят границу между успехом и неудачей.

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

Comments

[dimrub.livejournal.com]

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

Это как спорт высших достижений

[schegloff.livejournal.com]

Спортсмен из олимпийского чемпиона хороший. А вот работник...

[potan.livejournal.com]

Ни когда не умел быстро въезжать в задачу и выдавать нагора результат. Да и не помню, что бы в индустрии это тредовалось (кроме собеседований :-)).

[fat-crocodile.livejournal.com]

плюсую к коллегам.
как говорил мой дедушка, спешка уместна при ловле блох.

да и вообще какие-то алгоритмы программировать приходится довольно редко, обычно задача так не стоит

[pivovaroffs.livejournal.com]

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

Вот такого руководителя не хотел бы:)

[optimist-09.livejournal.com]

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

Они же олимпийцы!

[optimist-09.livejournal.com]

КАк программист (экс)и преподаватель скажу:
- их же тренируют и, скорее всего, они уже
хотя бы частично этот алгоритм делали,
- возможно у них были заготовки.
Вот так вот :)
Не огорчайтесь ::))

[alex-bykov.livejournal.com]

Именно. Поддерживаю оратора. Есть стандартные наработки + умение распознать в произвольной формулировке стандарт.

[stoshagownozad.livejournal.com]

я тоже читала такое про переводческие программы. дескать, кто мышкой кликает, тот лох и тормоз.

ну, я не знаю, у меня скорость работы примерно 666 (шутка и не шутка, но в среднем от 600 до 670) слов перевода в час с мышкой. Скорость, вообще говоря, неплохая, если судить по итоговым результатам. "Норма" примерно вдвое ниже. Уж я не знаю, сколько слов в час можно выгадать, не пользуясь мышью, тем более, что надо ещё потратить часть ценного мозга на запоминание комбинаций клавиш. Я клавиатурой только в Дежа Вю пользуюсь и в Мемо (потому что там не предусмотрено почти никакх мышьих вариантов), а вот как продуктивно работать в традосе, регулярно нажимая по две-три клавиши служебных - ума не приложу.

[aghartha.livejournal.com]

Прошу прощения у хозяина журнала за оффтоп; а также у Вас, если окажется, что этот комментарий Вам покажется лишним. Но команда "Set/Close Next Open/Get" работает по нажатию ALT и "серый плюсик", а команда "Copy Source" по - ALT и Insert. И они действительно очень удобные и экономят время при работе на "большом" компьютере. На ноутбуке первой комбинации очень не хватает :-/ особенно в "полевых" условиях, без мышки.

[http://users.livejournal.com/_winnie/]

А лобовое решение тут прокатывает? Перебрать все подмножества, благо для n < 80 их не больше четырёх штук. А перебирвать подмножества это то что топ-кодеры действительно делали 1000 раз на тренировках.

В реальном программирование такого не надо, там действительно адекватней пример выше - в системе из миллиона строк найти место и починить.

А сложность алгоритмов - сильно меньше, чем их подгонка под реальные человеческие требования, и чаще всего эти алгоритмы уже сидят готовые внутри баз данных или стека TCP/IP.

[fregimus.livejournal.com]

Нет, их число растет экспоненциально от количества знаков в заданном числе, как 2^k. Для числа 123 их уже 8. Перебор не прокатывает. Все три решения были основаны на признаках делимости, как и мое.

[aamonster.livejournal.com]

Что-то сдается мне, что несколько абзацев текста с примерами понять легче, чем вашу формулировку. Что такое "булеана множество" - я не вполне понимаю... К примеру, сколько элементов в этом множестве для числа 33?
А так - вроде данная задачка решается очень быстро, если сразу вспомнить признак делимости на 9 и сообразить, сколько раз каждая цифра войдет в сумму. Ответ n*trunc(log10(n)+1) mod 9 - верный? Хотя за полторы минуты я бы его наверняка не выдал, даже если бы сразу понял условие.

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

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

[dskrvk.livejournal.com]

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

[jakobz.livejournal.com]

Я работал приличное время в допечатной подготовке. В фотошопе, в частности. Там - да, там заучиваешь все нужные шоткаты, врубаешь fullscreen, и давай какие-нибудь фотки чистить и вытравливать. Чтобы это кормило, надо делать все весьма шустро.

Теперь я работаю программистом. Конкретно мне все эти шоткаты и мега-скорость не так важны.

Возможно если клепать сайты на потоке и этим жить - там надо.

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

Мне кажется что топкодер - именно про однообразные задачи. Я его считаю задротством и не люблю.

[calcin.livejournal.com]

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

Для данной задачи:
mod 9 взято для того, чтобы найти не сумму по модулю всех чисел, а сумму по модулю всех цифр этих чисел (10^n всегда даёт в остатке 1 при делении на 9).

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

Кстати, я не очень понял. А что, ограничения на числа нет? Допустим, в вашем примере число 3333333 даёт множество S(3333333) = {'3'}, соответственно, оно также изоморфно подмножеству S(123).

[fregimus.livejournal.com]

Множество цифр числа, { 3, 3, 3, 3, 3, 3, 3 } в данном случае. Это разные тройки. Наверное, я не очень хорошо переформулировал задачу.

[rwalk.livejournal.com]

Этот пример все-таки не столько программистский, сколько математический. Терпеть не могу олимпиадные задачи, но тут думать действительно долго не надо. У меня другой вопрос к программистам - будет ли для них существенно отличаться время написания соответствующего кода от времени написания математиком формулы (a₁+...+a_k)2^n-1 (mod 9)=n2^{n-1 (mod 6)} (mod 9)? И при чем тут 10⁸⁰?

[janatem.livejournal.com]

Согласен, что это чисто математическая задача. У меня получился такой же ответ за несколько минут (только у вас опечатка — справа от знака равенства n используется как длина числа и как само число).

Даже если забыть про теорему Ферма или про функцию Эйлера, всё равно записанное в лоб выражение N*2^(n-1) (mod 9) вычисляется мгновенно для чисел, занимающих единицы байтов в разумном представлении.

[http://users.livejournal.com/_aristeo/]

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

[rombell.livejournal.com]

Водитель такси и гонщик формулы-1.
Гонщик может проехать гораздо быстрее, но только в строго отведённых местах. Таксист же знает в своём городе закоулки, срезы, объезды, умеет договариваться с гайцами, усмирять клиентов, может отремонтировать машину (хотя бы знает куда ехать) и т.п.
Совсем другие навыки и другие знания.

[gadyuka.livejournal.com]

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

[kvakosavrus-q.livejournal.com]

Спешка хороша на соревнованиях и при ловле блох
В реальной работе требуются совершенно другие навыки

[Исенбаев Владислав (from livejournal.com)]

На topcoder'е есть три градации сложности: на 250, 500 и 1000 баллов.

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

Задачи на 500 уже сложнее, на них может уйти 10-30 минут и далеко не все участники умеют их решать. Среди них попадаются интересные идейные задачи, но ~70% все еще достаточно стандартны.

Задачи на 1000 обычно занимают 30-60 минут, среди них почти не бывает стандартных и они по духу близки к олимпиадным задачам по математике, с уклоном в CS. Очень малая доля участников умеет стабильно решать задачи этого уровня и это умение очень трудно "натренировать", в отличие от 250 и 500


Вообще, задачи на topcoder нечасто бывают задачи со сложной реализационной частью и почти не бывают чисто реализационными или на стандартные алгоритмы, в отличие от задач ACM. Есть еще некоторые форматы соревнований, со своей спецификой задач. Если

[Исенбаев Владислав (from livejournal.com)]

У упомянутой задачи кстати есть простое решение, работающее для любого модуля p, не только для 9

[fregimus.livejournal.com]

Вот это зубодробительно! Не подсказывайте, буду думать!

[erofeich.livejournal.com]

Совершенно лишний навык для программиста, скажем так, работающего на моем месте и в окрестностях.
Я могу себе представить, точнее даже знаю место где сложные задачи могут возникать если не каждый день, то хотя бы регулярно. Если сделать громадное допущение и представить что завтра все такие места раздулись до размеров, ну не знаю там, майкрософта и посадили себе в штат по олимпиаднику, то даже в этом случае, я боюсь, они не смогут обеспечить его подобными задачами на 8 часов в день и 5 дней в неделю.
Лично в моей практике таких случаев не случалось вообще. То есть я сталкиваюсь со сложными задачами, но они скорее о технологическом, или человеческом факторе.

[fdo-eq.livejournal.com]

Для задачи, обозначенной в первой фразе, рекомендую познакомиться с ресурсом "проект Эйлер": http://projecteuler.net/

[fregimus.livejournal.com]

Спасибо! Я знаю его, и тоже о нем думал. И, пожалуй, оттуда задачи и возьму.

[sharpc.livejournal.com]

250 это способность быстро комбинировать несложные абстракции (скажем, штуки 3: арифметика остатков, свойства булеана, разбиение на цифры) и безбажно переносить их в код — ни о каких классах задач не может быть и речи. 500 и 1000 действительно требуют понимания довольно сложных вещей, которые встречаются на практике не часто, однако и стабильно решает их совсем немного человек: в отношении их в индустрии ценнее, скорее, стремление к совершенству и изрядно прокачанный общеаналитический скилл, чем конкретный опыт.

Локализация бага в обычном промышленном коде, как правило, работа скорее механическая, а вот локализация бага в чужом решении задачи на TopCoder (challenge phase) — действительно нетривиальная задача, тренировка в решении которой заметно улучшает и чтение (подсознательную интерпретацию) обычного кода, и качество его написания (т.к. приучает делать предсказания относительно возможных ошибок на этапе продумывания/написания).

Читая комментарий Исенбаева о тривиальных и стандартных задачах, учитывайте, что разница между средним читателем и ним примерно как между средним читателем и Теренсом Тао :)

Да, полезно. Нет, не обязательно.

[pphantom.livejournal.com]

Сразу оговорюсь, что я не совсем инженер-программист, но писать приходится часто и много...

Нет, подобные навыки практически не востребованы. Более того, как показывает опыт, в некотором смысле они даже вредны (многие слишком увлекаются тренировками к этому виду спорта, полагая, что тем самым научатся программированию).

[fregimus.livejournal.com]

Так и я тоже код-то пишу ежедневно, и думал, что нормально. А вот…

[captainl.livejournal.com]

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

Кстати, Этюды для программистов Уэзерелла не пробовали?

[fregimus.livejournal.com]

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

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

[racoonbear.livejournal.com]

таких задач в год даже в математическом проекте штук 5 максимум будет.
Так что совершенно некритично. Время уйдёт на другое.

[superhimik.livejournal.com]

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