?

Log in

No account? Create an account

Previous Entry | Next Entry

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

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

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

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

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

Tags:

Comments

pivovaroffs
Dec. 26th, 2011 09:18 am (UTC)
Не знаю, может где и востребовано - но как бывший программист и нынешний их руководитель, считаю куда более полезным другое "экстремальное" умение:
за несколько десятков минут разобрать, где в системе размером в миллион строк кода находится нужный кусок, почему он падает, и исправить его, не сломав ничего вокруг.
Опять же, такие задачи при нормально поставленных процессах скорее исключение - но они встречаются, в отличие от описанной в посте.
optimist_09
Dec. 26th, 2011 09:22 am (UTC)
Вот такого руководителя не хотел бы:)
Господин Пиваваров, извините,
а где написанные к этому коду инструкции и схемы?
Зачем мучать программеров и заставлять за несколько десятков минут врубаться в забытые программы?
Хороший руководитель имеет необходимую документацию.
Всего доброго, читайте мат.часть и с Новым Годом!
pivovaroffs
Dec. 26th, 2011 09:35 am (UTC)
Re: Вот такого руководителя не хотел бы:)
"Опять же, такие задачи при нормально поставленных процессах скорее исключение". Но исключения бывают.
calcin
Dec. 26th, 2011 10:22 am (UTC)
Re: Вот такого руководителя не хотел бы:)
Ну, для того чтобы изучить "правильную" документацию на код в 1 миллион строк, нужно уж не меньше нескольких недель.
И по-настоящему можно вжиться в код, только поработав с ним эти несколько недель.
А как заставить человека поработать с кодом несколько недель? Только писать что-то своё или править ошибки.

Я сам несколько раз сталкивался с такими задачами: совершенно посторонний, не мой проект, большой, документация есть - падает. Выяснить почему, как исправить и/или обойти. При достаточной мотивации удалось решить.
racoonbear
Dec. 28th, 2011 07:45 am (UTC)
Re: Вот такого руководителя не хотел бы:)
Наивный вы )
Есть естественная деградация системы. Представьте себе продукт с 20-летней историей, который 10 лет девелопился, а потом 10 лет поддерживался. К концу там родная мать ничего не узнает - потому что денег не выделили на рефакторинг документации.
optimist_09
Dec. 28th, 2011 08:00 am (UTC)
Re: Вот такого руководителя не хотел бы:)
Вот об этом и речь - плохой руководитель,
впрочем, это конечно, согласен, устаревшая технология,
НО бизнес-процессы поддерживают доработки, или хотя бы должны поддерживать.
С новым Годом!